You are here

I missed my fifteen seconds of fame :) | Cypress Semiconductor

I missed my fifteen seconds of fame :)

 I left for my Hawaiian vacation on August 20, the same day I would have received this email newletter from Embedded.com:

 

8-19-10: Ganssle vs Pearson on requirements / Crenshaw on mediocrity / PID Basics

 

That "Pearson" was/is me, and refers to the the back-and-forth between my article "I don't need no stinkin' requirements" (www.eetimes.com/design/embedded/4205794/I-don-t-need-no-stinkin--requirements-) and Jack Ganssle's column "I desperately need stinkin' requirements" (www.eetimes.com/discussion/other/4206193/I-Desperately-Need-Stinkin-Requirements) written in response to mine. While the titles look in conflict, they really are dealing with different issues. Mine is about approaching your design with the expectation that changes will happen. Jack's is about the need for real good requirements. But since Jack turned the spotlight on the requirements, that's where the focus went.


It is always fun to get a newsletter in your inbox that announces your new article (sometimes this is how I learn it was finally published), but this was even cooler, I had created a controversy (actually the editor who changed the title helped) and brought out not just one but two responses from a legend in the (admittedly nerdy) embedded developer world (more about Jack Ganssle here: http://www.ganssle.com/bio.htm).


I posted to my blog last week (www.cypress.com/) where I presented my definition of requirements that don't stink, which need two things: 

1) unambiguously identified requirement statements, which I expect to be tagged with "shall" exclusively, and 

2) requirement-statements that are implementable AND testable. 


Jack has also followed up (I don't think he reads my blog, but whatever) where he posted the "rules for requirements" from a talk by (apparent Seattleite) Steve Tockey (www.construx.com/Page.aspx). His three rules (presented in Jack's latest column www.eetimes.com/discussion/other/4206402/More-on-requirements): 

1) A requirement is a statement about the system that is unambiguous,

2) A requirement is binding (product requires it, customer will pay for it, product is unacceptable without it), and

3) A requirement is testable.


I believe Steve's/Jack's #2 is obvious - a requirements document contains what the product "requires" and the process of turning the requirements into a project plan will often separate the wheat from the chaff - since every requirement increases the cost and schedule and risk for the product. This statement it a bit gratuitous and either aimed at new-college-grads or hackers who have joined a "real" software/embedded project. That is why I left it out.


The other two agree with my two - within all of the words in a requirements document, the team needs to be able to separate nice-to-know info from must-do requirements; and then they need to agree the statement can be implemented AND tested. I think Jack underemphasized the implementation part. From my marketing seat, I have often struggled with developers who thought (usually warranted) that I was requiring a specific implementation (and I might have been unnecessarily) OR was asking for something impossible (usually NOT true, and from time to time I had to roll-up my engineering sleeves and prove it).


So, what are you gonna do? Understand the requirements are important and writing good ones is not easy but it is essential and you must strive for great requirements.


Hang loose (I have one more week left :)

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.