Requirements Creep

In my last blog entry I mentioned how stressful things can get when we are not given good, or any, requirements for a project, beyond the ship date.  Right after I posted that, I happened to see a message on the IEEE P730 Working Group on Software Quality Assurance Standards email list, by Robin Goldsmith of Go Pro Management, that I thought was worth posting here.  With Robin's permission here is what he wrote:

       "A major cause of creep, quality problems, and overruns comes from the common failure to recognize that what most people call "requirements" (i.e., specifications) actually are a form of high-level design.  The word "specification" is  a synonym for design.  Requirements specifications are human-defined attributes of a product, system, or software which is a presumed way how to satisfy the REAL, business requirements deliverable whats that provide value when met.  The product and its specifications provide value if and only if they satisfy the REAL, business requirements.


       Creep mainly occurs when the product/specifications fail to satisfy the REAL, business requirements, usually because the REAL business requirements have not been defined adequately, which in turn is mainly due to people thinking the product specifications are the requirements.


       The difference often is easier to see in an acquisition situation.  Most formal and informal Requests for Proposals (RFPs) specify the requirements of a product, system, or software the buyer thinks they need.  When the seller sells them such a product, the buyer--not the seller--is on the hook if the product fails to provide expected value.  In contrast, appropriate acquisition involves the seller proposing a product, system, or software to satisfy the buyer's described REAL business requirements.  Then the legal burden is on the seller if the proposed product fails to provide expected value.


       In addition to putting the burden of legal responsibility on the seller, there's a software engineering advantage of requesting the seller to propose a product that meets the buyer's REAL business requirements.  This gives the buyer the opportunity to take advantage of the seller's usually far greater knowledge of the subject area their product addresses, rather than having the less-informed buyer specify the product requirements.


       Well-formed formal and informal contracts and acquirer-supplier agreements  more reliably lead to success because they identify both high-level and detailed REAL business requirements, which usually include various constraints on how those requirements may be met.


       In effective product acquisitions, the seller does include a requirements specification in their proposal; and when the proposal is accepted by the buyer, the seller's entire proposal including any requirements specifications becomes part of the contract the seller is legally bound to deliver--by providing a product that conforms to the contracted requirements specifications.


       Of course, often the seller is engaged to develop a requirements specification as part of the contracted work.  Effective acquisitions then involve a separate subsequent proposal for providing a product that conforms to the requirements specification.  Especially for government acquisitions, the seller producing the requirements specification may be precluded from also proposing a product to meet the specifications they've defined."

Robin is the author of the book, Discovering REAL Business Requirements for Software Project Success; ISBN: 978-1580537704, which I've just added to my reading list.





It requires diligence from all of us to keep the Creeping Feature Creature at bay...