How the components of a requirement help with verification
There are many ways to model requirements. I have already written about this topic expressed several times. Today we are looking at another possible model of a requirement that was developed by a HOOD Group employee. Let's take a look at it today and examine the added value it offers us.
The context of a requirement
Philip Stolz presented the Model of a recent request in the HOOD block and can be seen above. First of all, it can be seen that a requirement should have three direct relationships to:
Stakeholders: Every requirement needs at least one stakeholder, because requirements should not be an end in themselves.
Statement: The statement is true if the requirement is fulfilled. In a certain sense, the statement is therefore a structured transformation of the requirement.
Addressee: The addressee is responsible for ensuring that the statement of the requirement becomes true.
These three elements define the context in which a requirement is placed.
Consistency in the model
As can be seen in the image, the requirement is indirectly defined and influenced by other elements. In particular, the other elements result in circular relationships. Such relationships can be very useful if they are used correctly. For example, the triangular shape of the V-model a triangular relationship, which for consistency checks can be usedThe requirement defines both the design and the test. If the test fails, this indicates a problem in one of the three elements (or their children).
However, the relationships shown in this model are much more complex than the simple triangular relationship of the V-model. In particular, the UML notation is used here. In particular, the statement is an integral part of the requirement (composition), while the addressee only has an affiliation (aggregation).
All other relationships (except stakeholders) are generalizations: Inheritance is used here. The hardware, for example, is indirectly a specialization of the object (with the development object as the connecting link).
The benefit
Philip promises in the introduction that the model helps to find out whether a requirement is verifiable. The core element for this purpose is the statement: the "translation" of the requirement into statements enables precisely this. Furthermore, the remaining relationships could be used to check consistency. In other words, to check whether the statement is still correct in the context of the object. However, Philip does not go into the question of what such a consistency check might look like in practice in this article.
Requirements have statements. Making these explicit helps to formulate good, testable requirements [tweetthis]Requirements have statements. Making these explicit ensures good, testable requirements[/tweetthis]
In practice, I see two ways of using this model:
(1) Use of statements: I think the idea of making the statements of requirements explicit for verification is a very good one. I have already modeled requirements in a slightly modified form in the past, using constraints instead of statements. I have used this approach in a Article in the IREB magazine documented.
(2) Furthermore, the model can be used to ensure that all important aspects of working with requirements are covered. The relationships do not necessarily have to be as formal as described here. However, if the relationship to the addressee is not established anywhere, then important information may be missing.
Conclusion
As Philip says at the beginning, a model is a simplified representation of reality with a specific purpose. I was able to recognize two benefits of this model and have described them here.
However, there is a lot more to the model. In this respect, I am curious to see whether there will be any follow-up articles here that deal with this.
Image: Philip Stolz. Background: Kjpargeter
