1 © 2005 course technology University Of Palestine Chapter 6 Storyboarding the User’s Experience

2 Chapter Objectives Now that you’ve defined the scope of the project, you’re ready to take your project “into analysis.” You’ll be able to carry out these B.O.O.M. steps: 2. Analysis 2a) Dynamic analysis i) Describe system use cases (use-case description template)

3 © 2005 course technology Step 2: Analysis The Analysis phase of the project is the one that takes up most of a Business Analyst’s time. Its objective is to discover and document the requirements of the proposed system. The central product of this step, the completed BRD, acts as a contract between the business and the developers.

4 © 2005 course technology Step 2: Analysis The Analysis phase involves a number of steps: 2. Analysis 2a) Perform dynamic analysis i) Describe system use cases (use-case description template) ii) Describe state behavior (state machine diagram) 2b) Perform static analysis (object/data model) (class diagram) 2c) Specify testing (test plan/decision tables) 2d) Specify implementation plan (implementation plan) 2e) Set baseline for development (BRD/analysis)

5 © 2005 course technology Step 2a i: Describe System Use Cases At the end of the Initiation phase, you identified system use cases in the BRD. This version was baselined for Step 2: Analysis. For your first changes, review the list of system use cases. If needs have changed or you have learned further information, update the system use-case diagrams and related text in the BRD. Once you’ve settled on a list of system use cases, your next step is to investigate and document each one thoroughly.

6 © 2005 course technology Step 2a i: Describe System Use Cases Deliverables of Step 2a i: Describe Use Cases: 1.The BRD template contains a section for system use- case diagrams. These diagrams are updated. 2.The BRD has a section called “System Use-Case Descriptions.”1 For each system use case that appears in the system use-case diagrams, a use-case description is added that includes a completed use-case description template. The text documentation may be augmented with any of the following:

7 © 2005 course technology Step 2a i: Describe System Use Cases The text documentation may be augmented with any of the following: Activity diagrams Decision tables Decision trees Other related artifacts containing supplementary documentation

8 © 2005 course technology The Use-Case Description Template The UML, as we’ve learned, doesn’t have a lot to say about text. The Use-Case Description template fills that gap. Keep one thing in mind when using this or any other template: Its main value is as a way to institutionalize best practices in your organization. You should customize it as time goes on, based on what works for you.

9 © 2005 course technology ………………………………………. Look Book Page 115, 116, 117, 118

10 © 2005 course technology Documenting the Basic Flow The basic flow describes the most common way that the use case plays out successfully. (Some people call it the “happy scenario) As a rule of thumb, the basic flow should not list any conditions, since subsequent sections handle all errors and alternatives.

11 Use-Case Writing Guidelines The following guidelines are compiled from standards in practice: 1.Tell a story: Write sentences that describe the unfolding narrative of the user’s interaction with the system. 2.Use a simple subject-verb-object sentence structure. 3.Use a consistent tense (present or future tense). 4.Each step should contain one testable, traceable requirement. 5.Keep the number of steps in a flow small (maximum 9 to 25 steps).

12 Use-Case Writing Guidelines (Cont.) 6.Minimize the use of the word “if.” Use alternate and exception flows instead. 7.Merge data fields and use the merged data name in the use case. For example, use the merged field Contact Information rather than the individual fields Name, Address, and Phone Number. 8.Do not describe the interface design within the use case. Describe the workflow only; document design details elsewhere. 9.Document the sequencing of each step clearly and consistently.

13 Use-Case Writing Guidelines (Cont.) 10.Establish a standard for documenting repetitive steps: 1 User selects payee. 2 System displays accounts and balances. 3. User selects account and provides payment amount. 4. System validates that funds are available. User repeats Steps 1 through 4 until indicating end of session. 11.Label the requirements. Use a numbering scheme or text labels. (In the case study, you’ll be using numbers to label the requirements.)

14 Basic Flow Example: CPP System Review Case Report 1.The system displays a list of resolved cases that have not been reviewed. 2.The user selects a case. 3.The system validates that the case is payable. 4.The system determines the payment amount. 5.The system marks the case as payable. 6.The system records the payment amount. 7.The system checks the Cash fund records to ensure that adequate funds exist. 7.1 No funds shall be removed from the cash fund or disbursed at this time.

15 Basic Flow Example: CPP System Review Case Report (Cont.) 8. The system records the fact that the case has been reviewed. …………. 12. Other Related Artifacts (The purpose of this section is to provide a point of reference for details that relate to this use case, but would distract from the overall flow. Include references to artifacts such as decision tables, complex algorithms, and so on.)

16 Documenting Alternate Flows Document each scenario not covered in the basic flow as an alternate flow or as an exception flow. An alternate flow is a variation that does not lead to abandonment of the users goal.

17 Typical Alternate Flows 1. The user selects an alternative option during a basic flow step: for example, “User requests same day delivery.” 2. The user selects a tool icon at any time during the use case; for example, “User selects spell-checking.” 3. A condition regarding the internal state of the system becomes true; for example, “Item out of stock.” 4. Recoverable data entry errors are identified. For example, the basic flow states, “The System validates withdrawal amount”; the alternate flow reports, “Funds are low.”

18 Alternate Flow Documentation There are a number of issues you’ll need to clarify for each flow:

19 Example of Use Case with Alternate Flows: CPP System/Review Case Report Basic flow: 1.The system displays a list of resolved cases that have not been reviewed. 2.The user selects a case. 3.The system validates that the case is payable. 4.The system determines the payment amount. 5.The system marks the case as payable. 6.The system records the payment amount. 7.The system checks the cash fund records to ensure that adequate funds exist No funds shall be removed from cash fund or disbursed at this time. 8.The system records the fact that the case has been reviewed.

20 Example of Use Case with Alternate Flows: CPP System/Review Case Report (Cont.) Alternate flows: 3a. Non-payable case: 1. The system marks the case as non-payable. 2. The user confirms the non-payable status of the case. 3. Continue at Step 8.. 7a. Cash funds low but sufficient: 1. The system marks the case as payable. 2. The system displays the low funds warning. (See “Prompts and Messages.”)

21 Documenting an Alternate of an Alternate What if there are alternate ways that an alternate flow step could play out? Document these the same way that you documented the original alternate flows. Look at the example in Book page ( 124 )

22 Documenting Exception Flows List each error condition that leads to abandonment of the user goal in the exception flows. Typical exception flows include cancellation of a transaction by the user and system errors that force a transaction to be canceled. Documentation rules are the same as for the alternate flows except that there is often no convergence point. In that case, the last line of the flow should read, “The use case ends in failure.”

23 Guidelines for Conducting System Use-Case Interviews 1.Ask interviewees to describe the basic flow. 2.Go through the basic flow, step by step, and ask if there is any other way each step could play out. List each of these as an alternate or exception flow, but don’t let the interview veer off into the details of what happens within each of these flows. 3.Ask interviewees if there are any alternatives or errors that could happen at any time during the basic flow. 4.Now that you have a comprehensive list, ask interviewees to describe each flow in detail. 5.Finally, go over each of the steps in the alternate and exception flows, asking if there are any other ways those steps could play out.