Originally published on Developer.com, September 24, 2014.
Unit testing and test driven design don’t help you if your requirements aren’t right. It may be that trying to create the tests will expose that you have a problem but wouldn’t it be nice to know that there are gaps in requirements before you sit down to write code? Although it’s impossible to get perfect requirements, most developers would love to get requirements that are better than what they’re getting.
Whether you’re getting requirements from a business analyst or you’re creating them yourself, here are a few simple tips for ensuring that your software requirements are right. These tips are pulled from my Pluralsight course Gathering Good Requirements for Developers.
Ensurance
Here are some things that you should check to ensure they have been covered:
- Are all the stakeholders represented? Have you received feedback from all of the parties impacted by the solution?
- Do you have functional requirements for all user requirements? Were you able to translate all of the high-level user requirements into specific requirements?
- Do all of the events that the system must respond to have responses? If you look at all of the events such as approvals, rejections, creations, and the like, do they all have a system response?
- Are the boundaries for the system covered and are they clear? Every system has boundaries where it stops and boundary conditions for input and output ranges. Are these boundaries addressed and are they clear? Questioning whether something is lesser than, equal to, or greater than is the hallmark of this check.
- Are all of the potential states the system can get into covered? If you map out the possible states that the system can get into do you know how the system—or the users—can or should respond at each step?
These checkpoints can help ensure that your requirements are complete, but are the requirements SMART?
SMART
SMART is an acronym that can help make sure that requirements can be implemented. Specifically, SMART is:
- Specific: Is it clear exactly what is being said?
- Measurable: Is it vague or can it be easily measured?
- Actionable: Can you actually do something in the system to achieve the result?
- Realistic: Can you possibly implement the requirement?
- Time-constrained: Does the requirement tell you how much effort to spend on it? (Usually, this is described indirectly through the priority.)
Even if you’ve tried to create a SMART set of requirements, some vague words may have cropped up. Here are some vague words to look out for….
Vagaries
Here are a few imprecise words—and some questions to ask about them:
- Acceptable/Adequate: What’s acceptable to you versus what is acceptable to me?
- As much as possible: How do you measure this?
- Best/Greatest: As compared to what?
- Fast/Quick/Rapid: How long is that, exactly?
- Improved/Better/Faster/Superior: How much better? Can you quantify that?
- Generally/Usually/Almost always: What are the rules? What percentage of the time?
- Maximize/Minimize/Optimize: How much? What about the law of diminishing returns?
- Normally/Ideally: Under what conditions should this happen?
- Optionally: Who chooses?
- Probably: Will it or won’t it?
- Robust: What behaviors or functions make up robust?
There may be places where these words are necessary in a requirements specification. However, when it comes to specifying the solution, it shouldn’t be the case.
Stamping It Out
Creating good requirements—requirements that can be implemented—is a big job and, with all the details, it’s no wonder that it may be hard to get them right on a first pass. By going back through the specification with a critical eye looking for SMART requirements, imprecise words, and the idea that all the options and paths are covered, you can create a set of requirements to be proud of and—more importantly—a set of requirements that can make it easier for you to create exactly the system that your users are looking for.