This first article I wrote, includes my years of experience on Aspice and the conclusions I have drawn as a result of dozens of audits I have undertaken.
In addition, what I wrote does not aim to repeat the standard, it clearly reveals what you should do as a result of the practices given in the standard.
As you know, requirements determine the basis of a product. Requirements that are not well defined, not analyzed, not reviewed, not approved by the customer, or not tracked (without traceability) are requirements that do not have a basis and cannot be used.
Now let’s try to understand what is required of us for the Aspice standard. First, let’s clarify the base practices.
1. SWE.1.BP1: Specify software requirements:
It asks us to specify the software requirements, and while doing so, it asks us to reference system requirements, stakeholder requirements, and separate the requirements into functional and non-functional requirements.
Then the document we should have as output is the Software Requirements Specification.
In this document, the requirements must be separated into functional and non-functional requirements, and the system requirements must be specified separately or processed integratedly within the requirements.
So, what should be taken into consideration when writing the Software Requirements Document?
- First, each requirement is specific, so it should be specified with a unique number or naming.
- Software requirements must be testable. For example, we cannot write a requirement such as the screen will be plain. Some of the non-functional requirements may not be testable, but they must be controllable. For example, we can only control a requirement regarding hardware features.
- Coding details should not be included when writing requirements.
- Requirements should be written with shall be V3, should be V3.
- When writing requirements, we should take into account stakeholder requirements and/or customer requirements and/or technical specification items. Using a traceability matrix is a good way to do this.
- More than one feature should not be defined within a requirement. Because while testing, we cause the error percentage to increase. If one of multiple nested requirements fails the test, the entire requirement fails.
2. SWE.1.BP2: Structure software requirements:
What is desired in this base practice is;
It is a logical structure in the written requirement definitions document. Actually, we first make this configuration as functional and non-functional. However, in order not to cause confusion in functional requirements and at the same time to work in an order while testing and monitoring, it is necessary to make an extra grouping.
This grouping;
- It can be done module-based,
- It can be done according to priority value,
- It can be done in version order,
- Logically, it can be used in different structures.
3. SWE.1.BP3: Analyze software requirements:
The most important thing to do for this base practice is to create a checklist.
In order to analyze the requirements, the control criteria should first include the cost values specified in the feasibility study, the compatibility of the technical values, the compatibility of the specified time, and also information such as technical specification (or customer, stakeholder requirements) – requirement traceability, checking whether the requirements are written in the required order, checking whether the requirements are written in testable criteria should take place.
4. SWE.1.BP4: Analyze the impact on the operating environment:
While writing the requirements, we must define the environment requirements within the scope of non-functional requirements and be able to analyze these defined requirements.
When performing analysis, it is necessary to determine the impact of the requirements on the system components and the operating environment. If we are working with the Aspice standard, we must have defined in advance the details of how the impact analysis will be carried out. Regardless of the definitions within which we make the impact analysis, we can still create a checklist to conduct the impact analysis of the system in which the product created by our requirements will be executed, or we can also examine and evaluate it in the risk analysis in accordance with the impact value.
5. SWE.1.BP5: Develop verification criteria:
Are the requirements I received correct –> Verification
Is the product I made correct–> Validation
This is the verification of the desired requirements in base practice.
This;
- It can be done with checklists; To give an example of the questions in the checklist:
Do the requirements specify a single functionality?
- Are the requirements clearly defined so that they can be tested? Is each requirement uniquely numbered? Is there no code detail in the requirement?
- Is Requirement – Requirement traceability or Requirement – Customer Requirement traceability available?
questions can be used.
- This can be done through review meetings with the team, which is very important. Sometimes the Analysis Specialist receives the requirement, but requirements that are not possible to code have been created in the technology used. If the technical team makes the necessary review in time, change requests at the product code stage are reduced.
- This can be done through review meetings with the customer, so if a requirement document written as a result of analysis meetings with the customer must be reviewed and approved by the customer.
- Can be verified by traceables. This traceability can be in the form of requirement – requirement, requirement – technical specification, requirement – stakeholder requirement. It prevents deficiencies from occurring in the requirements created after analysis.
- Can be verified with Test Scenarios. Test scenarios consist of criteria that include verification of each requirement.
- Verification can be done with the Requirements Definitions document template. It allows you to check whether the template is used correctly or whether there are any missing titles or sections.
6. SWE.1.BP6: Establish bidirectional traceability:
What we want from us here is to create traceability with a sustainable structure that can follow the requirements from start to finish. Traceability between Software Requirement – Software Requirement,
Between System Requirement – Software Requirement,
Between Specification or Customer Requirement – Software Requirement, if any,
Between System Architecture – Software Requirement.
Traceability must be two-way. In other words, if requirement G2 corresponds to technical specification T10, T10 may correspond to requirements such as G2 and G5.
I usually use Jira for traceability. I take the software requirements as one issue type, the system requirements as another issue type, establish a connection between them, and then I provide two-way traceability with one of the many plug-in applications related to traceability.
There various applications for traceability
Applications such as Doors are also among the best applications used for two-way traceability.
7. SWE.1.BP7: Ensure consistency:
Ensuring consistency is achieved through traceability records (System Requirement – Software Requirement, System Architecture – Software Requirement) and also by reviewing these traceabilities. What is required of us is to both carry out traceability, maintain it and review it.
8. SWE.1.BP8: Communicate agreed software requirements:
In this practice, it want to communicate the requirements we have written and the changes in the requirements to the relevant parties. Therefore, using a strong communication network with stakeholders is of great benefit at this point. I find the Confluence / Jira integrated system useful. I outline the requirements in a space accessible to the relevant parties within the authority, manage the changes in Jira, and update the requirement document that needs to be updated on confluence in an integrated way to Jira, and inform the parties by defining a Jira issue via the confluence document.
Communication network with stakeholdes has great importance. Confluence and Jira offer nice features for this purpose.
