Chapter 6 - Scenarios - posted by Harvinder Singh

Chapter 6 - Scenarios

At this stage of the requirements process, the business events were identified, and thereby the business use cases (BUCs) that respond to the events. The scenarios must be used to model and record the BUCs, as they are very effective, largely because of their ready acceptance by nontechnical stakeholders.

Formality Guide

Scenarios are useful in most situations, e can understand them, and they fit into any development style, but projects will have different needs related to their size.

Let’s have a look on these three projects:

·        Rabbit projects can use scenarios as a trawling technique, discover the required functionality by working with scenarios. Rabbit scenarios usually overlook non-functional requirements and capture them later by writing separate non-functional story cards.

·        Horse projects might consider scenarios as an alternative to writing atomic functional requirements. For complex products or if you need the functional requirements documented for contractual purposes, use scenarios to discover the requirements, but not as the final specification.

·        Elephant projects make use of scenarios as a discovery tool. The complete scenario (when the exceptions and alternatives have been discovered) used as the basis for writing the functional requirement and should be kept as part of the documentation. Also, the developers analysed them when they start programming.

Scenarios

A scenario is sequence of steps that tells the story of a business use case. In requirements work you break the work into a series of steps, and by explaining these steps, you explain the work.

An enterprise analyst uses a scenario to elicit, and to describe, a business use case to its involved stakeholders. When exploring a enterprise use case, most effective the fascinated stakeholders with expertise or information in the part of the work which you are modeling with your state of affairs should be invited. Once reached the settlement with the stakeholders, the Business Analyst produce one or more eventualities to define the actor’s interaction with the product.

The first version can be simple and informal. After getting the whole story, spoil it down into steps considered the best to capture the regular path through the story. Later the BA will alter it with next activities, but for now it is vital affirm this state of affairs with the interested stakeholders. Stakeholders are invited to take part and revise the situation until it represents a consensus view of what the work have to be.

Once a consensus is reached on the work, the BA starts to formalize the scenario:

·       The first part of the formalized scenario identifies it and gives it a meaningful name.

·       Next, it is the start-up mechanism, or trigger, for the business use case.

·       Then, add any preconditions that must exist when the business use case is triggered.

·       Consider adding the interested stakeholders to the scenario, as these people have an interest in the outcome of the business use case.

·       Include the active stakeholders – the people or systems that do the work of the business use case. Usually, one active stakeholder triggers the business use case, and then one or more others participate in the work.

Alternatives: Options emerge when you wish the client to have a decision of potential activities. These decisions are deliberate, as they are needed and characterized by the business. They for the most part exist to make crafted by the business utilize case progressively appealing and helpful to the members. At the point when you purchase books or music on the web, for instance, you can choose whether to put your chose products in a shopping basket anticipating registration or have them sent legitimately to you when you click "purchase." These purposeful decisions offered by the merchant are options.