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, Requirements Experts 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.
Tags: defective requirements, requirement, requirement management, requirement validation, requirements, system validation, system verification, Verification
By Chris December 2, 2014 - 2:40 pm
I came across a big miss in early-stage requirements writing just this past weekend while attending a friend’s birthday.
It was held at a restaurant/bar/arcade – really a combination of all three at once. I walked up to a cabinet and inserted a quarter, pushed the start button and went to set down my beverage of choice. The only problem was, there was no place to put it! The game pad was slanted, and so was the top, so I shrugged it off and just set it down on the floor next to me.
You’d think for a “barcade”, they’d have gotten this concept down. Maybe I should check their website for openings as “Resident Systems Engineer”.
By Lou Wheatcraft December 17, 2014 - 3:19 pm
Chris, good example of the need to do the upfront scope definition activities before writing requirements. I like to identify the stakeholders upfront for all life cycle stages of the product. Use of the product from the actual users in the operational environment is very important as you point out. In ths situation the developers did not consider the actual users nor the actual operational environment the arcade game is in.
I agree with you that a big obstacle to good requirements is a failure to do the upfront work before writing the requirements. This upfront work includes defining the Need, goals, objectives, stakeholders, drivers and constraints, and external interfaces. It also includes working with the stakeholders to develop system concepts, user stories, use cases, operational scenarios, etc. in order to fully understand the needs of the stakeholders.
If you don’t do these activities, there will be stakeholder needs not defined and understood resulting in missing and even incorrect requirements. When this happens the developers do not understand what is needed and thus, even though the may meet the stated requirements (pass system verification) they will fail system validation – a failure of the delivered system to achieve its intended purpose in its operational environment.
By Kamal Hammoutene February 18, 2015 - 3:46 am
Great article Lou!
For me, the biggest obstacle for good requirements can be found the English litterature and in G. K. Chesterton’s work. Chesterton (1874-1936) was “English writer, lay theologian, poet, philosopher, dramatist, journalist, orator, literary and art critic, biographer, and Christian apologist.”.
Here is an extract of this book “The Scandal of Father Brown (1935)” :
————–
“It was comfortably furnished; and Lord Stanes was presiding over grog and cigars, when the priest made his confession with a grimace. Lord Stanes had become rather surprisingly friendly, in a cool and casual way.
‘I know that is saying a good deal, with your record,’ said Stanes, ‘but certainly the detectives, including our seductive friend with the glass eye, don’t seem at all able to see the solution.’
Father Brown laid down his cigar and said carefully: ‘It isn’t that they can’t see the solution. It is that they can’t see the problem.’
‘Indeed,’ said the other, ‘perhaps I can’t see the problem either.'”
————–
So, imho, the biggest obstacle for good requirements is ….. the human being, always inclined to think in solutions as Chesterton wrote:
‘It isn’t that they can’t see the solution. It is that they can’t see the problem.’
By Lou Wheatcraft February 18, 2015 - 7:54 am
Very good! I totally agree! You need to understand the problem first. Note that the word “problem” can have several meanings. Problem as in something bad that needs to be fixed or an opportunity that needs to be pursued? In either case you need to work with the stakeholders that have the problem and work with them to understand what needs to be done to solve the problem. Out of this analysis should be a “Need” statement that clearly communicates the desired outcome. Then you can work with the stakeholders to define goals that need to be accomplished to meet the Need and the objectives that will tell you when the goals have been accomplished. You can read more about Need, goals, and objectives in my paper: “Delivering Quality Products That Meet Customer Expectations“