Deliverable #3

Identified Use CasesAuthored Use CasesAgreed Use CasesFinish with Requirements…..

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)

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.

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.

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).

Life Cycle of Use Cases A. Requirements

Identified Authoring Agreed to

B. Development Analyzed Designed Implemented

C. Testing Verified Accepted

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.

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.

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.

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.

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…

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:

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.

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…

Example of essential outline state: 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

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…

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.

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…

Note the differences in the system response.(Conversational Form) 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.

Notice attributes captured. This is where we are and this is whereWe need to go for Deliverable #3 – among other things. More details (attribute capture) and elaboration on alternate paths, as appropriate.

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….

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.

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:

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.

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.

Use Case Modeling Process – Team Efforts

1 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

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!