Requirements Engineering

(요구사항과 명세서) Part 2. Requirements and Specification Establishing what the customer requires from a software system (S/W 시스템에서 고객이 요구하는 것이 무엇인가를 설정한다) Contents 4.Requirements Engineering (요구 공학) 5.Requirements Analysis (요구 분석) 6.System Models (시스템 모델) 7.Requirements Definition and Specification(요구사항 정의 및 명세서) 8.Software Prototyping (소프트웨어 시제품화) 9.Formal Specification (정형적 명세화) 10.Algebraic Specifications (대수적 명세화) 11.Model-based Specification(모델기반 명세서) Chapter 4 - Slide 1

제2부 요구사항과 명세서 Chapter 4. Requirements Engineering Objectives To introduce the notion of requirements engineering (요구공학 용어 소개) To explain why requirements at different levels of detail are needed (요구사항이 여러 레벨로 명세 되어야 하는 이유) To describe how the system requirements document may be organized (시스템 요구사항 문서가 어떻게 구성되어야 하는가) To describe the requirements validation process (요구사항 확인과정) To explain why requirements evolve during the lifetime of a system (시스템 생명주기 기간 내에서 요구사항이 진화되는 이유) Contents 4.1 The requirements engineering process (요구공학 과정) 4.2 The software requirements document(소프트웨어 요구사항 문서) 4.3 Requirements validation (요구사항 확인) 4.4 Requirements evolution(요구사항 진화) (요구공학) Chapter 4 - Slide 2

Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed (시스템으로부터 고객이 요구하는 서비스와 시스템 운용과 개발 도중의 제약조건들을 설정하는 과정) Requirements may be functional or non-functional (요구사항 기능적 요구사항과 비기능적 요구사항으로 분류) Functional requirements describe system services or functions (기능적 요구사항 시스템 서비스나 기능들을 설명) Non-functional requirements is a constraint on the system or on the development process (비기능적 요구사항 시스템상의 제약조건이나 개발과정상의 제약조건) 공학(Engineering) 개발하려는 시스템의 정의를 체계적으로 수행하는 process. Chapter 4 - Slide 3

제2부 요구사항과 명세서 / 4장 요구공학 What is a requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification (서비스나 시스템 제약조건의 고수준 추상문장에서부터 수학적 상세기능 명세서까지의 범주) This is inevitable as requirements may serve a dual function (필연적으로 요구사항은 2가지 기능의 역할 담당) (1) May be the basis for a bid for a contract - therefore must be open to interpretation (계약의 기본이 될 수 있다 해석상의 오해가 없을 것) (2) May be the basis for the contract itself - therefore must be defined in detail (계약서 자체의 기준이 될 수 있다 상세하게 정의될 것) - Both these statements may be called requirements (이들 2 문장이 요구사항이 된다) Chapter 4 - Slide 4

Requirements definition/specification (요구사항 정의/명세서) (1) Requirements definition (요구사항 정의) 요구사항을 추상적으로 설명 A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers (2) Requirements specification (요구 명세서) 요구사항을 상세하게 설명: 기능명세서 라 칭한다 A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor (3) Software specification (S/W 명세서) 요구공학과 설계 행위를 연결 A detailed software description which can serve as a basis for a design or implementation. Written for developers Chapter 4 - Slide 5

Definitions and specifications Requirements definition (요구사항 정의) 1. The software must provide a means of representing and accessing external files created by other tools. Requirements specification (요구 명세) 1.1 The user should be provided with facilities to define the type of external files. 1.2 Each external file type may have an associated tool which may be applied to the file. 1.3 Each external file type may be represented as a specific icon on the user s display. 1.4 Facilities should be provided for the icon representing an external file type to be defined by the user. 1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the represented by the selected icon. [그림 4.1] Definitions and specifications (요구사항 정의 및 요구명세서) Chapter 4 - Slide 6

Requirements readers Requirements definition -. 관리적 측면의 목표. 시스템 상세지식이 필요 없는 고객, 계약자, 관리자가 이해 Requirements specification -. 고급기술자의 시탶, 프로젝트 관리자용 Software specification -. 구현 위주의 문서 Client managers System end-users Client engineers Contractor managers System architects System end-users Client engineers System architects Software developers Client engineers (perhaps) System architects Software developers [그림 4.2] Requirements readers (명세의 종류에 따른 관련자들) Chapter 4 - Slide 7

Wicked problems (문제점) Most large software systems address wicked problems (대부분의 대형 시스템은 문제점을 내포) Problems which are so complex that they can never be fully understood and where understanding develops during the system development (문제점이 너무 복잡하여 완벽한 이해가 어렵고, 시스템 개발 도중에 이해되는 경향) Therefore, requirements are normally both incomplete and inconsistent (요구사항 불완전하고 일관성이 없음) Chapter 4 - Slide 8

Reasons for inconsistency (일관성 결여의 이유) (1) Large software systems must improve the current situation. (대형 S/W 시스템은 현재의 상황을 개선하기 위해 작성) It is hard to anticipate the effects that the new system will have on the organization (현조직에서 신시스템이 어떤 영향을 미칠지 예상키 어려움) (2) Different users have different requirements and priorities. (서로 다른 사용자들은 다양한 요구사항과 우선순위를 가짐) There is a constantly shifting compromise in the requirements (요구사항 중에서 상호 이율 배반적인 사항이 존재) (3) System end-users and organizations who pay for the system have different requirements (시스템 비용을 지불하는 최종 사용자와 조직들은 서로 다른 요구사항이 있을 수 있음) (4) Prototyping is often required to clarify requirements (요구사항을 명확히 하기 위해 시제품이 필요) Chapter 4 - Slide 9

4.1 The requirements engineering process - 요구사항 정의와 요구사항 명세서를 생성하는 프로세스 1) Feasibility study (실행계획 연구) - Find out if the current user needs be satisfied given the available technology and budget? (주어진 기술과 예산을 현사용자 수요에 만족되는지를 결정) 2) Requirements analysis (요구사항 분석) - Find out what system stakeholders require from the system (기존 시스템 조사, 시스템 요구사항 생성) 3) Requirements definition (요구사항 정의) - Define the requirements in a form understandable to the customer (고객이 이해할 수 있는 형식으로 요구사항을 정의) 4) Requirements specification (요구 명세서) - Define the requirements in detail (요구사항을 상세하게 정의) (요구공학 프로세스) Chapter 4 - Slide 10

4.1 The requirements engineering process (cont') Feasibility study Feasibility report Requirements analysis System models Requirements document Requir ements definition Definition of requirements Requirements specification Specification of requirements [그림 4.3] The RE process (요구 공학 프로세스) Chapter 4 - Slide 11

4.2 The Software requirements document The requirements document is the official statement of what is required of the system developers (시스템 개발 담당이 무엇을 개발해야 하는가에 대한 공식적인 문서) Should include both a definition and a specification of requirements (요구사항 정의와 요구명세서 포함) It is NOT a design document. (설계문서가 아님) As far as possible, it should set of WHAT the system should do rather than HOW it should do it (시스템이 어떻게 개발되어야 하는가가(방법) 아니고, 무엇을 개발해야 하는가(개발 대상)에 대한 문서) (S/W 요구사항 문서) Chapter 4 - Slide 12

4.2 The requirements document (cont') Requirements document requirements (요구사항 문서의 요구조건) - Heninger가 S/W 요구문서가 구비해야 할 6가지 조건을 제시 1) Specify external system behavior (시스템의 외부행위 규정) 2) Specify implementation constraints (구현상의 제약조건 규정) 3) Easy to change (변경 용이) 4) Serve as reference tool for maintenance (유지관리를 위한 참조도구 제공) 5) Record forethought about the life cycle of the system i.e. predict changes (시스템 생명주기에 대한 예상) 6) Characterize responses to unexpected events (예측하지 않았던 사태에 대한 대처 방안) - 요구문서는 다음 정보를 부록으로 처리할 것 (1) Hardware (2) Database 요구 (3) Index Chapter 4 - Slide 13

4.2 The requirements document (cont') Requirements document structure (요구명세 문서의 구조) 1)Introduction (개요) - Describe need for the system and how it fits with business objectives 2)Glossary (용어) - Define technical terms used 3)System models (시스템 모델) - Define models showing system components and relationships 4)Functional requirements definition (기능적 요구사항 정의) - Describe the services to be provided - 다음 페이지 계속 - Chapter 4 - Slide 14

4.2 The requirements document (cont') Requirements document structure 5)Non-functional requirements definition (비기능적 요구사항 정의) 1. Define constraints on the system and the development process 6)System evolution (시스템 진화) 1. Define fundamental assumptions on which the system is based and anticipated changes 7)Requirements specification (요구 명세) 1. Detailed specification of functional requirements 8)Appendices (부록) 1. System hardware platform description 2. Database requirements (as an ER model perhaps) 9)Index (색인) Chapter 4 - Slide 15

4.3 Requirements validation (요구사항 확인) Concerned with demonstrating that the requirements define the system that the customer really wants (요구사항들이 고객이 실제로 원하는 시스템을 정의하고 있는지를 알아내는 것) Requirements error costs are high so validation is very important (요구사항 오류 수정은 고비용이므로 확인과정은 중요함) Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error (제품 출하 후 요구사항 오류수정 비용은 구현 시 오류수정 비용의 100배 정도) Prototyping (discussed in Chapter 8) is an important technique of requirements validation (시제품 방법은 요구사항 확인의 중요한 기법) Chapter 4 - Slide 16

4.3 Requirements validation (cont') Requirements checking (요구사항 검토) Validity. (타당성)» Does the system provide the functions which best support the customer s needs? (시스템이 고객의 요구를 최상으로 지원하는 기능을 제공하는가) Consistency. (일관성)» Are there any requirements conflicts? (요구사항 중 상충되는 부분이 있는가) Completeness. (완전성)» Are all functions required by the customer included? (고객이 요구하는 모든 기능이 있는가) Realism. (현실성)» Can the requirements be implemented given available budget and technology (주어진 예산과 기술 내에서 요구사항 구현이 가능한가) Chapter 4 - Slide 17

4.3 Requirements validation (cont') Requirements reviews (요구사항 재검토) Regular reviews should be held while the requirements definition is being formulated (정규 검토는 요구사항 정의가 공식화되는 도중에 이루어져야 한다) Both client and contractor staff should be involved in reviews (재검토에는 고객과 계약자 쌍방이 참여할 것) Reviews may be formal (with completed documents) or informal. (재검토는 공식적일 수도, 비공식적일 수도 있다) Good communications between developers, customers and users can resolve problems at an early stage (개발담당자, 고객, 사용자들간의 원활한 의사소통으로 시작단계에서 문제점을 해결할 수 있다) Chapter 4 - Slide 18

4.3 Requirements validation (cont') Review checks (확인 점검 항목) Verifiability. (검증가능성)» Is the requirement realistically testable? (요구사항이 현실적으로 시험 가능한가) Comprehensibility. (이해성)» Is the requirement properly understood? (적절하게 이해할 수 있는가) Traceability. (추적성)» Is the origin of the requirement clearly stated? (요구사항의 원 취지가 명확하게 정의되었는가) Adaptability. (적응성)» Can the requirement be changed without a large impact on other requirements? (요구사항 변경이 타 요구사항에 큰 충격 없이 변경 가능한가) Chapter 4 - Slide 19

4.3 Requirements validation (cont') Requirements in a formal language Requirements problem report Requirements processor Requirements analyser Requir ements database [그림 4.5] Automated consistency checking (요구사항 일관성 자동 점검) Chapter 4 - Slide 20

4.4 Requirements evolution (요구사항 진화) Requirements always evolve as a better understanding of user needs is developed and as the organization s objectives change (조직의 목적 변화와 사용자 요구의 발전적 이해에 따라, 요구사항은 항상 진화해야 한다) It is essential to plan for change in the requirements as the system is being developed and used (시스템이 개발되고 이용되는 동안, 요구사항 변화에 대처할 수 있는 계획이 필수적이다) Chapter 4 - Slide 21

4.4 Requirements evolution (cont') Initial understanding of problem Changed understanding of problem Initial requirements Changed requir ements [그림 4.6] Requirements evolution (요구사항 진화) Time Chapter 4 - Slide 22

4.4 Requirements evolution (cont') Requirements classes (요구사항 분류) (1) Enduring requirements. (지속적 요구사항) Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors, nurses, etc. (고객 조직의 핵심활동에서 유도된 안정된 요구사항 (병원에는 항상 의사와 간호사가 있다)) May be derived from domain models (영역모델에서 유도 가능) (2) Volatile requirements. (임시적 요구사항) Requirements which change during development or when the system is in use. (개발시/사용시에 변화하는 요구사항) In a hospital, requirements derived from health-care policy (병원에서의, 건강증진 사업 정책) - 4개의 종류로 재분류 (그림 4.7 참조) Chapter 4 - Slide 23

4.4 Requirements evolution (cont') Classification of volatile requirements (임시적 요구사항의 분류) 1) Mutable requirements (순변성 요구사항) - Requirements that change due to the system s environment (시스템 환경 변화에 의한 변경) 2) Emergent requirements (긴급 요구사항) - Requirements that emerge as understanding of the system develops (시스템 개발 도중 돌발한 요구사항) 3) Consequential requirements (필연적 요구사항) - Requirements that result from the introduction of the computer system (컴퓨터 시스템 도입에 따른 요구사항) 4) Compatibility requirements (호환성 요구사항) - Requirements that depend on other systems or organizational processes (타 시스템과 조직의 업무 절차에 관련된 요구사항) Chapter 4 - Slide 24

4.4 Requirements evolution (cont') Requirements document changes (요구사항 문서의 변경) The requirements document should be organized so that requirements changes can be made without extensive rewriting (요구사항 문서가 조직적으로 구성되어 요구사항 변경에도 대규모의 재작성 사태가 없을 것) External references should be minimized and the document sections should be as modular as possible (외부 참조는 최소화, 문서의 절은 모듈화 할 것) Changes are easiest when the document is electronic. (문서가 전자화될 때 변경 용이) Lack of standards for electronic documents make this difficult (전자문서의 표준화가 부족하여 애로사항이 있음) Chapter 4 - Slide 25

4.4 Requirements evolution (cont') Requirements change Requirements document V1 Requirements change Requirements document V1 Requirements document V2 System implementation V1 System implementation V2 System implementation V1 System implementation V2 Requirements and system inconsistent (일관성 없는) Requirements and system consistent (일관성) [그림 4.8] Un-Controlled and Controlled requirements evolution (제어불가, 제어 가능 요구사항 진화) Chapter 4 - Slide 26

Key points It is very difficult to formulate a complete and consistent requirements specification (요구사항을, 완전하고 일관성 있도록 정형화 하는 것은 매우 어려움) A requirements definition, a requirements specification and a software specification are ways of specifying software for different types of reader (요구사항 정의, 요구 명세서, 소프트웨어 명세서는 다른 관점에서 S/W를 설명하는 방법) The requirements document is a description for customers and developers (요구사항 문서는 고객과 개발자를 위한 것) Chapter 4 - Slide 27

Key points Requirements errors are usually very expensive to correct after system delivery (요구사항의 오류는 시스템 출하 후 수정하기에 비용이 많이 소요) Reviews involving client and contractor staff are used to validate the system requirements (고객과 계약자가 함께 참여한 검사는 시스템의 요구사항 확인에 사용됨) Stable requirements are related to core activities of the customer for the software (지속적인 요구사항은 고객의 핵심 업무와 관련이 있음) Volatile requirements are dependent on the context of use of the system (잘 변하는 요구사항은 시스템의 사용 환경에 의해 결정됨) Chapter 4 - Slide 28