When we talk to potential customers who are seeking requirements management tools, we begin with asking them: “What is your requirements management process?” Usually they say, “we get requirements from our customers and then trace them to our products.” In areas where the customer knows exactly what they need and have been doing it for many, many years, this might work. But in the fast paced businesses of today, that approach will miss a lot of the real requirements, gaps, and risk areas. Ignorance of these requirements usually means product failure or worse, loss of life. Your company is then liable for that failure and in the US that usually means a lawsuit. If you can’t prove that you did the necessary analyses, your company will usually lose the lawsuit.
If they say they do analysis on those original customer requirements we than ask: “How do you do requirements analysis?” Often the answer is: “Well, we read them and look for shall statements.” Again, this is insufficient and will lead to failure! A requirement must be:
- Clear: Clear represents if this Requirement is unambiguous and not confusing.
- Complete: Complete represents if this Requirement expresses a whole idea.
- Consistent: Consistent represents if this Requirement is not in conflict with other requirements.
- Correct: Correct represents if this Requirement describes the user’s true intent and is legally possible.
- Design: Design represents if this Requirement does not impose a specific solution on design; says “what”, not “how”.
- Feasible: Feasible represents if this Requirement is able to be implemented with existing technology, and within cost and schedule.
- Modular: Modular represents if this Requirement can be changed without excessive impact on other requirements.
- Traceable: Traceable represents if this Requirement is uniquely identified, and able to be tracked to predecessor and successor lifecycle items/objects.
- Verifiable: Verifiable represents if this Requirement is provable (within realistic cost and schedule) that the system meets the requirement.
If they say they understand the need for complete requirements analysis, then we ask: “Did you know that functional analysis and modeling is a critical part of requirements analysis and management?” Again, most of the time the answer we receive is: “No, we don’t need that! All we need is a cheap tool that traces the requirements to product.” As you might expect this approach also leads to failure.
The Department of Defense (DoD) recognizes this problem. They define the purpose of requirements analysis as:
“To (1) obtain sets of logical solutions [functional architectures] derived from defined Technical Requirements, and (2) to better understand the relationships among them. Once these logical solution sets are formed, allocated performance parameters and constraints are set, and the set of Derived Technical Requirements for the system can be initially defined.
Outcomes: For each end product of a system model:
- A set of logical models showing relationships (e.g., behavioral, functional, temporal, data flows, etc.) among them
- A set of ‘design-to’ Derived Technical Requirements”
Most experts use a process like the one below:
Notice that functional analysis and allocation is in the center of this process. Other process models have this as well, but tend to bury it. That is a mistake. What functional analysis does is enable the analyst to create user stories (sometimes called use cases, scenarios, or threads) that can be used to validate the user requirements. As you conduct this analysis by creating a functional model, you can identify gaps and problem areas that the user may not have originally considered. You can also use these models to derive the performance requirements and identify other constraints using simulation.
The figure below shows a functional model of a process for fighting forest fires. It includes data entities and resources used in the operation. The rounded rectangular blocks represent the functional requirements for the operation. Even though some of these functions may currently be performed by people, many of them can be automated to enhance the performance of the overall system. Many of these functional requirements would be missing if you just asked people what the requirements were.
We can better understand the performance requirements by execution of this model in a simulation. An example of the results from a discrete event simulation is shown below:
These results show the time, cost and resources (water) used to put out the fire. By running these kinds of simulations, we can easily determine cost, schedule and performance metrics needed to accomplish the operation. Isn’t it better to know that early in the design phase rather than later?
The end result of performing these analyses is a much better set of requirements to build or buy what the users need. It will also build the case that you did the due diligence in this litigious society. That could mean the difference between a successful project and a failed project.