How To Write Good Requirements (With Example)

A usable set of good requirements is essential to the success of software teams and the products they build. Requirements help align the team around a project and give engineers and designers the information they need to execute their work successfully. In addition, they drive the design and development of the software and ensure the user experience meets customer needs. Writing good requirements takes skill and time, but they can ultimately improve the quality of your product and make your team more productive.

What is a requirement?

Each requirement details a function that a product must be able to perform, and the importance of requirements is that they operate as a single source of truth for the software team to reference, helping them plan their work. Requirements sit in the gap between an initial idea and the final product, and they carry specific details on how a piece of functionality must work. They serve as the foundation of a project and influence all successive work.

IEEE standard best practices for requirements

The IEEE 830 recommends that software requirements provide the following benefits:

1. Establish the basis for agreement between the customers and the suppliers on what the software product is to do.
2. Reduce the development effort.
3. Provide a rationale for estimating costs and schedules.
4. Provide a baseline for validation and verification.
5. Facilitate transfer.
6. Serve as a basis for enhancement.

Potential problems with requirements

You may have encountered poorly written requirements at some point. They may have been unclear or perhaps didn’t exist. Here are some commonly encountered requirements problems.

Ambiguous and complex to read

If requirements are unclear, they could be open to misinterpretation. Consequently, a misunderstood requirement could lead to incorrect work, which could be costly.

Missing requirements

When a requirement is absent, the design and development teams are left with a lot of unanswered questions. This situation wastes time for the team and risks them making incorrect assumptions.

Incorrect terminology

Requirements are a communication tool that helps the product team to be successful. Using standard terminology that your team also understands is critical. Using variations or unexpected words to explain things might be confusing.

Writing how instead of what

Requirements should specify what a specific feature should do, not how it would be done.

Wrong grammar or poor sentence structure

A requirement might contain all the necessary information, but if it’s written poorly, it will be challenging to understand. So take extra care to avoid sloppy writing practices when creating requirements.

How to write requirements

No ambiguity

There are often multiple ways to write the same thing, but that can also mean there’s more than one way it can be understood. Therefore, requirements must be written in ways that have just one clear interpretation. It’s also a good idea to avoid subjective words like “simple” and “user-friendly” because these mean different things to different people. Be as clear as you can with your requirements.

Be brief

The essence of a first-rate requirement is its brevity. Therefore, limit your requirement to statement length because long, drawn-out paragraphs risk ambiguity and confusion. Furthermore, short accounts help with better organization and readability within the requirements document.

Are they doable?

A requirement can only help if the software can do what’s being asked of it. Feasibility questions can relate to the technology, business, or finances involved. If existing technology cannot support the requirement, or if unrealistic, unworkable needs are demanded of the company, the requirement should be abandoned. This is also true if financial limitations would make the requirement impossible to achieve.

Rank requirements according to priority

How necessary is a specific requirement? Is it a “nice to have,” or is it mandatory? To help with basic prioritization, use a simple scale, like Low/Medium/High or Mandatory/Nice To Have, to help rank your requirements. Prioritization helps your team with clarity and direction.

Are your requirements testable?

Testers should be able to verify that the requirements have been implemented correctly. The test should either pass or fail. Ambiguous requirements make it impossible to determine a pass or fail.

Use consistent terminology

It’s essential to keep terminology consistent to avoid ambiguity. Create a glossary or a style guide if necessary. For example, if you’re writing requirements for Admin users, don’t flip back and forth between Admin User and Administrator. Inconsistency leaves room for confusion.

Avoid using conjunctions like “and”

Requirement statements that include connecting words like “or” “and” or “yet” are probably addressing more than one requirement. By avoiding the use of these words, you ensure each requirement focuses on only one thing.

Five tips for writing better requirements

• Use precise words to convey specific things. “Shall” should be used to signify what the system must do. “Will” should be used to represent facts. “Should” will define a goal to achieve.
• Use a template for requirement statements such as The <thing> shall provide <something> to achieve <this>.
• Strong requirement statements focus on what the result of the entire requirement will provide for the stakeholder.
• Use bold and other kinds of text formatting to emphasize the importance of certain parts.
• Avoid using ambiguous words or terms like “etc.” or “and/or” because they are undefined.

How to set priorities for requirements

Requirements can stack up over time which can be overwhelming. Some projects can even have hundreds or thousands of requirements. If so, how can we know which to build first or which to support with more resources? Prioritizing requirements will help you gain the clarity to know which ones to focus on. Here are some points to consider when prioritizing requirements:

1. Benefit – What will the business or your customers gain from a specific piece of functionality?
2. Penalty – If a particular requirement is not implemented, could there be undesired consequences?
3. Cost – Consider the level of effort and resources needed when prioritizing requirements.
4. Risk – Various reasons might cause the requirement to fail to deliver the expected value.
5. Dependencies – Some requirements are dependent on others. Therefore, perform the connected requirements first to allow the latter to proceed.
6. Time Sensitivity – There might be deadlines connected to some requirements that will need earlier attention.
7. Regulation or Compliance – These requirements may be needed to comply with changes in laws or rules.

As you can see, there are several things to consider when prioritizing requirements.

An Example of a Requirement

Lastly, imagine we are writing a requirement about the contents of a payment processing application’s email notification.

Poor: The email notification must include the relevant information.

Good: The email notification shall include the dollar amount, date, payee name, and identification number.

Conclusion

Writing good requirements takes practice. Put yourself in the developer’s shoes as you write and ask yourself, “As the developer, do I feel confident in what this requirement asks?” If you have any doubts, your requirement needs further work.

As you continue to practice writing requirements, get feedback from your peers and stay aware of how others write requirements. Good requirements add immediate value for your team and customers.