From 5069f5299c508b882261efbbf97a388e200978f8 Mon Sep 17 00:00:00 2001 From: Alexander Schlemmer <a.schlemmer@indiscale.com> Date: Tue, 10 Dec 2024 13:33:29 +0100 Subject: [PATCH 1/7] Drafted for texts about the crawler. --- src/architecture.md | 24 +++++++++++++++++++++++- src/model/model.dsl | 4 +++- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/architecture.md b/src/architecture.md index a12d961..31216b7 100644 --- a/src/architecture.md +++ b/src/architecture.md @@ -10,10 +10,15 @@ ### Stakeholders +test + | Role/Name | Contact | Expectations | |-------------|----------------|--------------------| | *\<Role-1>* | *\<Contact-1>* | *\<Expectation-1>* | | *\<Role-2>* | *\<Contact-2>* | *\<Expectation-2>* | +| IndiScale | | | +| PoLis | | | + ## Architecture Constraints @@ -55,15 +60,32 @@ Contained Building Blocks Important Interfaces *\<Description of important interfaces>* -#### \<Name black box 1> +#### LinkAhead Crawler *\<Purpose/Responsibility>* +Scans files in specific directories of the file system and synchronizes them with the LinkAhead instance. Before insertion and updates of +`Records` in LinkAhead, a meta data check is carried out to verify whether the meta data that was exported from kadi4mat is compatible with +the target data model (in LinkAhead and the EDC). Validation failure leads to specific validation error messages and prevents insertions or updates +of the scan result. *\<Interface(s)>* +The crawler component consists of: +- A cfood (file in YAML format) which specifies the mapping from data found on the file system to `Records` in LinkAhead. +- A definition of the identifiables (file in YAML format) which defines the properties that are needed to uniquely identify `Records` of the data model in LinkAhead. +- The data model definition (file in YAML format). This is needed by the crawler to do the meta data check. +- Crawler extensions specific to the project (cusotm converters and custom transformers). These are python modules + containing functions and classes that can be referenced within the cfood. + +The interface is a Python-function that is implemented as a module into the RuQaD demonstrator. The function calls the scanner and main crawler functions of the +LinkAhead crawler software. *\<(Optional) Quality/Performance Characteristics>* *\<(Optional) Directory/File Location>* +- Main interface: `ruqad/src/ruqad/crawler.py` +- Crawler extensions: + - Custom converters (currently not used): `ruqad/src/ruqad/crawler-extensions/converters.py` + - Custom transformers: `ruqad/src/ruqad/crawler-extensions/transformers.py` *\<(Optional) Fulfilled Requirements>* diff --git a/src/model/model.dsl b/src/model/model.dsl index c21d64d..47cbc5e 100644 --- a/src/model/model.dsl +++ b/src/model/model.dsl @@ -6,6 +6,7 @@ model { kadi_polis = softwaresystem "Polis Kadi4Mat" "The Kadi4Mat electronic lab notebook instance of the PoLiS Cluster of Excellence." } group "BatCAT Data Space" { + # Shouldn't this be split up in LinkAhead and EDC? dataspace_node = softwaresystem "BatCAT Data Space Node" "LinkAhead and EDC-based components of the BatCAT Data Space." data_consumer = person "Data Consumer" "R&D departments from the consortial partners of the BatCAT Data Space." @@ -19,7 +20,7 @@ model { } - #linkahead = softwaresystem "LinkAhead" "LinkAhead research datamanagement system." + # linkahead = softwaresystem "LinkAhead" "LinkAhead research datamanagement system." #edc_framework = softwaresystem "ECD Framework" "Catalog, Provider Connector, Identity Hub and other components of the BatCAT dataspace." @@ -27,6 +28,7 @@ model { ruqad -> kadi_polis "Pull battery-related datasets." ruqad -> quality_checker "Invoke quality assurace pipeline on raw data from PoLiS." ruqad -> dataspace_node "Ingest data to LinkAhead." + # ruqad -> linkahead_crawler "Ingest data to LinkAhead with the LinkAhead-Crawler." data_consumer -> dataspace_node "Browse datasets and request access for reuse." data_curator -> dataspace_node "Review and control the offering of datasets to the BatCAT Data Space." -- GitLab From 7898c65b18b52ca3e678664c15cdd09fdb89c1cb Mon Sep 17 00:00:00 2001 From: Alexander Schlemmer <a.schlemmer@indiscale.com> Date: Wed, 11 Dec 2024 10:42:06 +0100 Subject: [PATCH 2/7] added some text to introduction and glossary --- src/architecture.md | 38 +++++++++++++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/src/architecture.md b/src/architecture.md index 31216b7..d641dbb 100644 --- a/src/architecture.md +++ b/src/architecture.md @@ -6,8 +6,32 @@ ### Requirements Overview + +The aim of the project is to build a demonstrator that connects the data management system kadi4mat and EDC allowing for quality checked data exchange from kadi4mat to EDC. +This needs to be achieved by a tool that exports data from the source system, carries out quality and meta data checks (involving an existing pipeline) and importing the +data into the target system. + +TODO: Link to requirements document + +The motivation is to allow a seamless exchange of data between research and industry. +It is important to ensure that the FAIR criteria are met, therefore a dedicated check for meta data and the FAIR criteria is implemented. +The FAIR criteria can be summarized to the following practical checks: +- Is a PID present? +- Is the domain-specific meta data complete? +- Is there provenance information? +- Does the data include license information? + ### Quality Goals +Our main qulity goals are, using the terms from ISO 25010 (see glossary for definitions): + +- Operability +- Compatibility +- Transferability +- Maintainability + + + ### Stakeholders test @@ -66,7 +90,7 @@ Important Interfaces Scans files in specific directories of the file system and synchronizes them with the LinkAhead instance. Before insertion and updates of `Records` in LinkAhead, a meta data check is carried out to verify whether the meta data that was exported from kadi4mat is compatible with the target data model (in LinkAhead and the EDC). Validation failure leads to specific validation error messages and prevents insertions or updates -of the scan result. +of the scan result. The software component also carries out a check of data FAIRness of the data exported from kadi4mat (in ELN format). *\<Interface(s)>* The crawler component consists of: @@ -88,6 +112,10 @@ LinkAhead crawler software. - Custom transformers: `ruqad/src/ruqad/crawler-extensions/transformers.py` *\<(Optional) Fulfilled Requirements>* +- Data ingest from exported ELN file into LinkAhead. +- Data ingest from quality check into LinkAhead. +- Check of FAIRness of data from ELN file. +- Meta data check *\<(optional) Open Issues/Problems/Risks>* @@ -209,7 +237,11 @@ Mapping of Building Blocks to Infrastructure ## Glossary +[//]: # (These are probably defined in: https://www.iso.org/standard/78176.html) + | Term | Definition | |-------------|-------------------| -| *\<Term-1>* | *\<definition-1>* | -| *\<Term-2>* | *\<definition-2>* | +| Operability (ISO 25010) | "System can be understood, learned, used and is attractive to users." | +| Transferability (ISO 25010) | "System can be transferred from one environment to another." | +| Maintainability (ISO 25010) | "System can be modified, corrected, adapted or improved due to changes in environment or requirements." | +| Compatibility (ISO 25010) | "Two or more systems can exchange information while sharing the same environment." | -- GitLab From f01c6c4c2e632da5a2a140c8b315f49af9460b1e Mon Sep 17 00:00:00 2001 From: Alexander Schlemmer <a.schlemmer@indiscale.com> Date: Wed, 11 Dec 2024 11:52:04 +0100 Subject: [PATCH 3/7] more text --- src/architecture.md | 18 +++++++++++------- src/workspace.dsl | 5 +++++ 2 files changed, 16 insertions(+), 7 deletions(-) diff --git a/src/architecture.md b/src/architecture.md index d641dbb..dd653e5 100644 --- a/src/architecture.md +++ b/src/architecture.md @@ -34,8 +34,6 @@ Our main qulity goals are, using the terms from ISO 25010 (see glossary for defi ### Stakeholders -test - | Role/Name | Contact | Expectations | |-------------|----------------|--------------------| | *\<Role-1>* | *\<Contact-1>* | *\<Expectation-1>* | @@ -69,8 +67,11 @@ test ## Solution Strategy + ## Building Block View +![System Landscape Diagram](embed:buildingBlocks) + ### Whitebox Overall System ***\<Overview Diagram>*** @@ -211,15 +212,18 @@ Mapping of Building Blocks to Infrastructure ## Cross-cutting Concepts -### *\<Concept 1>* +### Using YAML for storing machine readable information -*\<explanation>* +The YAML format is used in several components of the software for storing and exchanging information in a +format that is machine-readable and also human-readable at the same time. -### *\<Concept 2>* +### REST interfaces -*\<explanation>* +Multiple components of the software use REST interfaces for data exchange. -… +- Gitlab-API +- kadi4mat-export (?) +- LinkAhead ### *\<Concept n>* diff --git a/src/workspace.dsl b/src/workspace.dsl index 1606cb5..e490348 100644 --- a/src/workspace.dsl +++ b/src/workspace.dsl @@ -16,6 +16,11 @@ workspace "RuQaD" "Architecture Overview on the RuQaD Demonstrator" { include * # autolayout lr } + + systemLandscape buildingBlocks "Building Blocks" { + # include * + } + styles { element "Element" { color white -- GitLab From 6f7ad5bb9317d4d01a0d2f723d6ebdc2482941da Mon Sep 17 00:00:00 2001 From: Daniel <d.hornung@indiscale.com> Date: Wed, 11 Dec 2024 12:36:21 +0100 Subject: [PATCH 4/7] DOC: Readme --- README.md | 8 +++++--- tools/README.md | 26 ++++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 3 deletions(-) create mode 100644 tools/README.md diff --git a/README.md b/README.md index 76b7240..7569a8f 100644 --- a/README.md +++ b/README.md @@ -21,8 +21,10 @@ The src directory contains the doc-as-code sources. The tools directory contains the following tools: -* [tools/serve](./tools/serve) - serve a static site on localhost. +* [tools/serve](./tools/serve) - serve a static site on http://localhost:8080 which renders the documentation, + including diagrams. * [tools/validate](./tools/validate) - validate your structurizr workspace. -* [tools/structurizer-lite](./tools/structurizer-lite) - the original structurizer-lite tool. Use this to interactively layout single diagrams. +* [tools/structurizer-lite](./tools/structurizer-lite) - the original structurizer-lite tool. Use this to interactively + layout single diagrams. -All tools require docker. +All tools require docker, more information in the [readme](tools/README.md) in the tools directory. diff --git a/tools/README.md b/tools/README.md new file mode 100644 index 0000000..3c44f67 --- /dev/null +++ b/tools/README.md @@ -0,0 +1,26 @@ +# Documentation tools # + +This directory contains a few utility scripts: + +- serve: Render and serve the documentatil as html. +- validate: Validate the documentation files. +- structurizer-lite: Web server for layouting diagrams. + +All these tools require Docker to run, they should be started from this repo's top level directory, +otherwise they will not find the documentation sources. + +## serve ## + +Running `tools/serve` starts a web server on http://localhost:8080 which renders the documentation +as html, including the diagrams. + +This uses the *structurizr-site-generatr* to serve the documentation saved in `src/workspace.dsl`. + +## validate ## + +`tools/validate` starts a Docker container which runs validation checks on `src/workspace.dsl`. + +## structurizer-lite ## + +`tools/structurizer-lite` starts a *structurizr* container which allows some editing of the +diagrams. However, it is not quite clear how these diagrams are saved/exported..? -- GitLab From 6928ae1e28ba4419f219727dac9b1f1b86aeda17 Mon Sep 17 00:00:00 2001 From: Daniel <d.hornung@indiscale.com> Date: Wed, 11 Dec 2024 12:36:35 +0100 Subject: [PATCH 5/7] WIP: Quality checker. --- src/architecture.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/architecture.md b/src/architecture.md index dd653e5..33ce675 100644 --- a/src/architecture.md +++ b/src/architecture.md @@ -31,15 +31,15 @@ Our main qulity goals are, using the terms from ISO 25010 (see glossary for defi - Maintainability - ### Stakeholders -| Role/Name | Contact | Expectations | -|-------------|----------------|--------------------| -| *\<Role-1>* | *\<Contact-1>* | *\<Expectation-1>* | -| *\<Role-2>* | *\<Contact-2>* | *\<Expectation-2>* | -| IndiScale | | | -| PoLis | | | +| Role/Name | Contact | Expectations | +|------------------|-------------------|--------------------------------------------------------------| +| *\<Role-1>* | *\<Contact-1>* | *\<Expectation-1>* | +| *\<Role-2>* | *\<Contact-2>* | *\<Expectation-2>* | +| | | | +| IndiScale | Henrik tom Wörden | Quality and FAIRness of entities are successfully annotated. | +| PoLis / Kadi4Mat | | Entities can be exported to other dataspaces. | ## Architecture Constraints @@ -85,6 +85,8 @@ Contained Building Blocks Important Interfaces *\<Description of important interfaces>* +#### Quality Checker #### + #### LinkAhead Crawler *\<Purpose/Responsibility>* -- GitLab From c2a2fb58b9e767ca6e2cc5dcfcbd8dec999dddec Mon Sep 17 00:00:00 2001 From: Daniel <d.hornung@indiscale.com> Date: Wed, 11 Dec 2024 13:26:46 +0100 Subject: [PATCH 6/7] DOC: Quality checker. --- src/architecture.md | 45 ++++++++++++++++++++++++++++++++++++ src/model/quality_checker.md | 6 ++++- 2 files changed, 50 insertions(+), 1 deletion(-) diff --git a/src/architecture.md b/src/architecture.md index 33ce675..4287848 100644 --- a/src/architecture.md +++ b/src/architecture.md @@ -87,6 +87,36 @@ Important Interfaces #### Quality Checker #### +*\<Purpose/Responsibility>* + +The quality checker executes data quality checks on the data which was retrieved from the input +dataspace (a Kadi4Mat instance in this case). It provides a structured summary for other components +and also a detailed report for human consumption. + +*\<Interface(s)>* + +The quality checker is implemented as a Python class `QualityChecker` which provides mainly a +`check(filename, target_dir)` method to check individual files. This class is available in the +module `ruqad.qualitycheck`. + +*\<(Optional) Quality/Performance Characteristics>* + +The quality checker relies on the [demonstrator 4.2](https://git.rwth-aachen.de/fair-ds/ap-4-2-demonstrator/ap-4.2-data-validation-and-quality-assurance-demonstrator) to perform the checks. The quality of this +component so far seems excellent, but is beyond RuQaD's responsibility. + +*\<(Optional) Directory/File Location>* + +*\<(Optional) Fulfilled Requirements>* + +*\<(optional) Open Issues/Problems/Risks>* + +##### Open issues ##### + +- The demonstrator 4.2 service currently relies on running as Gitlab pipeline jobs, which introduces + a certain administrative overhead for production deployment. +- It is possible and may be desirable to parallelize the quality check for multiple files by + distributing the load on a number of service workers, instead of checking files sequentially. + #### LinkAhead Crawler *\<Purpose/Responsibility>* @@ -126,10 +156,25 @@ LinkAhead crawler software. *\<black box template>* +*\<Purpose/Responsibility>* +*\<Interface(s)>* +*\<(Optional) Quality/Performance Characteristics>* +*\<(Optional) Directory/File Location>* +*\<(Optional) Fulfilled Requirements>* +*\<(optional) Open Issues/Problems/Risks>* + + #### \<Name black box n> *\<black box template>* +*\<Purpose/Responsibility>* +*\<Interface(s)>* +*\<(Optional) Quality/Performance Characteristics>* +*\<(Optional) Directory/File Location>* +*\<(Optional) Fulfilled Requirements>* +*\<(optional) Open Issues/Problems/Risks>* + #### \<Name interface 1> … diff --git a/src/model/quality_checker.md b/src/model/quality_checker.md index 232403f..f91883d 100644 --- a/src/model/quality_checker.md +++ b/src/model/quality_checker.md @@ -1,3 +1,7 @@ # Quality Assurance -This is based on the demonstrator 4.2 +Quality assurance is implemented by using the [demonstrator 4.2](https://git.rwth-aachen.de/fair-ds/ap-4-2-demonstrator/ap-4.2-data-validation-and-quality-assurance-demonstrator). This software consumes data +files and data description schemas and returns an extensive report on the data quality mostly +intended for explorative analysis by humans, as well a condensed JSON file which is used by other +Software such as RuQaD. + -- GitLab From d0a073e505550ce842bae37f34c51809ae6035e0 Mon Sep 17 00:00:00 2001 From: Daniel <d.hornung@indiscale.com> Date: Wed, 11 Dec 2024 13:46:19 +0100 Subject: [PATCH 7/7] DOC: Added meta-documentation as links and quotes. --- src/architecture.md | 167 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 166 insertions(+), 1 deletion(-) diff --git a/src/architecture.md b/src/architecture.md index 4287848..558ba89 100644 --- a/src/architecture.md +++ b/src/architecture.md @@ -4,6 +4,8 @@ ## Introduction and Goals +<https://docs.arc42.org/section-1/> + ### Requirements Overview @@ -23,7 +25,15 @@ The FAIR criteria can be summarized to the following practical checks: ### Quality Goals -Our main qulity goals are, using the terms from ISO 25010 (see glossary for definitions): +> The top three (max five) quality goals for the architecture whose fulfillment is of highest +> importance to the major stakeholders. We really mean quality goals for the architecture. Don’t +> confuse them with project goals. They are not necessarily identical. +> +> The ISO 25010 standard provides a nice overview of potential topics of interest: +> +> ... + +RuQaD's main quality goals are, using the terms from ISO 25010 (see glossary for definitions): - Operability - Compatibility @@ -33,6 +43,15 @@ Our main qulity goals are, using the terms from ISO 25010 (see glossary for defi ### Stakeholders +> Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that +> +> - should know the architecture +> - have to be convinced of the architecture +> - have to work with the architecture or with code +> - need the documentation of the architecture for their work +> - have to come up with decisions about the system or its development + + | Role/Name | Contact | Expectations | |------------------|-------------------|--------------------------------------------------------------| | *\<Role-1>* | *\<Contact-1>* | *\<Expectation-1>* | @@ -44,16 +63,41 @@ Our main qulity goals are, using the terms from ISO 25010 (see glossary for defi ## Architecture Constraints +<https://docs.arc42.org/section-2/> + +> Any requirement that constrains software architects in their freedom of design and implementation +> decisions or decision about the development process. These constraints sometimes go beyond +> individual systems and are valid for whole organizations and companies. + ## Context and Scope +<https://docs.arc42.org/section-3/> + +> System scope and context - as the name suggests - delimits your system (i.e. your scope) from all +> its communication partners (neighboring systems and users, i.e. the context of your system). It +> thereby specifies the external interfaces. +> +> If necessary, differentiate the business context (domain specific inputs and outputs) from the +> technical context (channels, protocols, hardware). + + + ### Business Context +> Specification of all communication partners (users, IT-systems, …) with explanations of domain +> specific inputs and outputs or interfaces. Optionally you can add domain specific formats or +> communication protocols. + **\<Diagram or Table>** **\<optionally: Explanation of external domain interfaces>** ### Technical Context +> Technical interfaces (channels and transmission media) linking your system to its environment. In +> addition a mapping of domain specific input/output to the channels, i.e. an explanation with I/O +> uses which channel. + #### System Landscape ![System Landscape Diagram](embed:sl) @@ -67,13 +111,53 @@ Our main qulity goals are, using the terms from ISO 25010 (see glossary for defi ## Solution Strategy +<https://docs.arc42.org/section-4/> + +> A short summary and explanation of the fundamental decisions and solution strategies, that shape the +> system’s architecture. These include +> +> - technology decisions +> - decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern +> or design pattern +> - decisions on how to achieve key quality goals +> - relevant organizational decisions, e.g. selecting a development process or delegating certain +> tasks to third parties. + + ## Building Block View +<https://docs.arc42.org/section-5/> + +> The building block view shows the static decomposition of the system into building blocks (modules, +> components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, +> tiers, functions, macros, operations, data structures, …) as well as their dependencies +> (relationships, associations, …) +> +> This view is mandatory for every architecture documentation. In analogy to a house this is the floor +> plan. + + ![System Landscape Diagram](embed:buildingBlocks) ### Whitebox Overall System + + +> Here you describe the decomposition of the overall system using the following white box template. It contains +> +> - an overview diagram +> - a motivation for the decomposition +> - black box descriptions of the contained building blocks. For these we offer you alternatives: +> - use one table for a short and pragmatic overview of all contained building blocks and their interfaces +> - use a list of black box descriptions of the building blocks according to the black box template (see below). Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modelling tool). +> - (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. +> +> Since there are so many ways to specify interfaces why do not provide a specific template for them. +> +> In the best case you will get away with examples or simple signatures. + + ***\<Overview Diagram>*** Motivation @@ -213,8 +297,20 @@ LinkAhead crawler software. ## Runtime View +[https://docs.arc42.org/section-6/](https://docs.arc42.org/section-6/) + +> The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas: +> +> 1. important use cases or features: how do building blocks execute them? +> 2. interactions at critical external interfaces: how do building blocks cooperate with users and neighbouring systems? +> 3. operation and administration: launch, start-up, stop +> 4. error and exception scenarios +> +> Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their architectural relevancy. It is not important to describe a large number of scenarios. You should rather document a representative selection. + ### \<Runtime Scenario 1> + - *\<insert runtime diagram or textual description of the scenario>* - *\<insert description of the notable aspects of the interactions @@ -228,8 +324,29 @@ LinkAhead crawler software. ## Deployment View +[https://docs.arc42.org/section-7/](https://docs.arc42.org/section-7/) + +> The deployment view describes: +> +> 1. the technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and +> 2. the mapping of (software) building blocks to that infrastructure elements. +> +> Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments. +> +> Especially document the deployment view when your software is executed as distributed system with more then one computer, processor, server or container or when you design and construct your own hardware processors and chips. +> +> From a software perspective it is sufficient to capture those elements of the infrastructure that are needed to show the deployment of your building blocks. Hardware architects can go beyond that and describe the infrastructure to any level of detail they need to capture. + ### Infrastructure Level 1 +> Describe (usually in a combination of diagrams, tables, and text): +> +> 1. the distribution of your system to multiple locations, environments, computers, processors, .. as well as the physical connections between them +> 2. important justification or motivation for this deployment structure +> 3. Quality and/or performance features of the infrastructure +> 4. the mapping of software artifacts (building blocks) to elements of the infrastructure + + ***\<Overview Diagram>*** Motivation @@ -259,6 +376,17 @@ Mapping of Building Blocks to Infrastructure ## Cross-cutting Concepts +[https://docs.arc42.org/section-8/](https://docs.arc42.org/section-8/) + +> This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (→ cross-cutting) of your system. Such concepts are often related to multiple building blocks. They include many different topics, such as +> +> - domain models +> - architectural patterns or design patterns +> - rules for using specific technology +> - principale, often technical decisions of overall decisions +> - implementation rules + + ### Using YAML for storing machine readable information The YAML format is used in several components of the software for storing and exchanging information in a @@ -278,14 +406,51 @@ Multiple components of the software use REST interfaces for data exchange. ## Architecture Decisions +<https://docs.arc42.org/section-9/> + +> Important, expensive, large scale or risky architecture decisions including rationales. With +> “decisions†we mean selecting one alternative based on given criteria. +> +> Please use your judgement to decide whether an architectural decision should be documented here in +> this central section or whether you better document it locally (e.g. within the white box template +> of one building block). Avoid redundant texts. Refer to section 4, where you captured the most +> important decisions of your architecture already. + ## Quality Requirements +<https://docs.arc42.org/section-10/> + +> 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. + ### Quality Tree +> The table or tree (as defined in ATAM – Architecture Tradeoff Analysis Method) of quality +> requirements, with quality/evaluation scenarios as leaves. + ### Quality Scenarios +> 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. + ## Risks and Technical Debts +<https://docs.arc42.org/section-11/> + +> A list of identified technical risks or technical debts, ordered by priority + ## Glossary [//]: # (These are probably defined in: https://www.iso.org/standard/78176.html) -- GitLab