Author: Geri Schneider Winters
Consider all the different kinds of requirements you write – Use Cases, Business Rules, Security, Database, Performance, Usability, Reliability, Regulatory, “shall” requirements. Good requirements are well-defined. How can you determine if your requirements are well defined?
We often hear that good requirements are testable. This means you have some precise, unambiguous way of determining if the requirement has been met or not.
Of course, you can only define a test for a requirement if the requirement is well-defined! So we are back to making sure that the requirement is well-defined.
One approach is to use critical thinking.
Here is an example of a requirement:
“The system shall be easy to use.”
Think critically about this requirement. Is this a good, well-defined requirement? How will you test this requirement?
Think about that for a moment.
You can see that this kind of requirement is not testable in its current form.
First of all, a system that is easy for a person who has used computers for 10 years, may not be easy for someone new to computers. Is the system easy for someone with Windows experience, or easy for someone with Linux/Unix experience? What does “easy” mean? Does it mean easy to learn, or easy to use after you have learned it? Is it easy because everything is menu driven, or because everything is hot-key driven? Is it easy because it is like another popular software product? Is is easy because specific tasks can be completed in a specific amount of time? Is it easy for accountants to use because it is like other accounting systems? Is it easy for the general public to use because the interface is presented as a checkbook?
To make this requirement well-defined, you have to define who is using the system, and what that kind of person means by easy.
Often early in a project, the requirements will not be well defined. And that is OK at that stage of the project. But you can not produce code that meets the users requirements if the requirements are not clear and precise. The easiest way to make sure the requirements are clear enough to produce code from, is to ask “How will I test or verify this requirement?”
For use cases, many companies test the preconditions and postconditions and not the individual steps of the use case. They consider the individual steps to be guidelines to how the use case will work, not necessarily the actual precise steps. Other companies treat every step as a precise requirement. So the level of precision of the steps of your use case will vary depending on how the use case will be tested.
You might get the idea that you need to work closely with whoever is testing the code for the project. That is correct! Requirements and the tests for the requirements are closely related. They are so closely related, that some companies will ask the BA to write the requirements and test the completed product.
Some projects will start by having someone write the test cases first, then someone will produce the user requirements. This is called test-first design and is a very powerful technique for producting exactly the product the users want.
I know of one very large successful company that does not keep the project requirements once the tests for the project are written. They consider the requirements and the tests to capture the same information, so they throw away the requirements once all the tests for the project are written.
So test-first design is an approach to making the requirements clear, precise, and testable. Test-first design is a large part of the XP process, though is can be used with any process.
Of course, this assumes that the users know what they want! And that is often part of the problem. That leads to another technique for software projects – iterative development. The whole point of this technique is to solve the problem that the users do not know what they want.
You will write some requirements for the project, the requirements that seem to be the best defined. Then create code for those requirements, show it to the users, and ask if this is what they wanted. Typically some of it will be what the users want and some will not.
You will have meetings with your users to determine what to fix in the current product, and elicit another set of relatively well-defined requirements. Then build another version of the product and show it to the users again.
Iterative development assumes that some of the requirements are not clear, precise, and testable, and that they will not be until the users have seen the product and interacted with it.
Some iterative development processes are Rational Unified Process, Agile, and XP.
You can use techniques such as critical thinking, test-first design, and iterative development to improve the precision of your requirements, which will lead in turn to software that meets the needs of the users.
How do you make sure your requirements are well-defined?
Even if you are not responsible for the test cases for the requirements, try writing some tests for your requirements to see if the requirements are well-defined.