In my blog about the Zachman Framework, I introduced the framework and its components. Today, I read a great post by Barbara Carkenord at B2ttraining: "Why Identify Business Processes and Use Cases?". The point of her blog post is that Business Analyst shouldn't jump into defining use cases without first describing the business processes because they both come from a different perspective. And as we saw from my Zachman Framework post, Business process emerge from the perspective of the Business Owner.
What is a Business Process?
From wikipedia: A business process or business method is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers.
There are three types of business processes:
Management processes, the processes that govern the operation of a system. Typical management processes include "Corporate Governance" and "Strategic Management".
Operational processes, processes that constitute the core business and create the primary value stream. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales.
Supporting processes, which support the core processes. Examples include Accounting, Recruitment, Technical support.
There are three types of business processes:
Management processes, the processes that govern the operation of a system. Typical management processes include "Corporate Governance" and "Strategic Management".
Operational processes, processes that constitute the core business and create the primary value stream. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales.
Supporting processes, which support the core processes. Examples include Accounting, Recruitment, Technical support.
This is the "HOW" or "Activities" that allows the enterprise to create products or services. The Business Owner's interested in business processes stems from their desire to keep cost under control by doing things effectively and efficiently. This is where you will get your business requirements. Skipping the definition of business process means missing out on the understanding of the important tasks within an enterprise and how those tasks are performed. if the end result is to find/build a solution that makes work easy (via automation or introduction of a system), then understanding how things are done is important. A Business Analyst who doesn't understand the business process will not help the Business Owner achieve their desire for effectiveness and efficiency.
Use cases on the other hand contains the definitions of actors (users of the system) and desired system's behavior. This is the perspective of the Architect. When defining the What, How, Where, Who, When and Why, use cases fall under the "WHO" in the Models of Fundamental Concepts. This perspectives looks at the underlying functions of each business process. Your functional requirements will come from use cases.
Moral of the story, you can't have on without the other. As Barbara points out: they are both important. To have a complete set of requirements you must complete both business processes and use cases.
Use cases on the other hand contains the definitions of actors (users of the system) and desired system's behavior. This is the perspective of the Architect. When defining the What, How, Where, Who, When and Why, use cases fall under the "WHO" in the Models of Fundamental Concepts. This perspectives looks at the underlying functions of each business process. Your functional requirements will come from use cases.Moral of the story, you can't have on without the other. As Barbara points out: they are both important. To have a complete set of requirements you must complete both business processes and use cases.
