In this KnowledgeKnugget™ you will learn the concept of business process analysis for requirements identification. At the end of this KK, you will understand the different types of diagrams – Data Flow Diagrams (DFD), Swimlane or Activity Diagrams, and Business Process Modeling Notation (BPMN) – that are in use. The KK will also explain which diagram is better for different types of analysis (problem analysis, timing analysis, exception analysis, information usage analysis).

Using Business Process Models to Define Requirements

Business Process Analysis is a concept that originated in the ‘90’s where organizations discovered the benefits of thinking in terms of “Business Process” as opposed to the underlying “functions” and “procedures”. A business process combines manual and automated tasks that ultimately add measurable value to a product or service. A model (business process diagram) of these manual and automated processes is a picture of how your business process works (as-is) or should work in the future (to-be). To develop an effective application that optimally supports the business process, developers have to understand the business process thoroughly. The challenge for the person tasked with defining requirements for an IT system (aka the one wearing the BA hat) is to express the inner workings of the business process in terms the Information Technology (IT) department needs for developers to build the application right.

The 1990’s business process revolution also introduced concepts such as “Business Process Reengineering” and “Business Process Improvement” as methods for restructuring and improving the efficiency of business processes. As a result, many (especially larger) organizations created departments solely responsible for modeling, analyzing, and improving the organization’s business processes and related workflows. These organizations have extensive business process documentation often including models that you can use for business process analysis. In companies that have no process documentation, you can create business process models as needed. In either case, the model makes you aware of aspects of the business process that are not obvious even (or perhaps, especially) to those involved in the process.

Process Models Define Solution Functional and Non-functional Requirements

Business Process Analysis identifies bottlenecks, inefficiencies, disconnects and other problem areas. Developers need solution functional and non-functional requirements to develop or modify an application. As the one wearing the BA hat, your responsibility is to use the results of Business Process Analysis to drive out business, stakeholder, and ultimately solution requirements for an IT solution.

For that you need to be able to recognize things like:

• What the process does (what does it deliver)
• The internal steps (aka sub-processes, activities, tasks, or internal processes depending on the model’s level of detail) in each process
• The sequence in which these internal steps are executed (control flow)
• External elements that interact with the process
• Conditions that influence the execution of each process
• The business data that individual processes create and consume
• Where business data comes from and where it goes to (data flow)
• The value that each internal step adds
• The owner or organizational unit responsible for the process
• . . .

One challenge in interpreting business processes using a business process model is that there are several competing conventions for drawing them.

… [end of excerpt]