Several commenters to Herding Cats asks about requirements elicitation. Here's some top level guidance. But first a fundamental change needs to take place in the IT world on how to capture requirements. This change is guided by the processes used in the defense and space business.
It's called Capabilities Based Planning. Identifying System Capabilities is the starting point for any successful program. Systems Capabilities are not direct requirements, but a statements of what the system should provide in terms of “abilities.”
For example, on the Hubble Space Telescope Robotic Service Mission, three capabilities were needed:
- Do no harm to the telescope.
- Change the Wide Field Camera.
- Connect the battery umbilical cable.
Here's a brief presentation on the concepts of Capabilities and Requirements
Capabilities Based Planning
The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?”
Capabilities statements can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory for the techncial assessment of the project's progress. But measuring how the Capabilities are being fulfilled is most meaningful to the customer.
The “meaningful to the customer” unit of measure are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission.
The process flow shown on Page 4 of the slideshow is the starting point for Identifying the Needed Capabilities and determining their priorities.
Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing from a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that are fulfilled by the program.
In order to fulfill these capabilities, requirements need to be met. But we need the capabilities first. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means.
The concept of CBP recognizes the interdependence of systems, strategy, organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments. CBP relies on scenarios to provide the context to measure the level of capability.
Requirements Elicitation
Requirements are the defined attributes for an item prior to the efforts to develop a design for that item. System requirements analysis is a structured, or organized, methodology for identifying an appropriate set of resources to satisfy a system need (the needed capabilities) and the requirements for those resources that provide a sound basis for the design or selection of those resources.
It acts as the transformation between the customer’s system needs and the design concept implemented by the organization’s engineering resources.
The requirements process decomposes a statement of the customer need through a systematic exposition of what that system must do to satisfy that need. This need is the ultimate system requirement which all other requirements and designs flow.
There are two fundamental classes of requirements:
- Process Performance Requirements.
- Product Performance Requirements.
The Process Performance Requirements define how the work processes are used to produce a beneficial outcome to the customer.
The Product Performance Requirements define the product specifications and how they are related to the process requirements. As well as the product and process requirements, there are functional and non‒functional requirements.
These non‒functional requirements play a significant role in the development of the system. Non‒functional requirements are spread across the entire system or within individual services and cannot be allocated to one specific product artifact (e.g., class, package, component).
This makes them more difficult to handle than functional requirements. The specifics of the system’s architecture, such as highly distributed services bring up additional difficulties.
The distinction between process and product requirements lays the foundation for the Work Breakdown Structure. The WBS, the related Integrated Master Plan (IMP) and Integrated Master Schedule (IMS), also focus on this separation.
The success of the project or program depends on defining both the product and the processes that support or implement the product.
When properly connected, the Requirements Taxonomy, the Work Breakdown Structure, the IMP and the IMS “foot and tied” to the Performance Measurement Baseline (PMB). This provides the traceability of the increasing maturity of the deliverables (vertical) and the physical percent complete of the work efforts (horizontal).
Step-by-Step for Capabilities
- Determine what the system is supposed to do in terms of Scenarios or Use Cases. This is not a new approach at all. Alistair Cockburn introduced the notion of Use Cases long ago. But they went astray because doing good Use Cases requires understanding what capabilities the customer needs.
- What is the business problem or mission to be accomplished?
- How would you recognize that this problem has been solved or the mission was accomplished?
- Measures of Effectiveness are the units needed to confirm this accomplishment.
- Assemble these Capabilities into a functional architecture, showing how each capability supports the mission or business need. The process flow below is an example.
- Develop a maturity flow for each capability showing how the presence of this capability allows the business or the mission to do some work.
- This of course is simple agile - working software.
- But agile is now coming to see that bottom up, response to the customer need requires a framework - a Programmatic Architecture to assure that the end is reached as planned.
- This of course is Stephen Covey's Habit 2 Begin with the End in Mind, and is actually the Integrated Master Plan / Integrated Master Schedule paradigm of DOD 5000.02 procurement. Imagine that 5000.02 and agile on the same page. See Agile+EVM=Success for guidance here.
Here's a picture of the Capabilties Maturity Flow from a real project...
As each capability appears, the project can then start producing useful services - do something useful. But - and this is critical - the business or the mission MUST be capable of receiving this capability. It does no good to have capabilities that cannot be put to use. This is the purpose of this diagram. To show what capabilities are needed, in what order. This is a Top Down process, done by the business or mission owners.
Step-by-Step for Requirements
- For each defined capability there needs to be a process and product requirements as shown on Page 7 of the slide deck.
- Each requirement MUST flow from a needed capability. Each requirement needs a reason for being there. It needs a parent. It must fulfill some needed capability.
- As an aside - all requirements are derived. This means all requirements are derived from the needed capabilities. In some circles this is not the paradigm, but in the complex, software intensive world of space flight and weapons systems - All Requirements Are Derived from the Mission Statement or the Concept of Operations (ConOps).
- Thesetwo documents are usually missing in the IT world, with the resulting gap of not knowing WHY we're doing something.
