Characteristics of Good Requirements

What are the few qualities that we can adhere to while writing the requirements? Here is a checklist which can help to write a good piece of requirement.

Cohesive: The adjective form of the word says ‘tending to stick together’. Words to correlate this quality are Connected, United, Bound, or well integrated. All the requirements should be related and should support the same objective / purpose or intent.

Complete: Words to make the meaning more appropriate from requirements perspective are Entire, Full or the opposites as Incomplete, or Partial. All the needed requirement aspects are documented. The document does NOT lack any piece of requirement and we don’t have to look outside for the requirement. In other words, the requirement is self-contained.

Consistent: The individual piece of requirement can be uniquely identified and does NOT contradict with the other piece of requirement OR with the similar / same requirement called out again. It’s always advisable, to write a piece of requirement just once, and then if required, put a reference or call out the section, rather than re-writing the same piece again. This helps in maintaining consistency and avoid any contradiction.

Correct: The question to ask here is “Does this capture the business requirements and/or user expectations correctly?” One way to ensure this is to establish the traceability with the business requirements.

Modifiable: A piece of requirement can be modified without impacting the rest. It’s important to keep the requirement organized, so that the changes can be easily recorded. The advise mentioned in requirement quality ‘Consistent’ also helps in managing this quality too (Note that, we have put a reference to this advise and have not mentioned again).

Unambiguous: A simple term for this quality is ‘Clear’. There would be lot of stakeholders who would be reviewing and using the requirement for various purposes and it’s quite essential that the requirement leads to just one interpretation for everyone who reads it i.e. there is no second / alternative meaning.

Feasible: The question to ask here is ‘Can the requirements be implemented realistically?’. There are times, when requirements are defined, but either the business or technical constraints does NOT allow the requirement to be implemented.

Testable: Are the requirements written in a way that they can be tested? If they can NOT be tested, there will NOT be anyway to ensure the solution meets the business expectation. In a nutshell, all the requirements should be able to get tested.

We can call them as ‘Best Practices’ for requirement. I believe, we should keep this handy and run through them whenever the requirements are written.

Reference: BABOK v2.0, Watermark Learning