By: Simone Bernardi, Anders Ekman, Celeris AB
A common mistake in requirements management
A common mistake in the adoption of new ways of working within corporations is the excessive focus on new tools and new innovative methods (see example Shreta et al. (2019) on the use of AI techniques for requirements elicitation), at the cost of leveraging domain knowledge and more traditional but effective practices. Like you would buy the latest running shoes but would trip over untied laces while trying to win the 100m sprint. The same holds true in the field of requirements management. Badly written and poorly thought requirements, can turn out to a complete nightmare during product and software development.
The handshakes in products’ requirements management
Even worse, products often involve multiple stakeholders and disciplines. Various handshakes take place during product development, like between business stakeholders and system engineers, and between system and software engineers. Every handshake and every interaction requires the involved parties to gather to establish traceability between the distinct layers of needs and requirements. If needs and requirements are not properly articulated, such sessions will end up in lengthy review meetings going through hundreds of poorly specified and challenging requirements, where it is unclear whether the requirements are complete and non-conflicting.
Characteristics of good requirements
When writing and reviewing requirements, it often pays off keeping following features and questions in mind:
-
Unique: Is the requirement unique or is it a duplicate to another requirement?
-
Non-Conflicting: Is the requirement non-conflicting with other requirements (a conflict is present if it is impossible to meet both requirements simultaneously)?
-
Unambiguous: Is it clear how to interpret the requirement or is the requirement ambiguous and gives rise to multiple interpretations?
-
Relevant: Does the requirement come across as relevant for what is to be developed by the team?
-
Feasible: Is the requirement feasible to implement, given the available budget and time?
-
Verifiable: Can the requirement satisfaction be verified with a reasonable effort?
-
Complete: Does the set of requirements within your area of expertise offer a complete coverage of all relevant aspects of the intended solution or are relevant requirements missing?
These characteristics are valid independently of the requirements type, and already from the beginning, from the requirements elicitation phase with stakeholders, down to system engineers, and subsystems thereof. Well-written requirements support efficient and effective product developments within your organization. Still, the risk of deviating from these good characteristics is behind the corner. Memorizing them or writing them on a small memo in front of you is not a bad idea. A traditional practice that pays off in this agile world!
References: Sharma, Shreta and Pandey, S. K., Integrating AI Techniques in Requirements Elicitation (October 2, 2019). Proceedings of International Conference on Advancements in Computing & Management (ICACM) 2019, Available at SSRN: https://ssrn.com/abstract=3462954 or http://dx.doi.org/10.2139/ssrn.3462954 Source: On writing good requirements | LinkedIn
