Goals and Requirements
Non-Functional requirements may be very difficult to state precisely.
- Imprecise requirements may be difficult to verify
- Goals are helpful to developers as they convey the intentions of the system users
일반적으로 비기능 요구사항은 정확하게 언급, 작성하기 매우 힘듭니다. Brain-storming이나 Interview들의 기술들을 이용해서 user requirements를 뽑아내기 때문에 정확하게 정의할 수 없습니다. 이렇게 뽑힌 user requirements들 중 quality attributes들을 Goals이라고 부릅니다. 이는 Non-verifiable NFR로 추상적인 단계의 Quality Attributes입니다.
Goal
- A general intention of the user such as 'ease to ues'
- Often NFR (Quality Attributes)
앞에서 말했듯, 일반적인 NFR들을 Goals라고 부릅니다. 유저가 흔히 '사용하기 쉬워야 해요'라고 말하는 것과 같은 것을 말합니다.
Verifiable Non-Functional Requirements
- A statements using some measure that can be objectively tested
객관적으로 테스트, 검증할 수 있는 NFR을 말합니다. 우리는 다양한 방법으로 user등의 stakeholders들로부터 user requirements를 뽑아냅니다. 그렇게 뽑아낸 user requirements들은 measurable하지 않고, verifiable하지 않기 때문에, Requirement analysis를 통해 measurable, verifiable한 system requirements를 만드는데, Goal같은 Quality Attributes는 Goal Analysis를 통해 verifiable NFR을 만들 수 있습니다. 이는 한 번에 이루어질 수 없고, 여러 번의 반복끝에 만들어집니다.
Example
+ Goal을 보면 easy to use와 같이 measurable하지 않은 요소들이 있습니다. 이를 Goal Analysis를 통해 아래의 verifiable NFR과 같이, 4-hour of training등의 measurable한 요소들이 들어감을 볼 수 있습니다.
+ 이 Goal과 Verifiable NFR은 모두 Software Requirements Specification (SRS)에 들어갑니다.
Goal (Tree) Analysis
Goal Analysis
- Focus on why a system is required
- Express the 'why' as a set of stakeholder goals
- Goal refinement to arrive at specific requirements
- Goal evolution
- Goal hierachies show refinements and alternatives
Goal Analysis는 Goal을 특정한 요구사항, 즉 system requirement로 정제합니다. 그리고 Goal의 계층구조는 Goal이 어떻게 정제되고, 어떤 대체안이 있는지를 보여줍니다.
Goal model visualizes goal analysis
- (Hard) Goal
- Desicribe functions that must be carried out
- FR
- Soft Goal
- Cannot really be fully satisfied such as quality
- NFR (Quality)
Hard Goal은 FR을 말하는 것으로, 어떻게든 만족시켜야지 출시를 할 수 있다는 관점에서 Hard Goal이라는 이름이 붙었습니다. Goal Analysis는 User requirements를 System requirements로 변환하는 방법인데 일반적으로 FR은 use case analysis를 requirements analysis방법으로 사용합니다.
Soft Goal은 NFR, 특히 Quality Attributes를 말하는 것으로 최대한 만족시키는 것이지, 모두 만족시키는 것은 불가능하기 때문에 Soft라는 이름이 붙었습니다.
+ Or를 나타내는 표기법이 따로 있습니다. 특수한 표기가 없다면 And를 의미합니다.
+ Tree의 윗 부분에 있는 것들은 Goal로 Non-Verifiable NFR을 말합니다. 아래에 있는 것들은 Verifiable, Measurable한 NFR을 말합니다. 즉 Tree의 아래로 내려올 수록 refinement가 된다 볼 수 있습니다. 이는 Brain-storming과 같은 방식으로 이루어 지기도 합니다.
Goal Elaboration
- 'Why' questions explore higher goals (context)
- 'How' questions explore lower goals (operations)
- 'How else' questions explore alternatives
'왜', 맥락과 관련된 부분은 높은 단계의 goal입니다. '어떻게', 작동과 관련된 부분은 낮은 단계의 goal입니다. '또 어떻게'는 대안에 관한 부분입니다.
- Relationships between goals
- One goal helps achieve another (+) → 어떤 것이 다른 것에 긍정적인 기여를 하면 +로 표시합니다.
- One goal hurts achievement of another (-) → 어떤 것이 다른 것에 부정적인 기여를 하면 -로 표시합니다.
- ++와 --는 +와 -보다 더 큰 긍정/부정적인 기여를 의미합니다.
+ 아래로 내려갈수록, detail하고 solution과 관련된 (How) 부분이고, 위로 올라올수록, 추상적인 목표 (why) 와 관련된 부분입니다.
+ 이런식으로 모든 Goal에 대해 정리한다면, 어떤 System Requirements가 어떤 Goal에 영향을 미치는지 확인할 수 있고, Analysis하는 관점에서 Quality Attributes를 선택해야 합니다.
Requirements Engineering Processes
The RE process varies widely depending on:
- the application domain
- the software development process applied
- the people/organization developing the requirements
RE는 적용되는 도메인, 적용하는 소프트웨어 개발 방법, 개발하는 사람이나 조직에 따라 바뀔 수 있습니다.
There are 4 common activities:
- Requirements elicitation and analysis
- Requirements specification
- Requirements validation
- Requirements change management
+ Agile, XP의 경우 IEEE std 830:1998을 따르는 SRS를 만들지 않을 뿐, document를 만들기는 합니다.
+ Iterative한 process의 경우는 이번 iterative에서 할 만큼만 SRS를 만듭니다.
+ RUP는 elaboration까지 SRS를 정확하게 만들기 위해 RE를 반복하고 그 다음 phase에서는 requirement를 수정할 때만 SRS를 수정합니다.
+ 한 번의 cycle로는 SRS을 뽑아내기 굉장히 힘들기 때문에, 여러 번의 반복 끝에 만들어냅니다.
Requirements Elicitation and Analysis
Called requirements elicitation or requirements discovery
- software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc.
이 단계에서는 우선 User requirements를 뽑아내기 위한 Elicitation단계를 거칩니다. 소프트웨어 개발자는 이해관계자로부터 여러가지 정보들을 알아내야합니다.
Difficulties in requirements elicitation:
- Stakeholders don't know what they really want
- Stakeholders express requirements in their own terms
- Different stakeholders may have conflicting requirements
- ...
Process Activities in Requirements Elicitation
- Requirements discovery
- Ineracting with stakeholders to discover their requirements
- Domain requirements are also discovered at this stage
- Requirements classification and organization
- Groups related requirements and organises them into coherent clusters
- Prioritization and negotiation
- Requirements specification
- Requirements are documented and input into the next round of the spiral
Requirements Discovery
Techniques for requirements discovery: (to make user requirements)
- Requirements workshop
- Brainstorming
- Storyboards (Use-case scenario)
- Interviews
- Questionnaires
- Role playing
- Prototypes
- Customer requirement specification review
Requirements Analysis
- Specify user requirements into System requirements with support of requirements analysis models
Requirements Analysis는 user requirements를 system requirements로 바꾸기 위한 방법이라고 볼 수 있습니다.
Requirements Analysis Models for software development
- In Structured Analysis (SASD)
- DFD (data flow diagram)
- FSM (finite state machine)
- ERD
- In Object-Oriented Analysis (OOAD)
- Use cases
- SSD (system sequence diagram)
- Domain model
위에 모델들은 FR을 위한 모델로, FR에 대한 User requirements를 처리하기 위한 방법입니다. NFR의 경우는 앞서 살펴보았던 Goal Analysis를 사용합니다. 이때 문서화하는 것은 다음 단계인 Requirements Specification단계이고, 이 단계에서는 다음과 같은 방법을 통해 list-up만 하는 것입니다.
Requirements Specification
The process of writing down the user and system requirements in a requirements document.
- User requirements have to be understandable by end-users and customers who do not have a technical background
- System requirements are more detailed requirements and may include more technical information
The requirements may be part of a contract for the system development
- Requirements should state what the system should do, and the design should describe how it does this.
- In practice, requirements and design are often inseparable
User requirement는 기술적인 이해가 없는 고객이나 이해관계자를 위한 것인 반면, System requirement는 기술적인 이해가 필요한 정보들이 들어있습니다. 이런 requirements들을 문서화 하는 작업입니다.
그 문서화 된 requirements는 시스템 개발에 있어서 계약서와 같은 역할을 수행합니다. 그 requirement는 시스템이 어떤 것을 해야하고 이를 통해 디자인을 어떻게 해야할 지를 알 수 있기 때문입니다. 일반적으로 requirements는 디자인과 분리할 수 없기 때문입니다.
문서화하는 기준은 IEEE std 830:1998을 따릅니다. 또한 점점 RE단계를 거듭할수록 abstract한 FR과 NFR은 verifiable한 FR만 남게됩니다. (그렇다고 NFR이나 Domain requirement가 마지막 단계에서 없어진다는 것은 아닙니다)
또한 그런 문서와 함께, System Test Plan (STP) 도 같이 만들어지는데, 이는 V model에서 사용됩니다.
The Software Requirements Document
The software requirements document is an official statement ot what is required of the system developers
- 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
- Should include both a definition of user requirements and a specification of the system requirements
중요한 점은 여기에서 디자인을 하면 안됩니다. 이 문서에서는 해당 시스템이 어떤 것을 수행해야하는지만 담겨있어야지 이를 수행하기 위해서는 어떻게 해야하는지는 적어서는 안됩니다. 어떻게 하는지, 디자인의 단계는 RE에서 하는 것이 아닙니다.
Features for good specifications
SRS Contents
Software Requirements Specification should address:
- Functionality
- External interface
- Required performance
- Quality attributes
- Design constraints imposed on an inplementation
Requirements Document Variability
Information in requirements document depend on the type of system and the approach to development used
Requirements documents standards have been designed → IEEE standards 830-1998, There are 8 templates
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
Requirements checking
- Validity: Does the system provide the functions which best support the customer's needs?
- Consistency: Are there any requirement conflicts?
- Completeness: Are all functions required by the customer included?
- Realism
- Verifiability: Can the requirements be checked?
이전에 봤었던 Features of Good Specification들을 검사하는 단계입니다. Requirements Verification이라고 하지 않는 이유는 verification이란 spec에 맞는지 확인하는 것인데, spec이 아직 안 만들어졌기 때문에 validation이라 하는 것입니다.
Requirements Validation Techniques
- Requirements review
- Prototyping
- Test-case generation →Test는 나중에 하긴 하지만, 미리 Test case를 만들면 Requirements를 다시 한 번 생각할 수 있기 때문에 validation technique으로 사용합니다.
Requirements Change Management
Requirements change management is the process of managing changing requirements during the requirements engineering process and system development, and even after delivery
Requirements change management는 RE단계에서만 이루어지는 것이 아니라 개발의 모든 단계에서 이루어질 수 있고, 심지어 배포 이후, 유지보수 단계에서도 사용됩니다. 이는 Requirement가 변경되면 해야하는 단계이기 때문입니다. 만약 Software V&V단계에서 error가 발생해서 requirement를 수정해야한다면 requirement change management단계를 수행해야합니다.
Requirement change management tools start traceability analysis from requirements to code and TC. so CTIP is useful.
일반적으로 requirement 변경은 TC와 많이 mapping되기 때문에 Requirement change management tool은 CTIP과 같이 다니는 것이 좋습니다.
'[학교 수업] > [학교 수업] Software Engineering' 카테고리의 다른 글
| [Software Engineering] 9주차 (2) (3) | 2024.11.01 |
|---|---|
| [Software Engineering] 9주차 (1) (4) | 2024.10.28 |
| [Software Engineering] 7주차 (1) (1) | 2024.10.14 |
| [Software Engineering] 6주차 (1) (1) | 2024.10.07 |
| [Software Engineering] 5주차 (2) (5) | 2024.10.04 |
