Requirements – What’s the Big Deal????

Posted on: August 13th, 2012 by Lou Wheatcraft No Comments

The ultimate goal of any project should be to deliver a winning product – one that delivers what is needed, within schedule and budget, with the desired quality.  A key issue many have is a lack of appreciation concerning the importance and role of requirements in developing products and the impact bad requirements and bad requirement practices have on the final outcome of the project.

As stated by Ivy Hooks, Founder and past President of Requirements Experts states: “People who write bad requirements should not be surprised when they get bad products.  But they always are.”

Various “books of knowledge” and engineering development handbooks and texts define what a requirement is.  We will address more formal definitions in subsequent posts.   For now I will present a very pragmatic definition:

  • “Design-to” requirements are a means of communicating stakeholder expectations to the design team.
  • “Build-to” requirements are a means of communicating the design team’s expectations to the builders and coders.

Depending on your domain and environment there are various means used to communicate these expectations and various work instructions and processes for how best to communicate these expectations.  The most widely accepted means of communicating these expectations is  requirements via sentences with a “shall”.  The system “shall” do something with a specific result.  A “shall” statement is contractually binding and will be verified.  [Note:  We understand there are those that do not like using “shall” statements for requirements, but read on so I can make my point.]

Requirements link the product development life-cycles together.

Requirements are the common thread that links all the product development life-cycles together.   In the beginning are stakeholder expectations.  Requirements are derived to communicate what the system must do to realize these expectations.  When we validate a set of requirements, we are making sure the requirement set is complete, correct, and consistent for the level of the system architecture we are defining requirements for.  Once this set of requirements is validated, approved, and baselined, the design team then comes up with a design that meets these requirements and defines an architecture for the system.  Requirements provide the foundation upon which the product design is based.

Requirements at one level are allocated to the parts of the architecture at the next level and the process repeats until the organization can make a buy, build, code, or reuse decision.  Once all the parts are available, each is verified to make sure the part meets its requirements.  Then the parts are integrated together and the next level of the architecture is verified to make sure it meets its requirements.  This process continues until you have the completed product that will be delivered.  Notice that each step of the design and verification activities involved requirements.  Once the completed system has been verified to meet its requirements then “System  Validation” activities are performed to validate that the designed, built, coded, and verified system meets its intended purpose in its operational environment.  What is being done is to make sure the system addresses the stakeholder expectations that were documented at the beginning of the product development lifecycle.

As you can see, requirements are not just a document with words.  In fact I make a point to all my students that developing requirements is not an exercise in writing, but is an exercise in engineering.   Requirements evolve as the system architecture evolves.  They say “the devil is in the details”.   As the design evolves and we get smarter, requirements may change.  Thus requirement management occurs over the life of the project.

In the end, we want to deliver a winning product, one that has been verified to meet the requirements and has been validated to meet the stakeholder expectations.  This cannot be done if the development team does not recognize the importance of a disciplined approach to product development and the need to define a good set of requirements so projects can be successful. The result of following these processes is a set of requirements that describe the characteristics, capabilities, functionality, performance, and quality the system needs to have to meet stakeholder expectations.

Without requirements how can stakeholder expectations be proven to be met?

Tags: , , , , , , , , , , , , , ,
Posted in Requirement Development, Requirement Elicitation, Requirement Management, Scope Definition, Writing Requirements | Tagged , , , , , , , , , , , , , , | Leave a comment

Leave a reply