You are here

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.

Dilbert.comp>

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".

 

ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.