Why do our requirements stink? | Cypress Semiconductor
Why do our requirements stink?
My recent article "I don't need no stinkin' requirements" (www.eetimes.com/
design/embedded/ 4205794/I-don-t-need-no-stinkin--requirements-) presented a design method to deal with the common experiece of changing requirements. I still hold that requirements change and you need to be prepared for it, but esteemed embedded expert Jack Ganssle has posted a counter-point article "I desparately need stinkin' requirements" (www.eetimes.com/discussion/other/4206193/I-Desperately-Need-Stinkin-Requirements) where he points out the problem is not changes in "requirements" for the product (that is, how the product needs to perform) but that the written set of requirements stink. And rather than blunder ahead with bad requirements, we need to demand (and work for) well-developed complete requirements. Bravo Jack, this is the crux of the problem, fix the requirements and they won't change and there is less disruption.
We need to write good requirements. And everyone around us has an idea of what those requirements should be. And how easy they are to write. Here is a classic interchange between Dilbert and his boss illustrating the problem.
It is possible, however, to write a good requirement. I adamently believe it starts with an agreed nomenclature. I stick to what in my experience seems de facto industry standard - the word "shall". Any statement that is a requirement will contain a "shall". Any statement without a "shall" is not a requirement - it may be information and it may be useful, but it is not a requirement (and therefore is not going to be done).
Next, is the statement implementable and testable as written. Is it specific enough to have a test that shows it has been achieved (positive test), and more importantly, are there test cases that verify (when they fail) that the requirement isn't satisfied. Using Dilbert above, we could start with asking how many clients and how many servers must be supported, and perhaps the result is: The system shall support 17 servers and 2100 clients simultaneously. You could concieve of a test to verify that, though in reality the cost of running the test case, or simply acquiring the necessary hardware, might preclude running the test (at least in 1994 when the comic first appeared), but at least there is enough information.
What if a "shall" statement is not implementable and testable? Then break it down. Ask "What does this mean?" or more specifically "Does this mean xxx?" until you get down to statements that are implementable and testable. But avoid requiring an implementation unless it is absolutely a "requirement". For instance, in the underlined requirement above, Dilbert might ask "Does this mean we can use Commodore 64 computers for all the clients?".
As Jack also points out, there are great books on writing requirements (his favorite is Karl Wiegers’ “Software Requirements.”) but not a single university course. So most of us get our degrees from the college of "hard knocks and lost weekends".