SCENARIOS
A Scenario is an outline of a plotted sequence of steps where the plot is supposed to suggest that you smash the work into a sequence of steps or scenes and by way of explaining
these steps, you give an explanation for the work.
The scenario is a neutral medium that is simple and understandable to stakeholders. The scenario should only be presented to interesting stakeholders who have knowledge in that part. The first thing we need is, to create an agreement that what will be the output from the work or what the work must do. After achieving the agreement, we need to decide how much work must be done by product. Then, we need to produce scenarios by breaking down the functions of business use cases into small steps. Each step stands for meaningful activity. There should be about 3 to 10 steps ideally in order to keep scenarios simple.
Then we need to confirm this scenario with the interested stakeholders. All stakeholders can be invited to participate and revise this scenario until it represents a consensus view of what the work
should be.
THE ESSENCE OF THE BUSINESS
The scenarios belong to the first quadrant of the Brown-Cow model - The How-Now view. To look at other quadrants, we need to take into consideration the essence of the problems. For this, we need to go back over the scenarios and eliminate the technological bias by keeping in mind what does the business needs to do.
DIAGRAMMING THE SCENARIOS
The better approach is to draw a picture first to explain the functions of a business use case. There are many choices that can be used for scenarios. However, UML is a popular choice that stands for Unified Modeling Language. Sometimes BPMN can be used as well which is Business Process Modeling Notation. The figure depicts the airline check-in example as a UML activity diagram.
ALTERNATIVES
Alternatives arise when you wish the user to have a choice of possible actions. These choices are intentional, as they are wanted and defined by the business. They usually exist to make the work of the business use case more attractive and convenient to the participants. When you buy books or
music online, for example, you can decide whether to place your selected goods in a shopping cart awaiting check-out, or have them sent directly to you when you click “buy.” These deliberate choices offered by the vendor are alternatives.
EXCEPTIONS
We must pause here to urge you to delay looking for exceptions until you are satisfied with the normal case scenario. It is far too easy for stakeholders to get carried away with exceptions, and your review session with them can be quickly derailed by needlessly chasing exceptions that are not guaranteed ever to happen. It is only when you have the normal case that you can methodically work through it by looking for the exceptions and deciding what you will do about them.
In this chapter we learned how to tell a story, or create a scenario, and how this action can help stakeholders to understand the business use case (BUC). If both parts agree, BA and stakeholders, the BUC will form the basis for writing the requirements.
ReplyDeleteOn BUC’s one point that we need to pay attention is why we are creating this BUC. What is the trigger? Is It important to the project to have this BUC? What are the preconditions? If this BUC is important we need to know what stakeholder should be involved, what alternatives we have, what exceptions and what out come we will have after the complete the BUC.
I am going to talk about Alternatives
ReplyDeleteAlternatives arise when you wish the user to have a choice of possible
actions. These choices are intentional, as they are wanted and defined by
the business. They usually exist to make the work of the business use case
more attractive and convenient to the participants. When you buy books or
music online, for example, you can decide whether to place your selected
goods in a shopping cart awaiting check-out, or have them sent directly to
you when you click “buy.” These deliberate choices offered by the vendor
are alternatives.
while if we talk about TD bank the alternative for everything thing is customer care and support.
they are the one who are going to resolve problem by just asking some questions.
Misuse cases and how to use them to your benefit
ReplyDeleteMisuse cases (you might like to think of them as “unhappy cases”) show neg-
ative or harmful possibilities, such as someone abusing the work or attempt-
ing to defraud it. Examples include users deliberately entering incorrect data,
customers using stolen credit cards, and pranksters making fictitious calls or
transactions, planting a virus or other malware, or engaging in any of the
myriad other things that can be done to harm the work.
It may be helpful here to think in terms drawn from fiction writing and
use the idea of the protagonist and the antagonist. The protagonist is the
hero or main character of the story: the good guy, the user, the actor using
the product following your normal use case scenario. Winnie the Pooh is
the ideal protagonist—he is well intentioned and you want him to win out
in the end. But like Pooh, your protagonist might be of very little brain and
make mistakes: forget his password, choose the wrong option, get honey on
the keys, or any of the many unfortunate things a Pooh can do.
Cast your protagonist as someone who is forgetful, slow, distracted,
and not paying attention. (You are bound to know someone like that.) Go
through the normal case scenario, and for each step, ask what can be done
wrongly. It may be simpler to write a new scenario for each misuse, as the
ramifications of a misstep may be complex enough to warrant their own
separate story.