Understanding the Use Case Life Cycle for Effective Software Development

1. Deliverable #3 Identified Use Cases Authored Use Cases Agreed Use Cases Finish with Requirements…..

2. Requirements and Analysis • Wish to finish up Requirements • Artifacts: Complete Requirements Specification • Use Cases + Supplementary Specs = Requirements Specifications • Can drive the entire development process • Through Analysis and Design and Implementation • Through Verification and Acceptance • Use Cases ARE A Requirements Tool • Data Flow Diagrams • Much Older technology – still of immense value though… • Used for Requirements and Analysis (Logical DFDs) • Used to support Design and Implementation (Physical DFDs)

3. Life Cycle of a Use Case • Use Cases – series of transformations; mature through development stages. • Different presentation approaches at different points in the use case’s evolution. • Mistaken impression: Use Cases are a development (analysis, design, implementation) artifact rather than a requirements one • Use Cases are used extensively in Analysis and Design (via Use Case Realizations), but they are not a Design Artifact.

4. Will Look At: • 1. Software Development: how the use case is reflected throughout the full software development cycle • 2. Use Case ‘Authoring’ – how the use case is reflected throughout the maturing process • 3. Teamwork – the activities involved in creating the use cases and how these impact individual working practices.

5. 1. Software Development Life Cycle using Use Cases as Driver • Not originally part of traditional object-oriented software development. • Over time, the importance to OO methods became apparent. • Now, Use Cases are part of the UML. • “Use Case Driven”  use cases defined for a system are the basis for the entire development process. • Use Cases, thus, covers activities such as analysis, design, implementation, and testing (all phases).

6. Life Cycle of Use Cases • A. Requirements • Identified • Authoring • Agreed to • B. Development • Analyzed • Designed • Implemented • C. Testing • Verified • Accepted

7. Use Cases – Life Cycle - Overview • A. Requirements: • Use cases evolve from Identified, Authored to Agreed. • Evolves the glossary / domain model • Evolves supplementary specifications – contain system-wide requirements not captured by the use cases in particular.

8. Use Cases – Life Cycle - Overview • B. Development (analysis, design, implementation) • Analysis and Design • Use Cases are ‘realized’ in analysis and design models using analysis and design objects... • Describes ‘how’ the use cases are performed in terms of interacting objects in the model. • Contains subsystems and objects and how these parts need to interact to perform the use cases. • Analysis and Design do not change the use cases, but indicate that the use cases have been realized in the analysis and design of the system. • Implementation (code and unit test…) • During implementation, the design model is the implementation specification. • Use Cases are the basis for the design model and are implemented in terms of design classes. • Once code has been written, the use case can be considered to be in the implemented state.

9. Use Cases – Life Cycle - Overview • C. Testing: Verification and Acceptance • Use Cases constitute basis for identifying test cases and test procedures to be verified. • Tests passed? Use Case can be considered to be in the verified state. • Acceptance state reached when validated by user acceptance testing.

10. 2. Authoring Life Cycle - Overview • Many, many descriptions of the maturing of a use case and many strong adherents to various approaches • All approaches involve an evolution • Various names; evolve at different rates; various stopping places depending on the degree to which the use cases are to be used in the software development.

11. Authoring – one approach: series of ‘states’ • State 1: Discovered • Placeholder for what is to come • Visual index at most • State 2: Briefly described • E.g. This use case describes how a Customer uses the system to view and purchase the products on sale. Products can be found by various methods, including browsing by product type, browsing by manufactgurer, or keyword searches. • Sometimes this is as far as we need to go especially if behavior is easily understood and can be expressed in the form of a prototype more easily than words. • Other times, if behavior more complex, need more work…

12. Life cycles states continued • State 3: Bulleted Outline • Outline includes basic flow of events organized sequentially. • 5 – 10 simple statements • Identify most significant alternatives / exceptions. • Shows scale / complexity of the use case • Example:

13. Example of bulleted outline state: • Basic Flow: - get understanding of use case and complexity • Verifies scope; good for exploring ‘risks.’ • 1. Browse Products Notice: verb…object • 2. Select Products • 3. Identify Payment method • 4. Identify shipping method • 5. confirm purchase • Alternative Flows • 1. Keyword search Notice: noun clauses. Condition. • 2. no product selected State… • 3. product out of stock • 4. payment method rejected • 5. shipping method rejected • 6. product explicitly identified • 7. order deferred • 8. ship to alternative address • 9. purchase not confirmed • 10. confirmation fails • 11, etc. • If use cases are to act as a specification for more formal analysis, design, and testing, we need more detail.

14. Life cycles states continued • State 4: Essential Outline • Focus on the most important behavior and leave out much detail. • Defining characteristic of this format: • Presents a pure, external ‘black box’ view of system. • Intentionally focuses on usability, ensures needs of user are ‘up front.’ No details of what is ‘inside.’ • Generally ignores specifics of the user interface (better presented in prototypes and UI mock-ups – ahead). • Generally, a two-column format…

15. User Action 1. Browse product offerings 2. Select items for purchase 3. Provide payment instructions 4. Provide shipping instructions 5. Complete transaction System Response 1. Display product offerings 2. Record selected items and quantities 3. Record payment instructions 4. Record shipping instructions 5. Record transaction and provide receipt Example of essential outline state:

16. Comments at this point • Note: Many uses cases may stop prior to this. • Some may skip this stage and go to next stage… • Essential Use Cases are for the most important use cases in the system. • These descriptions are likely to evolve. • Essential Use Cases – very effective for facilitating user-interface and user-experience analysis and design. • Beware: too much detail can constrain the UI designers; don’t force designers to a particular technology or mode of interaction. • As usual, some recommend use case authoring stop here at the essential outline stage. • But if Use Cases are to drive other aspects of development, more is needed…

17. Life cycles states continued • State 5. Detailed Description • Complete the specification of the system. • Description may be in a conversational form or a narrative form. • In state 5, we add detail to the outline. More and more detail is added. • IF the use case has a strong sense of dialog between actor and system, then the description might be expressed in conversational form; otherwise, narrative form.

18. Forms for Detailed Description State • Conversational Form • Great for cases where actor does something and system does something back in response. • Especially good for where this is a single actor engaged in interactive dialog. • Difficult to use when there is more than one actor (frequent in real business systems) or when there is a single actor and complex responses…

19. User Action 1. Browse product offerings 2. Select items for purchase 3. Provide payment instructions 4. Provide shipping instructions 5. Complete transaction System Response 1. Display product offerings, showing categories selected by the user 2. For each selected item in stock, record selected items and quantities reserving them in inventory. 3. Record payment instructions capturing payment terms and credit card type, number, and expiration date using a secure protocol. 4. Record shipping instructions, capturing billing address, shipping address, shipper preferences, and delivery options. 5. Record transaction and provide receipt containing a list of the products ordered, their quantity and prices, as well as the billing and shipping addresses and the payment terms. The credit card information should be partially omitted, displaying only the last four digits of the credit card number. Note the differences in the system response.(Conversational Form) Notice attributes captured. This is where we are and this is where We need to go for Deliverable #3 – among other things. More details (attribute capture) and elaboration on alternate paths, as appropriate.

20. Forms for Detailed Description State • Narrative Form: • Here, outline can be expanded by adding detail but the tabular format is replaced by a more narrative description. • Most common form and more flexible, as it supports ongoing evolution of the use case, with additional subflows….

21. Note the differences in the system response. (Narrative Form) • The narrative form of the use case Browse Products and Place Orders • 1. The use case starts when the Customer selects to browse the catalogue of the product offerings. The system displays the product offerings showing the categories selected by the Customer • 2. The Customer selects the items to be purchased. For each selected item that is in stock, the system records the items and quantity required, reserving them in inventory. • 3. The system prompts the Customer to enter payment instructions. Once entered, the system records payment instructions, capturing payment terms and credit card type, number, and expiration date using a secure protocol. • 4. The system prompts the Customer to enter shipping instructions. Once entered, the system records the shipping instructions, capturing billing address, shipping address, shipper preferences, and delivery options. • 5. The system prompts the Customer to con firm the transaction. Once confirmed, the system records the transaction details and provides a receipt containing a list of the products ordered, their quantity and prices, as well as the billing address, shipping address, and payment terms. Credit card information is partially omitted, displaying on the last four digits of the credit card number.

22. Comments on Detailed Description • Most common ‘last’ state – as use case efforts ‘run out of steam.’ • Unfortunately, detailed description loses benefits of brevity and succinctness offered by bulleted and essential outline. • Also lacks details required of ‘fully-featured’ requirement specifications. • Last state: not fully specified:

23. Life cycles states continued • State 6 – Fully Described • Use Case has complete flow of events, has all terminology fully defined in supporting glossary, and unambiguously defines all of the inputs and outputs involved in the flow of events. • Fully described use cases are: • Testable – sufficient info to enable test formation • Understandable – can be understood by all stakeholders • Unambiguous – Use case has only one interpretation • Correct – All information is actually requirements information • Complete – Nothing missing from the use cases. • All terminology used is defined. Flow of events and all other use cases properties are defined. • Attainable – System can be actually created. • Support other software development activities: analysis, design, and testing. • Test: Pass onto analysis/design team for analysis and design, and to the test team for test design. If teams are satisfied, your use cases contain sufficient detail.

24. Example of Fully-Described state: • An extract from the fully described use case Browse Products and Place Orders • Basic Flow: • 1. The use case starts when the actor, Customer, selects to browse the catalogue of product offerings. • {Display Product Catalogue} • 2. The system displays the product offerings highlighting the product categories associated with the Customer’s profile • {Select Products} • 3. The Customer selects a product to be purchased entering the number of items required. • 4. For each selected item that is in stock, the system records the product identifier and the number of items required, reserving them in inventory and adding them to the Customer’s shopping cart. • {Out of Stock} • 5. Steps 3 and 4 are repeated until the Customer selects to order the products. • {Process the Order} • 6. The system prompts the Customer to enter payment instructions. • 7. The Customer enters the payment instructions. • 8. The system captures the payment instructions using a secure protocol • 9. Perform Sub-flow Validate Payment Instructions.

25. Use Case Modeling Process – Team Efforts1 of 2 • Use Case model cannot be fully developed by doing all as a group – quite the contrary. • Do a lot together in the beginning to establish the project vision - scope and identify and describe use cases. Get agreement on the problem to be solved. • Get the use cases identified and briefly described. • Complement this with an initial draft of the key supplementary specifications and an outline glossary or domain model. • At this time – no need to fully detail any of the use cases, although it is a good idea to have identified a majority of significant alternative flows for each. • Need to scope the project – this is what we are doing... • This can be done in workshops…. • Most healthy projects can then break up for individual authoring

26. Use Case Modeling Process – Team Efforts 2 of 2 • Prioritize use cases based on • Customer priority – value placed on use cases by stakeholders…- rank them! • Architectural significance - to reduce risk; and drive the architecture. • Initial Operational Capability – set of use cases that would provide initial functionality to enable the system to be used. • Normally, the basic functionality of the majority of the use cases will be needed to provide a working system – not necessarily true for all of the alternative flows… • Used to order the work – break use cases into Packages (subsystems containing use cases or parts of use cases…) • Again, helps to order development; controls scope; might be needed for confidentiality … • No need to wait for all to stabilize to ‘press on’ with certain packages… • Those packages having greatest risk should be up front!