Alice/my_digital_garden
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

changes

Browse source
This commit is contained in:
Alice 2023-09-20 09:55:02 +01:00
parent f1fd2b7a06
commit 47c2ae5f14
7 changed files with 23 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

164
content/RAS/T - Aula 2.md Normal file
View file

@ -0,0 +1,164 @@
19 Setembro 2023 - #RAS
## Contents
1. [[RAS/T - Aula 2#Definition of Requirement|Definition of requirement]]
2. [[RAS/T - Aula 2#Functional requirements|Functional requirements]]
3. [[RAS/T - Aula 2#Non-functional requirements|Non-functional requirements]]
4. [[RAS/T - Aula 2#4. User and system requirements|User and system requirements]]
5. [[RAS/T - Aula 2#Recap|Recap]]
## 1. Definition of Requirement
The requirements express the users necessities and restrictions that are
placed on the system.
A **requirement** is a capacity that a system must possess, to satisfy the
users necessities.
The IEEE 610.12-1990 standard definition divides requirements into
two alternatives:
1. user needs
2. system capacities
Requirements can be divided into:
1. functional requirements
2. non-functional requirements
A r**equirement that for a stakeholder** can be perceived
as being **functional**, can be considered as **non-functional**
for **a different one**.
> [!info] A candidate requirement is a requirement that was identified by some elicitation technique.
## 2. Functional requirements
> [!tip] Definition
> A functional requirement describes a functionality to be made
available to the users of the system.
- This type of requirements should not mention any technological issue.
- Ideally, functional requirements must be independent of design and
implementation aspects.
> [!note]- Note: Cohesion and Completion
> Collectively, the set of functional requirements must be complete and
coherent. The set is:
> - *coherent*, if there are no contradictions among its elements;
> - *complete*, if it considers all the necessities that the client wishes to see
satisfied.
>
> Defining complete requirements is the most difficult attribute to
achieve or evaluate.
> [!note]- Note: Implicit and Explicit Requirements
> Implicit requirements are referred like that because the client may not be aware about these requirements.
>
> An **implicit requirement** is a requirement included by the development team, based on the domain knowledge that it possesses, in spite of not having been explicitly requested by the stakeholders.
>
> An **explicit requirement** refers to a requirement that was requested by the clients and that is represented in the documentation.
## 3. Non-functional requirements
> [!tip] Definition
> A non-functional requirement corresponds to a set of restrictions
imposed on the system to be developed.
- Alternative terms: quality requirement or quality attribute
- It establishes how attractive, fast, or reliable the system is.
- It includes time constraints, restrictions in the development process, or
adoption of standards.
> [!example]- Example: Technological restriction
> The product must be developed in C++.
> [!info] **A non-functional requirement does not change the essence of the system functionalities.**
- Non-functional requirements are applicable to the system as a whole
and not just to some of its parts, as, generally, non-functional requirements **cannot be modularized**.
- The non-functional requirements are frequently **emergent properties** of the system at hand. *An emergent property of a system is a property that can be associated with the system as a whole, but not individually to each of its components.*
- *Reliability* is a good example of an emergent property.
> [!info] **Non-functional requirements are crucial to decide the system architecture.**
### 3.1 Classification of non-functional requirements
> [!tip]- Classification: Sommerville (2010)
> - **product requirements**: characterise aspects of the behaviour of the system itself (*reliability, performance, efficiency, portability, usability, testability, and readability*).
> - **organisational requirements**: come from strategies and procedures established in the context of the manufacturing process of the system or the client organisation (process standards and implementation requirements).
> - **external requirements**: have origin in external factors to the system and the development process (interoperability, legal, and ethical requirements).
> [!tip]- Classification: Roberson and Roberson (2006)
> - **appearance**: the aspect and the aesthetics of the system;
> - **usability**: the easiness of utilization of the system and everything that permits a more friendly user experience;
> - **performance**: aspects of speed, real-time, storage capacity, and execution correction;
> - **operational**: characteristics about what the system must do to work correctly in the environment where it is inserted;
> - **maintenance and support**: attributes that allow the system to be repaired or improved and new functionalities to be added;
> - **security**: issues related to access, confidentiality, protection, and integrity of the data;
> - **cultural and political**: factors related to the stakeholders culture and habits;
> - **legal**: laws that apply to the system so that it can operate.
#### 3.1.1 Usability
- **Ease of use** is related to the efficiency of utilizing a system and with the mechanisms that reduce the errors made by the users.
- **Personalization** is associated with the capacity of adapting the system to the tastes of the users.
- **Ease of learning** is concerned with the way users are trained to use the system.
- **Accessibility** indicates how easy it is to use the system, for people who
are somehow physically or mentally disabled.
> [!example]- Example: Usability requirements
> 1. The product shall be easy to use for illiterate persons.
> 2. The product shall be intuitive to use for children with 4 years old.
> 3. The product shall be usable by visually impaired persons.
#### 3.1.2 Maintenance and support
- System maintenance is divided into four types: preventive, corrective, perfective, and adaptive.
- **Modifiability** is related to maintenance and is dependent on how easy it is to locate the components that must be changed.
> [!example]- Example: Maintenance and support requirements
> 1. The source code of the product programs should contain comments.
> 2. The product must be prepared to be translated to any language.
#### 3.1.3 Legal
> [!example]- Example: Legal requirements
> 1. The product shall be aligned with the PMBoK guide.
> 2. The product shall be certified by the Taxing Authority.
> 3. The product shall fulfil with the copyright.
## 4. User and system requirements
A **user requirement** represents:
1. a functionality that the system is expected to provide to its users;
2. a restriction that is applicable to the operation of that system.
- These requirements are related to the problem domain.
- They are normally expressed without great mathematical rigour, using natural language and informal diagrams.
A **system requirement** constitutes a more detailed specification of a requirement, being generally a formal model of the system. These requirements are oriented towards the solution domain, and are documented in a more technical language than the one
adopted for the user requirements.
### 4.1 Problem domain
- The requirements result from necessities that exist in the problem domain to be addressed.
- User requirements should be described with the problem domain terminology.
# Recap
1. Requirements represent the necessities of the users and the constraints that are applied to a system and that must be considered throughout the development.
2. The requirements can be classified, according to a first criterion, as either functional or non-functional.
3. Non-functional requirements are divided in 8 different types: appearance, usability, performance, operational, maintenance and support, security, cultural and political, and legal.
4. The requirements can be designated as either user or system requirements.
5. User requirements are related to the problem domain and are usually expressed in a natural language.
6. A system requirement is oriented towards the solution domain and is a detailed specification of a requirement, generally in the form of a formal model of the system.
[[Próxima aula]]
[[RAS/TP - Aula 1|Aula prática]]