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 :)