In this article, I cover what are good requirements vs bad requirements. In short how to write clear requirements.
This is a big topic that could take a whole book to break down the method, however, this is an abridged version.
But before we get started.
“Business analysts must have thick skin: thick enough to take feedback on documents and receive unexpected answers to questions!” — Laura Brandenburg
Hmm and moving on
Did you know that the average $3 million project costs companies using poor requirements practices an average of $5.87 million per project — a $2.24 million premium? , according to s study conducted by IAG Consulting’s new Business Analysis Benchmark.
That’s a lot!
Let’s start with the basics of defining what a requirement is. A requirement defines what is needed or wanted as it relates to change.
In the context of Business Analysis, a change warrants the Business Analyst to assess, elicit, and document the needs of the stakeholders such that it adds value to the stakeholders.
Why Should you Write Clear Requirements?
Clear Requirements = Successful Delivery = Happy Stakeholders = Robust Product
The more time spent writing clear requirements, the more likely it is that the end product will function as expected by the stakeholders.
As illustrated above there are ripple effects to having clear requirements. The more time spent upfront clarifying the needs of the stakeholder’s the better the outcomes of the effort. If the stakeholders and the project team are concerned about the outcome then quality matters.
Writing requirements clearly can reduce the cost of building a product
Remember I had mentioned the cost of bad requirements earlier on, well that is evidence in itself that the stakeholders should be concerned about the clarity of the requirements and what is a document. This relates directly to the quality of the product delivered.
Just because it will make you a better Business Analysis Practitioner
It doesn’t matter if you are a newbie or an experienced practitioner, building your clarity muscle is critical. The testers, the developers, and the stakeholders will thank you for that.
You may ask yourself, well what are bad/ unclear requirements and honestly you won’t know they are bad until you have written a bad requirement and someone points that out to you. For this article lets use the word unlcear and not bad.
Here are some examples of bad requirements.
Bad requirements have the following characteristics with examples. The use case for this example is to design the home page for a blog.
Table 1:
| Bad requirement Characteristics | Examples |
| Irrelevant | The website visitor shall have the ability to not purchase the items. |
| Inconsistent | Requirement in the same document:The website user shall have the ability to log in to the account on the home page. Requriements further along in the same document:The website use shall have the ability to log in to the account on the contact us page. |
| Negative | The website user won’t need to click on the ‘Payment Submit’ link more than once. |
| Long | The website user shall have the ability to click on the home page at the top OR the home page in the right side menu to go back to the main page |
| Redundant | Requirement at the start of the document:The user shall have the ability to access the contact us page on the home page. Requirement further along in the document:The user shall have the ability to access the’ Contact Us’ page on the ‘About Us’ page. |
| Have a lot of And’s and Or’s in one requirement | The website user shall have the ability to click on the home page at the top OR the home page in the right side menu to go back to the main page |
| Mentions Wants | The website user will want the ability to contact technical support |
| Talk about the How Vs the What | The system shall use WordPress to develop the website |
| Not specific enough | The website should be available round the clock |
What are the 4 Steps to achieve clarity in requirements?
Step#1: Follow a requirements template
Imagine for a second that you are a new teacher thrust in the midst of chaotic kindergartners. I bet you would feel overwhelmed and the feeling of wanting to run away. Pretty much the fight or flight situation.
Well, now imagine that you are a brand new BA in an organization that is thrust into a new 100 million dollar project. I bet you would feel overwhelmed and asking your self why the heck did I ever want to be a BA.
In both situations, the teacher and the BA should have tools that they can use. Using a template is a tool and adds structure such that it makes sense out of chaos.
Ask if there is a company standard template or if not use one that makes sense.
That being said, make sure you have the following sections are in any template:
- Background of Project
- Glossary
- Assumptions
- Constraints
- Scope – In Scope/ Out of Scope
- Business Rules
- Business Requirements
- Functional Requirements
- Non Functional Requirements
- Attachments/ Examples/ Models
Understand the assumptions before you delve into the requirements.
Afterall Assumptions = Unknowns = Risks
Step#2: Avoid the usage of AND/ OR in one requirement
A few years ago I attended some toastmasters sessions and among their guiding principles is to avoid the use of the hmmm’s and the ands while you speak. It’s the same principle with requirements.
If you have an and/ or in your requirement that is a sign to breakout the requirement in two requirements instead of 1.
In the example in Table 1 the requirement as, the website user shall have the ability to
There you have it this
Step#3: Usage of Shall, Should, Will Vs Must in your requirements
When I first started out as a Business Analyst there was this big debate on the usage of Shall Vs Must. The usage of the word “Must” enforces something and may not be ideal to use if the stakeholders have a desire to see specific functionality.
However, the word shall has been pretty much universally accepted by the internal and US legal system. Here is a breakdown of when to use these words in your requirements.
Table 2:
| Word | When to Use | Example |
| Will | Used as a statement on fact | The report will contain the following data elements …… In this case, a report exists and therefore the requirement is to replicate the existing report. |
| Should | Used to indicate a requirement that is not mandatory but should be looked into to see if this can be implemented | The website user should have the ability to interact with a CSR via chat. |
| Shall | Makes a requirement binding and must be implemented/ verified | The User shall have the ability to click on the submit button. |
| Must | A mandatory requirement. The recommendation is to not use this. | N/A |
Step # 4: Mind those TBD’s
Developers and Testers hate the word TBD. A TBD is ok to include in the requirements however one trick to use for TBD’s is to atleast get a temporary understanding of what the TBD should be and include a Rationale as to why the requirement is left as a TBD.
As an example, the System shall be up 10 – 20 hours a day. Rationale: The CSR’s use the system from 7:30 am EST to 6 pm EST during business hours There can be instances when the system is needed by the business beyond those hours.
In the above example it is perfectly ok for the business to provide a range of the hours. It’s only when the developers provide the system impacts to those hours and there has been a conversation around what works and does not work by both parties that the hours of the system can be determined.
Conclusion
These are just 4 steps for you to start improving the clarity of our requirements. If done right, requirements can be a cost saver to an organization. They can help you be the go to person on requirements in your organization.
To Summarize:
- Follow a Requirements Template
- Avoid the usage of And/OR in one requirement
- Usage of Shall, Should, Will Vs Must in your requirements
- Mind those TBD’s
What are some requirements practices that are effective in your Business Analysis Practice?
