A requirement describes a portion of a feature or expected benefit and can originate from many sources. Before beginning development on a product it is important to have a clear understanding of the origins and objectives of the requirements process, not only generally, but in terms of a specific design effort.
A collection of requirements is put together to describe the entirety of a product or a system. In any complex project, you may have more than one sponsor and stakeholder. You need to understand these people and their areas of concern. You will need to assess competing or conflicting requirements and resolve them in cooperation with the customer. Then, you will need to document and manage those requirements. Things inevitably change as development progresses, and you will need to make sure those changes are controlled. Lastly, you will need to confirm that you have delivered a final design that meets all requirements.
No single requirement in a design will by itself determine the end objective or benefit provided. However, collectively the requirements must describe the customer’s expected features and benefits of the product. Whether you work for a nonprofit or a for-profit entity, you will need to ensure the benefits you provide are greater than the cost. Even in the worst-case scenario, the benefit and cost should be equal.
Requirements come in many forms, and can originate from any place (Figure 1 ). There can be industry specific requirements in the form of expected standards or performance targets, as well as specific design features. For example, The Society of Automotive Engineers has numerous standards that can apply to various vehicles. Consider the SAE J1455 Standard for Environmental performance of a product. Your customer may have specific features, system interactions, or expected performance characteristics as well. These can point to other requirements, known as derived requirements.
Incorrect or irrelevant requirements need to be expunged from the project. You also may receive duplicate requirements. Thorough reviews are necessary to spot incorrect, irrelevant, duplicate, or conflicting requirements and remove them from the project scope and technical documentation. These rules apply to agile projects as well.
What is a ‘good’ requirement?
The clearer the language used in defining requirements, the more likely you are to meet your project goals. Well-written requirements will be coherent and will not conflict with one another. In the process of evoking the requirements the team is likely to find competing or conflicting requirements.
Resolving inconsistencies usually requires negotiation with the sponsors. In addition, the requirements must be correct and observable. That is, the requirements are written to accurately present the objectives and observable in that the end state pointed to by the requirement has a way to demonstrate that the requirement is met. Ambiguous requirements are the bane of product development when the team attempts to get by implication or intuition what should be clearly defined.
The observable aspect of the requirements makes it possible to verify that those requirements are met, so requirements must be written in a way that provides a mechanism for verification. Verification skills may not be part of the expertise of those who write specifications and is another good reason for including the verification and test personnel in the generating or review of requirements. Ultimately, traceability of requirements generated, from the scope of the project through to the projects sponsor’s objectives, is required for success.
How to gather requirements
There are numerous methods available to the team for gathering requirements. To start, some subset of the team will likely interview the project sponsor and the direct customers of the final product. Surveys and questionnaires can be used to evoke and quantify product requirements. Focus groups gain help to gain understanding of the end customer needs. Another way to achieve this clarity is to spend time with the end customer in field studies. This can be time consuming, however witnessing firsthand the event or activity the project proposes to solve can be a significant way of clarifying the objective.
If there are competitive products out in the field, your team may purchase some of these and use them to learn more about their significant features. The team may tear down the product to learn which features of the product provide user benefits (for example, current consumption and battery size).
Regulatory requirements require careful attention. Noncompliance to regulations can cost the enterprise greatly, the effects of which are felt long after the end of any profit from the product. Standards are not quite as strong as regulatory demands. However, standards are norms or expected behavior in the technical area under consideration.
Noncompliance with norms can cause problems, and in such a case the team will likely need to show evidence of why that non-compliance is okay. If any investigation of a failure in the product should arise post launch, the team may be asked to demonstrate the measure of diligence employed and justify the reason for not meeting the standard.
Functional decomposition breaks down the features into discrete elements in a hierarchical view. In this way the team can see that to obtain the top level feature, there must be some sub-features or supporting functions. This decomposition can inform the team of some nuances in the feature that were heretofore unknown. Additionally, the decomposition can help the team arrive at forced failure responses, whereby the product’s response to failure is defined by requirements into a reaction that will do no harm.
Consider the cruise control on the car interrupted by the brake pedal press. What happens if the brake pedal switch is faulty? If the brake pedal switch is failing, you would not want the system to allow engagement of the cruise control function. This requires the system to know when the brake pedal switch is faulty, which in turn requires more requirements to dictate the system behavior. All of this would now be incorporated into requirements documentation.
There are many sources through which requirements may originate. It is not unusual for the ultimate use of the product to go beyond that for which it is planned. Some of these environmental factors may not be known via the methods of product research previously mentioned.
Using simulation to gather requirements
There are many methods available to evaluate assumptions you may make about requirements. Some of those techniques are:
- Product mock ups
- Rapid prototyping
Product mockups can be used for physical world explorations such as size and product envelope as well as some functional criteria.
Rapid prototyping allows you to build an actual incarnation of product quickly. You can hand to your end customer for their assessment. This provides a way to weed out requirements that are not vital to the product and uncover things you did not know that will be vital for success.
Simulation techniques help you understand the requirements. Simulation and modeling need not be highly technical or complex. For an embedded product, you may have to devise ways to mimic the final product features in software. We have seen Excel used to develop the human machine interface for an instrument cluster. We have also seen visual basic code providing the same graphical simulation replicating the interaction of would-be user via mouse clickable stalk switches. In the extreme incarnation, you may need groups of computers to replicate the system to uncover interactions that would otherwise be difficult to imagine and document.
For complex systems, modeling can save considerable money on product development. Appropriate modeling requires understanding how the product will function in the real world. The same is true for complex simulation. Ultimately, the model is only as good as its ability to predict how the finished product will work. Whatever modeling approach you use it should be capable of the following:
- Aid in the creation of performance specifications
- Allow for high-level simulations
- Generate a working virtual mockup
- Allow for some modeling to be done in spreadsheet
- Provide holistic assessment of product performance and subsystem interactions
There are limits to system modeling. Not all is known in the early stages, and you need to improve the models predictability. To do so, you have to compare the model predictions to the real world outcomes. This allows you to consider variables and requirements that you are unable to consider in other ways. This external world exploration is performed via testing. You will need to measure how the real world works, see if it matches your model predictions, and where the discrepancy is unacceptable, you will need to understand both the real world variables and the model limitations. The ultimate goal is to improve your model to better predict real-world performance.
Analyzing the preliminary list of requirements means winnowing out those things you initially thought were requirements in favor of those things that absolutely must be delivered to produce the desired outcome (Figure 2 ). Most times that desired outcome will have a business case associated with it and a customer problem solved.
Your team will need to prioritize and assess competing requirements to distill the work into a concerted direction. The team may have more to explore regarding the requirements through subsequent work in making the product, specifically prototype parts and development iterations on the way to the final product. At this point, your team should have already performed simulation activities as a way to vet and understand the proposed system and the requirements.
In many cases, your team will discover competing requirements that need to be reconciled. In the end, the team will match the highest priorities to the best, most likely, concepts to achieve that objective.
There are a number of tools for assessing the concepts against the requirements. However, for brevity we will only discuss one of these techniques, the Pugh Matrix .
With the Pugh Matrix, the team identifies the most important attributes of the product and compares the design against those attributes. The individual attributes need to be weighted as all requirements and objectives are not likely to be of equal importance.
To determine the best approach to achieving the objective, the team will need to document what is known about the product. If you keep requirements in multiple documents (for example, one for system level specifications and another for component specifications) you will need a document tree that shows the interconnections between specifications.
- If broken down into multiple documents, you need a document tree to manage it
- Use a standard format
- The ability to identify patterns
- Consistency – Each document needs to be individually identified by means of an alpha-numeric designator such as REQ_SW_HMI_20
- The ability to disambiguate with disaggregation when it is necessary for a requirement to meet multiple needs
Configuration management is closely connected to requirements and their management. Requirements are the documented version of the product that establish the scope of the project work. Once specifications have gone through the review process and are adjusted, the specifications and the associated content will fall under configuration management.
The delivery plan for the product will be developed incrementally as you approach the final instantiation of the product. The requirements to be met will be prioritized. For example, we have ‘n’ number of requirements; in the first build, we produce 1-4 of these requirements. These may be the most complicated or most valued requirements, or perhaps there is a dependency that must be delivered before you can deliver the most valued.
All of this will be managed by the configuration management process as you generate version descriptions/release notes that will inform the recipient of the product, the contents allowing for a comparison to the intended final product. One of the recipients of this work will be the verification and test group.
Knowing which requirements are in what product iteration provides a focus point for the test work. You can then grow the test coverage to match the growth in requirements. Your test group will not test requirements not delivered.
No matter how well the product is defined at the onset of the project, as you build the prototype iterations and test or validate, adjustments to the product definition are likely to be required. To control the changes to requirements, they should be put under configuration management control.
The change management process must be well-defined and controlled. Indiscriminate change to requirements or change via telephone call cannot be allowed. The change management process includes rules for deciding responsibilities and will be documented in the configuration management plan. The entire team and stakeholders must be aware of these processes.
Knowing which requirements are delivered in what iteration allows the test work to focus on deliveries; the test coverage needs to grow to match the growth in requirements. Specifically, for every requirement, there will be at least one test case to confirm. There should be a map of the requirements identifiers to the test case identifiers as shown below:
Test cases for each individual requirement
This allows you to confirm that the product delivered meets customer demands; this is part of contract closure.
The ultimate success of a project hinges on meeting all of the requirements, which must be well-defined. An understanding of the objectives of the customer in the market place is the starting point. You need to sift through all requirements to evaluate their relevance and relative importance. You also need to document and trace changes from the original requirements as you gain understanding through the development of the product and through your interactions with the customer or sponsor. This is accomplished through periodic builds of simulated or prototype parts that allow you to compare the initial interpretation of requirements with the final evaluated documented requirements. Ultimately, your contract closure activities for the project will be derived from this comparison, and will indicate you have reached the successful conclusion of the project.
Jon M. Quigley is a principal at Value Transformation LLC , a product development training and cost improvement organization. Jon is the author of several books on project management and software development. Mr. Quigley is also a frequent speaker at industry events. He has more then twenty years of product development experience, ranging from embedded hardware and software through verification and project management.
Kim Robertson started his first company at the age of 18 and has an extensive background spanning forty years in all aspects of business and aerospace. He is the author of over 100 discipline specific training packages, 3 fiction books, and articles for CMTrends and various other trade publications from industrial arts to Configuration Management. His interests in education and training development started in his teens. He is a NDIA certified Configuration Manager with degrees from Westminster College in Mathematics and Physical Sciences and a Master’s degree from the University of Phoenix in Organizational Management with a subspecialty of Government Contracts.