You might find other lists on the Internet of things that make requirements "good." I'm going to give you a list of what makes requirements bad.
Don't ever write requirements like these...
- Bad Requirements are Ambiguous. If you tell me, "The system should be able to be dropped from a height of 8 feet onto a wooden floor without breaking it," I will build you a system that will not break the floor when it falls onto it. The system, however, will shatter into a thousand pieces.
- Bad Requirements are Subjective. If you tell me, "The system should use pretty colors," I am not going to build your system. If you tell me, "The system should be fast," I am not going to build your system.
- Bad Requirements are not Testable. If you tell me, "The system should never crash on a Saturday afternoon," I'm going to ask you to watch it every Saturday to make sure it doesn't.
All of the examples I just gave could be rewritten to be good requirements. It just takes a little more thought.
- The system shall not break when dropped from a height of 8 or more feet onto a surface with a Brinell hardness of 1.6 HBS 10/100 or greater.
- The system should use only pink and purple as display colors for text.
- The system should process inputs at a rate of 3 per second.
- The system should have a mean time between failures of 87 days.
Remember, you can't build the right system from the wrong requirements.
|Amphibian.com comic for August 15, 2014|