Business Use Cases
A business use-case model is a model that describes the processes of a business and their interactions with external parties like customers and partners.
The blastoff process, which we described in the previous chapter, establishesthe scope of the work—the business area to be studied. This scope—ideally
shown graphically as a context diagram—defines a business area, part of which
is to be automated by your intended product. In reality, this work scope is
probably too large to be studied as a single unit. Just as you cut your food into
small bites before attempting to eat it, so it is necessary to partition the work
into manageable pieces before studying it to find the product’s requirements.
In this chapter we provide heuristics for finding the most appropriate use
cases. In later chapters you will see how this process allows you to arrive at
the most relevant and useful product to build.
Understanding the work:
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 (sometimes all of) the work.
installed in the owner’s area of business and will do part of (sometimes all of) the work.
It does not matter which kind of work it is—commercial, scientific, embedded real-time,
manual, or automated—you always have to under-stand it before you can decide which kind of
product will best help with it. 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 note-books—in fact, anything that is used to produce the owner’s goods, services, or information. Until you understand this work and its desired outcomes, you cannot know which product will be optimally valuable to the owner.
Formality Guide:
Rabbit projects should pay particular attention to this chapter. When run-
ning an iterative project, it is important to have a rock-solid grasp of the
business problem to be solved. We strongly suggest that rabbits make use of
business use cases to explore their problem domain before starting to formu-
late a solution. This approach does not add to the documentation load, and
late a solution. This approach does not add to the documentation load, and
it lessens the time spent delivering inappropriate solutions.
use cases as we describe them in this chapter. We have found that the BUC
scenarios are a useful working tool for discussing 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. We shall discuss this aspect in later chapters.
Elephant projects should definitely use business events. Given that ele-
phant projects have a large number of stakeholders, clear communication is
both important and difficult. We have found that BUC scenarios are an ideal
mechanism for discussing the work in geographically distributed teams.
Later, the BUC scenarios and their PUC derivatives are maintained as part
of the formal documentation. The BUC scenario is also useful for discussing
high-level issues with outsourcers.
mechanism for discussing the work in geographically distributed teams.
Later, the BUC scenarios and their PUC derivatives are maintained as part
of the formal documentation. The BUC scenario is also useful for discussing
high-level issues with outsourcers.
THE SCOPE OF THE WORK.
ReplyDeleteThe 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. same as if TD bank wants to introduce a new application or the service they have to look how that thing will work in outside world.moreover there will be some potential question about the service and risks. these all question will make sense because service is going to outside world.
WHY ARE BUSINESS EVENTS OR BUSINESS USE CASES GOOD IDEA.
The work’s response to a business event brings together all the things that
belong together. As a result, you get cohesive partitions with minimal interfaces
between the pieces. This partitioning gives you more logical chunks
of work for your detailed requirements investigation—the fewer dependencies
that exist between the pieces, the more the analysts can investigate the
details about one piece without needing to know everything about all the
other pieces.
Business Event
ReplyDeleteBusiness events and their feedback: A business event appears at the point the adjacent system resolve to do something, or as part of its task, some processing action occurs. The adjacent system expresses the work that the event has happened by dispatching a triggering data flow. When this stream of data arrives, the work reacts by processing the approaching data, and by retrieving and recording saved data.
Time-Triggered Business Events
A time-triggered business event appears when a set up time is reached. This is situated on either a periodic occurrence, an established time interval, or a certain amount of time elapsing since one more business event. The normal feedback is to recapture stored data, process it and send some information to a contiguous system.
This comment has been removed by the author.
ReplyDeleteGood work guys!!
ReplyDeleteNow, I want to include that how can we find the business events?
When business events happens, then we get some response from the project. Events can happen outside the scope of the work which is known as External event or it can be time-triggered event.
In external events, communication from outside tells that event has been happened. In time triggered events, the outcome flows towards the outside world. Data flows must be available in both situations
Business Use Case
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.