How to write a good requirement
When buying enterprise technology, well-written requirements are crucial to making the right choice on your technology evaluations.
Get those requirements right, and you’re the hero who has saved everyone time and money. Get it wrong, and you end up with tenders, vendors, and solutions that do nothing but hemorrhage money.
Requirements Specific Documentation (RSDs) or Software Requirement Specification (SRSs) communicates your specific business software needs to potential suppliers or developers. They need to be precise and carefully written because they can transform your business, relieve long-standing issues and boost productivity.
Do not become another example of a company with ‘Never enough time to do it right, but always time enough to do it over.
Our guide is here to help you write short, articulate, and unambiguous requirements that tie directly to your overarching business needs and objectives and lead you down the path of success.
Best Practices for Writing a Good Requirement
1. Understand the difference between a ‘Need’ and a ‘Requirement.’
The International Institute of Business Analysis (IIBA) defines a “requirement” as a condition or capability required by a stakeholder to solve a problem or achieve an objective.
A “need” is a high-level representation of the requirement needed. The need is the end result or purpose. It is the "why we are doing this.”
Mohamed Elgendy Illustrates the difference below;
“Business needs identify and define why a change to an organizational system or capabilities is required.”
“Requirements are what need to be done in order to achieve the need or goal.”
Requirements shouldn’t be overcomplicated. We often feel the need to be emotionally expressive or verbose to communicate the importance, but vendors need absolutes and definition.
2. Use requirements templates
Good requirements focus on a clear result for the end-user. If you decide to use requirements templates, stick with tested templates that vendors are used to seeing. Among the most common is the “The software shall do ‘X’ to achieve ‘Y’” format.
3. Use the correct requirements terminology
Don’t stuff language in that doesn’t need to be there and stick to requirement terminology. Use the term:
- ‘Shall’ for stating the requirement.
- ‘Will’ for stating facts.
- ‘Should’ for stating goals.
4. Ensure each requirement has no ambiguity
Requirements should be clear, defined, and unambiguous. A good requirement expresses one need and it cannot be interpreted any other way.
Avoid using words like “and/or”. If you need these or the requirement is complex, break it up.
Bad Example: “We want the system to be user-friendly and accessible.”
User-friendly to who and what constitutes accessible?
Good example: “The software shall be remotely accessible by the customer care team.”
5. Keep the requirement short.
Long requirements are rarely concise enough to be clear. Keeping your statements short and to the point leaves very little room for things to be misinterpreted.
6. Understand the difference between functional and non-functional requirements
Functional requirements articulate what the system should do.
For example: The software shall send a verification request upon account creation.
Non-functional requirements describe how the system will perform the function and the limits expected. These are based on your expectations of what the new software should do.
For example: The software shall send a verification email 3 minutes after a profile has been set up.
Most requirements will have elements of both functional and non-functional.
7. Avoid linguistic pitfalls in your requirement
Making linguistic assumptions with requirements is not a good idea.
Do what you can to avoid the following:
- Ambiguous and subjective terms: versatile, user-friendly, bespoke, easy to use, robust, usability, good, and approximately.
- Jargon. If only your company or industry says it, it’s not clear to others.
- Clauses. eg. Except, if necessary, but, if possible…
- Abbreviations, acronyms, adverbs, rambling, and buzzwords.
- Splitting one requirement across others. It should be explicitly stated on its own rather than deduced from other requirements if it is important.
- Negative requirements. Don’t say “We don’t want it to do X”. What do you want?
8. Review your requirements
Put the requirement in the hands of the team and ask them what they think it means. If the stakeholders are unsure, you need to rewrite your requirement.
Considerations for writing requirements
Solid requirements create a mutual understanding and agreement between stakeholders on what the software should be able to do, how it should do it, and give you an agreed basis to judge the success of the software.Writing requirements is not a one-size-fits-all approach but there are certain aspects you should always consider:
Is this requirement needed?
Is your requirement an essential function - a non-negotiable? You should rank your requirements from low priority to mandatory (nice to, should or must have).
Is this requirement verifiable?
It should be possible to inspect, test, and demonstrate the requirement. In testing, your team should be able to tell if it works and has been implemented correctly. Poorly written requirements are unclear and don’t give you any certainty when you conduct testing.
Is the requirement feasible?
We’re all for dreaming big but is it actually possible to do what you are asking? If you don’t have the technology, budget or schedule to support the requirement, the requirement should not exist.
Don’t underestimate the importance of a well-written requirement
Writing good requirements is essential but it does take practice and it always helps to have a guide. Think of it as being lost and having enough data to send one short message for help to a loved one. Will the recipient of the message know what to do when they receive the message? Or will you be stuck in the trenches of legacy software?
If you lack the time or confidence, Olive is here to help. We provide you with libraries of vendor-validated requirements that help you articulate exactly what you need. You can access our examples or just use them as triggers for other potential conditions.
We know that ambiguity, oversights, and mistakes happen easily, yet the risks of choosing the wrong software have never been higher. Team demoralization, lost revenue, wasted time & effort, replacement costs, shelfware, or even worse, workaround solution costs can far exceed the intended benefits.
Olive helps you to drastically reduce these risks and cover your basis by helping you capture & share clear, unambiguous requirements with potential vendors.Olive guides you through the technology evaluation process in less time than a traditional RFI/RFQ/RFP process, so you can put the work into getting your requirements right. Olive’s platform will save you time and money while giving you the best opportunity to select software that will deliver measurable benefits and take your company to the next level.