requirements documentation

Once all of the requirements have been gathered, it is time for the analyst to write the requirements specifications document. Let us discuss the best practices that are applicable to all types of the documentation (see Table).

Each requirement listed in the document must be necessary. While it may sound somewhat silly to question the necessity of scope components since the stakeholders asked for them specifically in the first place, industry studies show that as much as 50% of requirements can be cut from the scope of the project by asking a simple question like, “Do you really need this feature?” or, “Would a project be a ‘no go’ without this component?”

The necessity of the requirement can also be checked in the following fashion: if one can trace the requirement back to the parent business problem via the parent feature and the relationship is still logical, then the requirement is most likely indispensable.

Each requirement must be verifiable, which implies that the requirement can be tested. This criterion is strongly related to the ambiguity that will be discussed a bit later in this chapter. In general, if the requirement is not measurable, it is very unlikely that it would be verifiable. For example, requirements like:

• “The building shall be sustainable”
• “The system shall be efficient”
• “The light bulb shall save energy’

are not verifiable since different people can – and most likely will have a different understanding what “sustainable”, “efficient” and “save energy” mean. On the other hand, statements like:

• “The building shall generate 50% of the energy it needs”
• “The system shall decrease the account opening process from 27 to 4 operations”
• “The light bulb shall have a luminous efficacy of at least 55 lumens per watt (lm/W)

are completely verifiable because it is very easy to test whether they conform to the requirements imposed on them by the stakeholders.

 

Criteria For Good Requirements

Criteria

Explanation