How to Elaborate Requirements Through Use Cases and User Stories Mar$n Schedlbauer, Ph.D., CBAP, CSM, PSM

Transcription

1 November 5 th, 2015 How to Elaborate Requirements Through Use Cases and User Stories Mar$n Schedlbauer, Ph.D., CBAP, CSM, PSM

2 Requirements Techniques Narrative Statements often in the form of The system/solution shall User Stories high-level description of user needs that are elaborated later Use Cases narratives for each usage scenario including exceptions Visual Artifacts UML models, storyboards, context diagrams, mockups 2

3 The Business Analyst is asked to collect and organize lots of information, not just requirements. Information Objectives Requirements Assumptions Constraints Rules Stakeholder Solution Transition Functional (Detailed) Non-Functional (QoS) Risks 3 3

4 Requirement Type: Objective Requirement Type: Objective Definition: Describes the needs and objectives of the organization and why some project has been initiated. Objectives describe WHAT the organization is trying to achieve and WHY it is important. Discovered Through: Organizational Analysis Preferred Format: SMART benefit statements specifying metrics that can be used to gauge success. Examples: Reduce incidents of adverse drug interactions by 30% within the next twelve months. Lower the average cost of prescriptions by 15% within 6 months by substituting generics or alternative medicines. Require all hospitals and health centers to use the prescription management system exclusively for all prescriptions.

5 Requirement Type: Stakeholder Requirement Type: Stakeholder Definition: Describes the needs of specific stakeholders and WHAT they need from the solution. These requirements serve as a bridge between objectives and solution requirements. Regulatory bodies are recognized stakeholders who are often represented by proxy. Discovered Through: Requirements Analysis Preferred Format: Use Cases or User Stories; Regulatory Rules Examples: (as a use case) Physician writes prescription (as a use case) Physician checks interaction of prescribed drug with other drugs that have been prescribed previously. (as a user story) As a physician, I want to check if the drug I am prescribing has side effects so that I can alert my patient. (as a regulation) The FDA requires compliance with standard CFR 21 Part 11.

6 Requirement Type: Functional Solution Requirement Type: Functional Solution Definition: Describes the external behavior of the solution and the information that it manages. Discovered Through: Requirements Analysis Preferred Format: Narrative statements or steps in a use case scenario. Screen or report mockups. Examples: The system shall list the side effects by order of probability of occurrence. The system shall allow the patient to select the pharmacy to which the prescription will be sent. The system shall transmit prescriptions using the SCRIPT format. 6

7 Requirement Type: Non-Functional Requirement Type: Non-Functional Solution Definition: Describes quality of service requirements and environmental conditions under which the solution must remain effective. Includes requirements relating to performance, response time, security, usability, compatibility, availability, and reliability, among others. Discovered Through: Requirements Analysis Preferred Format: Narrative statements. Examples: The system shall be available from 2am through midnight, 99% of the time. The system shall not display any patient identifying information, except the patient s name and insurance information, on any printed prescription. The system shall list drug side effects and contraindications within 2 seconds after a drug has been selected, 90% of the time. 7

8 Requirement Type: Transition Requirement Type: Transition Definition: Describes the capabilities that the solution must have to ease transition from the current state to the future state. Includes data conversion requirements and ways to bridge skill gaps. Discovered Through: Solution Assessment and Validation Preferred Format: Narrative statements. Examples: Send a memo to all physicians informing them that all prescriptions must be electronic. Inform patients that they must provide the name and address of the pharmacy to which they want prescription to be sent. Input the addresses of all Massachusetts Walgreen s, CVS, and RiteAid pharmacies into the database. 8

9 Plus: Assumptions Artifact: Assumption Definition: Describes an understanding that is taken as true without concrete proof. Discovered Through: Requirements Analysis Preferred Format: Narrative statements. Examples: Patients have access to a pharmacy that accepts electronic prescriptions. Pharmacies accept the SCRIPT format. 9

10 Plus: Constraints Artifact: Constraint Definition: Describes a limitation or restriction on the solution. Discovered Through: Requirements Analysis Preferred Format: Narrative statements. Examples: The solution must be operable by the end of the fiscal year. The solution must be compliant with the regulations of the ACA. 10

11 Plus: Rules Artifact: Rule Definition: Describes a policy or guidelines by which an organizational unit operates. Discovered Through: Requirements Analysis Preferred Format: Narrative statements; Decision Table. Examples: Patients may not receive samples of medications. The prescribing physician must be licensed in the state in which the prescription is filled. 11

12 Definition: User Story DEFINITION: USER STORY A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder. A Guide to the Business Analysis Body of Knowledge (BABOK Guide). 12

13 Initial Use Cases As User Stories User stories define requirements from a user s perspective and are deliberately written without much detail Details are added during conversations with the user and subject matter experts once the user story has been selected for a iteration. They serve as an initial use case brief and are eventually elaborated through use case scenarios. Example user story using the canonical form: As a patient, I want to view my past prescriptions so that I can request refills and see side effects. 13

14 User Story Qualities An effective user story conveys the following: The perspective or role of the user requiring the functionality described by the story The feature defining the action that the user must be able to perform using the product The purpose of the story describing the user s intention 14

15 Definition: Use Case DEFINITION: USE CASE A use case is a description of the observable interaction between an actor and a solution that occurs when the actor uses the system to accomplish a specific goal. BABOK Guide, Version

16 Definition: Actor DEFINITION: ACTOR An actor is a human, device, or system that plays some specific role in interacting with a solution. BABOK Guide, Version

17 Definition: Scenario DEFINITION: SCENARIO An analysis model that describes a series of actions or tasks that respond to an event. Each scenario is an instance of a use case. BABOK Guide, Version

18 Applying Use Case Principles to Story Elaboration During conversations when trying to understand a user story s intent, ask the users and SMEs to: Identify possible scenarios Describe the details of each scenario Define post-conditions, i.e., what will be true when the goal is accomplished Define pre-conditions, i.e., what we assume is true in order for the feature to work For each scenario step, ask if that can be done differently Ask if every user does it the same way; if not, consider defining personas to understand the different user roles 18

19 Analysis Process with User Stories and Use Cases Find the actors (users) Find the goals of each actor Define the goals as user stories Elaborate the user stories by identify scenarios Write detailed use case narratives Augment the narratives with diagrams, models, and mockups Review use cases with stakeholders 19

20 Use Case Diagrams A use case diagram is a graphical representation of the actors and their initiated use cases: write presciption Physician check interactions with other drugs The diagram is informal and often only sketched on a whiteboard during an elicitation session. Only record the use cases formally if they are used by remote teams or are needed for compliance. 20

21 System Use Case Catalogs Instead of recording the actors and use cases in a diagram, a catalog is often preferable because it is easier to manage. Actor Use Cases Physician write prescription check drug interactions view prescription history Nurse (same as physician) Patient request refill view prescription history Pharmacist fill prescription 21

22 Use Case Narrative The details of the use case and its associated scenarios are captured in the use case narrative. Each use case has an associated narrative. The use case narrative describes the flow of control through each normal and alternate scenario. Physician write presciption Use Case: Write Prescription Actors: Physician, Patient Trigger: a medication is required Pre-Conditions: Patient has received medical exam Post-Conditions: prescription sent to pharmacy Normal Scenario: 1. This use case starts when a medication is required. 2. The physician selects the medication. 3. The physician checks if generic alternatives are available. {V1}... Alternate Scenarios: V1: Generics Are Available V

23 Scenarios Define Use Cases Use cases are defined fully through scenarios: Basic path scenario The typical course of event Alternate scenarios An alternate way in which the basic path can play out but still result in a successful outcome Exception scenarios When something goes wrong and the use case cannot be completed successfully Every scenarios represents a path through the use case from the start triggered by an event to its completion. 23

24 Perspective: Current vs Future State A use case is created from a specific perspective: Current State: As-Is Future State: To-Be 24

25 Best Practices for Defining Use Cases Stakeholders often don t know their processes and needs well. Asking for the first step of a use case or process may confuse them. A better approach might be to state a use case as an interaction and ask: What happens during this interaction? What is the desired outcome or goal of this interaction? What tasks do have to be accomplished to achieve the goal? What does the interaction produce as its deliverable? Who participates in the interaction? Don t focus on the order of steps, just tell me what happens. 25

26 More Best Practices Afterwards, for each step ask them: What other step must be completed before this one can be done? Who carries out the activity? Does it always happen like this? When does this step get done differently? Now you are ordering the activities and you are starting to elicit the branches in the flow. 26

27 Pre and Post Conditions Pre-Conditions: Define what you assume to be true in order for the use case to succeed Post-Conditions Describe what the use case will have altered or accomplished. This is essentially a summary of the use case outcome It s often much easier to define the pre- and post-conditions after you have investigated the basic and alternate flows. 27

28 Stakeholder Reviews Schedule a walkthrough with the appropriate stakeholders, domain experts, developers, and end users to assure that the use case has been understood correctly. ü Do this before you proceed to implementation. 28

29 Summary: User Stories Versus Use Cases User stories are not the same as use cases, but both serve a similar purpose: understand what the user needs. User Story Simple statement of user need and purpose for need Elaborated through conversation on agile projects Defines acceptance criteria and scenarios Use Case More complete definition of user need and how system is expected to behave Elaborated through step-by-step narrative scenarios Defines pre and post conditions Both are augmented with models to specify expected behavior, but the models may not be formal work products or deliverables in an agile environment. 29

30 Summary: Benefits and Challenges Benefits Instills customer ownership Useful for iterative and incremental delivery of solutions May eliminate the need for more detailed requirements specifications in agile environments where stakeholders and delivery teams are co-located Clearly defines the value that a features provides Prioritize with story points for timeboxed iterations Challenges Not detailed enough when regulatory restrictions require detailed documentation May not align with waterfall methods that are documentation centric Does not document non-functional requirements well and therefore require additional techniques to be used in conjunction with user stories Story format may not include enough detail for teams that are distributed 30

31 Interactive Case Study Consider the design of a virtual shopping assistant for a clothing store, such as Macy s. 1. define at least five user stories 2. take one of the user stories and refine it into a use case 3. elaborate the use case by defining the functional requirements for the normal scenario 4. identify alternate and exception scenarios 5. describe pre- and post-conditions What other artifacts would you need to create to communicate the requirements fully? How would you decide what s really necessary? What about non-functional requirements, constraints, and business rules? 31