“What is the difference between user requirements and product requirements?”
The short answer is that user “requirements” often address only what the users expect they will be able to do with the system or their expectations for the functionality, performance, and quality of the product being developed. There are often many problems with the set of user (or customer) requirements. They are often incomplete, inconsistent, ambiguous, and not feasible. To make matters even worse, there are often implicit requirements in addition to those explicitly stated.
Note: For the remainder of this discussion, where I use the term “stakeholder”, I am really referring to all stakeholders involved in the use, procurement, development, testing, maintenance, upgrading, etc. of the product under development.
On the other hand, product requirements (what are often called “technical requirements”) are a complete set of requirements addressing the needs and expectations of all stakeholders, for all lifecycle stages, and for both nominal and off-nominal cases. The technical requirements include requirements addressing functionality, performance, quality, interactions with other systems (interface requirements), standards, regulations, and physical characteristics. In short, the technical requirements are a complete, consistent, correct, clear set of requirements.
In the early lifecycles, I don’t really like using the term “requirements” when talking about the process of working with the various stakeholders, including the users. Often the focus of the stakeholder expectations is from the view of how the stakeholders will interact with the system so they can do something to accomplish a given function. Stakeholder expectations are often captured in the form of system concepts which include stories, scenarios, use cases, operations concepts, concepts of operations, etc. From the user expectations, we can derive what the system needs to do to enable the user to do what he/she needs to do using the system. This determination is made via technical analysis and preliminary design – engineering. The system has to enable the user to perform the needed functions. That is the reason for the system.
So how do you go from stakeholder expectations to the product technical requirements? The answer to this question is addressed in our recently published newsletter as well as on our blogs “Going from system concepts to requirements – Part 1”.
Before writing requirements there is a lot of work that needs to be done. Of prime importance is working with the various stakeholders, including the users, to understand and document their expectations. Once we understand these expectations, we define and agree to at least one feasible system concept to meet the agreed-to stakeholder expectations. From these activities we can derive and agree to a set of feasible technical product requirements. These requirements are how we communicate the stakeholder expectations to the designers. These requirements will then guide the design and be used as the subject of verification activities.
Verification will prove that the designed and built system meets the product technical requirements. System validation will prove that the designed, built, and verified system will meet the agreed-to feasible stakeholder expectations. Another way of saying this is that system validation will show that the system can accomplish its intended purpose in its operational environment.
It is possible to pass verification and fail system validation as well as fail verification but pass system validation. In either case when this happens, there is a process problem in either defining the stakeholder expectations or defining the requirements. To me this is the primary reason for focusing on stakeholder expectations first and then the technical requirements. Just jumping to requirements, or worse, jumping straight to design is asking for certain failure.
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.
