Chapter 4 - Business Use Case
Business Use Cases
Business Use Cases
Business events are useful to partition the work, but it is the work’s response to the event that now captures the interest of the requirements analyst. For every business event, there is a preplanned response to it, known as a business use case (BUC). The business use case is always a collection of identifiable processes, data that is retrieved and/or stored, output generated, messages sent, or some combination of these. Alternatively, we could simply say that the business use case is a unit of functionality. This unit is the basis for writing the functional and non-functional requirements.
Understanding the Work:
When we say “work,” we mean the system for doing business. This system includes the human tasks, the software systems, the machines, and the low-tech devices such as telephones, photocopiers, manual files, and notebooks. In fact, anything that is used to produce the owner’s goods, services, or information. Until you understand this work and its desired outcomes. The product you intend to build must improve its owner’s work; it will be installed in the owner’s area of business and will do part of the work. All the business case follows some criteria:
● They are “natural” partitions—each one makes an obvious and logical
contribution to the work.
● They have minimal connectivity to other parts of the work.
● They have a clearly defined scope.
● They have rules for defining their scope.
● They have boundaries that can be observed and defined.
● They can be named using names that are recognizable to stakeholders.
● Their existence can be readily determined.
● They have one or more stakeholders who are experts for that part of
the work.
A diagram is given below to understand more clearly:
Formality Guide
Rabbit project helps to explore business use cases and understand their problem domain before starting to formulate a solution. This approach does not add to the documentation load, and it lessens the time spent delivering inappropriate solutions.
Horse projects should consider partitioning the work area using business use cases. Horse project helps to discuss the current and future work with your stakeholders. There is also the possibility of using BUC (and later product use case [PUC]) scenarios as the documentation to pass along to the developers, which allows you to avoid writing many of the detailed requirements. Horse projects are more formal and hold a blastoff meeting. 
Elephant projects should definitely use business events. Elephant projects have a large number of stakeholders and maintain clear communication where both are important and difficult. Elephants have a lot to lose by not having the blastoff deliverables firmly in place before proceeding further in the product development process. In most cases, the deliverables are discovered during meetings with the key stakeholders, and the results are recorded and distributed.The Scope of the Work
The work is the business activity of the owner of the eventual product; alternatively,
you can think of it as the part of the business that your customer or client wants to improve. To understand this work, it is best to think about how it relates to the world outside it. This perspective makes sense because the work exists to provide services to the outside world. To do so, the work must receive information and signals from the outside world, use these affected by the current development. Even if you are building an electromechanical device, such as an automated teller machine (ATM), and most of the human participation occurs outside the product boundary, your work context must still include the work that the human will be doing with the device.
Business events and business use cases allow you to carve out a cohesive piece of the work for further modeling and study. By understanding the work being done by each of the BUCs, you come to understand the optimal product you can build to support that work. If you are outsourcing, you might not determine the product use cases, but work instead on the business use cases. These business use cases can then serve as your negotiating document when you ask your outsourcer which parts of them he can deliver as product use cases.
Business analysts are equipped with two important tools for defining the project scope requirements: context diagrams and use case models. The first thing a business analyst should do when assigned to a project is to confirm that these two models exist, and have been approved and accepted by the stakeholders. If they don't exist, or haven't been approved, the business analyst should tackle these before starting detailed business system analysis.
ReplyDeleteThe Work scope is usually large and cannot be studied as a single unit and therefore it is important to divide the work into manageable pieces to simplify it and to make it easy to study the product's requirements. Business events and Business Use Cases allow to understand the work. The BUC are the most simple units of work to study and it is the pre-planned response to every Business event. The product use cases from from business use cases are derived ti group the requirements according to the response of business events. This results in developing a product valuable to the owner.
ReplyDeleteThis chapter is of the utmost importance in the course of Business Requirements Gathering as Business Use Case is used to divide the work as it is faster and more convenient and the idea of a preplanned ways for dealing with the specific problems is very important in the field of business analysis. Business events and Business Use Cases allow to understand the work. The B.U.C. are the most simple units of work to study and it is the planned before response to every Business event. The first thing a business analyst should do when assigned to a project is to confirm that these two models exist, and have been approved and accepted by the stakeholders. At last but not the least i will like to make a note that this chapter helped me a lot in the understanding of Business Use Case or BUC.
ReplyDelete