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


Signoff – Challenges and how to approach them ?

Requirement sign off is one of the key milestone on the Software Development Life Cycle and often considered as a dreaded milestone by the approvers or the signing authority.

Before we move on see why this is considered that way, and how do we approach this, let’s understand, why an approval is required on the requirement package.

Why  sign-off is required?

When a requirement is presented for the sign-off, the requirement is basically the business analyst’s understanding of the scope, business requirements etc. Obtaining a sign-off ensures that the stakeholders goes through the understanding that the Business analyst have and fill up the gaps if any; that way, ensures that the solution requirements are captured and will be delivered in the right direction (this is the first step towards building the right product). This also helps in resolving any conflict that may arise in future where the stakeholder may change their mind on the requirement and the construction has already begun.

Why this is considered a dreaded milestone?

Continue reading


What is traceability ?

The relative form of ‘Traceable’; the dictionary meaning says “capable of being traced” i.e. the series of footprints, the track or the path, anything which can help what we are looking for. On the software engineering, an important aspect is ‘trace the requirement’.

So, what is the need to ‘trace the requirement’? because there is a possibility, that on the subsequent phases of the development and testing we may miss the track and that way we reach to a destination (product), we are not suppose to (deliver). Either, we move on a completely off the track, stopped before the destination (missing requirement) OR moved ahead of the same (deliver extra functionality), not realizing, we have already crossed our destination long back. So, traceability helps sticking to the track and the destination.

Speaking specifically on the requirements aspect, traceability is all about discovering and maintaining relationships between important facets of Requirement, such as the following:

Continue reading