# Chapter 3: Identifying User Stories and Use Cases > **Course Code**: IS332 — Analysis and Design of Information Systems > **Faculty**: Faculty of Computers and Artificial Intelligence, Cairo University (FCAI-CU) > **Department**: Information Systems Department > **Instructor**: Dr. Sherif Zahran > **Primary Reference**: *Systems Analysis and Design in a Changing World* (7th Edition), Satzinger, Jackson, & Burd — Chapter 3 --- ## Table of Contents - [3.0 Chapter Overview & Learning Objectives](#30-chapter-overview--learning-objectives) - [3.1 System Views and Modeling Perspectives](#31-system-views-and-modeling-perspectives) - [3.1.1 Structural versus Dynamic Views](#311-structural-versus-dynamic-views) - [3.1.2 UML Diagram Classification](#312-uml-diagram-classification) - [3.2 User Stories: Agile Requirements Definition](#32-user-stories-agile-requirements-definition) - [3.2.1 What is a User Story?](#321-what-is-a-user-story) - [3.2.2 The Canonical User Story Template](#322-the-canonical-user-story-template) - [3.2.3 Acceptance Criteria](#323-acceptance-criteria) - [3.2.4 Real-World User Story Cards](#324-real-world-user-story-cards) - [3.2.5 The User Story Lifecycle](#325-the-user-story-lifecycle) - [3.3 What is a Use Case?](#33-what-is-a-use-case) - [3.3.1 Definition and Purpose](#331-definition-and-purpose) - [3.3.2 Functional Decomposition and Naming Conventions](#332-functional-decomposition-and-naming-conventions) - [3.3.3 The Two Techniques for Identifying Use Cases](#333-the-two-techniques-for-identifying-use-cases) - [3.4 Technique 1: The User Goal Technique](#34-technique-1-the-user-goal-technique) - [3.4.1 Philosophy and Industry Popularity](#341-philosophy-and-industry-popularity) - [3.4.2 Step-by-Step Procedure for the User Goal Technique](#342-step-by-step-procedure-for-the-user-goal-technique) - [3.4.3 Example User Goals Across Operational Roles](#343-example-user-goals-across-operational-roles) - [3.5 Technique 2: The Event Decomposition Technique](#35-technique-2-the-event-decomposition-technique) - [3.5.1 The Concept of an Event](#351-the-concept-of-an-event) - [3.5.2 Three Types of Events (External, Temporal, State)](#352-three-types-of-events-external-temporal-state) - [3.5.3 External Event Checklist & Tracing](#353-external-event-checklist--tracing) - [3.5.4 Temporal Event Checklist & Tracing](#354-temporal-event-checklist--tracing) - [3.5.5 State Event Checklist & Tracing](#355-state-event-checklist--tracing) - [3.5.6 Critical Guidelines for Event Decomposition](#356-critical-guidelines-for-event-decomposition) - [3.5.6.1 Finding the Actual Event versus Operational Steps](#3561-finding-the-actual-event-versus-operational-steps) - [3.5.6.2 Tracing a Sequence of Transactions](#3562-tracing-a-sequence-of-transactions) - [3.5.6.3 The Perfect Technology Assumption](#3563-the-perfect-technology-assumption) - [3.5.6.4 The Elementary Business Process (EBP) Standard](#3564-the-elementary-business-process-ebp-standard) - [3.5.7 Step-by-Step Procedure for Event Decomposition](#357-step-by-step-procedure-for-event-decomposition) - [3.6 Brief Use Case Descriptions](#36-brief-use-case-descriptions) - [3.7 Master Use Case Catalog: RMO CSMS Project](#37-master-use-case-catalog-rmo-csms-project) - [3.7.1 Sales Subsystem (11 Use Cases)](#371-sales-subsystem-11-use-cases) - [3.7.2 Order Fulfillment Subsystem (9 Use Cases)](#372-order-fulfillment-subsystem-9-use-cases) - [3.7.3 Customer Account Subsystem (9 Use Cases)](#373-customer-account-subsystem-9-use-cases) - [3.7.4 Marketing Subsystem (4 Use Cases)](#374-marketing-subsystem-4-use-cases) - [3.7.5 Reporting Subsystem (7 Use Cases)](#375-reporting-subsystem-7-use-cases) - [3.8 UML Use Case Diagrams](#38-uml-use-case-diagrams) - [3.8.1 Core Notation and Visual Symbols](#381-core-notation-and-visual-symbols) - [3.8.2 Subsystem-Centric Use Case Diagram (Customer Account Subsystem)](#382-subsystem-centric-use-case-diagram-customer-account-subsystem) - [3.8.3 Actor-Centric Use Case Diagram (Online Customer — Sales Subsystem)](#383-actor-centric-use-case-diagram-online-customer--sales-subsystem) - [3.8.4 Internal Roles Use Case Diagram (Sales Support Staff)](#384-internal-roles-use-case-diagram-sales-support-staff) - [3.8.5 Advanced Use Case Relationships: The `<>` Stereotype](#385-advanced-use-case-relationships-the-includes-stereotype) - [3.8.6 The `<>` Stereotype](#386-the-extends-stereotype) - [3.8.7 Practical Steps for Constructing Use Case Diagrams](#387-practical-steps-for-constructing-use-case-diagrams) - [3.9 Chapter Summary & Key Terminology Glossary](#39-chapter-summary--key-terminology-glossary) --- ## 3.0 Chapter Overview & Learning Objectives Chapter 3 focuses on the most fundamental building block of functional requirements in modern systems development: **identifying and modeling Use Cases and User Stories**. While Chapter 2 explored general requirements gathering and non-functional constraints, Chapter 3 details the precise techniques analysts use to discover **WHAT** specific business activities the system must execute. By mastering the **User Goal Technique** and the **Event Decomposition Technique**, analysts ensure that software delivers direct business value without missing vital background transactions or cluttering scope with premature security controls. ### Learning Objectives After studying this chapter, students should be able to: 1. **Explain the Centrality of Use Cases**: Articulate why use cases and user stories serve as the primary drivers for systems analysis, design, estimating, and testing. 2. **Author Agile User Stories**: Write structured user stories complete with measurable acceptance criteria following standard agile conventions. 3. **Apply the User Goal Technique**: Systematically interview business users across operational roles to discover their day-to-day functional goals. 4. **Master the Event Decomposition Technique**: Identify business-driven external events, time-driven temporal events, and system-driven state events. 5. **Apply Analysis Standards**: Utilize the **Elementary Business Process (EBP)** standard and the **Perfect Technology Assumption** to establish the appropriate scope and level of detail for use cases. 6. **Compose Brief Use Case Descriptions**: Summarize use case responsibilities in clear, one-sentence functional overviews. 7. **Construct UML Use Case Diagrams**: Model actors, automation boundaries, associations, and `<>` relationships. --- ## 3.1 System Views and Modeling Perspectives ### 3.1.1 Structural versus Dynamic Views In object-oriented software engineering (originated by Rumbaugh, Jacobson, and Booch in 1999), complex software systems cannot be adequately described by a single model. Instead, systems are examined through two complementary architectural perspectives: ```mermaid flowchart TD Arch["Object-Oriented System Architecture"] --> Structural["Structural (Static) Views Define WHAT the system is made of: Classes, objects, physical components, deployments, and use cases"] Arch --> Dynamic["Dynamic (Behavioral) Views Define HOW the system behaves over time: Workflows, object interactions, state changes, and event handling"] ``` --- ### 3.1.2 UML Diagram Classification | System View | Focus & Nature | Key UML Diagrams Utilized | Primary Purpose in Analysis & Design | |:---|:---|:---|:---| | **Static / Structural** | System structure, components, and associations | • **Use Case Diagram**
• **Class Diagram (Domain & Design)**
• **Component Diagram**
• **Deployment Diagram** | Defines functional boundaries, business data objects, software packages, and hardware nodes. | | **Dynamic / Behavioral** | System behavior, state transitions, and messages | • **Activity Diagram**
• **System Sequence Diagram (SSD)**
• **Interaction / Sequence Diagram**
• **State Machine Diagram** | Models operational workflows, object-to-object messaging, and the lifecycle states of business objects. | > **Key Architectural Link**: > - **Use Case Diagrams** define the static functional scope. > - **Activity Diagrams** and **Sequence Diagrams** extend use cases by detailing their dynamic internal execution. > - **State Machine Diagrams** capture the dynamic lifecycle behavior of data entities defined in the static **Class Diagram**. --- ## 3.2 User Stories: Agile Requirements Definition ### 3.2.1 What is a User Story? A **User Story** is a brief, one-sentence statement authored in the everyday business language of the end user that articulates what a user does as part of their work and why they need that capability. User stories provide a rapid, lightweight, and conversational alternative to traditional, cumbersome requirements documents. They emphasize human dialogue between business users and developers over rigid legalistic specifications. --- ### 3.2.2 The Canonical User Story Template Every agile user story follows a standard three-part grammatical template: $$ ext{ extbf{As a}} \;\; \langle ext{role played} angle, \;\; ext{ extbf{I want to}} \;\; \langle ext{goal or desire} angle \;\; ext{ extbf{so that}} \;\; \langle ext{reason or business benefit} angle.$$ - **Role Played**: Specifies the exact user persona or job title (e.g., *Bank Teller*, *Warehouse Shipping Clerk*, *Online Shopper*). - **Goal / Desire**: Describes the specific action or software function desired. - **Reason / Benefit**: Articulates the business value or efficiency gained, preventing developers from building features that have no tangible purpose. --- ### 3.2.3 Acceptance Criteria A user story by itself is intentionally brief. To ensure that developers know when the feature is complete and working correctly, user stories are accompanied by **Acceptance Criteria**. - **Definition**: A concrete, testable checklist of conditions, business rules, and operational boundaries that must be satisfied before the user story is accepted as "Done". - **Focus**: Acceptance criteria focus strictly on **business functionality and data verification**, never on premature UI styling (such as button colors or font sizes). --- ### 3.2.4 Real-World User Story Cards (Figure 3-1) In agile teams, user stories and acceptance criteria are traditionally written on physical $3 imes 5$ inch index cards: ``` +--------------------------------------------------------------------------------+ | USER STORY CARD 1: BANK TELLER CASH DEPOSIT | +--------------------------------------------------------------------------------+ | STORY: | | As a bank teller, I want to process a customer cash deposit quickly so that | | I can serve more waiting customers and minimize queue times. | | | | ACCEPTANCE CRITERIA: | | 1. System must accept customer account number via key entry or magnetic swipe.| | 2. System must verify that the target account is open, active, and valid. | | 3. System must record cash denomination breakdown (bills and coins). | | 4. Cash drawer balance must automatically increment by the exact amount. | | 5. System must immediately update available balance and print paper receipt. | | 6. Transactions exceeding $10,000 must automatically flag for AML compliance. | +--------------------------------------------------------------------------------+ ``` ``` +--------------------------------------------------------------------------------+ | USER STORY CARD 2: WAREHOUSE SHIPPING CLERK DISPATCH | +--------------------------------------------------------------------------------+ | STORY: | | As a shipping clerk, I want to ship an order as accurately as possible as | | soon as the items are boxed, so that customers receive goods without delay. | | | | ACCEPTANCE CRITERIA: | | 1. System must scan barcode on shipping box and match to open order number. | | 2. System must verify that every ordered item has been scanned into the box. | | 3. System must communicate with courier API (FedEx/UPS) to generate tracking. | | 4. System must print adhesive shipping label and packing slip immediately. | | 5. Order status in database must transition from 'In Fulfillment' to 'Shipped'| | 6. Automated shipping confirmation email with tracking link sent to customer. | +--------------------------------------------------------------------------------+ ``` --- ### 3.2.5 The User Story Lifecycle User stories evolve through five disciplined states within agile development: ```mermaid flowchart LR S1["1. Product Backlog (Identified & Estimated)"] --> S2["2. Sprint Backlog (Committed for Iteration)"] S2 --> S3["3. In Progress (Pair Programming & Unit Tests)"] S3 --> S4["4. In Testing / Review (Verify Acceptance Criteria)"] S4 --> S5["5. Done / Accepted (User Sign-Off & Deployed)"] S4 -->|Defects Detected| S3 ``` --- ## 3.3 What is a Use Case? ### 3.3.1 Definition and Purpose A **Use Case** is an activity that the information system performs, typically in response to an explicit request or trigger by a user or external actor. - Use cases define the **functional requirements** of the software. - While user stories are user-centric conversations (*"what I want as an individual"*), use cases are system-centric functional contracts (*"what the software executes from start to finish"*). - In modern iterative systems development, an agile user story is frequently analyzed and expanded into a formal use case for architecture, database design, and testing. --- ### 3.3.2 Functional Decomposition and Naming Conventions To build a complex enterprise system, analysts perform **functional decomposition**—dividing the overall system into smaller, discrete, and manageable use cases. #### The Verb-Noun Naming Rule Every use case name **must** begin with a strong action verb followed by a specific noun phrase representing the object acted upon: - ✅ *Correct Use Case Names*: `Look up customer`, `Ship items`, `Calculate sales tax`, `Create phone sale`, `Print monthly ledger`. - ❌ *Incorrect Names*: `Customer Account System` (too broad, describes a subsystem), `Billing` (a vague noun, lacks action), `Click submit button` (too granular, represents an internal UI step). --- ### 3.3.3 The Two Techniques for Identifying Use Cases There are two primary industry techniques for discovering use cases: 1. **The User Goal Technique**: Centers on human users, asking what each worker needs to accomplish. 2. **The Event Decomposition Technique**: Centers on business events in the environment, identifying external requests, temporal time triggers, and internal state thresholds. ```mermaid flowchart TD Discovery["Identifying Use Cases"] --> UGT["1. User Goal Technique • Focus: Human operational users • Question: What goals do you achieve daily? • Best for: Direct interactive user applications"] Discovery --> EDT["2. Event Decomposition Technique • Focus: Business environment events • Question: What occurrences trigger system responses? • Best for: Comprehensive enterprise systems (captures time & state)"] ``` --- ## 3.4 Technique 1: The User Goal Technique ### 3.4.1 Philosophy and Industry Popularity The **User Goal Technique** is the most widely adopted and straightforward technique in the software industry. It operates on a simple, intuitive premise: **information systems exist to help end users achieve their operational work goals**. By interviewing workers across every job classification, analysts identify the discrete tasks users must perform to do their jobs. --- ### 3.4.2 Step-by-Step Procedure for the User Goal Technique ```mermaid flowchart TD Step1["Step 1: Identify all potential categories of users (roles) who will interact with the system"] --> Step2["Step 2: Schedule and conduct structured interviews with representatives of each user category"] Step2 --> Step3["Step 3: Ask users to list the specific tasks and operational goals they must accomplish"] Step3 --> Step4["Step 4: Express each identified goal as a discrete Verb-Noun use case name"] Step4 --> Step5["Step 5: Identify points where multiple user roles share the exact same use case"] Step5 --> Step6["Step 6: Eliminate duplicates, merge overlapping tasks, and resolve ambiguities"] Step6 --> Step7["Step 7: Conduct a review meeting with users to validate and approve the master use case list"] ``` --- ### 3.4.3 Example User Goals Across Operational Roles (Figure 3-2) At RMO, analysts interviewed personnel across departments to compile candidate use cases: | User Category / Role | Operational Question Asked | Identified Use Case (Verb-Noun) | |:---|:---|:---| | **Online Retail Customer** | *"What do you want to do on our website?"* | `Search for item`
`Fill shopping cart`
`Check out shopping cart`
`Track shipment`
`Rate and comment on product` | | **Phone Order Clerk** | *"What tasks do you perform while on the phone with a caller?"* | `Look up customer`
`Create phone sale`
`Check inventory stock`
`Process account adjustment` | | **Store Sales Representative** | *"What activities do you execute at the retail store register?"* | `Create store sale`
`Process item return`
`Look up customer loyalty credits` | | **Warehouse Shipping Clerk** | *"What work steps do you complete on the shipping dock?"* | `Ship items`
`Record packaging weights`
`Manage courier manifests`
`Create backorder` | | **Marketing Specialist** | *"What changes do you make to promotional campaigns?"* | `Add/update product information`
`Add/update promotion`
`Add/update accessory package` | --- ## 3.5 Technique 2: The Event Decomposition Technique ### 3.5.1 The Concept of an Event An **Event** is an occurrence at a specific time and place that can be described, can be remembered by the system, and that triggers the system to respond. The **Event Decomposition Technique** is significantly more comprehensive than the User Goal Technique. Rather than focusing solely on what users say they want, it analyzes the business environment to determine every event that requires a response from the software. ```mermaid flowchart LR Event["Business Event Occurs in Environment"] --> System["Information System Receives Trigger"] System --> UseCase["System Executes Corresponding Use Case"] UseCase --> DBUpdate["Database State Updated & Output Delivered"] ``` --- ### 3.5.2 Three Types of Events (External, Temporal, State) All events fall into one of three distinct classifications: ```mermaid flowchart TD Events["System Events"] --> Ext["1. External Event Initiated by an outside agent/actor crossing the automation boundary"] Events --> Temp["2. Temporal Event Initiated automatically by the arrival of a predetermined date or time"] Events --> State["3. State (Internal) Event Initiated automatically when an internal system condition or threshold is reached"] ``` --- ### 3.5.3 External Event Checklist & Tracing (Figure 3-4) An **External Event** occurs outside the system boundary, initiated by an external agent (a person, department, or third-party computer system) that supplies data or requests services. #### External Event Checklist for RMO - External agent wants to purchase goods $\implies$ `Check out shopping cart` / `Create phone sale`. - Customer changes residential mailing address $\implies$ `Update customer account`. - Customer requests current order status $\implies$ `Look up order status`. - Customer returns damaged merchandise $\implies$ `Process item return`. - Supplier updates wholesale catalog and unit costs $\implies$ `Update supplier pricing`. - Credit card clearinghouse authorizes/declines transaction $\implies$ `Process credit authorization`. --- ### 3.5.4 Temporal Event Checklist & Tracing (Figure 3-5) A **Temporal Event** is an event that occurs as a result of the reaching of a specific point in time. It has **no human actor** initiating the request; instead, the internal system clock acts as the trigger. #### Temporal Event Checklist for RMO - **Daily Time Triggers (e.g., Midnight / End of Business)**: - Time to generate daily transaction summary for accounting $\implies$ `Produce daily transaction report`. - Time to transmit daily courier pickup manifests to FedEx/UPS $\implies$ `Transmit shipping manifests`. - Time to back up transaction logs to secure cloud vault $\implies$ `Execute automated database backup`. - **Weekly / Bi-Weekly Time Triggers**: - Time to produce weekly executive sales trend analytics $\implies$ `Produce sales trends report`. - Time to calculate employee payroll commissions $\implies$ `Process payroll disbursements`. - **Monthly Time Triggers**: - Time to generate monthly billing statements for corporate accounts $\implies$ `Generate customer account statements`. - Time to evaluate customer loyalty tier rankings $\implies$ `Recalculate customer loyalty points`. --- ### 3.5.5 State Event Checklist & Tracing A **State Event** (also called an **Internal Event**) occurs when an internal system condition changes or a numerical threshold inside the database is crossed. #### State Event Examples for RMO - Warehouse inventory count drops below reorder point $\implies$ `Reorder inventory stock`. - Customer credit balance exceeds approved credit limit $\implies$ `Flag account for credit hold`. - Package tracking API detects shipment marked "Delivered" $\implies$ `Close shipment record`. --- ### 3.5.6 Critical Guidelines for Event Decomposition #### 3.5.6.1 Finding the Actual Event versus Operational Steps (Figure 3-6) A frequent trap for novice analysts is mistaking individual keystrokes or preliminary conversational exchanges for separate events. ```mermaid flowchart TD subgraph OperationalSteps ["Conversational User Steps (NOT Separate Events)"] S1["Customer asks about garment fabric"] S2["Customer checks available color swatches"] S3["Customer checks item unit price"] S4["Customer decides to buy and provides credit card"] end subgraph TrueEvent ["The Actual Business Event"] E["Customer places an order (Triggers Use Case: 'Create phone sale' or 'Check out cart')"] end OperationalSteps -->|Synthesized into| TrueEvent ``` > **The Rule**: Do not define a use case for every intermediate question. Group related sequential queries into the **single overarching business event** that leaves the database in a permanent, stable state. --- #### 3.5.6.2 Tracing a Sequence of Transactions (Figure 3-7) A single real-world customer relationship generates a long chronological sequence of independent events over weeks or months: ```mermaid flowchart LR E1["Event 1: Customer creates account"] --> E2["Event 2: Customer places order"] E2 --> E3["Event 3: System bills credit card"] E3 --> E4["Event 4: Shipping fulfills order"] E4 --> E5["Event 5: Customer returns item"] E5 --> E6["Event 6: Accounting issues refund"] ``` Each independent step in this customer lifecycle represents a distinct event requiring its own standalone use case! --- #### 3.5.6.3 The Perfect Technology Assumption (Figure 3-8) > [!IMPORTANT] > ### 💡 The Perfect Technology Assumption > When identifying initial business use cases, **assume that all computing technology works flawlessly**: > - Computer hardware never crashes. > - Network connectivity is 100% reliable and instantaneous. > - Memory and disk capacity are infinite. > - Operating software contains zero bugs. > - Users never make typographical errors and are 100% honest (no fraud or unauthorized access). #### Why Apply This Assumption? If analysts attempt to model security, login dialogs, password encryption, database backups, network reconnection, and fraud detection during initial functional requirements gathering, the true business needs become hopelessly obscured. | Event Type | Initial Analysis (Core Process 3) | Detailed Systems Design (Core Process 4) | |:---|:---|:---| | **Core Business Functions** | `Look up customer`
`Check out shopping cart`
`Ship items`
`Process item return` | Design the physical UI screens, SQL queries, and object classes to implement these. | | **System Controls & Security** | **DEFERRED (Ignored)**
*(Do NOT create use cases for Login, Logout, Change Password, Backup Database)* | **INCLUDED & DESIGNED**
Security architecture, multi-factor authentication, database replication, encryption. | --- #### 3.5.6.4 The Elementary Business Process (EBP) Standard How do analysts determine the correct granularity for a use case? They apply the **Elementary Business Process (EBP)** standard: - **EBP Definition**: An Elementary Business Process is a fundamental task performed by **one person, in one place, at one time**, in response to a business event, that adds measurable business value and leaves the organizational data in a consistent, stable state. - **Too Small**: *"Select size dropdown"* (a mere UI interaction, does not leave data stable). - **Too Big**: *"Operate the company retail stores"* (encompasses hundreds of processes over months). - **Just Right (EBP)**: `Check out shopping cart`, `Ship items`, `Process item return`. --- ### 3.5.7 Step-by-Step Procedure for Event Decomposition ```mermaid flowchart TD Step1["Step 1: Consider the external environment and identify external agents (customers, suppliers, banks)"] Step2["Step 2: Brainstorm the external events that each agent can initiate that affect the system"] Step3["Step 3: Consider the passage of time and identify temporal events (daily, weekly, monthly reports)"] Step4["Step 4: Consider internal state thresholds and identify state events (inventory reorders, credit holds)"] Step5["Step 5: Apply the Perfect Technology Assumption (strip away login, logout, backups, hardware failures)"] Step6["Step 6: Verify each candidate use case against the Elementary Business Process (EBP) standard"] Step7["Step 7: Formulate the master event-response table and name each use case using Verb-Noun syntax"] Step1 --> Step2 --> Step3 --> Step4 --> Step5 --> Step6 --> Step7 ``` --- ## 3.6 Brief Use Case Descriptions Once use cases are identified, analysts draft a **Brief Use Case Description** (Figure 3-9) for each one. This is a concise 1–2 sentence statement summarizing the primary steps and intended outcome: | Use Case Name | Brief Functional Description | |:---|:---| | **Create customer account** | User/actor enters new customer contact and billing data; the system validates fields, assigns a unique customer ID, and creates customer and account records. | | **Look up customer** | User/actor enters customer account number or telephone; the system queries the database, retrieves account history, and renders customer profile details. | | **Process account adjustment** | Manager enters customer order number and adjustment amount; the system verifies manager authorization and creates an audit transaction record for the financial credit. | --- ## 3.7 Master Use Case Catalog: RMO CSMS Project The combination of User Goal Technique and Event Decomposition produces the complete functional inventory for RMO's CSMS project across its five operational subsystems (Figures 3-10a through 3-10e): ### 3.7.1 Sales Subsystem (11 Use Cases) | # | Use Case Name | Primary Actors Involved | Brief Description | |:---:|:---|:---|:---| | 1 | **Search for item** | Customer, Customer Service Rep, Store Sales Rep | Search product catalog by keywords, category, size, or color, and display inventory availability. | | 2 | **View product comments and ratings** | Customer, Customer Service Rep, Store Sales Rep | Display verified customer reviews, star ratings, and community feedback for selected merchandise. | | 3 | **View accessory combinations** | Customer, Customer Service Rep, Store Sales Rep | Display algorithmically recommended companion items, matching garments, and seasonal bundles. | | 4 | **Fill shopping cart** | Customer | Add merchandise item variants to temporary shopping session cart with quantity and size. | | 5 | **Empty shopping cart** | Customer | Clear all selected merchandise items from active shopping cart session. | | 6 | **Check out shopping cart** | Customer | Submit cart contents, calculate shipping and taxes, capture payment details, and finalize online purchase order. | | 7 | **Fill reserve cart** | Customer | Reserve limited-edition or out-of-stock items for future purchase hold. | | 8 | **Empty reserve cart** | Customer | Remove items held in reservation status. | | 9 | **Convert reserve cart** | Customer | Transfer reserved items directly into active shopping cart when inventory arrives. | | 10 | **Create phone sale** | Customer Service Representative | Process catalog phone order with caller, verify credit card, and submit warehouse fulfillment request. | | 11 | **Create store sale** | Store Sales Representative | Process physical point-of-sale checkout at retail store register with barcode scanning. | --- ### 3.7.2 Order Fulfillment Subsystem (9 Use Cases) | # | Use Case Name | Primary Actors Involved | Brief Description | |:---:|:---|:---|:---| | 1 | **Ship items** | Shipping Clerk | Scan boxed order items, print courier shipping labels, and notify courier dispatch. | | 2 | **Manage shippers** | Shipping Clerk | Configure courier accounts, contract rates, delivery zones, and pickup schedules (FedEx/UPS). | | 3 | **Create backorder** | Shipping Clerk | Automatically split unfulfilled line items into pending backorder status when stock is insufficient. | | 4 | **Create item return** | Shipping Clerk, Customer, Marketing | Process returned goods, record reason codes, update inventory disposition, and issue customer credits. | | 5 | **Look up order status** | Shipping Clerk, Customer | Query real-time processing and fulfillment status of an existing order. | | 6 | **Track shipment** | Shipping Clerk, Customer, Management | Query external courier API to display live transit location and delivery confirmation. | | 7 | **Rate and comment on product** | Customer | Submit post-purchase garment ratings, quality feedback, and customer fit comments. | | 8 | **Provide suggestion** | Customer | Submit unstructured ideas for new product features, apparel styles, or catalog enhancements. | | 9 | **Review suggestions** | Management | Evaluate customer suggestions and route actionable feedback to merchandising teams. | --- ### 3.7.3 Customer Account Subsystem (9 Use Cases) | # | Use Case Name | Primary Actors Involved | Brief Description | |:---:|:---|:---|:---| | 1 | **Create/update customer account** | Customer, Customer Service Rep, Store Sales Rep | Enter or modify customer profile details, mailing address, billing preferences, and password. | | 2 | **Process account adjustment** | Management | Authorize and apply goodwill credits, dispute settlements, or manual fee reversals. | | 3 | **Send message** | Customer | Transmit secure inquiry message to customer support staff regarding order inquiries. | | 4 | **Browse messages** | Customer | Review historical customer support message threads and responses. | | 5 | **Request friend linkup** | Customer | Send invitation to fellow outdoor enthusiast to link profiles for community shopping. | | 6 | **Reply to linkup request** | Customer | Accept or decline incoming community linkup requests from peers. | | 7 | **Send/receive partner credits** | Customer | Transfer promotional credits and gift coupons between linked community member accounts. | | 8 | **View "mountain bucks"** | Customer | Display accumulated RMO loyalty reward points ("Mountain Bucks") and tier qualification. | | 9 | **Transfer "mountain bucks"** | Customer | Redeem or gift accumulated loyalty rewards toward catalog merchandise purchases. | --- ### 3.7.4 Marketing Subsystem (4 Use Cases) | # | Use Case Name | Primary Actors Involved | Brief Description | |:---:|:---|:---|:---| | 1 | **Add/update product information** | Merchandising Specialist, Marketing | Maintain master product catalog data, specifications, garment descriptions, and retail pricing. | | 2 | **Add/update promotion** | Marketing Specialist | Create promotional discount codes, seasonal sale campaigns, and automated markdown schedules. | | 3 | **Add/update accessory package** | Merchandising Specialist | Group compatible products into curated bundles (e.g., ski package: jacket + pants + goggles). | | 4 | **Add/update business partner link** | Marketing Specialist | Establish affiliate tracking links and reciprocal advertising arrangements with resort partners. | --- ### 3.7.5 Reporting Subsystem (7 Use Cases) | # | Use Case Name | Primary Actors Involved | Brief Description | |:---:|:---|:---|:---| | 1 | **Produce daily transaction summary** | Management | Generate daily consolidated ledger of sales, tax collections, returns, and cash deposits. | | 2 | **Produce sales history report** | Management, Marketing | Generate multi-year historical sales breakdowns categorized by channel, store, and product line. | | 3 | **Produce sales trends report** | Marketing Specialist | Analyze emerging apparel sales velocity and consumer purchasing patterns over time. | | 4 | **Produce customer usage report** | Marketing Specialist | Segment customer database by demographic engagement, lifetime value, and purchase frequency. | | 5 | **Produce shipment history report** | Management, Shipping | Audit courier performance metrics, transit times, on-time delivery rates, and freight costs. | | 6 | **Produce promotion impact report** | Marketing Specialist | Evaluate financial effectiveness and incremental revenue lift generated by marketing campaigns. | | 7 | **Produce promotional partner report** | Management, Marketing | Measure traffic referrals, conversion rates, and royalty commissions paid to affiliate partners. | --- ## 3.8 UML Use Case Diagrams ### 3.8.1 Core Notation and Visual Symbols (Figure 3-11) A **Use Case Diagram** is the official UML behavioral model used to graphically illustrate use cases, external actors, and the relationships connecting them. ```mermaid flowchart LR Actor(("Shipping Clerk (Actor)")) subgraph Boundary ["Automation Boundary: Order Fulfillment Subsystem"] UC1(["Ship items"]) UC2(["Manage shippers"]) UC3(["Create backorder"]) end Actor --- UC1 Actor --- UC2 Actor --- UC3 ``` - **Actor (Stick Figure / Entity)**: - Represents a specific **role** played by an external agent interacting with the software. - An actor can be a human user (e.g., *Shipping Clerk*), an organizational department, or an external automated system (e.g., *Bank Clearinghouse*, *FedEx Server*). - Actors always reside **outside the automation boundary**. - **Use Case (Oval)**: - Represents the discrete business activity executed by the software. - Labeled with an action-oriented **Verb-Noun** phrase. - **Automation Boundary (Box)**: - A bounding rectangle that encloses all computerized use cases, separating internal software logic from external actors. - **Association Line (Solid Line)**: - Connects an actor to a use case, indicating that the actor initiates, participates in, or receives services from that use case. --- ### 3.8.2 Subsystem-Centric Use Case Diagram (Customer Account Subsystem) (Figure 3-12) The following diagram models the entire **Customer Account Subsystem**, illustrating how different actors share access to use cases: ```mermaid flowchart LR Customer(("Customer")) CSR(("Customer Service Representative")) SSR(("Store Sales Representative")) Manager(("Management")) subgraph Boundary ["Automation Boundary: Customer Account Subsystem"] UC_Account(["Create/update customer account"]) UC_Adjust(["Process account adjustment"]) UC_SendMsg(["Send message"]) UC_BrowseMsg(["Browse messages"]) UC_ReqLink(["Request friend linkup"]) UC_ReplyLink(["Reply to friend linkup"]) UC_PartnerCredit(["Send/receive partner credits"]) UC_ViewBucks(["View 'mountain bucks'"]) UC_TransBucks(["Transfer 'mountain bucks'"]) end Customer --- UC_Account CSR --- UC_Account SSR --- UC_Account Manager --- UC_Adjust Customer --- UC_SendMsg Customer --- UC_BrowseMsg Customer --- UC_ReqLink Customer --- UC_ReplyLink Customer --- UC_PartnerCredit Customer --- UC_ViewBucks Customer --- UC_TransBucks ``` --- ### 3.8.3 Actor-Centric Use Case Diagram (Online Customer — Sales Subsystem) (Figure 3-13) Analysts also organize use case diagrams from the perspective of a **single actor**, isolating everything that persona can perform: ```mermaid flowchart LR Customer(("Online Retail Customer")) subgraph SalesBoundary ["Sales Subsystem — Customer Facing Capabilities"] UC1(["Search for item"]) UC2(["View product comments and ratings"]) UC3(["View accessory combinations"]) UC4(["Fill shopping cart"]) UC5(["Empty shopping cart"]) UC6(["Check out shopping cart"]) UC7(["Fill reserve cart"]) UC8(["Empty reserve cart"]) UC9(["Convert reserve cart"]) end Customer --- UC1 Customer --- UC2 Customer --- UC3 Customer --- UC4 Customer --- UC5 Customer --- UC6 Customer --- UC7 Customer --- UC8 Customer --- UC9 ``` --- ### 3.8.4 Internal Roles Use Case Diagram (Sales Support Staff) (Figure 3-14) Internal operational staff often interact with the exact same sales subsystem through specialized assisted-sales channels: ```mermaid flowchart LR CSR(("Customer Service Representative (Phone Orders)")) SSR(("Store Sales Representative (Retail POS)")) subgraph SalesSubsystem ["Sales Subsystem — Assisted Sales"] UC_Search(["Search for item"]) UC_Comments(["View product comments and ratings"]) UC_Accessory(["View accessory combinations"]) UC_PhoneSale(["Create phone sale"]) UC_StoreSale(["Create store sale"]) end CSR --- UC_Search CSR --- UC_Comments CSR --- UC_Accessory CSR --- UC_PhoneSale SSR --- UC_Search SSR --- UC_Comments SSR --- UC_Accessory SSR --- UC_StoreSale ``` --- ### 3.8.5 Advanced Use Case Relationships: The `<>` Stereotype (Figure 3-15) In complex software systems, multiple use cases frequently share an identical sequence of operational steps. Rather than duplicating that logic in every use case, UML provides the **`<>` relationship**. - **Definition**: A relationship between use cases where one use case (the base use case) stereotypically and unconditionally incorporates the behavior of another use case (the included use case). - **Analogy**: Identical to calling a shared, reusable subroutine or function in programming. - **Notation**: A dashed directed arrow pointing **from the base use case TO the included use case**, labeled with the stereotype `<>`. ```mermaid flowchart LR Customer(("Customer")) subgraph SalesBoundary ["Sales Subsystem — Shared Checkout Logic"] Checkout(["Check out shopping cart (Base Use Case)"]) PhoneSale(["Create phone sale (Base Use Case)"]) VerifyCard(["Verify credit card (Included Subroutine)"]) CalcTax(["Calculate sales tax & shipping (Included Subroutine)"]) end Customer --- Checkout CSR(("Customer Service Rep")) --- PhoneSale Checkout -.->|<<includes>>| VerifyCard Checkout -.->|<<includes>>| CalcTax PhoneSale -.->|<<includes>>| VerifyCard PhoneSale -.->|<<includes>>| CalcTax ``` > **Why Use `<>`?**: > - Eliminates redundancy in requirements specifications. > - When tax calculation algorithms or credit card gateway APIs change, analysts and developers modify only the single included use case. --- ### 3.8.6 The `<>` Stereotype While `<>` models mandatory, shared behavior, UML also defines the **`<>` relationship**: - **Definition**: Models optional, conditional, or exceptional behavior that is only inserted into the base use case if a specific **extension point condition** is met. - **Notation**: A dashed directed arrow pointing **from the extending use case BACK TO the base use case**, labeled `<>`. - **Example**: An optional extended warranty or gift wrapping option that only triggers if the customer checks a box during checkout. --- ### 3.8.7 Practical Steps for Constructing Use Case Diagrams When creating use case diagrams for project reviews: 1. **Identify the Audience**: Determine whether the diagram is meant for executive sponsors (subsystem overview), specific user groups (actor-centric), or development teams (detailed relationships). 2. **Set the Automation Boundary**: Draw the bounding rectangle representing the software application or subsystem. 3. **Place the Actors Outside**: Position primary human roles on the left and external systems on the right. 4. **Place Use Cases Inside**: Draw ovals labeled with action-oriented Verb-Noun phrases. 5. **Draw Associations**: Connect actors to their participating use cases using clean, non-crossing lines. 6. **Factor Common Behavior**: Identify opportunities to extract shared subroutines using `<>`. 7. **Name and Annotate**: Provide a descriptive title and version number for each diagram. --- ## 3.9 Chapter Summary & Key Terminology Glossary ### Chapter Summary - **Use Cases** and **User Stories** are the foundation of functional requirements in modern systems development, defining the specific capabilities the system must execute. - Systems are analyzed through **Structural Views** (static data and system components) and **Dynamic Views** (workflows and object message passing). - **User Stories** follow the template: *"As a ``, I want to `` so that ``"*, verified by explicit, testable **Acceptance Criteria**. - The **User Goal Technique** identifies use cases by interviewing operational users about their day-to-day job goals. - The **Event Decomposition Technique** discovers use cases by identifying **External Events** (actor-driven), **Temporal Events** (time-driven), and **State Events** (internal condition-driven). - Analysis is kept focused by applying the **Perfect Technology Assumption** (ignoring logins, security, and hardware failures during initial analysis) and the **Elementary Business Process (EBP)** standard (one person, one place, one time, leaving data stable). - **Brief Use Case Descriptions** provide quick 1–2 sentence operational overviews. - **UML Use Case Diagrams** model actors, automation boundaries, associations, and reusable shared subroutines via the **`<>`** relationship. --- ### Key Terminology Glossary - **Acceptance Criteria**: The concrete, testable conditions and rules that must be satisfied for a user story to be accepted by business stakeholders. - **Actor**: A UML role played by an external user, department, or external system that interacts directly with an information system across the automation boundary. - **Automation Boundary**: The defined perimeter in a use case diagram separating the computerized software components from external actors. - **Brief Use Case Description**: A concise, one- or two-sentence description summarizing the primary steps and outcome of a use case. - **Elementary Business Process (EBP)**: A fundamental operational task performed by one person, in one place, at one time, in response to an event, which adds business value and leaves data in a permanent, stable state. - **Event**: An occurrence at a specific time and place that can be described, can be remembered by the system, and that triggers a system response. - **Event Decomposition Technique**: A disciplined requirements analysis method that identifies use cases by uncovering external, temporal, and state events. - **External Event**: An event initiated by an external agent or actor outside the system automation boundary. - **Functional Decomposition**: The engineering technique of breaking a large, complex system down into smaller, discrete functional use cases. - **`<>` Relationship**: A UML use case relationship where one base use case unconditionally executes another included use case as a mandatory subroutine. - **`<>` Relationship**: A UML use case relationship where an extending use case optionally provides additional functionality to a base use case under specific conditions. - **Perfect Technology Assumption**: The analytical standard that assumes all computing hardware, networks, and software operate with 100% reliability and security during initial requirements gathering. - **State Event (Internal Event)**: An event triggered automatically when an internal system condition changes or a numerical threshold inside the database is reached. - **Temporal Event**: An event triggered automatically by the passage of time or the arrival of a predetermined calendar date/clock time. - **Use Case**: An activity or functional service that the system performs, typically in response to a request by an actor. - **Use Case Diagram**: A standard UML graphical diagram illustrating use cases, external actors, automation boundaries, and relationships. - **User Goal Technique**: A requirements gathering technique that identifies use cases by discovering the operational tasks and goals that business users need to accomplish. - **User Story**: A brief, conversational requirement statement written from the perspective of an end user specifying role, goal, and business benefit.