Systems Engineering has two components
- System - a set of interrelated components working together toward some common objective.
- Engineering - the application of scientific principles to practical ends; as the design, construction and operation of efficient and economical structures, equipment, and systems.
When we work in the Enterprise IT domain or any Software Intensive Systems ...
...systems engineering is focused on the system as a whole; it emphasizes its total operation. It looks at the system from the outside, that is, at its interactions with other systems and the environment, as well as from the inside. It is concerned not only with the engineering design of the system but also with external factors, which can significantly constrain the design. These include the identification of customer needs, the system operational environment, interfacing systems, logistics support requirements, the capabilities of operating personnel, and such other factors as must be correctly reflected in system requirements documents and accommodated in the system design. [Systems Engineering Principles and Practices, Alexander Kossiakoff, John Wiley & Sons]
So what does this mean in practice?
It means when we start without knowing what DONE looks like, no method, no technique, clever process is going to help us discover what DONE looks like, until we spend a pile of money and expend a lot of time trying out various ideas in our search for DONE.
What this means is that emergent requirements, mean wandering around looking for what DONE looks like. We need to state DONE in units that connect with Capabilities to fulfill a mission or deliver success for a business case.
What this doesn't mean is that we need the requirements up front. In fact we may not actually what the requirements up front. If we don't know what DONE means, those requirements must change and that change costs much more money then writing down what DONE looks like in units of measure meaningful to the decision makers.
So Here's Some Simple Examples of What A Capability Sounds like
- We need the capability to pre-process insurance claims at $0.07 per transaction rather than the current $0.11 per transaction.
- We need the capability to remove 1½ hours from the retail ordering process once the merger is complete.
- We need the capability to change the Wide Field Camera and the internal nickel hydride batteries, while doing no harm to the telescope.
- We need the capability to fly 4 astronauts to the International Space Station, dock, stay 6 months, and return safely.
- We need the capability to control the Hell Fire Missile with a new touch panel while maintaining existing navigation and guidance capabilities in the helicopter.
- We need the capability to comply with FAR Part 15 using the current ERP system and its supporting work processes.
Here's a more detailed example
Identifying System Capabilities is the starting point for any successful program. Systems Capabilities are not direct requirements, but statements of what the system should provide in terms of “abilities.”
For example there are three capabilities needed for the Hubble Robotic Service Mission:
- Do no harm to the telescope - it is very fragile
- Change the Wide Field Camera - was built here in Boulder
- Connect the battery umbilical cable - like our cell phones they wear out
How is this to be done and what are the technical, operational, safety and mission assurance requirements? Don’t really know yet, but the Capabilities guide their development. The critical reason for starting with capabilities is to establish a home for all the requirements.
To answer the questions:
- 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. But measuring how the Capabilities are being fulfilled is most meaningful to the customer. The “meaningful to the customer” unit of measures 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.
This is the difference between fit for purpose and Fit for Use.
The process flow below 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 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. 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. Success means providing the needed capabilities, on or near schedule and cost. 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 Use Cases and scenarios to provide the context to measure the level of capability.
Here's One Approach For Capturing the Needed Capabilities
In Order To Capture These Needed Capabilities We Need To...
What Does All This Mean?
When we hear of all the failures of IT projects, and other projects for that matter, the first question that must be answered is
What was the root cause of the failure?
Research has shown that unclear, vague, and many times conflicting requirements are the source of confusion about what DONE looks like. In the absence of a definitive description of DONE in units of effectiveness and performance, those requirements have no home to be assessed for their appropriateness.
