my_digital_garden/4a1s/RAS/T - Aula 3.md

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.