Agile UseCases - unders/mywiki GitHub Wiki

Ivar Jacobson

Structure of a use-case narrative

The use-case narrative describes the What.

Basic Flow -------------------------------------- Alternative flow

1. insert card                       A1 invalid card          
2. validate card                     A2 non-standard amount 
3. select cash withdrawal            A3 receipt required
4. select account                    A4 insufficient funds in ATM
5. confirm availability of           A5 insufficient funds in account
funds                                A6 would cause overdraft 
6. return card                       A7 card stuck 
7. dispense cash                     A8 cash left behind
                                     etc.

Work Products

A use-case model visualizes the requirements as a set of use cases, providing an overall big picture of the system to be built. The model defines the use cases and provides the context for the elaboration of individual use cases.
Use cases are explored by telling stories. Each use case is described by (1) a use-case narrative that outlines its stories as a set of flows; and (2) a set of test cases that complete the stories. These can be complemented with a set of special requirements that apply to the whole use case and are often non-functional. These will influence the stories, help assign the right stories to the use-case slices for implementation, and, most importantly, define the right test cases.
The use-case model is complemented by supporting information. This captures the definitions of the terms used in the use-case model and when outlining the stories in the use-case narratives. It also captures any systemwide requirements that apply to all of the use cases.
A use-case realization can be created to show how the system’s elements collaborate to perform a use case. Think of the use-case realization as providing the “how” to complement the use-case narrative’s “what.” Common ways of expressing use-case realizations include simple tables, storyboards, or sequence diagrams.

Use-Case example

The use case below is “7. Browse and Shop” from an online shopping application. Slices 1 and 2 of the use case are based on individual stories derived from the basic flow: “Select and Buy 1 Product” and “Select and Buy 100 Products.” Slice 3 is based on multiple stories covering the availability of the various support systems involved in the use case.

Use-Case

The essential properties for a use case are its name, state, and priority. In this case the popular MoSCoW (Must, Should, Could, Would) prioritization scheme has been used. The use cases should also be estimated. Here a simple scheme of assessing relative size and complexity has been used.

Use-Case Slice

The essential properties for a use-case slice are: (1) a list of its stories; (2) references to the use case and the flows that define the stories; (3) references to the tests and test cases that will be used to verify its completion; and (4) an estimate of the work needed to implement and test the slice. In this example the stories are used to name the slice, and the references to the use case are implicit in the slices number and list of flows. The estimates have been added later after consultation with the team. These are the large numbers toward the bottom right of each sticky note.

Ordering

The use cases and the use-case slices should also be ordered so that the most important ones are addressed first.

Use-Case: 7. Browse and Shop

Priority: Must
Release: 1
Size: Very Large (estimated)
Complexity: High (estimated)

Use-Case Slice: 7.1 Select and Buy one product

Flows: BF
Test: 1 product, default payment, valid details.
Points: 5

Use-Case Slice: 7.2 Select and buy 100 products

Flows: BF
Test: 100 products, default payment, valid details.
Points: 5

Use-Case Slice: 7.3 Support systems unavailable

Flows: BF, A9, A10, A1, A12
Test: Select product, provide information, disconnect each system between
Points: 13

Things to do

Use-Case 2.0 breaks the work up into a number of essential activities that need to be done if the use cases are to provide real value to the team.

The Find Actors and Use Cases activity produces a use-case model that identifies the use cases, which will be subsequently sliced. These use-case slices will then be prepared by describing the related stories in the use-case narrative and defining the test cases. The slice is analyzed to work out how the system elements will interact to perform the use case, then implemented and tested as a slice. Use-Case 2.0 can be considered a form of test-driven development, as it creates the test cases for each slice upfront. Finally, the whole system is tested to ensure that all the slices work together when combined.

Use-case slices on a Kanban board

Input (5) -> Preparation (3) - > Development (4) -> System (3)      -> Live
             On-going | Done     On-going | Done    On-going | Done

Scoped                | Prepared Analysed | Implemented      | Verified

Reading from left to right, you can see that slices have to be identified and scoped before they are Input to the team. In this figure the work-in-progress limit is five, and the customers, product owner, or requirements team that are the source of the requirements try to keep five use-case slices ready for implementation at all times.

Create Order

Data:
    <customer-id>,              <customer-contact-info>,
    <Shipment-destination>,     <Shipment-mechanism>,
    <Payment-information>

Primary Course:
    1. Order clerk issues "Create Order" command with above data.
    2. System validates all data.
    3. System creates order and determines order-id.
    4. System delivers order-id to clerk.

Exception Course: Validation Error
   1. System delivers error message to clerk.

What is a feature

A feature is a set of related requirements that allows the user to satisfy a business objective or need.

A feature tends to be a “higher-level” objective than a requirement – and is usually more focused on business needs rather than implementation.

Feature example

1-Click Ordering

Therefore Use Case diagrams shows features and not Use Cases...

What is a requirement

A requirement is a capability that a product must possess or something a product must do in order to ultimately satisfy a customer need.

A requirement tends to be more granular, and is usually written with the implementation in mind. Those who consume requirements tend to be engineers or technical audience.

Requirement example related to the "1-Click Ordering" feature

User shall be able to activate 1-click ordering within his account
User shall be able to deactivate 1-click ordering within his account
User shall be able to order books with just 1 click
…
User shall be able to “Undo” his 1-click order for a period of 30 minutes from the time he placed such an order

Use Cases

A use case is a series of related interactions between a user (or more generally, an “actor”) and a system that enables the user to achieve a goal.

To phrase this definition in another way, a use case describes the system’s behavior as it responds to a series of related requests from an actor.

Use cases are perhaps the best way to capture functional requirements of a system.

UML Subject

Subject (sometimes called a system boundary) is presented by a rectangle with subject's name, associated keywords and stereotypes in the top left corner. Use cases applicable to the subject are located inside the rectangle and actors - outside of the system boundary. subject

Business Model Subject - Use cases could be used to model some business to analyse business processes, recognize the problems being experienced, determine the opportunities to better serve customers.
Software System Subject - System use cases describe a system that automates some business use case(s) or process. Subject in this case is software and/or hardware system, subsystem, component or device.