ch 4_Requirements Engine
Requirements Engineering
소프트웨어 개발에 있어서 무엇이 개발되어야 하는지를 결정하는 공정을 Requirements Engineering이라고 부른다.
- 고객이 서비스를 구축하는 과정
- 시스템 요구사항은 요구 사항 엔지니어링 프로세스 중에 생성되는 시스템 서비스 및 제약 조건에 대한 설명입니다.
Requirements abstraction
- 추상적인 방식으로 요구사항을 정의
- 여러 계약자가 계약에 대해 입찰할 수 있도록 작성
- 계약자는 클라이언트가 소프트웨어의 작업을 이해하고 검증할 수 있도록 클라이언트에 대한 시스템 정의를 자세히 작성
- 시스템에 대한 요구사항 문서
Types of requirement
- User requirements
- 사용자를 위해 작성, natural language 로 된 설명과 operational constraints에 대한 다이어그램
- System requirementsclient 와 contractor 간 계약의 일부가 될 수도 있다.
- 시스템의 기능, 서비스 및 operational constraints, 구현 사항을 자세하게 설명하는 구조화된 문서
requirements specification
Functional and non-Functional requirements
정산하기나 모임 관리처럼 시스템이 갖고 있는 기능은 기능적 요구사항이라하고 정산하는 속도, 시스템의 메모리 사용량처럼 기능은 아니나 측정해서 제한을 두고 시스템이 만족하도록 해야 하는 것은 비기능적 요구사항이라 한다.
- functional / non-functional example
- functional requirements
**non-functional requirements(성능 요구사항)**
Functional requirements(기능적 요구사항)
시스템에 주어지는 특정 입력에 대한 시스템이 산출하는 출력을 통해 정의된다.
- 시스템은 어떤 서비스를 제공하는가
- 어떤 입력이 주어졌을 때 어떻게 반응하는가
- 어떤 상황에서 어떻게 행동하는가
- 시스템이 무엇을 해야 하는지 설명 (기능 or 시스템 서비스)
기능적 사용자 요구사항 : 사용자에 의해 이해 될 수 있는 추상적 방법으로 설명
기능석 시스템 요구사항 : 시스템 기능, 입력, 출력, 예외사항 등
requirements imprecision
기능적 요구사항은 정확하게 명시
모호한 요구사항은 기재하지 않는다.
completeness and consistency
요구사항은 완전하고 일관되게 작성
- complete
- 필요한 모든 facilitie required에 대한 설명이 포함되어야함
- consistent
- 설명에 conflicts나 descriptions가 없어야 한다 .
non-Functional requirements(비 기능적 요구사항)
소프트웨어 기능들에 대한 조건(시스템의 속성)과 제약사항(reliability, response time, storage requirements)에 관한 요구사항
- 기능적 요구사항보다 더 결정적인 부분이 될 수 있다 -> why? 이부분이 충족되지 않으면 시스템 이용가치 X
- 각각의 특징과 서비스보다는 전체적인 시스템에 적용
non-Functional classifications
- Product requirements
- 제공된 product가 반드시 특정 방식(execution speed, reliability)으로 작동된다.
- Organisational requirements
- organisational policies 와 procedures 의 결과인 요구사항(process standards used, implementation requirements)
- External requirements
- 시스템 및 개발 프로세스의 외부 요인에서 발생하는 요구사항(interoperability, legislative requirements)
goals and requirements
- goalex) 시스템은 의료진이 쉽게 사용할 수 있고, 실수를 최소화 할 수 있도록 구성
- 사용자의 ease of use(용이성)과 같은 general intention
- verifiable non-functional requirementex) 의료진은 4시간 교육 후 모든 시스템 기능을 사용할 수 있음. 교육 후 사용자의 평균 오류 수는 사용 시간당 2번 이상이면 안됨(테스트 가능한 비 기능 요구사항)
- statement using some measure that can be objectively tested
- goals는 사용자의 intentions을 전달하므로 개발자에게 도움이 된다.
specifying nonfunctional requirements(시험! 3개 이상 쓰시오)
Requirements engineering processes
RE(Requirements Engineering)에 사용되는 프로세스는 application domain, people involved(관련자) and organisation developing 에 따라 다르다.
1) 도출(Elicitation)
2) 분석(Analysis)
3) 명세(Specification)
4) 확인(Validation)
elicitaion(요구사항 도출)
stakeholders(이해 관계자) : 최종 사용자, 관리자, 유지관리에 관련된 엔지니어, 도메인 전문가, 노동조합 등이 포함된다.
stakeholders는 application domain, provided service, required system performance, hardware constraints 등을 알아야 한다.
- discovery(발견)도메인 요구사항도 이 단계에서 발견된다.
- interacting with stakeholders and 요구사항 발견
- classification and organization(분류 및 구성)
- 관련 요구사항을 그룹화하고 일관성있는(coherent) cluster 로 구성한다.
- prioritization and negotiation(우선 순위 지정 및 협상)
- 요구사항의 우선 순위를 지정하고 요구사항 충돌을 해결한다
- specification(사양)
- spiral 방식으로 요구사항을 문서화하고 다음 단계로 진입한다.
→ Problems of elicitation
- stackholder는 자신의 요구사항을 명확하게 알지 못하고, 요구사항을 자신의 용어로 표현한다.
- stackholder마다 different conflicting requirements
- organisational and political factors 가 요구사항에 영향을 미칠 수 있다.
- requirements change during the analysis process
- new stackholder emerge and business environment may change
→ discovery
기존 시스템에 대한 정보를 수집하고, 이 정보에서 사용자 및 시스템 요구사항을 추출(distilling)하는 프로세스
- interviewing
- ethnography
- scenarios
specification(사양)
요구사항 문서에 사용자 및 시스템 요구사항을 작성하는 프로세스
- User requirements
- technical background가 없는 최종 사용자와 client가 이해할 수 있어야 한다.
- System requirements개발 계약의 일부로 사용할 수 있다 .⇒ System requirements soecufication 작성방법
- complete as possible 하게 작성하는 것이 중요
- 더 자세하고 많은 기술정보를 포함한 요구사항
requirements and design
→ Requirements : 시스템이 수행해야 하는 작업을 명시
→ design : 이를 수행하는 방법을 설명
requirements and design are inseparable
- system architecture는 요구사항을 구성하도록 설계
- system은 설계 요구사항을 생성하는 다른 시스템과 상호 운용(inter-operate)할 수 있다.
- non-functional requirements를 충족하기 위해 특정 아키텍쳐 사용 → 도메인 요구사항일 수도 있다.
- consequence of a reulatory requirement(규제 요건의 결과일 수도 있다. )
Natural language specification
- 요구사항은 diagram과 table을 포함한 natural language로 작성.
- 직관적(intuitive)이고 보편적(universal)으로 작성하여 사용자와 고객이 요구사항을 이해할 수 있도록 한다.
Natural language Problem
- Lack of clarity(명료성 부족)
- 문서를 정밀하게 만들면 어려워진다. ⇒ Precision is difficult
- Requirements confusion(혼동)
- functional or non-functional 이 섞이는 경향이 있다.
- Requirements amalgamation(통합)
- 여러 다른 요구사항이 함께 표현될 수 있다 .
Guidelines for writing requirements
- standard format을 만들어 모든 요구사항에 적용
- 일관된 방식으로 언어를 사용
- 텍스트 강조 표시를 사용하여 요구사항의 핵심 부분(identify key part)을 식별
- 컴퓨터 전문용어 사용을 자제(avoid the use of computer jargon)
- 요구사항이 필요한 이유에 대한 설명 작성
Structured specifications
작성자의 자유가 제한되고, 요구사항이 표준 방식으로 작성
임베디드 제어 시스템에 적절
비즈니스 시스템 요구사항을 작성하기에는 힘들다(too rigid)
Form-based specifications
- Definition of the function or entity.
- Description of inputs and where they come from.
- Description of outputs and where they go to.
- Information about the information needed for the computation and other entities used.
- Description of the action to be taken.
- Pre and post conditions (if appropriate).
- The side effects (if any) of the function.
Tabular specification(표 사양)
- used to supplement(보완) natural language
- possible alternative courses of action을 정의해야 할 때 특히 유용
software requirements document
- official statement 소프트웨어 요구사항은 시스템 개발자에게 필요한 사항에 대한 설명
- 사용자 요구사항의 정의 + 시스템 요구사항의 사양
- 시스템이 수행해야하는 작업을 위주로 설정한다.
Requirements document variability(변동성)
- 시스템 유형 및 개발 접근 방식에 따라 요구사항 문서의 정보를 다르게 작성
- incrementally developed systems 은 요구사항 문서에 세부사항이 적다
- IEEE standard : 요구사항 문서 표준 ⇒ 대규모 시스템 엔지니어링 프로젝트에 적용
structure of requirements documents(요구사항 문서의 구조)
- preface(머릿말)
- introduction
- glossary(용어사전)
- user requirements definition
- system archetecture
- system requireemnts specification
- system models
- →object models, data-flow models, semantic data models
- system evolution
- appendices
- index
Requirements validation
고객이 진정으로 원하는 시스템을 정의한다는 것을 입증
Requirements checking!
- Validity : 고객의 요구를 잘 지원하는가?
- Consistency : 요구사항 충돌이 있는가?
- Completeness : 고객이 요구하는 모든 기능이 포함되어 있는가?
- Realism : 가용 예산과 기술 내에서 요구사항을 구현할 수 있는가?
- Verifiability : 요구사항을 확인할 수 있는가?
Requirements validation techniques(검증 기술)
- Requirements reviews
- Prototyping
- Test-case generation
Review checks
- Verifiability(검증 가능성) → 요구사항을 현실적으로 테스트할 수 있는가?
- Comprehensibility(이해도) → 요구사항을 제대로 이해하고 있는가?
- Traceability(추적성) → 요구사항의 출처가 명확하게 명시되어 있는가?
- Adaptability(적응력) → 요구사항 변경 시 다른 요구사항에 영향을 주는가?
Requirements change
시스템의 비즈니스 및 기술 환경은 설치 후 항상 변경될 수 있다.
- 새로운 하드웨어가 도입될 수 있다.
- organization and budgetary constraints(제약) 으로 인해 최종 사용자 요구사항과 충돌할 수 있으며, 사용자 지원을 위해 새로운 기능을 추가해야 할 수 있다.
- 대규모 시스템에서 사용자가 서로 다른 요구사항과 우선 순위를 갖고 있어 충돌하거나 모순될 수 있다.
Requirements evolution
Requirements management
requirements engineering 및 시스템 개발 과정에서 변화하는 요구사항을 관리하는 프로세스
- 요구사항 관리 결정
- Requirements identification(요구사항 식별)
- Change management process(변경 관리 프로세스)
- Traceability policies(추적성 정책)
- Tool Support(도구지원)
- 요구사항 변경 수락 여부 결정
- 문제점 분석 및 사양 변경
- 변경 분석 및 비용 계산
- 구현 변경
Key point!
- Requirements for a software system set out what the system should do and define constraints on its operation and implementation.
- 시스템은 운영 및 구현에 대한 제약을 수행하고 정의해야 된다
- Functional requirements are statements of the services that the system must provide or are descriptions of how some computations must be carried out.
- 기능 요구 사항은 시스템이 제공해야 하는 서비스에 대한 설명이거나 일부 계산이 수행되어야 하는 방법에 대한 설명이다
- Non-functional requirements often constrain the system being developed and the development process being used.
- 비기능 요구사항은 개발 중인 시스템과 사용 중인 개발 프로세스를 제한하는 경우가 많다
- They often relate to the emergent properties of the system and therefore apply to the system as a whole
- 그것들은 종종 시스템 전체에 적용된다
- The requirements engineering process is an iterative process that includes requirements elicitation, specification and validation.
- 요구사항 엔지니어링 프로세스는 요구사항 도출, 사양 및 검증을 포함하는 반복적인 프로세스이다
- Requirements elicitation is an iterative process that can be represented as a spiral of activities – requirements discovery, requirements classification and organization, requirements negotiation and requirements documentation.
- 요구사항 도출은 요구사항 발견, 요구 사항 분류 및 구성, 요구 사항 협상 및 요구 사항 문서화와 같은 일련의 활동으로 나타낼 수 있는 반복적인 프로세스이다
- You can use a range of techniques for requirements elicitation including interviews and ethnography. User stories and scenarios may be used to facilitate discussions.
- 요구사항 도출을 위해 인터뷰 및 민족지학을 포함한 다양한 기술을. 사용할 수 있다. 토론을 용이하게 하기 위해 사용자 스토리와 시나리오를 사용할 수 있다
- Requirements specification is the process of formally documenting the user and system requirements and creating a software requirements document.
- 요구사항 사양은 사용자 및 시스템 요구 사항을 공식적으로 문서화 하고 소프트웨어 요구 사항 문서를 작성하는 프로세스이다.
- The software requirements document is an agreed statement of the system requirements. It should be organized so that both system customers and software developers can use it.
- 소프트웨어 요구 사항 문서는 시스템 요구 사항에 대한 합의된 설명이다. 시스템 고객과 소프트웨어 개발자가 모두 사용할 수 있도록 구성해야 된다
- Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism and verifiability.
- 요구사항 검증은 요구사항의 유효성, 일관성, 완전성, 현실정 및 검증 가능성을 확인하는 프로세스이다
- Business, organizational and technical changes inevitably lead to changes to the requirements for a software system. Requirements management is the process of managing and controlling these changes.
- 사업적, 조직적,기술적 변화 불가피하게 소프트웨어 시스템에 대한 요구 사항의 변경으로 이루어진다. 요구 사항 관리는 이러한 변경 사항을 관리하고 제어하는 프로세스이다
