87 lines
4.5 KiB
Markdown
87 lines
4.5 KiB
Markdown
---
|
|
dg-publish: true
|
|
---
|
|
|
|
🌫 26 de Setembro 2023 - #RAS
|
|
|
|
## Definition of Requirements Engineering
|
|
- **Requirements engineering** designates all the activities related to requirements discovery, negotiation, documentation, and maintenance.
|
|
- Alternative designation: analysis
|
|
|
|
>[!hint]+ Zave, 1997
|
|
>Requirements engineering, in the scope of software engineering, is focused on the real-world objectives established for the functionalities and the restrictions of software systems.
|
|
|
|
Requirements engineering seeks to ensure the three following objectives:
|
|
1. all the relevant requirements are explicitly known and comprehended at the intended level of detail;
|
|
2. a reasonable and wide agreement about the requirements is obtained among the stakeholders;
|
|
3. all the requirements are duly documented, in conformity with the established formats and templates.
|
|
|
|
>[!info] Requirements engineering determines what the system must do to meet the necessities of users and *not* how it should be built.
|
|
|
|
>[!info] It is desirable keeping the requirements strictly separated from their own solutions.
|
|
|
|
|
|
>[!hint] The requirements of a given system are necessary, clear, correct, complete, viable, traceable, verifiable and negotiable.
|
|
|
|
|
|
## Activities
|
|
Process Scheme: [[process.excalidraw]]
|
|
|
|
### 1. Inception
|
|
- Initiation of the process, based on some necessity or business expectation.
|
|
- At the end, the requirements engineer should be able to describe what is the client vision and return on investment.
|
|
- One must also evaluate if what the client needs is already available in the market.
|
|
|
|
### 2. Elicitation
|
|
- This activity handles how requirements should be captured.
|
|
- The requirements elicitation techniques must:
|
|
1. identify the sources of requirements;
|
|
2. aid the various stakeholders to correctly describe the requirements;
|
|
- This activity is inherently communicational, since it requires an in-depth interaction with the stakeholders.
|
|
- Requirements elicitation techniques:
|
|
1. Interview
|
|
2. Survey
|
|
3. Introspection
|
|
4. Ethnography
|
|
5. focus group
|
|
6. cooperative work
|
|
7. domain analysis
|
|
8. object-orientation
|
|
9. prototyping
|
|
10. scenario
|
|
11. goal modelling
|
|
12. persona
|
|
|
|
### 3. Elaboration
|
|
- This activity aims to analyse and classify the elicited, but not yet handled, requirements.
|
|
- Organises the requirements in cohesive groups.
|
|
- The analyst must intervene, whenever the requirements: do not make sense; are in contradiction among them; are incoherent; are incomplete; are vague.
|
|
|
|
### 4. Negotiation
|
|
- Requirements engineering involves communication and negotiation among various stakeholders.
|
|
- Conflict situations between requirements are inevitable. One needs to promote negotiation mechanisms among the stakeholders. Its result can have a significant impact on the acceptance of the final system.
|
|
- Another form of handling conflicts consists in adopting prioritisation techniques, to sustain the choice of the requirements subset to be implemented at each instant.
|
|
|
|
### 5. Documentation
|
|
- Requirements documents serve as the principal reference to the subsequent phases of the development process.
|
|
- The requirements document is organised according to two distinct perspectives:
|
|
1. user requirements - describe the expectations and the necessities of the users;
|
|
2. system requirements - establish the agreement between the client and the development team.
|
|
- The structure/formality of the documentation should vary in line with the system characteristics and the adopted process.
|
|
|
|
### 6. Validation
|
|
- The objective is to ensure that the requirements define the system desired by the client.
|
|
- One should examine the requirements document through inspections or technical reviews of the specifications, to evaluate if it describes the intended system.
|
|
- Validation is a testing activity.
|
|
- While the requirements engineering activities are conducted, it is necessary to execute tasks that allow requirements to be verified and validated.
|
|
|
|
### 7. Management
|
|
- The requirements set is constantly changing.
|
|
- Mechanisms to manage that instability context are needed, in order to evaluate the impact that the changes in the requirements can have.
|
|
- One must reject changes that imply: a significative increase in cost; a postponement of the final delievery; a system devaluation for the user.
|
|
- The requirements management activity seeks to aid the development team to identify, control and trace the requirements and their changes.
|
|
|
|
|
|
## Difficulties
|
|
1. Communication problems between requirements engineers and users are common.
|
|
2. Changes in the requirements must be considered as a natural fact.
|