Good requirements are crucial to the success of a software team and product. Requirements drive the design, development, and user experience of the software. They are the foundation of the project. Writing better requirements can take productivity and quality to the next level.

Writing better requirements

IEEE Best Practices for Requirements

The IEEE 830 states that software requirements provide the following benefit:

  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 basis for estimating costs and schedules.
  4. Provide a baseline for validation and verification.
  5. Facilitate transfer.
  6. Servers as a basis for enhancement.

Problems with Requirements

Many of us have probably encountered problems with requirements. Maybe the requirements weren’t clear, or maybe they didn’t exist at all. Perhaps you’re in a role that involves writing requirements, and you struggle with how much detail to include.

In this article, we’re going to take a look at some things you can do to ensure your requirements are the best they can be.

Tips For Writing Better Requirements

Requirements should be unambiguous

There are a number of ways in which to write something. Likewise, there are a number of ways in which something can be understood. Good requirements should only be understood one way. Avoid subjective words like “simple” and “user-friendly”. These mean different things to different people. Be as clear as possible with your requirements.

Requirements should be short

Requirements statements should be just that; statements. Long, drawn-out paragraphs risk ambiguity and confusion. Further more, short statements make for better organization and readability within the requirements document.

Requirements must be feasible

A requirement isn’t anything if it’s not possible to do the thing the requirement states the software should do. Feasibility can be related to the technology, business, or finances. If the technology isn’t there to support the requirement, the requirement shouldn’t exist. If unrealistic (unfeasible) needs are being asked of the business, the requirement shouldn’t exist. And if the money isn’t there to make it happen, the requirement shouldn’t exist.

Requirements should be prioritized

How essential is it to include the requirement? Is it a “nice to have” or is it a mandatory thing? Use a simple ranking scale like ‘Low / Medium / High’, or ‘Mandatory / Nice To Have’ to rank your requirements. Prioritization helps make sure your team is focusing on the things they need to be.

Requirements should be testable

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

Requirements should be consistent

Use consistent terminology. Create a glossary or a style guide if necessary. If you’re writing requirements for Admin users, don’t flip back and forth between “Admin User” and “Administrator”. Inconsistency leaves room for confusion.

Requirements shouldn’t include conjunctions like “and” / “or”

Requirements statements that include “and” / “or” are probably actually two different requirements. Avoid using these words to ensure your requirement is focusing on only one thing.

A Few More Tips

  • Use certain words to convey certain things. “Shall” should be used to signify what the system must do. “Will” should be used to represent facts. “Should” should represent a goal to be achieved.
  • Use templates for requirement statements: The <thing> shall provide <something> to achieve <this>.
  • Good requirement statements focus on what the result of the requirement will provide for the stakeholder.
  • Use bold and other formatting to emphasize importance.
  • Avoid using etc, and/or, and other ambiguous words.

Example Requirement

Let’s pretend we’re writing a requirement for what should be included in an email notification for a payment processing application.

Bad: The email notification must include the relevant information.

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

Conclusion

Writing better requirements takes practice. Put yourself in the developers shoes as you write your requirements. Ask yourself, “as the developer, do I feel confident in what this requirement is asking?”. If you have any doubt, your requirement probably needs work. As you continue to practice requirement writing, get feedback from your peers and keep an eye out for how others are writing requirements.

By writing better requirements, you’ll add immediate value to your entire team.