restructure file system
This commit is contained in:
parent
1e41014202
commit
c26037dee8
7 changed files with 191 additions and 108 deletions
27
.obsidian/workspace.json
vendored
27
.obsidian/workspace.json
vendored
|
|
@ -13,7 +13,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "markdown",
|
"type": "markdown",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "RAS/T1 - Aula 2 - 19 Setembro 2023.md",
|
"file": "Notes/MFES/T - Aula 2 - 18 Setembro 2023.md",
|
||||||
"mode": "source",
|
"mode": "source",
|
||||||
"source": false
|
"source": false
|
||||||
}
|
}
|
||||||
|
|
@ -69,7 +69,8 @@
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"direction": "horizontal",
|
"direction": "horizontal",
|
||||||
"width": 300
|
"width": 300,
|
||||||
|
"collapsed": true
|
||||||
},
|
},
|
||||||
"right": {
|
"right": {
|
||||||
"id": "fe57fca15d81c25f",
|
"id": "fe57fca15d81c25f",
|
||||||
|
|
@ -85,7 +86,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "backlink",
|
"type": "backlink",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "RAS/T1 - Aula 2 - 19 Setembro 2023.md",
|
"file": "Notes/MFES/T - Aula 2 - 18 Setembro 2023.md",
|
||||||
"collapseAll": false,
|
"collapseAll": false,
|
||||||
"extraContext": false,
|
"extraContext": false,
|
||||||
"sortOrder": "alphabetical",
|
"sortOrder": "alphabetical",
|
||||||
|
|
@ -102,7 +103,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "outgoing-link",
|
"type": "outgoing-link",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "RAS/T1 - Aula 2 - 19 Setembro 2023.md",
|
"file": "Notes/MFES/T - Aula 2 - 18 Setembro 2023.md",
|
||||||
"linksCollapsed": false,
|
"linksCollapsed": false,
|
||||||
"unlinkedCollapsed": true
|
"unlinkedCollapsed": true
|
||||||
}
|
}
|
||||||
|
|
@ -125,7 +126,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "outline",
|
"type": "outline",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "RAS/T1 - Aula 2 - 19 Setembro 2023.md"
|
"file": "Notes/MFES/T - Aula 2 - 18 Setembro 2023.md"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
@ -149,17 +150,23 @@
|
||||||
"obsidian-excalidraw-plugin:Create new drawing": false
|
"obsidian-excalidraw-plugin:Create new drawing": false
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"active": "201fe1705c33e116",
|
"active": "4c008c59a631fa8d",
|
||||||
"lastOpenFiles": [
|
"lastOpenFiles": [
|
||||||
|
"Notes/MFES/MFES - UC Details.md",
|
||||||
|
"README.md",
|
||||||
|
"2023-09-18.md",
|
||||||
|
"MFES/T - Aula 2 - 18 Setembro 2023.md",
|
||||||
|
"Notes/RAS/T - Aula 2 - 19 Setembro 2023.md",
|
||||||
|
"Notes/RAS",
|
||||||
|
"Notes/MFES/T - Aula 2 - 18 Setembro 2023.md",
|
||||||
|
"Notes/MFES",
|
||||||
|
"Notes",
|
||||||
|
"RAS/T - Aula 2 - 19 Setembro 2023.md",
|
||||||
"MFES/UC Details.md",
|
"MFES/UC Details.md",
|
||||||
"MFES/T1 - Aula 2 - 18 Setembro 2023.md",
|
|
||||||
"RAS/T1 - Aula 2 - 19 Setembro 2023.md",
|
|
||||||
"Definition of requirement.md",
|
"Definition of requirement.md",
|
||||||
"RAS",
|
"RAS",
|
||||||
"README.md",
|
|
||||||
"UC Details][Métodos.md",
|
"UC Details][Métodos.md",
|
||||||
"Test.md",
|
"Test.md",
|
||||||
"2023-09-18.md",
|
|
||||||
"Excalidraw/Drawing 2023-09-18 20.03.36.excalidraw.md",
|
"Excalidraw/Drawing 2023-09-18 20.03.36.excalidraw.md",
|
||||||
"MFES/Drawing 2023-09-18 19.03.04.excalidraw.md",
|
"MFES/Drawing 2023-09-18 19.03.04.excalidraw.md",
|
||||||
"Excalidraw/Drawing 2023-09-18 20.03.42.excalidraw.md",
|
"Excalidraw/Drawing 2023-09-18 20.03.42.excalidraw.md",
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
## Programa
|
## Programa
|
||||||
|
|
||||||
1. Lógicas para especificação formal
|
1. Lógicas para especificação formal
|
||||||
1. [[T1 - Aula 2 - 18 Setembro 2023#Proposicional Logic (PL)| Lógica Proposicional (PL)]]
|
1. [[T - Aula 2 - 18 Setembro 2023#Proposicional Logic (PL)| Lógica Proposicional (PL)]]
|
||||||
2. Lógica de Primeira Ordem (FOL)
|
2. Lógica de Primeira Ordem (FOL)
|
||||||
3. Lógica relacional (RL)
|
3. Lógica relacional (RL)
|
||||||
4. Lógica temporal linear (LTL)
|
4. Lógica temporal linear (LTL)
|
||||||
|
|
@ -27,9 +27,18 @@ Usually SAT solvers deal with formulas in conjunctive normal form (CNF)
|
||||||
|
|
||||||
## Proposicional Logic (PL)
|
## Proposicional Logic (PL)
|
||||||
|
|
||||||
|
An assignment is a function $A$ : $V_{prop} \implies {0,1}$ , that assigns to every
|
||||||
|
propositional variable a truth value. An assignment $A$ naturally extends to all formulas, $A$ : **Form** $\implies {0,1}$. The truth value of a formula is computed using **truth tables**:
|
||||||
|
|
||||||
| F | $A$ | $B$ | $\neg A$ | $A \land B$ | $A \lor B$ | $A \implies B$ | $A \iff B$ | $\bot$ | $\top$ |
|
| F | $A$ | $B$ | $\neg A$ | $A \land B$ | $A \lor B$ | $A \implies B$ | $A \iff B$ | $\bot$ | $\top$ |
|
||||||
| --------- | --- | --- | -------- | ----------- | ---------- | -------------- | ---------- | ------ | ------ |
|
| --------- | --- | --- | -------- | ----------- | ---------- | -------------- | ---------- | ------ | ------ |
|
||||||
| $A_1 (F)$ | 0 | 1 | 1 | | | | | | |
|
| $A_1 (F)$ | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 |
|
||||||
| $A_2 (F)$ | | | | | | | | | |
|
| $A_2 (F)$ | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 |
|
||||||
| $A_3 (F)$ | | | | | | | | | |
|
| $A_3 (F)$ | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 0 | 1 |
|
||||||
| $A_4 (F)$ | | | | | | | | | |
|
| $A_4 (F)$ | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
A formula $F$ is:
|
||||||
|
1. **valid** iff it holds under every assignment. We write $F$
|
||||||
|
|
||||||
159
Notes/RAS/T - Aula 2 - 19 Setembro 2023.md
Normal file
159
Notes/RAS/T - Aula 2 - 19 Setembro 2023.md
Normal file
|
|
@ -0,0 +1,159 @@
|
||||||
|
## Contents
|
||||||
|
1. [[T - Aula 2 - 19 Setembro 2023#Definition of Requirement|Definition of requirement]]
|
||||||
|
2. [[T - Aula 2 - 19 Setembro 2023#Functional requirements|Functional requirements]]
|
||||||
|
3. [[T - Aula 2 - 19 Setembro 2023#Non-functional requirements|Non-functional requirements]]
|
||||||
|
4. [[T - Aula 2 - 19 Setembro 2023#4. User and system requirements|User and system requirements]]
|
||||||
|
5. [[T - Aula 2 - 19 Setembro 2023#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.
|
||||||
|
|
@ -1,92 +0,0 @@
|
||||||
## Contents
|
|
||||||
1. [[T1 - Aula 2 - 19 Setembro 2023#Definition of Requirement|Definition of requirement]]
|
|
||||||
2. [[T1 - Aula 2 - 19 Setembro 2023#Functional requirements|Functional requirements]]
|
|
||||||
3. [[T1 - Aula 2 - 19 Setembro 2023#Non-functional requirements|Non-functional requirements]]
|
|
||||||
4. User and system requirements
|
|
||||||
|
|
||||||
## 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.
|
|
||||||
|
|
||||||
|
|
||||||
## 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.
|
|
||||||
|
|
||||||
|
|
||||||
## 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 modularised**.
|
|
||||||
|
|
||||||
- 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.**
|
|
||||||
|
|
||||||
> [!tip]- Classification of non-functional requirements : 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 of non-functional requirements : 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;
|
|
||||||
|
|
@ -2,7 +2,7 @@ Basicamente, isto é uma sopa de letras com alguma lógica por detrás (mas não
|
||||||
|
|
||||||
## Conteúdo
|
## Conteúdo
|
||||||
### Ano 1 (Mestrado)
|
### Ano 1 (Mestrado)
|
||||||
1. [[UC Details| (MFES) Métodos Formais de Engenharia de Software]]
|
1. [[MFES - UC Details| (MFES) Métodos Formais de Engenharia de Software]]
|
||||||
2. (ASCN) Aplicações e Serviços de COmpitação em Nuvem
|
2. (ASCN) Aplicações e Serviços de COmpitação em Nuvem
|
||||||
3. (RAS) Requisitos e Arquiteturas de Software
|
3. (RAS) Requisitos e Arquiteturas de Software
|
||||||
4. (CP) Computação Paralela
|
4. (CP) Computação Paralela
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue