Nowadays, the premise of software development projects is to produce software within a short time. Besides economic expectations from the company’s CEO, internal or external customers expect constant software improvements. Agile software approaches have revolutionised how software is created over the last few years. Frameworks such as Scrum, Lean-Agile or others are praised as the way to efficiently develop new or improve existing software (Cevik, 2016).
It is often claimed that using user stories or other agile work products is sufficient to guarantee high-quality software. The idea is that these work products typically cover documentation. However, since the publication of the agile manifesto, many agile development teams have claimed that software documentation is outdated and unnecessary (Beck et al., 2001). The written code and the internal structure are comparable to comprehensive and profound written software specifications.
Yet, based on personal experience, it is not the documentation that is lagging but rather the question of where a specific software requirement comes from and the impact of a new software requirement on an existing software application.
The organisation of a software requirement from its origin to the final implemented application is called Requirements Traceability (Bühne and Hermann, 2022, p. 96). When we talk about Requirements Traceability at ERNI, we always follow the definition of Requirements Traceability given by the International Requirements Engineering Board (IREB).
The IREB defines “Requirements Traceability” as follows:
“The ability to trace a requirement back to its origins, forward to its implementation in design and code and its associated tests, to requirements it depends on (and vice-versa)” (Glinz, 2022, p. 22).
Requirements Traceability is a comprehensive and well-structured approach that helps everyone within the development project understand the origins of a specific requirement through to its final implementation.
The usage of Requirements Traceability is not an end in itself. On the contrary, it supports the development process in four essential ways (Bühne and Hermann, 2022, p. 97):
- The responsible product owner or business analyst can evaluate the impact of a new requirement, which makes it possible to analyse these work products affected by the change.
- Requirements Traceability helps to understand why a specific requirement exists. In that way, it is possible to avoid unnecessary requirements.
- It can be analysed as to whether all requirements and subsequent development work products have been considered so that the desired product can be recorded, developed and tested.
- Requirements Traceability helps to determine work progress. The agile team or the traditional project manager can compare the actual work progress with the original stated project plan. If differences are spotted, appropriate actions can improve the overall project/development performance.
To sum it up, Requirements Traceability does not just improve the structure of your software documentation; it also improves the overall satisfaction of the development team and increases the overall project performance.
However, introducing Requirements Traceability into an existing development project or opening the idea of Requirements Traceability within an organisation’s development process also brings challenges.
It is often stated that it would bring additional effort to documentation and is perceived as complex.
Our experience shows that the maintenance of Requirements Traceability is often neglected because it is seen as a nuisance. Even if a team implements Requirements Traceability single-handedly within its project, the determination to follow that new doctrine is curtailed by the individual team members’ tendencies towards convenience.
However, we at ERNI know that these challenges can be tackled with the right experienced team and requirements engineering. Besides the initial build-up of Requirements Traceability within your existing projects, the key is to motivate your team members to follow the principles of reasonable requirements engineering by emphasising its outstanding benefits.
Additionally, suppose there is a need to train your teams to prepare them for engineering and management requirements. In that case, we provide assistance and guidance for meeting your organisation’s stated requirements and standards. Furthermore, we comprehensively analyse your current requirements engineering processes to align them with the IREB standard and allow more efficient work.
Sources:
Beck, K. et al. (2001) Manifesto for Agile Software Development. Available at: https://agilemanifesto.org/
Bühne, S. and Hermann, A.(2022) IREB® CPRE advanced level – requirements management, ireb.org. Available at: https://www.imbus.ca/academy/ireb-cpre-advanced-level-requirements-management
Cevik, H. (2016) To drive value to your customers faster you need to re-shape your digital business, Digital Doughtnut. Available at: https://www.digitaldoughnut.com/articles/2016/april/to-drive-value-to-your-customers-faster-you-need-t
Glinz, M. (2022) Glossary of requirements engineering terminology. Available at: https://tsting.cn/uploads/tx_kkdownloader/ireb_cpre_glossary_en_2.0.pdf