As the first stage in the Software Development Lifecycle, defining requirements is critical for the success of your project. When done correctly, a requirements specification can communicate a complete vision of the project’s design goals for all stakeholders. It may even serve as a legally binding contract agreement between you and your client. As important as it is, it’s a stage that’s often overlooked or oversimplified by many developers.
It’s one thing to think about the needs of the project and what the software needs to accomplish, but there’s a whole other skill that comes with being able to capture these requirements effectively on paper. Thankfully, it’s not a hard skill to develop. Simply knowing what makes a good requirement definition and what to look for when reviewing requirements specifications will make a tremendous difference.
I find myself repeatedly falling back on the guidance from Design for Electrical and Computer Engineers, and the 5 traits I discuss below are summarized from IEEE Std. 1233-1998 as cited in the book.
The 5 Traits
- Abstract. Requirements should only state what the system should do, not how it should do its job. Be wary of overspecification – if you find yourself discussing the implementation details of a system, try to take a step back and think at a higher level.
- Verifiable. There must be a way to measure or demonstrate that the final system has met the requirement. If there’s no way to verify that the requirement is met, then it shouldn’t be a requirement! Throw out unverifiable requirements at the beginning – the person writing the test plan will thank you later.
- Unambiguous. Requirements should only have one meaning. Try to have as many people review the requirements specification as possible to ensure that there is only one interpretation for a given requirement. Writing requirements in short, complete sentences can help achieve this goal.
- Traceable. Each requirement should be traceable to a customer need. If the design doesn’t achieve what the customer needed, it cannot be considered a success. Ensuring the traceability of engineering requirements will help reduce scope creep and keep the project focused on its true goal.
- Realistic. Requirements must set objectives that are technically feasible. Unachievable requirements doom a project from the start. Perform some up-front research or modeling to make sure you are setting realistic targets in your requirements. If it is difficult to determine the technical feasibility of a requirement, be sure to build in some tolerance and update it as the development proceeds.
Conclusion
The next time you are faced with creating or reviewing requirements for a project, stop and ask yourself, "is this requirement abstract? Verifiable? Unambiguous? Traceable? Realistic?" If you answer no to any of those questions, try to figure out a way to rework or rephrase it. Perhaps you need to throw out the requirement altogether! The key is to catch problems with your requirements up front, as poorly written requirements will only have a cascading negative effect as the project progresses.