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 |
Explanation |
|
Necessary |
Can the system meet prioritized, real needs without it? If yes, the requirement is not necessary |
|
Verifiable |
Can one ensure that the requirement is met in the system? If not, the requirement should be removed or revised |
|
Attainable |
Can the requirement be met in the system under development? If not, the requirement should be removed or revised |
|
Unambiguous |
Can the requirement be interpreted in more than one way? If yes, the requirement should be revised |
|
Complete |
Are all conditions under which the requirement applies stated? (e.g. all possible scenarios, alternatives and exceptions) |
|
Consistent |
Can the requirement be met without conflicting with other requirements? If not, the requirement should be removed or revised |
|
Traceable |
Is the origin of the requirement known? |
|
Concise |
Is the requirement stated simply and clearly? |
|
Design Free |
The requirement should be stating what must be done without indicating how |
|
Standard Constructs |
Requirements are stated as imperative needs using “shall” |
|
Unique Identifier |
Has the requirement been uniquely identified? |
|
Prioritized |
Has the requirement been assigned a priority relative to other requirements in the document? |
The attainability simply means that the requirement can be implemented in the product or service considering all the limitations of either technology, budget or time constraints of the project.
Ambiguity is defined as uncertainty or inexactness of meaning in language. Requirements ambiguity is one of the most dangerous time bombs in the specifications documentation and one of the most difficult ones to catch. Let me demonstrate it by sharing a couple of examples from my consulting practice.
The first story was conveyed to me by a senior manager of a construction company in Saudi Arabia. One of the services his organization provided was building of luxury villas for the local business elite. At one point of time the crew has finished erecting the walls of the house and building internal partitions. The building site was visited by the client, a vice president of large company whose wife happened to be pregnant at the time. The construction manager, whose command of both Arabic and English languages was, shall we say, poor took him on a tour of the building. When they got to the master bedroom the following conversation took place:
Construction Manager: And this room will serve as a master bedroom.
Client: (Pointing at one of the walls) And what is on the other side of this wall?
Construction Manager: There is another smaller room.
Client: Great! We will make it a baby room! And I want you to install a baby door over here (pointing to the wall again).
What do you think the client meant by “baby door”? Of course, he meant “the door through which my wife and I can get access to the baby’s room”! What do you think the construction manager who was too intimidated to question the client about his intentions, installed? A door about a third of normal size!
“It was actually very embarrassing on two levels,” said the manager who told this story, “first, the client was left with an impression that we have somewhat inadequate people working for us and second, the door the construction manager installed ended up costing almost ten times more because this was a custom order! And, of course we had to fix this problem at our own expense.”
Another story comes from a North American port authority whose CEO told the following ambiguity-related story:
“We were planning on building a cruise ship terminal. And somehow we allowed the expression ‘state-of-the-art’ to sneak into the project charter. From the project charter it was allowed to migrate to the requirements document and to the project plan.
Now, we had the following stakeholders on the project: the federal government, state government, municipal government, several cruise ship companies and the port authority itself. Do you think they all had one united vision of what ‘state-of-the-art’ means of a dozen different ones? Some stakeholders insisted on expensive building materials, others wanted to automate pretty much every function of the building and yet others wanted the facility to be 100% sustainable ... It was a nightmare! We went fifty million dollars over the budget because of just one phrase.”
Completeness of the requirements is also one of the potential time bombs in any specification documents and is quite difficult to catch. Complete requirement implies that all potential alternatives and exceptions in the requirements have been foreseen and addressed properly.
Consistent requirements are the specifications that do not conflict with other features and scope components.
Requirement traceability and unique identifiers are also closely linked since it would be fairly challenging to trace the requirements, especially on larger, more complicated projects if they are not labeled properly, e.g. BR 1.0, F 3.11 or Req 5.10.2.
Requirements should also be written in a concise manner with sentences being short and to the point, preferably in a simple, easy-to-understand language that can be “absorbed” by all types of audiences. It is also preferable that the requirements are written using standard constructs preferably with the verb “shall”:
- “The building shall be 175 meters high”
- “The ladder shall be able to support loads of up to 300 pounds”
- “The system shall be available 99.9% of the time”
The requirements must be design free, in other words they should not say how the requirement will be implemented (i.e. the technical solution), but only what is needed.
Finally the requirements must be prioritized.
This is an excerpt from my new book “Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects” that is being published by CRC Press The book should soon be available on Amazon.
About the Author
Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East. Read Jamal’s Blog @ www.thinktankconsulting.ca
- Please follow me on Twitter:
- Like our page on Facebook:
- Connect with me on LinkedIn:
- Subscribe to my RSS feed:
Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.