Bad Requirements Create Bad Systems

One of the most important lessons I've learned as a software engineer is the importance of good requirements. Requirements definition is absolutely the most important part of a software development project. You can have the best engineers in the world but if your requirements are terrible your system will be terrible.

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