How To Write a Good Requirement? 14 Qualities

In project management, everyone talks about requirements and classifications, like technical, software, functional, business and non-functional. But have you ever considered what makes a good requirement?

A good requirement should be clear, complete and correct. The latter means the final delivery addresses business needs. A clear requirement written in simple language improves understanding. A complete requirement considers all relevant stakeholder.

The Business Analysis Body of Knowledge (BABOK) defines a requirement as “a usable representation of a need.” In essence, these are conditions that become guiding ideas for a project and answer questions like:

1. What the tool or process will do? 
2. How will it achieve it? 
3. What are the constraints?

In the post, we will concentrate on the word “usable“, which will help us understand how we should write requirements. So, if we want to deliver projects that meet user needs and give them a solution they want, we need to make sure that our requirements fit for purpose.

Yet, many other attributes make a good requirement, and I recommend looking through all of them in the post so you can write that perfect requirement. The post will have the complete list, explore the importance of each aspect of the requirement and address ways to improve the quality. 

When Should You Consider The Quality Of Your Requirements?

You should review and write all your requirements at the project’s requirement engineering stage, thus avoiding pitfalls in the executing stages. Sure, you can address a lot of issues by just sensibly considering the clarity of each requirement.

However, it is always helpful to have a complete list to make sure that you have not missed a single thing, and your project will go smoothly with everyone knowing exactly what needs to be done. 

What Are 14 Qualities Of A Good Requirement? 

To write a high-quality requirement, we should consider the 14 qualities below. They could serve as a check-list when you are constructing your project requirements.

1. Clear or Understandable
2. Complete
3. Correct
4. Testable
5. Prioritised
6. Traceable
7. Achievable
8. Categorised
9. Relevant
10. Concise
11. Unique
12. Conformant
13. Owned
14. Consistent

Wow, it is a long list, but I promise you it will make your requirement crystal clear at the end. How can it not? Also, it will save you a lot of headaches. So, let’s go exploring each attribute with some examples.

1. Clear or Understandable Requirement

Why are clear or understandable requirements important?

If you have written a requirement, you will want to make sure that others understand it. However, it is not enough to write a requirement without spelling mistakes or grammar errors. You will need to make sure that people from different backgrounds or various levels of experience can follow it. 

Some people will be just a bit more technical and some business focus. Yet, they all need to understand what you have written. Project is a team sport, and it more likely than not that multiple individuals will need to contribute. 

How can you ensure the requirement is clear and understandable?

It will help if you appreciate the readership of your requirements. Investigate where they fit on a scale of business vs technical knowledge and adjust your documents accordingly. If you must add some technical aspects for business readers, then make sure you explain the meaning in the document. The same holds if you have business domain terms and need technical people to comprehend them. Maybe even include a Glossary of Terms to cover all bases. 

Finally, you could make sure that the requirements are not too difficult to read and have an excellent readability index. You can use tools like Microsoft Word or Grammarly, which I am currently using to write this post. I think Grammarly has some great tools to improve your writing in many ways.

Good requirement example

A new e-bike shall have a battery capable of supporting bicycle range of 100 miles (or 160 km). 

2. Complete Requirement

Why are the complete requirements important?

Completeness is very difficult to achieve. The goal is to include all requirements that you need to have a successful project. Therefore, we need to look more holistically into the whole set of requirements for the project and ask ourselves if all together they coherently cover overall business need or objective. 

However, it is tough to know things you are not aware of, yet you still should. Otherwise, the project may fail. So, how to solve this unsolvable problem!?

How can you ensure the requirement is complete?

First, you should know all your stakeholders by doing a stakeholder analysis. Check my post on stakeholder management. Get stakeholders and subject matter experts (SMEs) to review requirements, and ask what is not yet covered.

Second, check that your requirements address all scope elements, which should have been defined earlier in the project management process. 

Third, organise a workshop with the main stakeholders and go through use cases. Suppose process steps described by the session stakeholders are not congruent, then respectfully challenge business to explain. You should be able to spark a discussion (not an argument) to iron out some unknowns and improve your requirements.

3. Correct Requirement

Why are the correct requirements important?

There are actually two answers to this question. 

• One we have already answered, which is to make sure that the final product meets user needs. Thus, all of the criteria we are discussing in the whole post makes a requirement correct. 
• However, we could consider a second answer. The requirement is correct when it captures what the project set out to do in the first place, i.e. address specific business issues. 

Please, keep in mind that we do not want to capture the solution yet, and we should keep our requirements solution agnostic. There might be a different great solution in the market that will be discarded or not considered if you include a solution as a requirement.

How can you ensure the requirement is correct?

Consider all the criteria discussed in the post.

Plus, think if each requirement addresses problems or issues the business is trying to solve.

For all of your requirements, consider if you are not offering a solution but describing a need. 

4. Testable Requirement

Why are the testable requirements important?

Every single project will have a testing stage. When you build a system or change the process, you want to make sure that it works at the end. Thus, you need to set out your requirements in such a way that you can complete testing. 

To make them testable, we would need to ensure that our requirements are specific, objective (i.e. opposite to subjective) and measurable. If you do not have details recorded in your documents, you will not know if a particular testing result is a success or failure.

How can you ensure the requirement is testable?

Well, you want to review your requirements and add as many as possible specific and measurable attributes. If the e-bike needs to go 160 km with a single charge, then this is what you put in the requirement. Plus, having these specific numbers make the requirement to be objective.

Imagine the requirement says: “The e-bike will have an acceptable range with a single charge.” Who decides that!? What is acceptable!? You still have a way out in those cases; you can put a specific senior person in the document to make a decision.

5. Prioritised Requirement

Why are the prioritised requirements important?

All profit-seeking businesses want to maximise the value they get for the resources they use. Projects operate in the business environment, and of course, we want the same. All projects have triple constraints, time, cost and scope, which influences project outcome quality. 

We cannot give all resources to all requirements, and not all requirements are made equal. Therefore, we need to decide with the sponsor’s help which requirements to include in the solution and which will not bring much value. 

If you are running a project that deals with work packages, like Agile projects, prioritisation is essential. The Agile framework is used for reiterative projects, and you always complete the highest priority requirements first and package them for release at regular intervals.

How can you ensure the requirement is prioritised?

It would be best if you started by discussing the priority with individuals who raised requirements. If the requirement came from a document or process, it might be a sponsor who will decide. 

Review the importance of requirements against business and project goals. If you see discrepancies between business goals and priorities, then clarify with senior stakeholders who raised the requirement. 

If there is a disagreement about each requirement’s significance between senior stakeholders, have a wider discussion with them. Potentially you may need to escalate to higher management, like a steering committee (SteerCo).

6. Traceable Requirement

Why are the traceable requirements important?

Your requirement may come from various sources like interview notes, workshops or even unofficial coffee breaks. Yet, when you combine everything into one requirements document, you may lose the origin. And it could be a problem. 

It is essential to know the source because when you are completing the requirements’ analysis or need to clarify anything in development, you might need to go back to the source to get more details or even challenge the need.

How can you ensure the requirement is traceable?

There are a few ways you can ensure quality. First is relatively straightforward, record the source of the requirement in the documentation. 

The second is similar. You want to create a traceability matrix that tracks requirement through elicitation, build and testing. It helps with tracking the source and ensure that all of your requirements have been addressed and tested.

7. Achievable Requirement

Why are the achievable requirements important?

There are a few risks involved with having unachievable requirements in the document. 

If you keep unachievable requirements in the backlog, you may create false stakeholders’ expectations that your project plans to complete those. Thus, it may cause disappointment later down the line.

Also, due to misunderstanding, the project team may inadvertently try to solve unsolvable requirements and distract their attention from those that are actually achievable. 

How can you ensure the requirement is achievable?

The simple answer would be that you need to remove them from your requirements document. Maybe just keep them in the appendix for the record. Yet, it would help if you did not make this decision on your own. 

The requirement may have started in the process as an achievable, but changes in circumstances have changed the status. For example, you discussed the need with the technical team, and they have advised that the solution will fall outside either time or budget. You need to communicate new information to stakeholders and ask to either increase resources or remove the requirement. If they cannot make a decision, you may need to escalate to a SteerCo. Then update your requirements document accordingly.

8. Categorised Requirement

Why are the categorised requirements important?

The simple answer is that it is just easier to deal with your requirements when they are grouped. Say you are building an e-bike, then you will want all your functional requirements related to the frame be in one place. It helps you to see dependencies, find overlaps, and even areas you could save time.

How can you ensure the requirement is categorised?

You just need to figure out various groups that make sense to use in your project. The standard is to use functional or non-functional requirements, technical and general. Check out my post on both of these. When you have groups, make sure you can filter or at lease visually see each group separately.

9. Relevant Requirement

Why are the relevant requirements important?

There are two reasons you want your requirements to be relevant and to the point. 

One is that you want to make sure that requirements address the scope you have agreed on earlier in the project. If you are not addressing scope elements, you are managing something out of scope, which introduces “scope creep”. 

Second, it may be that the requirements are addressing the scope. Nevertheless, it actually does not give any new information to the project’s whole set of requirements and does not describe the business need better than what you already have. Thus, it may create confusion and waist time for people to figure out if there is a difference or not.

How can you ensure the requirement is relevant?

The first thing you can do is check in your Project Initiation Document or Terms of Reference (depending on the project). What did you have as a scope, and how your requirements fit in the whole picture. Then validate that your requirements have the right to exist individually. Or should you combine them with different requirements? 

Say you are building an e-bike frame and have an instruction to make it a triangle metal frame. Then in the next requirement, you specify that it should be an aluminium alloy frame. So, instead, you can say that we will need a triangle aluminium alloy frame. Now, it is relevant and more concise, which is our next attribute.

10. Concise Requirement

Why are the concise requirements important?

Here, we should consider both a single requirement independently and the entire list of the project’s requirements. 

When considering each requirement individually, we need to judge if it goes straight to the point, or we can remove some word without changing the meaning. You should not be using wordy phrases like “In order to achieve 95% accuracy…” instead of using “To achieve 95% accuracy…”. 

In addition to looking into individual requirements, we should also explore the whole project set. Similar to our aluminium alloy frame example. You should try combining two similar requirements into one if that does not omit critical information. Plus, the similarity could be because we expressed the same ideas in different words or took a different approach to describe the same problem or need.

You want to avoid both types of issues because it takes time to understand and process requirements, and if it is unnecessary, it is wasting project resources’ time. If you improve your requirements, both you and the reader can concentrate on the points, which the project is trying to achieve.

How can you ensure the requirement is concise?

As you have seen, there are a few things we can do. 

One is to be sensible and read through all the requirement, consider if a specific word used gives any additional important information. It may be that sometimes the whole paragraph is irrelevant or not important. So, you just need to press “delete”.

Further, you may need to combine multiple requirements into one if that does not change the requirements’ meaning.

Finally, we should use active voice. In the corporate world, people love using passive voice. It may sound more official, but actually, it hinders readability. 

11. Unique Requirement

Why are the unique requirements important?

Uniqueness links back to the requirement being concise and relevant. But there is one more issue with duplicates we have not covered. 

If you have two similar requirements, but because of using specific phrases, they contradict each other. Thus, it may cause execution issues as developers or project team might find it hard to understand what actually needs to be done. 

How can you ensure the requirement is unique?

Few things we have already covered when looking into categorised, relevant and concise requirements. For example, you need to categorise requirements to help you see if there are any overlaps.

Traceability strategy will help here as well. Suppose you have followed previous advice you having an excellent traceability map. It will save your life because if there are contradicting requirements, you will be able to identify the source or the owner and find out if requirements indeed are overlapping or are different. 

• If they are just duplicates or overlaps, you will be able to delete one or merger together after stakeholders confirmation.
• If you found out that these are actually different requirements, you should re-word to reveal the difference.

12. Conformant Requirement

Why are the conformant requirements important?

Having a standard format helps to save time, limit errors and increase readability for yourself and reviewers. You do not have to create “War and Peace” whenever you are writing new requirements. 

Agile illustrates conformant quality very well with the exact story format. It goes like this: “As a…I want (to)… So that…”. For example, “As a developer, I want to create a button in the header of the website. So that user can easily subscribe for a newsletter”. The structure tells you where to look for “Who”, “What”, and “Why”.

How can you ensure the requirement is conformant?

It will depend on the type of project framework your project uses; you may use a prescribed format if it is an Agile project. If your project’s framework is a waterfall or similar, you may need to create your standards for a single requirement or the whole business requirements document (BRD). Do not forget to check with your business if this is not the first project; there might be already templates available.

If you are the only one doing the requirements’ analysis, it may be easy to follow the format. Though you might want to agree on the standard, you will follow upfront if you have a buddy.

13. Owned Requirement

Why are the owned requirements important?

Every requirement should have an owner who can decide or explain, e.g. clarifying the need, resolving differences between two similar requirements, or approving changes. Plus, when the project does complete execution, we need this person to confirm that the project delivered the requirement as expected. 

In many projects, the owner will be a project sponsor, who often provides the budget. Still, this is not always the case, and some other senior stakeholders may be owners of the requirements. 

If you do not have a clear owner, you will have no one to verify that you have executed everything following expectations. If there are required changes mid-project, there is nobody to approve them. So, in short, the project will stall without clear direction.

How can you ensure the requirement is owned?

When somebody raises a new requirement, you should record the requestor as the owner in the beginning. Yet, the owner may change through the project.

Thus, if you find out that a more senior manager will ultimately need to sign-off a new requirement, update your documents. This way, you will always have someone to go-to for any clarifications.

14. Consistent Requirement

Why are the consistent requirements important?

Consistency is all about carrying the same message or meaning through the whole project. If you say that a particular requirement is for a customer, you would need to make sure that the customer has the same meaning in other requirements. 

Furthermore, different requirements should not possess contradicting messages because it will confuse the project team and decrease the probability of success, i.e. delivering what the business asked. 

How can you ensure the requirement is consistent?

The simple thing to do is to cross-check requirements and various meanings you assign to multiple words. 

To be extra thorough, you can create a Glossary of Terms or Dictionary to explain each concept and avoid any possible inconsistencies. You can also reuse the Glossary of Terms in your standard operating procedures (SOPs) for the same purpose.

Writing Good Requirement Conclusion

I hope after reading this post, you can see a few ways you can improve your current project requirements and increase the probability of success. Let’s go and do some quality requirements!? A good requirement is not only something fun to have but also removes many headaches later in the project. 

Unfortunately, with requirements, it is not as simple as logging everything stakeholders tell you. As a project team, we need to ensure we have quality requirements, which we can use over the whole project to the final delivery.

Let me know if you have ever thought about a good requirement in some many ways. Yet, I am sure if you had any issues due to requirements before, one of the qualities in the post will address them in the future.