SWEN 5135 Configuration Management
Business Use Case |
A business use-case
instance is a sequence of actions performed in a business that
produces a result of observable value to an individual actor of the
business.
A business use case defines a set of business use-case instances.
A business use case has a name. |
Topics
The processes of a business
are defined as a number of different business use cases, each of which
represents a specific workflow in the business. A business use case defines what
should happen in the business when it is performed; it describes the performance
of a sequence of actions that produces a valuable result to a particular
business actor. A business process either generates value for the business or
mitigates costs to the business.
A passenger can either travel individually or with a
group. When traveling with a group, a passenger is accompanied by a tour guide.
A business use case describes "a sequence of actions performed in a
business that produces a result of observable value to an individual actor of
the business". Hence, from an individual actor’s perspective, a business
use case defines the complete workflow that produces the desired results. This
is similar to what is generally called a "business process", but
"a business use case" has a much more precise definition.
The definition of the business use case concept contains a number of
keywords, which are essential to understanding what a business use case is:
- Business use case instance – Defined above is really a specific business
workflow ; that is, an instance. In reality, there are a great number of
possible workflows, many of them very similar.
To make the use-case model understandable, similar workflows are grouped
together into a business use case—a "class" in terms of the object
model. To identify and describe a business use case means to identify and
describe the class-like business use case, not the individual use case
instances.
- An individual actor – The actor is probably the real key to finding the
correct business use case. Starting with individual actors—or really
instances of actors—helps avoid business use cases that are too large or
complex.
When determining suitable actors, first try to name at least two or three
different people who could perform as the actor in question, then critically
evaluate the support each individual requires. For example, suppose you
initially identify an actor called "customer". Later, as you look
deeper into the support each individual customer requires, you might find
three rather different customers: the normal "user" of the product,
the "purchaser" and the "evaluator", who are competent to
compare the product with its competitors. Each of these may require a separate
business use case because they represent different roles that can be played in
the business.
- A result of observable value – This expression is very important in
determining the correct extent of a business use case, which should be
neither too small nor too big. Stating that the business use case should
give a result of observable value, that is, both perceived and measurable,
helps you to find a complete flow, and avoid business use cases that are too
small.
A good business use case helps an actor perform a task that has an
identifiable value. It may be possible to put a price on a successfully
performed business use case. A too-small business use case will have a limited
scope, thus also little re-engineering potential.
- In a business – The words "actions performed in a business",
means both that the business provides the business use case to the actor,
and that the business use case only covers what is actually done within the
business. Supporting work done elsewhere is not included.
- Action – The actions are invoked either on request from an actor to the
business or at a certain point in time. Actions include internal activities
and decisions, as well as requests to either the invoked actor or other
actors.
Business services are described through different business use cases, each
with a task of its own. The collected set of business use cases constitute all
the possible ways of using the business. See also Guidelines:
Business Use-Case Model.
In a use-case driven business modeling project, you develop two views of the
business.
The business use case itself presents an external view of the business, which
defines what is essential to perform for the business to
deliver the desired results to the actor. It also defines what
interaction the business should have with the actors when the business use
case is executed. Such a view must be developed when you are deciding and
agreeing on what should be done in each business use case. A collection of
business use cases gives an overview of the business that is very useful for
informing employees of what different parts of the business are doing, and what
results are expected.
A business use-case realization, on the other hand, gives an internal view of
the business use case, which defines how the work should be
organized and performed in order to achieve the same desired results. A
realization encompasses the business workers and business entities that are
involved in the execution of a business use case and the relationships between
them that are required to do the job. Such views must be developed to decide and
agree on how the work in each business use case must be organized to achieve the
desired results.
Both views of the business use case are primarily intended for people within
the business - the external view for people who work outside the business use
case, the internal view for people who work inside the business use case.
As a business operates, you will find that you can identify an almost
unlimited number of separate workflows. A use-case instance is simply a specific
workflow, or scenario. It corresponds to the work that a number of collaborating
business members perform in their roles defined in the object model, and not to
any particular business member or any role that the member is playing.
A business use case is what you normally work with to make the use-case model
understandable, and to avoid drowning in details. It represents the union of a
number of business use-case instances with workflows that are similar, but
normally not identical.
Typically, an employee who is competent to act in a certain role will do this
in instances of several different business use cases.
Example:
At the airport check-in counter, the two business use cases,
Individual Check-in and Group Check-in both require the same competencies from
the employee at the check-in counter, as well as access to the same information
about a certain departure. Thus, both use cases can and should be designed using
the same Check-in Agent business worker and Departure entity.
It is sometimes hard to decide if a service is one, or several business use
cases. Apply the definition of a business use case to the airport check-in
process. A passenger hands his ticket and baggage to the check-in agent, who
finds a seat for the passenger, prints a boarding pass and starts
baggage-handling. If the passenger has normal baggage, the check-in agent prints
baggage tag and customer claim check, and terminates the business use case by
applying the tag to the baggage, and giving the customer claim check, together
with the boarding pass, to the passenger. If the baggage has a special shape or
special contents so that it cannot be transported normally, the passenger must
take it to a special baggage counter. If the baggage is heavy, the passenger
must continue on to the airport ticket office to pay for it, because check-in
agents do not handle money.
Do you need one business use case at the check-in counter, another at the
special baggage counter and a third at the ticket office? Or do you need just a
single business use case? Surely, this transaction involves three different
types of actions. But the question is, will any of them be of value to a
passenger carrying special baggage if he does not do the others? No, it is only
the complete procedure—from the moment the passenger approaches the check-in
counter until he has paid the extra charge—that has value (and that makes
sense to the passenger). Thus, the complete procedure involving the three
different counters is a complete case of usage—a business use case.
In addition to this criteria, it is practical to keep descriptions of closely
related services together, so that you can review them at the same time, modify
them together, test them together, write manuals for them, and in general manage
them as a unit.
Notice also that two independent business use cases can have similar
beginnings.
Example:
In an insurance company, the business use cases Handle Claim
and Handle Request both start when someone (an actor) makes contact with a claim
handler. The claim handler and the actor exchange some information to make it
clear whether the actor is filing a claim or requesting some information. Then,
and only then, is it possible to decide which business use case is performing.
Although the two business use cases have similar beginnings, they are not
connected.
The name of the business use case should express what happens when an
instance of the business use case is performed. The form of the name should
therefore be active, typically described by the gerund form of the verb
(Checking-in) or a verb and a noun together.
The names can either describe the activities in the business use case from an
external or an internal viewpoint, for instance placing an order or receiving an
order. Although a business use case describes what happens within the business,
it is often most natural to name the business use case from its primary actor’s
point of view. Once you have made a decision which style is to prefer in your
case, you should follow the same rule for all business use cases in the business
model.
The goal of a business use case should be specified from at least two
perspectives:
- For the business actors the business process interacts with, specify the
value those business actors expect from the business (external goals).
- From the perspective of the organization performing the business
processes, define what the objectives are of having this business process in
place and what you hope to achieve by performing it (internal goals).
The most common categories metrics used are:
- Time - an approximation of the time it should take to execute the
workflow, or part of the workflow.
- Cost - an approximation of the cost of executing the workflow, or part of
the workflow.
The challenge is to understand what scenarios (business use-case instances)
are relevant to measure. Criteria to use are frequency of the scenario, or
business relevance of the scenario. If you can determine that a particular part
of the workflow has importance, you may save yourself some effort by only
measuring the cost or time of that subflow.
Most workflows may be thought of as several subflows, which together yield
the total flow. Sometimes several business use cases in the business have a
common subflow, or the same subflow appears in different parts of one business
use case. If this common behavior has any substantial volume, it should be
performed by the same business workers.
If a subflow is substantial, common to several business use cases, and also
forms an independent and naturally delimited part, the model might be clearer if
this behavior is partitioned out to a separate business use case. This new
business use case is then either included in the original use case (see Guideline:
Include-Relationship in the Business Use-Case Model), an extension to it
(see Guidelines: Extend-Relationship in the Business
Use-Case Model), or a parent use case to it (see Guidelines:
Use-Case-Generalization in the Business Use-Case Model).
Example:
At the airport check-in counter, the two business use cases,
Individual Check-in and Group Check-in both use the same procedure to handle an
individual passenger’s baggage. Because the subflow is independent of the
ticket handling, and is logically connected, it is modeled separately in the
business use case, Baggage Handling.
The workflow of a business use case can be visualized using activity
diagrams, see Guidelines: Activity Diagram in the
Business Use-Case Model.
For more information on structuring and describing the workflow of a business
use case, see Guidelines: Use Case, the discussions on
Flow of Events.
Following is a description of the workflow of the business use case Proposal
Process in an organization that sells solutions configured to each individual
customer. In Guideline: Activity Diagrams in the Business
Use-Case Model, the section on Examples of Use, you find an example of an
activity diagram visualizing the structure of this workflow:
1. Basic Workflow
1.1. Initial Contact
This process starts with an initial contact between the Customer and The
Company. This may happen in one of the following ways:
- The Customer contacts The Company with an inquiry or a set of requirements
- The Company decides that it has products that would add value to the
Customer and revenue to The Company.
The Company interacts with the Customer to establish:
- Customer contact person,
- The Company contact person,
- Whether this is a new customer to The Company,
- Any competitive information about the proposal or bidding situation
surrounding this agreement.
1.2. Initial Opportunity Work
There are two main purposes of this section:
- Gather customer requirements,
- Decide about further actions on this opportunity.
The steps, Gather Preliminary customer requirements, Create sales plan
(optional), and Perform Opportunity Analysis can be performed in an iterative
manner, and may be performed somewhat in parallel.
1.2.1 Gather Preliminary Customer Requirements
Gather both product requirements and customer business requirements by:
- asking the Customer
- looking at whatever customer input there is
- performing a preliminary site survey (optional)
- looking at any available customer information
A complete set of requirements would include:
- choice of technology (could be several, if the customers wants
alternatives investigated)
- any product preferences
- functional requirements (market analysis)
- building structure and environmental characteristics
- demography
- mobility/capacity
- network growth projection
- installed base information
- timelines
- service requirements
- price requirements
1.2.2 Create Sales Plan (optional)
The Company works with the Customer to determine how it is going to propose a
solution meeting the customer requirements. This creation is called a sales
plan, and includes the network and switch characteristics for the potential
solution. The strategic positioning of The Company and its network is also
discussed so that we can prepare for future needs.
This sales plan is then reviewed with the Customer for accuracy and
completeness. It will then be used throughout the proposal process as a guide
when deciding which products, market packages, and line items to propose, and
which assumptions to make when putting together the proposal.
1.2.3 Perform Opportunity Analysis
The Company will obtain the highlevel price and cost of the potential
solution. This is done in order to understand the potential value of this
opportunity, not to provide an accurate dollar amount to a Customer.
The Company then looks at the customer requirements to determine:
- risks in the opportunity (product availability, competition, customer
risk)
- costs compared to revenue
- type of opportunity (simple, complex, etc.)
- probability of sales
- anticipated number for size of sales
- estimated schedule
Based on this evaluation, The Company makes a decision whether or not to
continue the opportunity.
1.3. Create Proposal Project Plan
The Company will create a plan for creating and offering the proposal. The
plan will include the assignments to the individuals completing the parts of the
proposal.
1.4. Create Delivery Project Plan
The Company develops a tentative project plan for delivery of the solution
based on:
- time lines in customer requirements
- resource availability
- factory capacity
- new product availability
- availability of third party products
This project plan will be used for future factory planning.
Additionally, this project plan will be updated and modified during the Quote
Process.
1.5. Prepare a Quote
This flow is defined in detail in the business use case Quote Process, which
is included.
The result of the Quote Process is an engineered solution that may have various
levels of certainty, along with a price.
1.6. Compile Additional Information
The Company compiles information to respond to any inquiries (usually
regarding future development of products) that might be a part of the customer
business requirements. This may also include information The Company thinks the
Customer should know. The inquiries are generally of the following types:
- capability now
- capability in future
- compliance to standards
- compliance to future standards
- services offered now
- services offered in the future.
1.7. Analyze and Finalize the Proposal
The Company compiles a proposal that includes the following items:
- the quote(s)
- marketing literature (off the shelf)
- product information (off the shelf)
- financing terms and conditions
- scheduling information
- roll up the financial analysis to the proposal level
- penalties and liabilities of both the Customer and The Company
- legal 'environmental' statements
- any assumptions made when creating the solutions in the proposal
into a format to be presented to the Customer.
1.8. Present the Proposal
The Company presents/proposes the above information to the Customer.
1.9. Obtain Customer Decision
The Customer will give feedback on the proposal. The Company obtains an
agreement from the Customer on quotes within the proposal. Such an agreement may
have different format depending on the character of the solution and who the
Customer is.
It may be:
- a signed purchase order
- a verbal agreement that the Customer will submit a purchase order
- a signed contract
- a verbal agreement
- a negative decision occurs when there is no decision and validity expires
2. Alternative Workflows
2.1. Business Opportunity Rejected
If in 1.2., it turns out the business opportunity is rejected, the following
actions may be taken:
- completely rejected
- attempt joint venture with other Supplier
- redirect to other region
- pass the request to another distributor/Supplier
- attempt to change customer requirements
2.2. Unable to Meet Customer Requirements
If in Perform Opportunity Analysis or Prepare a quote, The Company is unable
to suggest a solution to the customer requirements, then the following actions
may happen:
- suggest another manufacturer's equipment
- re-evaluate the customer requirements
- contact The Company to find out about future products
- attempt to change customer requirements
- decide to develop new products
- seek joint venture or supplier
- seek alternative forms of financing
- apply different discount policy
2.3. Critical Information Not Known
If at any point in the Proposal Process The Company identifies some critical
information not known or available then he does one of the following:
- Obtain the information
- Make assumption and continue
If any assumptions are made, then they are logged and given to the Customer
in an attached document in the proposal.
2.4. New/Incomplete or Incorrect General Customer Profile
If The Company determines that the general customer profile is inaccurate for
some reason, the following actions may be taken.
- If the Customer is new, then negotiate an agreement
- Include/determine customer preferences
- Determine installed base
- Request an update to records
The possibilities of a business use case should reflect the improvement
potential you can see for the business use case, where in the process, as well
as scale. Refer to the metrics you have specified for the business use
case.
An extension point opens up the business use case to the
possibility of an extension. It has a name, and a list of references to one or
more locations within the workflow of the business use case.
See also Guidelines: Extend-Relationship in the
Business Use-Case Model.
- Its name and brief description are clear and easy to understand, even to
people outside the business modeling team.
- Each business use case is complete from an outside (actor’s)
perspective. For example, the business use case Handle Claim in an insurance
company starts when a customer files a claim. The Handle Claim business use
case is not complete unless it includes a notification about the decision
from the insurance company to the customer and (if appropriate) a
compensatory payment.
- Each business use case normally is involved with at least one actor.
Business use cases are initiated by actors, interact with actors to perform
the activities, and deliver results.
- It is possible, but unusual, for a supporting use case not to interact
with an actor. This is true if a business use case is initiated by an
internal event and does not have to interact with an actor to perform its
activities.
- It must be clear and easy to understand, even for people outside the
business modeling team.
- It describes the workflow, not just the purpose of the business use case.
- It describes only those activities that are inside the business.
- It describes all possible activities in the business use case. For
example, what happens if a condition is met, as well as what happens if it
is not.
- It does not mention actors who do not communicate with it. If it did
mention other actors, it would make the description difficult to understand
and maintain.
- It describes only those activities that belong to it, not what is going on
in other business use cases that work parallel to it.
- It does not mention other business use cases with which it does not have
relationships. If the business use case requires that some results exist in
the business before it can start, this should be described as a
precondition. The precondition should not have any references to the
business use cases in which the result was created.
- It indicates if the order of any activities described for the business use
case is not fixed.
- It is structured so that it is easy to read and understand.
- The description clearly describes the start and end of the workflow.
- Each extend-relationship is described clearly so that it is obvious how
and when to insert the business use case.
- It is substantial. Remember, a concrete business use case must be easy to
read, together with its abstract business use cases. Therefore, an abstract
business use case should not be too small. If an abstract business use case
is not substantial, it should be eliminated and its activities should be
described in the affected concrete business use cases.
- It contains logically related activities.
- It exists for a specific reason. An abstract business use case should
contain any of three kinds of activities: those that are common across
several business use cases; those that are optional; or those that are
important enough that you want to emphasize them in the model.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Artifacts >
Business Modeling Artifact Set >
Business Use-Case Model... >
Business Use Case >
Guidelines >
