Here at ArgonDigital, we are often asked what actually constitutes “good” requirements. If you gathered a group of project team members and started making a list of all the qualities that would define a “good” requirement, you would quickly become overwhelmed. We have narrowed the massive requirement wish-list down to the four essential qualities that “good” requirements should exhibit.
1. Atomic
An atom is the “smallest indivisible unit of matter that retains the properties of an element.” This is a good way to think about this requirement attribute. The requirement should be in its smallest indivisible form while still describing the capability requested by the stakeholder. If your requirement can be split into two (or more) separate statements, then it should be.
Example: “The homepage should display the sale item of the day and the customer’s account information if they are signed in” should clearly be split into two different requirements. Both required features are for the homepage, but are distinctly different functionalities.
2. Unambiguous
There are several types of ambiguity to watch out for – the most obvious form is when the requirement just doesn’t make sense. The second type of ambiguity is also easily identifiable – when you can think of more than one way to interpret the requirement. The third type is slightly more difficult to identify – when two different people understand the requirement, but have to different interpretations of what is being stated. Using your peers to review requirements is the best way to capture unambiguous requirements.
Example: “The system shall timeout if the page does not load in a reasonable amount of time” makes sense as a sentence, but “a reasonable amount of time” can obviously be interpreted in many different ways.
3. Testable
The requirement must provide a way to determine if the software built is sufficient. There must be a finite point distinguishing between passing and failing. If the test cannot fail, the requirement is not testable. This quality is most easily satisfied when you are creating requirements for something that has bounded limits, such as requiring that a password field have 6-10 characters including a number and a letter, or when the requirement just specifies that something be present. When defining the requirement, ask yourself “How will the testers know if the test fails?”
Example: “The system shall apply the entered payment amount to the customer’s bill” seems like it would be testable, but what if the customer enters “1000” – does that mean they want to make a $1000.00 payment or a $10.00 payment?
4. Necessary
If you ask the stakeholder, every requirement will probably be “necessary”. This is the one attribute that analyzes further than the statement and information within the requirement itself. The best way to verify that requirements are necessary is to trace them back up the chain – from nonfunctional and functional requirements to business requirements to business objectives. If the business objectives are measurable, preferably by a monetary value, you can easily determine which requirements are MORE necessary than others to determine where to make cuts if need-be. Requirements may also be necessary due to compliance purposes. It is important to document the business rules dictated by compliance standards and trace the requirements back to those business rules as well.
Example: “The webpage shall have a link to share via social media networking” is a common request from stakeholders. Is social media REALLY going to be valuable though? It seems like a good idea because social media is so popular, but it is not necessary or valuable for every application – when was the last time you shared that you paid your credit card bill?
It is not enough for a requirement to exhibit some or most of these qualities – requirements must be atomic, unambiguous, testable AND necessary to truly be high quality requirements. A good way to do a quick assessment of your requirement definition skills is to look at a sampling of requirements and see how many are satisfying all four criteria. If you find that you are not meeting all four criteria consistently, delve a little deeper and find out where your requirements are lacking.
