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

revert

Browse source
This commit is contained in:
Alice 2023-09-26 11:19:16 +01:00
parent 36e3ad586c
commit d5ca6727b4
14 changed files with 851 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

101
RAS/RAS - PL - Aula 1.md Normal file
View file

@ -0,0 +1,101 @@
🌫 20 Setembro 2023 - #RAS
> [!note]
> As resoluções dos exercícios aqui contidos podem conter erros. Se detetares um problema (e se o souberes resolver) por favor contacta-nos.
>[!help]+ Ex. 1
>Defina se os seguintes requisitos são funcionais ou não funcionais:
>1. Ter a possibilidade de exportar o ficheiro a que se refere a Portaria n. 321-A/2007, de 26 de março;
>2. Possuir um sistema que permita identificar a gravação do registo de faturas ou documentos equivalentes e talões de venda, através de um algoritmo de cifra assimétrica e de uma chave privada de conhecimento exclusivo do produtor do programa;
>3. Possuir um controlo de acesso ao sistema informática, obrigando a uma autenticação de cada utilizador;
>4. Não dispor de qualquer função que, no local, ou remotamente, permita alterar, direta ou indiretamente, a informação de natureza fiscal, sem gerar evidência agregada à informação geral.
>
> >[!hint]- Resolução
> >1. requisito funcional: define uma feature do sistema
> >2. *secção inicial* -> requisito funcional: garantir a integridade dos dados; *secção da encriptação simétrica* -> requisito não funcional : é um requisito tecnológico
> >3. requisito funcional: defina uma feature do sistema; requisito não funcional : é um requisito de segurança
> >4. não requisito: não define uma feature (é uma "não-feature") e não se qualifica a requisito não-funcional
>[!help]+ Ex 3.1 (Naveda and Seidman, 2006, pp. 39–40)
> Which is the type of elements less appropriate to be included in a requirements document?
>1. design restrictions
>2. product delievery constraints
>3. funcionalities to make available
>4. performance characteristics
>
>>[!hint]- Resolução
>>Option 2 is the less appropriate.
>>
>>- Option 1 contains non-requirements but has to do with the development of the software, thus it's important to be included in the requirement phase.
>>- Option 2 has nothing to do with the development at all and contains restrictive directives.
>>- Option 3. is a functional requirement.
>>- Option 4. is a non-functional requirement.
>[!help]+ Ex. 3.2 (Naveda and Seidman, 2006, pp. 33–34)
>Which is the type of requirements that should not be included in a requirements document?
>
>1. functional requirements
>2. maintenance requirements
>3. project requirements
>4. performance requirements
>
>>[!hint]- Resolução
>>Option 3. should not be included.
>>
>>- Option 1. is essential.
>>- Option 2. pertains to the directives that will define how the system will be maintained and managed in the future.
>>- Option 3. defines the circumstances around the project: it touches budget, the team members, other departments (than the development team), etc. It is too encompassing and it is not always about the development of the system. *The requirements document should be in the project documents*, not the other way around.
>>- Option 4. is a non-functional requirement, therefore its inclusion is necessary.
>[!help]+ Ex. 3.3 (Naveda and Seidman, 2006, pp. 41–42)
>Which is the element that must be included in a requirements document?
>
>1. acceptance/validation procedures
>2. delivery plans
>3. quality attributes
>4. activities to guarantee the quality
>
>>[!hint]- Resolução
>>Option 3. is a must.
>>
>>1. Option 1. pertains to the testing procedures.
>>2. Option 2. pertains to the expected plans of the delivery of the software (aka versions: version alpha, version beta,...).
>>3. Option 3. is a synonym for non-functional requirements.
>>4. Option 4. means the indicated protocol which regulates the quality of the product.
>[!help]+ Ex. 3.4 (Naveda and Seidman, 2006, pp. 57–58)
>Which of the following arguments is the most solid/strong to justify the specification of the non-functional requirements of a system?
>
>1. The non-functional requirements should only be considered in development contexts subject to tight restrictions (resources, budget, or deadlines).
>2. The non-functional requirements are only external characteristics of the system and can be obtained later.
>3. If a functionality is present in the system, the non-functional requirements determine how usable and useful it is.
>4. The non-functional requirements take less time to specify than the functional requirements.
>
>>[!hint]- Resolução
>>Option 3. is the best justification.
>>
>>Non-functional requirements are, colloquially, an enumeration of restrictions to the functional requirements being defined by a developing system.
>>Non-functional requirements are the buffer of quality of the product - these cannot be defined later. Their determination may take even more time than the definition of functional requirements since, sometimes, they can be even more implicit than their counterpart. Their determination should also be independent of resources or budgets; otherwise, there can/will be consequences on the quality of the software.
>[!help]+ Ex. 3.5
>Consider the following requirement: *The system should be easy to use for trained persons.*
>
>Classify this requirement with respect to its type.
>1. Functional
>2. Non-functional
>
>Is this requirement verifiable? Justify.
>
>>[!hint]- Resolução
>>Option 2., since it defines no feature.
>>
>>In terms of verifiability:
>>What is a trained person? That is debatable. Is it a person with 1h of experience, 3h, 5h? This needs to be defined. Also, what is easy? Is it defined by the number of errors this person commits (commit less than 3 errors in this determined feature - this is considered "easy")? Use correctly 80% of the software and it's "easy" and intuitive for the tester? This also needs defining.
>

34
RAS/RAS - T - Aula 1.md Normal file
View file

@ -0,0 +1,34 @@
🌫 12 Setembro 2023 - #RAS
# Definition of Software Engineering
Application of a systematic, disciplined and quantifiable approach to the analysis, design , implementation and exploitation of software systems, resorting to knowledge, principles, techniques and methods that originate from the empirical-scientific advances, in an ethical context to satisfy the necessities of human development.
# Team
- João M. Fernandes
- André L. Ferreira
- Manuel Alves
- Paulo Rafael Sousa
# Evaluation
- Test - January 02
- Min grade: 8.00 
- Exam - January 23
- Project
- Min grade: 10.00
- **phase 1**: teams of five students;
- deadline: October 20
- **phase 2**: teams unite to create bigger teams project
- deadline: November 24
- **phase 3**: teams unite to create bigger teams project
- deadline: December 22
- **project presentation**: Jan 08–12
- project mark in each phase is affected by individual performance:
- individual variation (-2..+2) (provided by each team)
- sum of variations is 0 within the team
- project mark = (mark1 + mark3) /2
- project mark in 2022/23 can be reused this year (send email)
- Final Mark = min(0.6×max(test, project)+0.4×min(test, project), test+2.5)
[[RAS/T - Aula 2|Próxima aula]]

164
RAS/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/PL - Aula 1|Aula prática]]