Now let us look at the issue of relevance.

What if the requirement as stated represents at best only part of the constituency. One stakeholder, but not all. What if the requirement does not meet the needs of the main authority behind the need? What if the requirement is a misinterpretation of a stated stakeholder need? These and many similar considerations doom even a clear requirement to fail the test of relevance. Here is how the requirements language can help us discover such problems..

Some of these parameters we met earlier, but now we can point out additional purposes, for relevance testing.

When we know the owner of a requirement is the Quality Director, who last approved a change 17 November, but we can see there is a new version later, we know we need to get the requirement owner to approve the change. If there is some question about the content we know that the first point of checking it out is with the author, who may admit it can be improved, or that they failed to realize something. If we wanted to check the relevance of the scale or the goal, we know we can analyze or speak to the listed stakeholders.
 

Most details should have an accompanying ‘source’ annotation; done here by a ‘<-‘ source arrow symbol.

The source information is primarily used in quality control and change processes, in order to know exactly where to check the specification. If you take a look at most people’s specifications you will find that source information at the detailed level is the exception, rather than the rule it should be. The source information indirectly tells us about levels of authority, and thus can be used to understand the priority of a requirement level.