IT 363 - Wk 5 Use Case and User Stories

User Story

The smallest piece of work that can provide value to the customer in Agile development; it captures what a user does or needs to do with the system and focuses on the user's need rather than system implementation.

User Story Components

Who - the user role/type (e.g. banking customer)

What - the action or goal (e.g. transfer money between accounts)

Why - the acceptance criteria (e.g. the system should transfer the money)

User Story Format

“As a [user role/type], I want to [action] so that [outcome/benefit].”

Acceptance Criteria

The accepted conditions or business rules that a feature must meet to be accepted by the Product Owner or stakeholders.

Acceptance Criteria Format

“Given [some context], when [I do some action], then [I expect the result].”

Use Case

A major, distinct, complete, end-to-end process of using a system that describes the service the system must perform from the actor's point of view.

Use Case Diagram

A model used to identify the primary elements and processes that form a system; actors are the external elements and use cases are the processes.

Actor

A human user, external system, or time event that interacts with the system.

Use Case Modeling

The process of identifying actors, use cases, and the relationships between them to represent visible functional requirements from the user's point of view.

Use Case Diagram – System Boundary

Draw a rectangle around the use cases to represent the system being modeled; actors remain outside the system boundary.

Use Case Diagram – Actor Symbol

Actors are shown outside the system boundary and are connected to the use cases they interact with.

Use Case Diagram – Use Case Symbol

A use case is shown as an oval containing the name of a complete process or service.

Use Case Diagram – Association

A line between an actor and a use case showing that the actor interacts with that use case.

Use Case Diagram – Include Relationship

Shows that one use case uses the functionality of another use case as part of its business process flow; shown with a dotted directed arrow labeled <>.

Use Case Diagram – Extend Relationship

Shows optional or conditional behavior that may extend another use case; shown with a dotted directed arrow labeled <>.

Use Case Diagram – Generalization

A relationship between two actors or two use cases where one is a more specialized version of another; shown with a closed-headed arrow pointing toward the more general element.

How to Develop a Use Case Diagram

1. Identify the system boundary. 2. Identify actors that interact with the system. 3. Identify major complete end-to-end use cases. 4. Place actors outside the boundary and use cases inside. 5. Connect actors to the use cases they interact with. 6. Add include, extend, or generalization relationships when appropriate. 7. Keep the diagram uncluttered, readable, and complete.

Use Case Granularity

Use cases should represent complete, meaningful processes rather than tiny individual steps; the diagram should remain readable while covering significant required functionality.

Use Case Scenario

A specific instance of a use case; a use case can have a primary scenario and several secondary or exceptional scenarios.

Primary Scenario

The normal path through a use case when nothing goes wrong.

Secondary Scenario

An alternative or exceptional path through a use case.

Use Case Narrative

A detailed written specification describing how an actor and the system interact during a use case.

Use Case Narrative Components

Use Case Name; Actors; Pre-conditions; Post-conditions; Basic Flow; Alternative Flows; Special Requirements; and Use Case Relationships.

Use Case Name

The name of the complete process being described in the narrative.

Pre-conditions

Conditions that must already be satisfied in the system before the use case can begin.

Post-conditions

The state of the system after the use case has executed.

Basic Flow

The normal sequence of interactions between the actor and system when the use case is executed successfully.

Alternative Flows

Subsidiary, optional, or exceptional events that can occur during the use case and should be documented separately.

Special Requirements

Business rules or other requirements that apply to the basic and alternative flows.

Use Case Relationships in a Narrative

Relationships such as <> or <> that connect the use case to other use cases.

How to Develop a Use Case Narrative

1. Name the use case. 2. Identify the actor or actors. 3. State the pre-conditions. 4. Write the basic flow as a sequence of actor actions and system responses. 5. Add alternative or exception flows. 6. State the post-conditions. 7. Add special requirements or business rules. 8. Identify include or extend relationships if applicable.

User Stories vs. Use Cases

Both identify users and describe the goal of a system feature from the user's perspective, but they serve different purposes.

User Story vs. Use Case – Detail

User Stories are short and deliberately leave out many details to encourage conversation, while Use Cases are more granular and describe the detailed process and interactions between actors and the system.

User Story vs. Use Case – Focus

User Stories focus on the result and benefit of a feature, while Use Cases focus on how the system and actor interact step by step.