Note: this is an update to this blog originally published in 2012.

Preparing for the future

A constant throughout the evolution of systems engineering is an ever-increasing complexity of systems which can be observed in terms of the number of system functions, components, and interfaces and their non-linear interactions and emergent properties.

Each of these indicators of complexity has increased dramatically over the last fifty years, and will continue to increase due to the capabilities that stakeholders are demanding and the advancement in technologies that enable these capabilities.

Today’s systems often rely on complex automation and control systems to operate safely, reliably, efficiently, and profitably.   This complexity presents organizations with challenges that need to be addressed.

Systems Engineering is critical to understanding the relations between the parts of current and future increasingly large, high speed, automated, and intelligent complex systems.  Requirements are the language used to communicate what is needed to understand, define, design, and implement these systems.

What are the benefits of implementing an effective RDM process?

Requirements have a significant impact on project success. Studies show the importance of having a quality set of requirements that are clear, complete, correct, and consistent as well as the consequences of not having a good set of requirements. Having poor requirements places projects at risk of significant cost overruns, schedule delays, and performance shortfalls. In fact, recent studies have shown that projects which fail to take effective actions to ensure a good set of requirements triple their chances of project failure. Recognizing the fact that poorly written and managed requirements represent a significant risk to your project and mitigating these risks can triple your chances of project success.  You can read more about this in my paper “Risk and Requirements”

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 organizations have is a lack of appreciation concerning the importance and role of requirements in developing products and the impact poorly written requirements and bad requirement development and management practices have on the final outcome of the project.

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

Consequences of poor requirements

The consequences of poor requirements are many.  The root causes of the issues listed below can be traced back to poor requirements and poor, unenforced, or the lack of an effective requirement develop and management process within your organization.

–  Cost and schedule overruns and liquidated damages (fines for late delivery)
–  Wasted effort due to rework
–  Work performed that is not needed
–  Missing, conflicting, or inconsistent requirements
–  Requirement(s) that can not be implemented
–  Requirement(s) that are not implemented
–  Project designs, builds/codes, delivers the wrong thing
–  Integration issues
–  Failed tests during system verification
–  Health, safety, environmental realized risk
–  System fails system verification and validation
–  High life cycle costs (testing, maintenance)
–  Products not performing as intended (lacking needed function and performance)
–  Recurring failures in the field
–  High warranty costs
–  Expensive recalls
–  Decreasing market share
–  Customers dissatisfied with the products – loss of market share
–  Reduced or lost profits
–  Nonconformance / compliance with industry standards, customer requirements or contract requirements

Requirements link the product development life-cycles together.

Various “books of knowledge” and engineering development handbooks and texts define what a requirement is.  A very pragmatic definition of requirements is:

–  “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. See also our blog: Why Do We Need Text-based Requirements?]

Requirements are the common thread that links all the product development life-cycles together.   In the beginning are stakeholder needs and expectations.  Requirements are derived to communicate what the system must do to realize these needs and 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 flow down (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, “system verification” activities are performed to make sure each 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 to the customer.

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 needs and expectations that were documented at the beginning of the product development lifecycle.

To better understand verification and validation please read my paper: Thinking Ahead to Verification and Validation

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

Notice that each step of the design and verification activities involved requirements.  As you can see, requirements are not just a document with words.  It is important to understand that developing requirements is not an exercise in writing, but is an exercise in engineering.   Requirements evolve as the system architecture evolves.  There is a common saying “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 well-written set of requirements so projects can be successful. The result of following these processes is a set of requirements that clearly describe the characteristics, capabilities, functionality, performance, and quality the system needs to have to meet stakeholder expectations.

Benefits of well-written requirements

–  Clearly communicate the stakeholder needs and expectations to the design team
–  Establish the basis for agreement between the stakeholders and the developers on what the product is to do
–  Reduce the impacts on cost & schedule due to rework due to omissions, misunderstandings, and inconsistencies
–  Provide a basis for estimating costs & schedules
–  Provide a baseline for design
–  Provide a baseline for system verification
–  Result in satisfied customers
–  Result in increased profits

Guidance on implementing an effective RDM process in your organization that will enable you to reap these benefits is addressed in my blog “Implementing a Requirements Development and Management Processes“.

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.