I was recently asked the question: “What do you think is the biggest obstacle to good requirements documentation? I have been doing this for 25+ years and never see the end product match the requirements…..”

I smiled when I saw the statement: “..never see the end product match the requirements…..”. This statement reminded me of a class I was teaching.  At the beginning of the class I like to ask the students why they are taking the class and what they hope to get out of it.    One young engineer replied: “I want to learn how to write requirements that match the product we have built.”   I had to laugh, and commented: “You have it backwards, you are supposed to build a product that meets your requirements!”

Requirement Driven Organization

The biggest obstacle to good requirements is working in an organization that is not requirement driven. In a requirement driven organization, the focus of all development processes is the requirements. A requirement driven organization, starts with defining stakeholder expectations and needs.  Once you have an agreement on these, they are translated into a language that can be understood by the design and development teams.  This language results in statements that are clear, concise, correct, complete, unambiguous, needed, verifiable, achievable, appropriate to the level, etc.  The resulting statements are what we call requirements.  If they don’t have these characteristics, they are not really requirements.

Requirement Validation

To make sure we have a good set of defect-free requirements, we do requirement validation.  Requirement validation checks to make sure that 1) the requirements clearly communicate the stakeholder expectations and needs as well as 2) the requirements have the characteristics of good requirements.  The result is a baselined set of requirements for the level of the product architecture the requirements are being written.  The Systems Requirement Review (SRR) is a requirement validation activity.

Design and Requirements – System Verification and Validation

During the design process, the designers should always be checking to see if their design will result in a part that meets the baselined requirements.  The  main purpose  of design reviews should be to make sure this happens. Once the part is built or coded, we do system verification to make sure the designed and built /coded part meets the baselined set of requirements.  While requirement development is a top-down process, the building, procuring, or coding of the parts and then integrating them together to make the system is a bottoms-up process.   For each part, you want to make sure that part meets its requirements before it is integrated together with other parts to make the next higher layer of the architecture.

Once you have competed design and system verification, the last step is system validation.  System validation makes sure the designed, built, and verified system meets its intended purpose in its operational environment.   Another way at looking at system validation is whether or not the designed, built, and verified system meets the stakeholder expectations and needs that you documented at the beginning of the project.

Making sure your product meets the requirements

With this foundation and understanding, we can now discuss the issue stated at the beginning of this blog – a product that does not meet requirements.

First of all, what are the consequences when your designed and built system does not meet the requirements (failed system verification)? Assuming you have a good set of defect-free requirements, failing system verification probably means the product is not going to meet the stakeholder expectations and needs.   The result – unhappy customers!

On the other hand, what are the consequences when your designed and built system passes system verification but does not meet its intended purpose in its operational environment (failed system validation)? As before, this probably is going to result in a product does not meet the stakeholder expectations and needs.  Again, the result – unhappy customers!

But wait!!! How can you pass system verification but fail system validation?  This can happen if you ended up with a defective set of requirements – requirements that are poorly written, ambiguous, incorrect, incomplete, etc.  You may have met the requirements, but they were the wrong set of requirements – they didn’t clearly communicate the stakeholder expectations and needs.

However, it is possible to fail system verification (not meet the requirements) and still pass system validation (meet the intended purpose in the operational environment).

How can this happen?!?!?!?!?!   This can happen when you again ended up with a defective set of requirements, but the designers and developers knew what the stakeholders needed and expected and designed and built the system based on this understanding – ignoring the bad set of requirements!

Again the result is a product that does not meet the requirements – but meets stakeholder expectations!

The root problem in either case is defective requirements!!! (For guidance on avoiding defective requirements. See my last blog: “How to Improve the Quality of your Requirements.”)

Now we can answer the question: “What is the biggest obstacle to good requirements?”

As stated previously, the biggest obstacle to good requirements is an organization that is not requirement driven. If this is the case, the organization doesn’t have a good requirement development and management process being implemented AND enforced within the organization. Because of this, you end up with poorly written, defective requirements.

If your organization is requirement driven AND has a good requirement development and management process, your products will pass BOTH system verification and system validation resulting in a product that does match your requirements AND meets stakeholder expectations.

If this is not the case, ArgonDigital would be happy to help you and your organization develop and implement a good requirement development and management process and become a requirement driven organization.  We offer both consultation and training.   For more details, see the training information on our web site.  We want to help you develop a winning product the first time – one that delivers what is needed, within cost and schedule constraints, with the desired quality.

P.S. For more information on risks your organization faces due to poor requirements you can download my paper “Risk and Requirements”.  To learn more about system verification and validation, you can down load my paper: “Thinking ahead to verification and validation”.

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.