BR Chapter 6: Scenarios
At this
stage of the requirements process, the business analyst has identified the
business events as well as the business use case which we referred to as BUC
and these correspond to the business events.
Below are
some of the techniques the Business Analyst can use to communicate requirements
to the stakeholders:
Scenarios
The Business Analyst can use Scenarios to model and record the BUCs. A scenario is an outline of a
plot, or a postulated sequence of steps - it tells the story of a business use case. The scenario is a
neutral medium, and one that is both simple and understandable to all
stakeholders. A
business analyst would use a scenario like this to elicit, and then describe, a
business use case to its interested stakeholders. The BUC is a discrete amount
of functionality; it happens in its own time frame and can be considered
separately from other parts of the work’s functionality.
The BA
model a scenario and use it to reach agreement on what the work has to do and Once
such agreement is achieved, you and the stakeholders decide how much of that
work will be done by the product.
The Essence of the Business
Since the
Scenario described above belong to the first quadrant of the model (the How-Now
view of the Work), “the
Essence of the Business” moves above the line and look at the What-Now and
Future-What Views. It
goes back over the scenario and eliminate any technological bias, while
simultaneously asking the relevant
question - “What does the business really need to do”? Although the essence might
not be a better solution to the problem - it is the real problem. You find the
real business problem when you eliminate all the technological camouflage that
normally makes up a description of some work.
Diagramming the Scenario
This is
an optional choice for most Business Analyst during the requirements analysis
stage. And some stakeholders prefer to see the Scenario being explained in diagram
detailing the functionality of a business use case.
Alternatives
Alternatives
arise when the Business Analyst wishes the user to have a choice of possible actions.
These choices are intentional, as they are wanted and defined by the business.
These alternatives usually exist to make the work of the business use case more
attractive and convenient to the participants. Although, the work reacts
differently depending on which alternative is selected and the Business Analyst
can find alternatives by examining each step of the normal case.
Exceptions
Exceptions
are unwanted but inevitable deviations from the normal case. They are unwanted
in the sense that the owner of the work would rather that they did not happen.
The Business Analyst is fully aware that Exceptions are unavoidable, and they
can occur from time to time, so they must be catered for - remember, the goal
of the exception scenario is to show how the work safely handles the exception.
You may, obviously, compose your business use case situations in whatever structure you and your partners like. The layout introduced in this area is one we have discovered helpful on numerous assignments. We recommend it as a reasonably great bargain among familiarity and an excessively bureaucratic methodology.
ReplyDeleteBusiness Event Name
Business Use Case
Trigger
Preconditions
Interested Stakeholders
Active Stakeholders
Normal Case Steps
Alternatives
Exception
Outcome
Also, because the technique requires the involvement of business line management and other stakeholders at an early stage in the architecture project, it also plays an important role in gaining the buy-in of these key personnel to the overall project and its end-product - the IT architecture.
ReplyDeleteThe Analyzing phase is where a great deal of real business architecture work is actually done. This is where the information that is gathered is processed, and documented, and where the models are created to represent that information, typically visually.
The analysis phase takes advantage of the knowledge and experience of the business scenario consultant using past work and experience to develop the models necessary to depict the information captured. Note that the models and documentation produced are not necessarily reproduced verbatim from interviews, but rather filtered and translated according to the real underlying needs.
The documentation of a Business Scenario should contain all the important details about the scenario. It should capture, and sequence, the critical steps and interactions between actors that address the situation. It should also declare all the relevant information about all actors, specifically: the different responsibilities of the actors; the key pre-conditions that have to be met prior to proper system functionality; and the technical requirements for the service to be of acceptable quality.
Some requirements analysts and some stakeholders believe that it is more appropriate to use a diagram to explain the functionality of a business use case. This preference is a matter of personal choice, and it depends largely on whether your audience responds more favourably to either text or diagrammatic scenarios. We leave it to you to experiment and decide which method is right for you.Several diagrams can be used for scenarios. The UML activity diagram seems to be a particularly popular choice.
ReplyDelete"Swim lanes" divide the work between the participants.
A diamond at the bottom of a standard model in is called a merge.
Diamonds are also used to denote decisions as they were in flowcharts.