Welcome in 2021,
I know its already been some months but I hope you had a good and motivated start into the new year. What could be better than starting by reading the newest blog post about „SWE.1 Software Requirements Analysis“? Last year we´ve analyzed the „SYS.3 System Architectural Design“ process and finished the system level of the left ‚V‘ (from the V-Model). Now we will focus on the software level. As mentioned todays process will show the software requirements related process steps. Here we go….
Let´s get started
ID: SWE.1
Process name: Software Requirements Analysis
Process purpose: The goal of this process is to alter software related content of the system requirements into a group of software requirements.
Process outcomes: This process is successful if:
- the software requirements are allocated to the software elements of the system with defined interfaces;
- software requirements are analyzed and categorized for correctness and verifiability;
- the impact on the operating environment by software requirements is being analyzed;
- a prioritization for implementing the software requirements is established;
- the software requirements are updated as needed;
- consistency and bidirectional traceability are established between (system requirements and software requirements) and (system architectural design and software requirements);
- the software requirements are evaluated for cost, schedule and technical impact;
- the software requirements are agreed and communicated to all affected parties.
Best practices:
SWE.1-BP.1 Specify Software Requirements
We start by identifying our relevant System Requirements and System Architecture. Once we´ve spotted our System Level, we can continue by defining our Software Requirements with its capabilities and functionalities. Afterwards they need to be classified in terms of functional or non-functional.
Following Work Products must be involved:
- 13-21 Change Control Record
- 17-08 Interface requirements specification
- 17-11 Software requirements specification
- 15-01 Analysis Report
- 13-22 Traceability Record
SWE.1-BP.2 Structure Software Requirements
Now we need to get some structure into our specification. This can be done by clustering your requirements after:
- project relevant cluster
- sorted for logical order within your project
- based on relevant criteria for your project
- priotization due to stakeholder needs
You will also want to start thinking about your verification criteria for each requirement. Those can be maybe reused due to similar projects/requirements.
What do we get in the end of this process?
- 17-50 Verification criteria
- 15-01 Analysis Report
SWE.1-BP.3 Analyze Software Requirements
So what might be our task here? :). Right, we need to check (analyze) our requirement regarding their interdependencies to check their correctness, technical feasibility and verifiability, and to support risk identification. We also take a look onto our costs, schedule and technical impact.
Following Work Products need to be used:
- 13-21 Change control record
- 15-01 Analysis Report
SWE.1-BP.4 Analyze the impact on the operating environment
In this process we need to analyze the impact on the interfaces of the System Elements and operating environment that our Software Requirements might have.
As a result we should provide:
- 13-21 Change control record
- 15-01 Analysis report
- 17-08 Interface requirements specification
SWE.1-BP.5 Develop verification criteria
As within the System Level, we need to provide quantitative & qualitative verification criteria for every Software Requirement. Typically the criteria should help showing that a requirement can be verified or tested within accepted constraints.
Therefore we need to track our activities within:
- 15-01 Analysis report
- 17-50 Verification criteria
- 13-21 Change control record
SWE.1-BP.6 Establish bidirectional traceability
Since we have reached our targeted information quality, we now need to link our Software Requirement with its targeted System- Requirements & Architecture.
This needs to be seen within:
- 13-22 Traceability record
- 13-19 Review record
SWE.1-BP.7 Ensure consistency
The same applies for consistency. We need to verify that our Software Requirements are consistent to the linked System- Requirements & Architecture.
This again can be found in:
- 13-22 Traceability record
- 13-19 Review record
SWE.1-BP.8 Communicate agreed software requirements
In the last step, our last task is to inform all relevant stakeholders about the changes & updates we have done through those processes.
This must be tracked within:
- 13-04 Communication record
Another SPICE process completed!!!!
The activities did hopefully sound familiar to you. They´re nearly the same as in SYS.2-System Requirements Analysis. If we put all of those diagrams together it should something like this:
Thank you
for reading my post. I hope you got a good feeling for this A-SPICE process.
Also check out a video my colleague Susan did for this process. I´ll link it here.
Ein Gedanke zu „SWE.1 – Software Requirements Analysis“