Business requirements |
|
Article Purpose
This article looks at the business requirements document and places it in context to business processing, workflow and other solution definitions.
Business requirements and BPM.
Today many methodologies are being implemented as a means of increasing the effectiveness and efficiency of processing systems. Amongst these initiatives is Business Process Management (BPM), which identifies key production workflow processes within an organization and then proceeds to optimize the arrangement and execution of these processes. Indeed many vendors are providing executable, automated workflow, solutions in the BPM space.
Although the optimization of business processes is vital to operational cost reduction, it should not be done without a comprehensive understanding of the business requirements of the processing system. Whilst BPM is a compelling work process optimization methodology, we should not loose sight of the need for separate business requirements.
This article examines the first level of operational requirements of a business system, namely the business requirements. To be more accurate these are:- The business requirements of a processing system. The term system is defined as a combination of people, process and technology with a common purpose. In this context, as the goal is to relate the software solutions to the business requirements, we are only examining data processing systems. The business requirements are one of the main engineering deliverables within the CMMi software process improvement framework, in future articles the software specification and other software engineering deliverables will be examined. The intent is to provide a comprehensive description of all Software Quality Assurance (SQA) documentation and procedures.
|
Specifying the business requirements
When specifying the essential data processing requirements of a system we only need to define “What”, the requirement is, and not “How”, the solution, it is done. The distinction of What versus How extends to workflow (business processes) or any organization of manual and automated processes.
One acid test of specifying the requirement versus the solution is to ask the question could an alternative workflow or man machine boundary satisfy the requirements. By way of example, take the requirements specification for a money lending operation 60 years ago. The calculation of loan rates, the payment schedules, the GL accounting treatment etc. would all be separately documented in the business requirements (of the processing system) document. Now consider the introduction of a calculator (machine) to the operation. The workflow and work organization may change, to utilize this calculator, but the essential business requirements remain the same. With this example it is clear we do not want to place the use of the calculator in the requirements, so a new workflow is produced (use cases, activity diagrams etc.), but the business requirements remain static. The business requirements only change when the requirement itself changes, for example a new loan rate or different collateral of GL account derivation.
Consider not having separate business requirements, from the workflow diagrams. In the previous example let’s now introduce an automated GL accounting system, to replace the manual GL booking. If all we have is the workflows or the business process diagrams, in place of the requirements, we could miss opportunities of completely re-organizing our workflow to satisfy our requirements and take advantage of the newer technology. If the workflow, or other solution component, becomes the requirements then it is difficult for us to see the ‘wood from the trees’. In the previous example we can do without some of the functions performed by the calculator, when the GL accounting system is introduced. When we eliminate these functions it may no longer make sense to be ‘batching’ the work for the calculator utilization. In other words it becomes difficult for us to rearrange the solution whilst still knowing that all of our requirements are satisfied if we have not explicitly stated our requirements in a separate document.
In order to re-arrange the solution (including) workflow, and not loose any required capabilities, we also need another document and that is a Requirements Traceability Matrix (RTM). The RTM cross references, two way, the business requirements to the place in our system that satisfies the requirement. In this way we can rearrange our workflows, to take advantage of technology, and know the impact on the ability of the system to satisfy the requirements.
The example given, of when there are no separate requirements, is a simple case but consider most realities of large enterprises. With merges, acquisitions, technology coming and going people opening new databases and duplicating data etc. to expedite a ‘pressing’ need it is clear that the costs of not understanding the essential requirements (and mapping them to the solution via a RTM) are huge as many inefficient processes (workflows) will co-exist. The processing capability of an organization can be measured on a throughput basis, i.e. cost per loan, or cost per item sold. The efficiency of the workflows (Business processes) will directly impact the process costs. The ability to optimize business processes is greatly enhanced by the existence of business requirements, which are separate from the solution. The RTM also stops duplication of effort as we can clearly see overlapping processes, with regard to the satisfaction of a given requirement.
|
|
|
Business Requirements scope
The scope of the business requirements should be as large as possible; in practice it is not possible to encompass the whole organization, in large companies, as this would slow down the ability to change any part of the system. Most companies organize themselves around product (or service) line, and this is usually how business requirements are partitioned. Typically, business process areas are the scope for requirement partitioning but with the introduction of enterprise modeling tools overlapping requirements (i.e. GL Booking) can be identified and accommodated in an appropriate workflow.
|
Conclusions
In conclusion, as far as a data processing ‘system’ is concerned, the most essential requirement is the businesses requirements of the processing system (be they manual or automated or a combination). These requirements should be separated from the solution and in this context business process (workflow) is a part of the solution.
|
|