jambor.pro/docs-onboarding
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update: Stakeholder Requirements Prozess verbessert und Traceability angepasst.

Browse source
This commit is contained in:
Jan Jambor 2024-12-20 13:02:12 +01:00
parent a0997b5523
commit 1761b026ae
4 changed files with 108 additions and 98 deletions
Download patch file Download diff file Expand all files Collapse all files

14
traceability-concept.md
View file

@ -2,6 +2,20 @@
![Traceability Concept](resources/diagrams/traceability-concept.png)
## Description of the layers
**Stakehodler Requirements**: It's crucial to understand that we always start with the stakeholder requirements where regulations are an important input. This is the customer's point of view, defines “what” should be done.
**System Requirements**: The system requirements are the answer to the stakeholder requirements. It describes “how” it is going to be implemented. Quality requirements, often called non-functional requirements, are part of the system requirements. They are stated as testable requirements e.g. latency time must be less than 200ms. Furthermore we also add potential risks at this level.
**Functional Specification**: ... to be continued
**Configuration Specification**: ... to be continued
## Implementation in Azure DevOps
We are following the CMMI process template in Azure DevOps.
Regulations are mapped as requirements work item in Azure DevOps that affect other requirements. In that way we see all regulations that affect a requirement and all requirements that are affected by a regulation. This is a bidirectional traceability.
All requirements are listed in a use case specific document. The requirements are linked to the regulations and the tests. The tests are linked to the requirements. This is a bidirectional traceability.