Many times when software requirements are collected, organized and documented, the focus is on the software capabilities needed. But software capabilities are not sufficient to get business value. One must also document the expected pattern of integrating the software capabilities into the business process to understand how the value will be realized.
Stating requirements in terms of business capabilities is a way to do this. Business Capability requirements always exist in a business context. A business process, a business model, an operating unit, etc. They are not independent from this context. Software capability requirements are necessarily independent of any specific business context, as the software is independent of the business operation. This notion of independence is not unique, it is analogous to a branch office procedure or policy, where we want to develop a generalized branch office operating procedure that works independently of any specific branch office, but allows all branch offices to operate and integrate with the home office in standard ways. In the same way, most software capabilities are generalized, so that they are independent of the business process, a report shows what it shows, a screen allows the input of data, but those actions outside of the context of a business process do not realize any value.
Let's walk through some examples of business capability requirements and some potential software capability requirement that might be integrated to meet the business capability requirements. We start by defining the business context.
Business context:
There are 20 offices, each having one or more departments or teams, that perform a specific client servicing process. In the current state, it requires two or three different roles from the team to complete this process in collaboration. Overall, the process takes 1.5 man hours. We also know that 1 in 10 contracts have to be revised after signing, and 1 in 20 approved contracts do not get imaged in the same day. Here are the current steps in the process:
- Rep Role
- Interview client to capture information
- Enter service contract on paper log
- Fill out of paper forms
- Get the client to sign those forms
- Approver Role
- review those forms for correctness and completeness
- Countersign the forms
- document the approval on paper log
- Associate or Rep Role
- update an existing software system with data from the forms.
- scan the paper forms into the imaging system
- File the paper forms in the client file.
- Countersign the paper log indicating that the process is complete.
Business capability requirements:
Increase the capacity of each office to perform by 200% without increasing staff.
Decrease the number of process exceptions by 50% without increasing staff.
Decrease the amount of time that the client is required to be involved in the process by 50%.
Software Capability Requirements:
- Provide an ability to generate signed paper forms, based on the answers to interview questions so that the staff and client involvement time to fill in paper forms is reduced by at least 50%.
- Provide an ability to validate input to ensure client responses meet internal contract criteria – so that we reduce the number of signed contracts that need to be revised by at least 50%.
- Provide an ability to capture electronic signature for clients and approvers so that staff time spent scanning paper forms is no longer necessary.
- Provide the ability to integrate data from the forms capture process into online systems so that staff time spent on manual key entry is eliminated.
- Provide the ability to automatically generate images of the signed and approved contract so that staff time spent scanning is eliminated, and all imaging process errors are eliminated.
- Provide an ability to audit of all service contracts that have been initiated in a given time period, and the status of that contract, so that the staff time spent updating a paper log is eliminated.
Observations:
Notice that each of the software capability requirements is related to a business capability requirement, and also some context information through a "so that" clause in the requirement. This structure is so that we can ensure that the software capabilities are directly tied to the business goal in the business context. If we created the abilities without meeting the "so that", we have not "satisfied" the requirement. The "so that" describes the business value that we want, and software capabilities that do not add business value are a waste.
The business capability requirements describe success criteria for the project. Before we get busy exposing the details of how we want the software capabilities to work, we must establish the success criteria, so that the builders can know when they have done it. We communicate this up front, because the builders should know why what they are doing is important.
The business capability requirements are separated from any statement of return on investment. We are freeing up staff time and reducing the errors in a process, What the business uses that staff time for is immaterial to the design of the software.
The software capability requirements do not specify any specific system that should receive a feature or capability. We know from the context that there are at least two software systems involved in the business context, yet neither of them directly mentioned in the software capability requirements.
Software capability requirements should be completely devoid of "how" they should describe a "what" and relate it to a "why". The what is a software capability, not a specific software component or feature. The specific components and features are part of a solution proposal or high level design,
Importance:
When there are larger decision about the solution as yet unmade (such as buy or build) documenting the requirements in terms of capabilities, rather than specific means of providing those capabilities becomes very important, It allows one to evaluate vendors independently, and against a build decision on level ground, or without bias.
No Comments