When there is discussion around requirements, requirements gathering, or implementation of requirements there is usually a core principle missing. This is more so in the agile software development world, where "requirements" are represented by stories on sticky notes placed on the wall. While the Scrum approach to managing the work flow is a valid approach, the question remains "how do we know what we want?"
A bigger question is "what capabilities do we want from this system when it it complete?" This is the Capabilities Based Planning question.
Let's start with the process of Capabilities Based Planning.
Capabilities Based Planning started in the defense business in several countries around the same time. The US DoD uses CBP as part of the Quadrennial Review process. So does Canada and Australia.
For IT this step is usually missing. When it is missing, there is no "home" for each of the requirements. There is no "reason" for the requirement in business terms. What remains are technical reasons wrapped in business language, but not pure business language. This is similar to the term "value" used in agile development in the absence of the unit of measure for value. A unity of measure meaningful to the decision maker.
The chart above is the top level process flow for defining the Capabilties of the needed system. If you download the referenced document, and flow the process you'll answer the question "what do we need this system to do when it is done?"
For example we are moving from one accounting paradigm to "project based accounting," to be compliant with the Cost Accounting Standards required by the Federal Government contracting standards. We need the capability to:
- Provide project based accounting
- provide real time access to financial data
- Be compliant with GAAP and CAS
- Reduce cost and risk through moving the existing system to the "cloud"
Those are "capabilities" statements. The technical and operational requirements neeed to fulfill these capabilities come next.
