Chapter-6, Scenarios

Chapter - 6
Scenarios


This chapter discussed about the scenarios which are used by the Business analyst to communicate with the stakeholders.

 Scenarios:
A scenario is a natural language tool for telling a story, also it is an outline of a plot of a requirements work or a predicted sequence of steps. The scenario is a simple, easier and understandable medium for all the stakeholders. So, in this you can divide the work in the series of steps and by using this technique, you can explain the work. With the help of scenarios, a Business Analyst describe the business use case to its interested stakeholders.

Formality Guide:
Scenarios help the projects to fit into every development style. Trawling technique is a scenario used by the rabbit projects to overlook non-functional requirements and capture them in written story cards. Horse projects use scenarios as an alternative to writing atomic functional requirements which helps in discovering the requirements. Elephant projects use scenarios as a discovery tool and these projects keep scenarios in a documentation so that developers can see them when they start programming.


Diagramming the Scenario: 
To discuss the scenario in a diagram format is depend upon the choice of requirements analysts in perspective to the audience interest. Sometimes, Business Analysts, stakeholders prefer to use a diagram for describing the functionality of a business use case. The popular choice for discussing the scenario in a diagram is the UML (Unified Modeling Language).

Misuse Cases and Negative Scenarios:
If you use the the misuse cases (unhappy cases) then it put the negative or harmful impact on your work such as people abusing or opposing your work. So check if something went wrong with the help of normal case scenarios and it is easy to write a new scenario for each misuse.

Scenario Template:
You can write your business case study in a template that you and your stakeholders like or prefer. The book described the useful template which compromises between the informality and an overly bureaucratic approach.

In this template, first provide the Business Event Name in which business use case responds. Then give the Business Use Case Name and Number which presents unique identity. Preconditions must exist before the use case and specify this case study to the stakeholders who are interested in it. There should be active stakeholders who are involved and doing work for the business use case. To complete the work, the Normal case steps are required. These steps should be written in a clear and natural-language statements so that business people understand them. Alternatives are acceptable variations in the processing of Normal case, if these alternatives are simple, then you can add this to Normal case. Outcome is the desired situation of this business use case which is also known as  the "post condition".


Comments

  1. Kerone Barnett2 April 2020 at 20:49

    "Scenarios are textual descriptions of how users will make use of the system when it is deployed. They guide the requirements gathering process and serve as a baseline from which more detailed requirements may be elicited." Taken from https://businessanalystlearnings.com/ba-techniques/2013/3/18/usage-scenarios-in-analysis

    To fully capture how a system/ product will function, the Business Analyst must develop several scenarios to document different areas of functionality. Scenarios are written in "layman" terminology so that all interested stakeholders can understand the information being shared and actively contribute to product development/ improvement. Stakeholders themselves may contribute to the development of a scenario through interviews, focus groups and workshops organized by the Analyst or Project Team.

    ReplyDelete
  2. Sukhpreet Singh3 April 2020 at 15:02

    Scenarios – It is used by business analyst to communicate with stakeholders.
    In this we have – Formality guide- Guides which is very useful like in Rabbit project and horse projects. Scenarios must be used to discover requirements but must not be considered as final specification. Misuse cases and negative scenarios – Sometimes misuse cases like entering incorrect data, using stolen credit cards etc. have negative effect and might result into abuse work.
    Exceptions – Exceptions are unexpected and undealt cases which were never expect and were never dealt with before. Some deviations from normal cases are exceptions.

    ReplyDelete
  3. Karandeep singh11 April 2020 at 19:11

    This comment has been removed by the author.

    ReplyDelete
  4. Karandeep singh11 April 2020 at 19:13

    Horse projects might consider scenarios as an alternative to writing atomic functional requirements. When they have been developed enough, they can serve to inform the developers of the functional needs of the product. However, this approach does not work all the time.
    Elephant projects make use of scenarios as a discovery tool. The meetings with the stakeholders are occasions for reviewing the desired way of working for each of the business use cases. When the scenario is complete— that is, when the exceptions and alternatives have been discovered and/ or decided—it is used as the basis for writing the functional requirements

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 7 – Business Requirements Gathering

Chapter 7 –  Understanding the Real Problem This chapter focuses on the Business Analyst “thinking above the line” and focusing on the true essence of the business. This requires reviewing the Brown Cow Model – that is looking at the area above the line – the “ What Now ”. This section examines the undiluted and core reason for the business’ existence. The next step would be to look at the future of the business, called the “Future What”. Examining these two areas helps the Business Analyst get to the heart of the business problem, rather than focus on possible solutions. With the right focus the Business Analyst is not distracted by what others may think the solution could be, but the BA delves and trawls through as much information as possible to accurately understand the business and how it functions, minus technology or automation. This determination to channel all efforts towards the core purpose of the business allows the BA to be more open to all possible solutions...
Read more

Chapter 3 - Business Requirements Gathering

Chapter 3 - Scoping the Business Problem This chapter focuses on Project Blastoff Deliverables such as Project Purpose, Scope of work, Stakeholders, Constraints, Names, Estimated Cost and Risks. The chapter refers to Scope, Stakeholders and Purpose as the Trinity confirming that these are core elements of any successful project blastoff. ·          For Project Scope, we must understand the extent of the work to be done and how this task (business improvement) will impact the current operational environment and its existing products and services. We must ensure that we accurately document the depth and breadth of the project. ·          For Project Purpose, we must accurately capture the quantifiable/ measurable business benefit to be gained from the completion of the project. ·          For Stakeholders, we must document all possible persons with a vest...
Read more

Chapter 4 - BUSINESS USE CASES

Business use cases  -Business events are useful to partition the work, but it is the work’s response to the  event that now captures the interest of the requirements analyst. For every business event, there is a preplanned response to it, known as a business use case (BUC). Rabbit Projects - it is important to have a rock-solid grasp of the business problem to be solved. Rabbits make use of business use cases to explore their problem domain before starting to formulate a solution. This approach does not add to the documentation load, and it lessens the time spent delivering inappropriate solutions. Horse Projects - Horse projects are more strategic than rabbits. they need more time to complete. There is also the possibility of using Business use case scenarios as the documentation to pass along to the developers. Elephant Projects - elephant projects have a large number of stakeholders, clear communication is both important and difficult. Business ...
Read more