Identifying User Stories and Use Cases PDF

IT2004 004 __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________...

IT2004 004 __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____ IDENTIFYING USER STORIES AND USE CASES 4. The current balance and new balance must be displayed. Use Case Description Use Case - An activity the system performs in response to a request by a User Story user. - It states what an end-user does as part of his or her work. - Two (2) techniques are recommended for identifying use - It describes a goal the user has when using the system cases: - A basic concept in Agile development because it focuses on 1. User goal techniques simplicity, additional value, and user collaboration. 2. Event decomposition technique - Document the functional requirement quickly and less - Use case techniques place the responsibility for identifying formally than traditional requirements modeling by focusing and detailing the requirements on the system developers. on who, what, and why for each function. - The standard template for a user story looks like this: Use Cases and User Goal Technique “As a , I want to so that.“ by determining what specific goals or objectives must be For example, some user stories for a bank teller might be: completed by the system for the user.  “As a teller, I want to process the deposit to quickly to - The user goal technique for identifying use cases includes serve more customers.” these steps:  “As a teller, I want to balance the cash drawer to assure 1. Identify all the potential users for the new system. there were no errors.” 2. Classify the potential users in terms of their functional role  As a customer of the bank using an ATM, some user (e.g., shipping, marketing, sales). stories might be: 3. Further classify potential users by organizational level  “As a bank customer, I want to withdraw cash and feel (e.g., operational management, executive) confident with the stack of cash I get is the correct User User goal and resulting use amount.” case  “As a bank customer, I want to deposit a check and feel Potential customer Search for item confident the deposit is recorded correctly.” Fill shopping cart View product rating and Acceptance Criteria comments - The final part of a user story Marketing manager Add/update product information - Indicate the features that must be present for the user to Add/update promotion be satisfied with the resulting implementation. Produce sales history report - Its focus on functionality, not on features or user-interface Shipping personnel Ship order design. Track shipment - Example: “bank teller making a deposit”: Create item return 1. Customer lookup must be by name or by account Table 1. Identifying the use case with the user goal technique number. 2. It would be nice to display the photo and signature 4. Interview each type of user to determine the specific goals of the customer. they will have when using the new system. Start with 3. Any check hold requirements must be indicated. goals they currently have and then get them to imagine 03 Handout 1 *Property of STI  [email protected] Page 1 of 7  IT2004 004 __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____ innovative functions they think would add value. Encourage them to state each goal in the imperative verb- noun form, such as Add customer, Update order, and Produce a month-end report. 5. Create a list of preliminary use cases organized by type of user. 6. Look for duplicates with similar use case names and resolve inconsistencies. 7. Identify where different types of users need the same use cases. 8. Review the completed list with each type of user and then with interested stakeholders. Use Cases and Event Decomposition - A technique to identify use cases by determining the business events to which the system must respond - Table 1 shows the potential customer use cases: Search for item, Fill shopping cart, and View product rating and Figure 1. Events in a charge account processing system comments are good examples of elementary business that lead to use cases processes. - An event occurs at a specific time and place, can be - Figure 1 shows some events that are important to a retails described, and should be remembered by the system. store’s charge account processing system. - Events drive or trigger all processing that a system does, so  The functional requirements are defined by use cases listing events and analyzing them makes sense when there is based on six events. a need to define system requirements by identifying use  A customer triggers three events: “customer pays a cases. bill”, “customer makes a charge”, and “customer changes address.” Event Decomposition Technique  The system responds with three use cases: Record a - When defining the requirements for a system, it is useful to payment, Process a charge, or Maintain customer begin by asking, “What business events occur that will require data the system to respond?” - The initial perspective helps keep the analyst focus on a high-  Three other events are triggered inside the system by level view of the system (looking at the scope), rather than on reaching a point in time: “time to send out monthly the inner workings of the system. statements,” “time to send late notices,” and “time to - It also focuses on the system’s interfaces outside people and produce end-of-week summary reports. other systems.  The system responds with use cases that carry out what it is time to do: Produce monthly statements, Send late notices, and Produce summary reports. Types of Events 1. External events 03 Handout 1 *Property of STI  [email protected] Page 2 of 7  IT2004 004 __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____ 2. Temporal events 3. State events (also called internal events) Identifying Events External Events - Events Versus Prior Conditions and Responses - An event that occurs outside the system – usually initiated by  It is sometimes difficult to distinguish between an an external agent or actor event and part of a sequence of prior conditions that - An external agent (actor) is a person or organizational unit that leads up to the event. supplies or receives data from the system.  Consider a customer buying a shirt from a retail store, - Checklist to help to identify external events: as shown in Figure 2.  The external agent wants something resulting in a  The analyst has to think through such a sequence to transaction. arrive at the point where an event directly affects the  The external agent wants some information system.  Data has changed and needs to be updated.  In this case, the system is not affected until the  Management wants some information. customer is in the store, has a shirt in hand ready to purchase, and says, “I want to buy this shirt.” Temporal Events - An event that occurs as a result of reaching a point in time. - The analyst begins identifying temporal events by asking about specific deadlines that the system must accommodate.  What output are produced at that deadline?  What other processing might be required at that deadline? - Checklist to use in identifying temporal events:  Internal outputs needed  Management reports (summary or exception)  Operational reports (detailed transactions)  Internal statements and documents (including payroll)  External outputs needed  Statements, status reports, bills, reminders Figure 2. Sequence of actions that lead up to only one event State Events affecting the system - An event that occurs when something happens inside the  The way to determine whether an occurrence is an event system that triggers the need for processing. or whether it is part of the interaction following the event - Also called internal events. is by asking if any long pauses or intervals occur (i.e., can - Often, state events occur as a consequence of external the system transaction be completed without events. interruptions?) or is the system at rest again, waiting for - Sometimes, they are similar to temporal events, except the the next transactions? point in time cannot be defined. 03 Handout 1 *Property of STI  [email protected] Page 3 of 7  IT2004 004 __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____ - The Sequence of Events: Tracing a Transaction’s Life Cycle  Figure 4 list some examples of events that can be  A useful method for identifying events is to trace the deferred until the developer is designing in the system sequence of events that might occur for a specific external controls. agent or actor.  From Figure 3, the analyst can think through all the possible transactions that might result from one new customer. Figure 4. Events deferred until designing system controls - Steps in the Event Decomposition Technique 1. Consider the external events in the system environment that requires a response from the Figure 3. The sequence of “transactions” for one specific customer system by using the external events checklist. resulting in many events 2. For each external event, identify and name the use case that system requires. - Technology-Dependent Events and System Controls 3. Consider temporal events that require a response  Sometimes, the analyst is concerned about events that from the system using the temporal event checklist. are important to the system but do not directly concern 4. For each temporal event, identify and name the use users or transactions (i.e., design choices or system case that the system requires and then establish the controls). point of time that will trigger the use case.  The analyst temporarily ignore these events; however, 5. Consider the state events that the system might they became important later for design. respond to, particularly if it is a real-time system in  The system controls checks or safety procedures put in which devices or internal state changes trigger use place to protect the integrity of the system. cases.  Perfect technology assumption states that events should 6. For each state event, identify and name the use case be included during analysis only if the system would be that the system requires and then define the state required to respond under perfect conditions (i.e., which change. equipment never breaking down, capacity for processing 7. When events and use cases are defined, check to see and storage being unlimited, and people operating the if they are required as part of the analysis using the system being completely honest and never making perfect technology assumption. Do not include events mistakes) that are involved such system controls as login, logout, change password, and backup or restore the database, as there are put in as system controls. 03 Handout 1 *Property of STI  [email protected] Page 4 of 7  IT2004 004 __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____ Fill shopping cart Customer Use Cases, Actors, and Use Case Diagram Notation