Business Requirements Modeling
Business Modeling can take many forms. The choice to use business modeling, and the choice of how and what to model, require a clear understanding of the objectives of the modeling exercise. Business modeling is an area where excessive effort and cost can be expended for little benefit if those objectives are not properly understood.
Business Requirements Modeling is used to understand the requirements imposed upon a business or part of a business by the eternal stakeholders.
- Objective: Understand the expectations the external stakeholders have of a business.
- Objective: Understand the expectations the external stakeholders have of a portion of a business.
Objective: Understand the expectations the external stakeholders have of a business.
To achieve this objective, we wish to focus on the value the business delivers to its external stakeholders. The external stakeholders are customers, suppliers, regulators, government agencies, shareholders, and employees. (Aside) It is important to note that employees fill multiple roles in relation to a business. Most of those roles are internal roles where the employees contibute to business processes, etc, and are not of interest here. Here we are interested in the role that the employee plays as a person with a family that relies on the business as a source of income, fulfillment, and other benefits. This is an example that shows the importance, in all forms of business analysis, of focusing not on individuals, but on the different roles that the individuals fill.
Use cases have developed as an excellent way of defining the functional requirements for a technical system in a way that focuses on the value the system delivers to its external stakeholders. They are equally useful for defining the requirements for a business in a way that focuses on the value the business delivers to its external stakeholders. There is plenty of information available on how to analyse requirements and develop use cases. Some of the information available is good, some is not. My Requirements Analysis page has some tips, and references to the good information that I have located.
Having identified the external stakeholders, they become the actors in our Business Use Case model. The information referenced above discusses system use cases, but the principles are equally applicable to business use cases. In this case, the business is the system. The use cases focus on the value the business deliver to the actors, and describe the way the actors interact with the business. The system boundary is the boundary of the business organisation.
Of course, we may only be interested in a subset of the value the business delivers to a subset of the external stakeholders. In this case, it is helpful to restrict the analysis to those actors and use cases that contribute to the objectives of the exercise.
Objective: Understand the expectations the external stakeholders have of a portion of a business.
In this case, the focus is not the whole business, but rather some business unit, department, business function, or team (possibly cross-functional). We can refer to this as the target business subsystem. Some of the actors may be external to the business. Others may be within the business but external to the target business subsystem. In this case, it is important to be very clear about where the system boundary lies to identify the right actors. It may well be the case that individual people or groups have roles within the target subsystem whilst having different roles as external stakeholders (modeled as actors). It is important to be clear about the distinction between individuals and their various roles. In the event that the internal processes of the target subsystem are modeled (for a separate objective), the internal roles will be represented as business workers.
Apart from having a different system boundary, the approach to modeling the expectations in this case is the same as for the above objective which relates to the whole business. Refer to my Enterprise Business Modeling page for more information on how this works in an enterprise context.
Additional Resources
Online
- Heumann, J. 2001, 'Introduction to Business Modeling Using the Unified Modeling Language (UML)', The Rational Edge, March 2001
- Wardley, J. 2001, 'Tighten Business Processes Before You Automate', The Rational Edge, April 2001
Other
- Eriksson, H. & Penker, M. 2000, Business Modeling With UML: Business Patterns at Work, John Wiley & Sons.
