Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alex's branch #13

Merged
merged 3 commits into from
Feb 18, 2024
Merged

Alex's branch #13

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e4efd5c
quality requirements docu v.1 (unfinished)
alexfdzs Feb 14, 2024
e062137
Starting with the quality scenarios
alexfdzs Feb 15, 2024
0f4e937
Finishing quality scenarios (v1.0)
alexfdzs Feb 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added docs/images/quality_tree.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
94 changes: 29 additions & 65 deletions docs/src/10_quality_requirements.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,72 +2,36 @@ ifndef::imagesdir[:imagesdir: ../images]

[[section-quality-scenarios]]
== Quality Requirements


[role="arc42help"]
****

.Content
This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority,
which will not create high risks when they are not fully achieved.

.Motivation
Since quality requirements will have a lot of influence on architectural
decisions you should know for every stakeholder what is really important to them,
concrete and measurable.


.Further Information

See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 documentation.

****
The main quality objectives of the project will be:
- Performance: The system will provide fast and effective responses to the user.
- Usability: The system will be intuitive, through a simple and clear interface.
- Security: The system will ensure the privacy and integrity of user data.
- Maintainability: The system will be easy to maintain, upgrade or extend, without putting the whole project at risk.

=== Quality Tree

[role="arc42help"]
****
.Content
The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.

.Motivation
The tree structure with priorities provides an overview for a sometimes large number of quality requirements.

.Form
The quality tree is a high-level overview of the quality goals and requirements:

* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root
* a mind map with quality categories as main branches

In any case the tree should include links to the scenarios of the following section.


****
image::quality_tree.png["Quality tree"]

=== Quality Scenarios

[role="arc42help"]
****
.Contents
Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

These scenarios describe what should happen when a stimulus arrives at the system.

For architects, two kinds of scenarios are important:

* Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.
* Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.

.Motivation
Scenarios make quality requirements concrete and allow to
more easily measure or decide whether they are fulfilled.

Especially when you want to assess your architecture using methods like
ATAM you need to describe your quality goals (from section 1.2)
more precisely down to a level of scenarios that can be discussed and evaluated.

.Form
Tabular or free form text.
****
Dividiremos los escenarios de calidad en escenarios de uso, cambio y fallo.

==== Usage scenarios

|===
| _Source_ | _Stimulus_ | _Attribute_ |_Artifact/Environment_ | _Reply_ | _Response measure_
| Players | A player wants to start a game | Performance | Game Interface | The system creates the game | Game creation time less than 0.5s
| Players | A player wants to answer a question | Performance | Game Interface | The system updates the question interface | Question update time less than 0.5s
| Players | A player wants to login with username and password | Security | User Interface | The system stores these credentials | These credentials will be encrypted to maintain their security.

|===

==== Change scenarios
|===
| _Source_ | _Stimulus_ | _Attribute_| _Artifact/Environment_ | _Reply_ | _Response measure_
| Developers | The game must have more modes to play | Maintainability | Game Interface |A new game mode must be implemented | The implementation of these new mode should be independent of the other game modes
| Developers | We want to migrate the database to another database system | Maintainability | Database | The system do the migration | Encrypted data will be migrated in encrypted form
|===
==== Failure scenarios
|===
| _Source_ | _Stimulus_ | _Attribute_| _Artifact/Environment_ | _Reply_ | _Response measure_
| Game error | An error occurs during the creation of a game | Failure | Game Interface | The system doesn't create the game | The system will alert the user of the error in the creation
|===