Thursday, April 9, 2020

Chapter 6 - Scenarios

Chapter 6 - Scenarios

Author - Zac Dewit


Scenarios

  • A scenario is an outline of a series of steps. This term is used to describe the parts of a section of work. Chapter 4 taught us how to split the work into parts. The scenario takes those parts and defines its functionality. 
  • These scenarios are especially used to create business use cases (BUC) with the help of the stakeholders. 
  • A scenario is simple and is easy to understand for all stakeholders. However, not all stakeholders need to see or hear about it. It can be specifically made for groups or can be made for all the people involved.
  • Once these scenarios have been made and shown, it should help the stakeholders reach an agreement on the work that needs to be done. Then you make more scenarios to describe how each person will interact with this new system
  • Each part of the scenario should be a part of the functions in a BUC. There should be 3 to 10 steps. This way there is still a clear path, but it is not overly complicated.

The Essence of the Business

  • If we think back to the brown cow model, the scenarios belong to the "how now" quadrant. To move to the "what" side of things, we need to consider the essence of the problem and in turn the essence of the business. 
  • To do this we need to eliminate any technology-based bias that we have while asking one simple question. What does this business do? By breaking it down to the simple form here we can refocus on what really needs to be done to make the business better.  

Alternatives 

  • Alternatives are choices that you have created for the user. These choices are put here on purpose. They are a desire of the business. These choices are usually available to make the user's life easier or more straightforward.
  • An example of this is when you buy textbooks and choose if you want digital or actual copies. 
  • These are positives and appeal to our desire to have options in life. 

Exceptions

  • Exceptions are the unwanted deviations. They are unwanted because the owner would have preferred if they never existed. This includes things like when people forget their passwords or do not have proper documents.
  • Do not look for exceptions until after you have found all your normal scenarios. It can be easy to spend forever thinking of exceptions that will likely never happen. It is important to save this step until nearer to the end. 
  • The goal of these scenarios is to understand how to safely and respectfully handle these exceptions to your normal work.

What if? Scenarios

  • Finally "what if?" scenarios are when you explore strange and outside the box ideas. You can ask questions like "What if we did this?" or "What if we rearranged this?". These questions can get stakeholders to reimagine how work can be done and even if you don't immediately find a solution to a problem, it can give a greater understanding of how the business works and how the parts of the work interact with one another. 
  • Another aspect of this is to find what is currently a constraint in the business. What is it that is holding you back from achieving so much more? If you can find these and eliminate them, you can improve the business.

3 comments:

  1. In Microsoft, a scenario for short, in which people or organisations interact with system. They indicates the events or actions that occur during the interaction. In essence of business, customers are important as they are the only source of value for a business. Alternatives in which there is limited choice to one of two possibilities, and courses of actions. The goal of the scenarios, need to understand to safely control exceptions to normal task.

    ReplyDelete
  2. In Microsoft, The Exception class includes a number of properties that help identify the code location, the type, the help file, and the reason for the exception: StackTrace, InnerException, Message, HelpLink, HResult, Source, TargetSite, and Data. When a causal relationship exists between two or more exceptions, the Inner Exception property maintains this information. The outer exception is thrown in response to this inner exception. The code that handles the outer exception can use the information from the earlier inner exception to handle the error more appropriately.

    ReplyDelete
  3. A scenario is a natural language tool for telling a story. We have discussed how to write this story; its intention is to help you and your stakeholders come to a coherent understanding of the functionality of a business use case. Writing the BUC scenario tests whether sufficient study has been done or the business analyst needs to ask more questions and investigate further. Once the BUC scenario is agreed—that is, you and your stakeholders have come to a consensus that it accurately represents the desired state of the work—it forms the basis for writing the requirements.

    ReplyDelete

Chapter - 12 - Fit, Criteria and Rationale

Fit, Criteria and Rationale Formality Guide A pleasing aspect (amongst many) of Kent Beck’s extreme Programming technique is its i...