# Chapter 5: Use Case Modeling > **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 5 --- ## Table of Contents - [5.0 Chapter Overview & Learning Objectives](#50-chapter-overview--learning-objectives) - [5.1 Detailed Use Case Modeling in Systems Analysis](#51-detailed-use-case-modeling-in-systems-analysis) - [5.1.1 Bridging High-Level Scope to Low-Level Design](#511-bridging-high-level-scope-to-low-level-design) - [5.1.2 The Three Complementary Detailed Models](#512-the-three-complementary-detailed-models) - [5.2 Use Case Descriptions](#52-use-case-descriptions) - [5.2.1 Levels of Description Detail (Brief, Intermediate, Fully Developed)](#521-levels-of-description-detail-brief-intermediate-fully-developed) - [5.2.2 Anatomy of a Fully Developed Use Case Description](#522-anatomy-of-a-fully-developed-use-case-description) - [5.2.3 Preconditions and Postconditions](#523-preconditions-and-postconditions) - [5.2.4 Master Specification 1: Create Customer Account](#524-master-specification-1-create-customer-account) - [5.2.5 Master Specification 2: Ship Items](#525-master-specification-2-ship-items) - [5.3 Activity Diagrams for Use Case Workflows](#53-activity-diagrams-for-use-case-workflows) - [5.3.1 Role of Activity Diagrams in Detailed Modeling](#531-role-of-activity-diagrams-in-detailed-modeling) - [5.3.2 Activity Diagram: Create Customer Account](#532-activity-diagram-create-customer-account) - [5.3.3 Activity Diagram: Ship Items](#533-activity-diagram-ship-items) - [5.4 System Sequence Diagrams (SSDs)](#54-system-sequence-diagrams-ssds) - [5.4.1 What is a System Sequence Diagram?](#541-what-is-a-system-sequence-diagram) - [5.4.2 The System as a Black Box](#542-the-system-as-a-black-box) - [5.4.3 SSD Notation & Message Syntax](#543-ssd-notation--message-syntax) - [5.4.4 Interaction Frames (Loop, Alt, Opt)](#544-interaction-frames-loop-alt-opt) - [5.4.5 Four Steps to Develop an SSD from an Activity Diagram](#545-four-steps-to-develop-an-ssd-from-an-activity-diagram) - [5.4.6 Detailed Case 1: SSD for Create Customer Account](#546-detailed-case-1-ssd-for-create-customer-account) - [5.4.7 Detailed Case 2: SSD for Ship Items](#547-detailed-case-2-ssd-for-ship-items) - [5.5 Validating Requirements with the CRUD Technique](#55-validating-requirements-with-the-crud-technique) - [5.5.1 The CRUD Concept (Create, Read, Update, Delete)](#551-the-crud-concept-create-read-update-delete) - [5.5.2 Cross-Checking Use Cases Against Domain Classes](#552-cross-checking-use-cases-against-domain-classes) - [5.5.3 The Master CRUD Cross-Reference Matrix](#553-the-master-crud-cross-reference-matrix) - [5.5.4 Four-Step Procedure for CRUD Analysis](#554-four-step-procedure-for-crud-analysis) - [5.6 Integrating Requirements Models (The Unified Picture)](#56-integrating-requirements-models-the-unified-picture) - [5.6.1 Interdependence of Systems Analysis Models](#561-interdependence-of-systems-analysis-models) - [5.6.2 The Complete Requirements Architecture](#562-the-complete-requirements-architecture) - [5.7 Chapter Summary & Key Terminology Glossary](#57-chapter-summary--key-terminology-glossary) --- ## 5.0 Chapter Overview & Learning Objectives Chapter 5 represents the culmination of **Systems Analysis (SDLC Core Process 3)**. In Chapters 3 and 4, analysts identified high-level functional use cases and defined static domain classes. However, knowing that a use case exists (e.g., `Ship items`) does not provide sufficient detail for a software engineer to write source code or design user interfaces. Chapter 5 provides the disciplined, low-level modeling tools required to document the exact internal behavior of each use case: 1. **Fully Developed Use Case Descriptions**: Textual specifications capturing scenarios, pre/postconditions, flows of activities, and exception handling. 2. **Activity Diagrams**: Graphical workflow models visualizing user-system handoffs. 3. **System Sequence Diagrams (SSDs)**: Interaction models defining the precise input and output data messages crossing the automation boundary into the system "Black Box". 4. **The CRUD Technique**: A rigorous validation framework ensuring that every domain class has complete lifecycle use cases. ### Learning Objectives After studying this chapter, students should be able to: 1. **Draft Use Case Descriptions Across Detail Levels**: Author brief, intermediate, and fully developed use case descriptions using standard 10-compartment templates. 2. **Formulate Rigorous Preconditions and Postconditions**: Specify exact database states required prior to execution and database updates guaranteed upon completion. 3. **Construct Detailed Activity Diagrams**: Translate textual flows of activities into actor-system swimlane activity diagrams. 4. **Develop UML System Sequence Diagrams (SSDs)**: Model system input events, parameters, return values, iteration loops, and conditional alternative branches. 5. **Execute CRUD Analysis**: Construct and evaluate a CRUD matrix to discover missing use cases and validate domain class coverage. 6. **Integrate Requirements Models**: Trace how use cases, activity diagrams, domain class diagrams, state machines, SSDs, and CRUD tables form a unified, coherent blueprint. --- ## 5.1 Detailed Use Case Modeling in Systems Analysis ### 5.1.1 Bridging High-Level Scope to Low-Level Design ```mermaid flowchart TD HighLevel["High-Level Scope (Ch 3 & 4) • Use Case Diagram (Functional Scope) • Domain Model Class Diagram (Data Scope)"] --> DetailedAnalysis["Detailed Use Case Modeling (Ch 5) • Fully Developed Use Case Descriptions • Detailed Activity Diagrams • System Sequence Diagrams (SSDs) • CRUD Cross-Check Matrix"] DetailedAnalysis --> LowLevelDesign["Technical Systems Design (Ch 6–14) • Database Schema & SQL Scripts • User Interface Screens & Dialogs • Multilayer Design Class Diagrams (DCD) • Three-Layer Software Sequence Diagrams"] ``` High-level analysis models answer *"What is the overall boundary of the system?"* Detailed use case modeling answers: - *What specific screens and fields does the actor see?* - *What parameters are transmitted over the network?* - *What error validations must execute?* - *What database records must be modified?* --- ### 5.1.2 The Three Complementary Detailed Models To completely document a use case, analysts combine three complementary models, each providing a distinct analytical viewpoint: ```mermaid flowchart LR UC["Use Case Under Analysis"] --> M1["1. Use Case Description (Textual Specification) Comprehensive tabular document detailing steps, rules, pre/post conditions, and errors"] UC --> M2["2. Activity Diagram (Graphical Workflow) Visual flowchart with swimlanes illustrating the sequence of actions and decisions"] UC --> M3["3. System Sequence Diagram (SSD) (Interaction Message Exchange) Visual model specifying exact data inputs and outputs passing into the black-box system"] ``` --- ## 5.2 Use Case Descriptions ### 5.2.1 Levels of Description Detail (Brief, Intermediate, Fully Developed) Not every use case requires an exhaustive, multi-page specification. Analysts calibrate description depth based on project risk, architectural complexity, and developer familiarity: | Detail Level | Format & Nature | When Best Applied | Real-World Example | |:---|:---|:---|:---| | **Brief Description** | 1 to 2 concise sentences summarizing the primary steps and outcome. | Simple, well-understood, low-risk CRUD use cases (e.g., standard lookup). | *"User enters customer ID; system retrieves and displays customer profile data."* | | **Intermediate Description** | Multi-paragraph or bulleted outline detailing actor actions and expected responses. | Moderately complex use cases with straightforward business rules. | Outlining the sequential steps of customer login and email preference updates. | | **Fully Developed Description** | Formal, 10-to-12 compartment engineering table capturing every operational nuance. | Core, complex, mission-critical, or high-risk use cases (e.g., checkout, shipping). | Complete engineering specification for `Create customer account` and `Ship items`. | --- ### 5.2.2 Anatomy of a Fully Developed Use Case Description A fully developed use case description utilizes a standardized template containing twelve critical compartments: ``` +--------------------------------------------------------------------------------+ | COMPONENTS OF A FULLY DEVELOPED USE CASE DESCRIPTION | +--------------------------------------------------------------------------------+ | 1. Use Case Name: Standard Verb-Noun identifier. | | 2. Scenario: Specific flow instance (e.g., Online vs. In-Store). | | 3. Triggering Event: The external, temporal, or state trigger. | | 4. Brief Description: Concise summary of the use case purpose. | | 5. Actors: Human roles, departments, or external systems. | | 6. Stakeholders: Parties with an operational/financial interest. | | 7. Preconditions: Mandatory system/database state BEFORE execution. | | 8. Postconditions: Guaranteed system/database state AFTER execution. | | 9. Flow of Activities: Two-column breakdown: Actor Steps vs. System Steps. | | 10. Exception Conditions: Explicit handling for errors, declines, and faults. | +--------------------------------------------------------------------------------+ ``` --- ### 5.2.3 Preconditions and Postconditions Two of the most critical compartments for software engineers and QA testers are the **Preconditions** and **Postconditions**: - **Preconditions**: - The precise conditions that **must be true** in the problem domain and the software database *before* the use case can begin execution. - If a precondition is not satisfied, the use case **cannot start**. - *Example*: In `Ship items`, the `Customer`, `Sale`, and `OrderItem` objects *must already exist* in the database. - **Postconditions**: - The precise conditions that **must be guaranteed to be true** in the database *after* the use case completes its normal flow of activities. - Specifies which objects were created, which attributes were updated, and which associations were established. - Serves as the primary validation criteria for Quality Assurance (QA) test cases. - *Example*: In `Ship items`, a `Shipment` record is created, `OrderItem` status is updated to "Shipped", and courier tracking numbers are stored. --- ### 5.2.4 Master Specification 1: Create Customer Account (Figure 5-2) The following formal specification details the `Create customer account` use case for RMO's online web portal: ``` ================================================================================ FULLY DEVELOPED USE CASE DESCRIPTION: CREATE CUSTOMER ACCOUNT ================================================================================ Use Case Name: Create customer account Scenario: Create online customer account Triggering Event: New prospective customer wishes to register an account online Brief Description: Online customer navigates to registration portal, enters personal identification, mailing address, billing preferences, and account credentials. System validates fields, creates database records, and sends verification email. Actors: Online Retail Customer Stakeholders: Customer Support, Marketing, Financial Accounting Preconditions: None. (Customer does not have an active registered account). Postconditions: • Customer object instance is created in database. • CustomerAccount record is created with assigned AccountNo. • Primary mailing Address object is linked to Customer. • Security credentials (hashed password) are stored. • Automated welcome verification email is transmitted. -------------------------------------------------------------------------------- FLOW OF ACTIVITIES: -------------------------------------------------------------------------------- ACTOR STEPS (CUSTOMER): SYSTEM RESPONSES: ----------------------- ----------------- 1. Customer accesses website and 1.1 System serves blank registration form clicks "Create Account" link. requesting personal and login data. 2. Customer enters name, phone, 2.1 System sanitizes input data. email address, and password. 2.2 System queries database to ensure email is not already registered. 2.3 System verifies password complexity. 3. Customer enters mailing address 3.1 System validates postal code and state and billing preferences. using automated address verification. 4. Customer submits registration. 4.1 System generates unique CustomerID. 4.2 System creates Customer, Account, and Address records in enterprise database. 4.3 System generates welcome session token. 4.4 System displays personalized welcome confirmation screen. 4.5 System dispatches verification email. -------------------------------------------------------------------------------- EXCEPTION CONDITIONS: -------------------------------------------------------------------------------- 2.2a Duplicate Email Address Detected: System alerts user that an account already exists with that email address. System provides direct links to "Log In" or "Reset Forgotten Password". 2.3a Password Fails Complexity Rules: System highlights password field, lists specific deficiencies (e.g., must contain 8+ characters, one uppercase, one number, one symbol), and prompts user to re-enter credentials. 3.1a Invalid Mailing Address / Postal Code: System alerts user that postal code does not match state/city, presents standardized postal format suggestions, and requests confirmation. ================================================================================ ``` --- ### 5.2.5 Master Specification 2: Ship Items (Figure 5-3) The following formal specification details the warehouse operational workflow for fulfilling and dispatching customer orders: ``` ================================================================================ FULLY DEVELOPED USE CASE DESCRIPTION: SHIP ITEMS ================================================================================ Use Case Name: Ship items Scenario: Ship new customer sale order from primary warehouse Triggering Event: Warehouse shipping clerk begins daily fulfillment cycle Brief Description: Shipping clerk selects open order, verifies physical packed items against pick list, assigns commercial courier, records shipped line items, handles backorders, prints shipping label, and transitions order status in database. Actors: Warehouse Shipping Clerk Stakeholders: Warehouse Operations, Inventory Management, Couriers, Customer Preconditions: • Customer and shipping address must exist. • Sale order must exist in 'Pending Fulfillment' state. • Sale line items (OrderItem instances) must exist. • Courier accounts (FedEx, UPS) must be configured and online. Postconditions: • Shipment record created with courier tracking ID. • Shipped OrderItem records updated to 'Shipped'. • Unfulfilled items updated to 'Backordered'. • Inventory physical stock levels decremented. • Order status updated to 'Shipped' or 'Partially Shipped'. • Shipping confirmation email sent to customer. -------------------------------------------------------------------------------- FLOW OF ACTIVITIES: -------------------------------------------------------------------------------- ACTOR STEPS (SHIPPING CLERK): SYSTEM RESPONSES: ----------------------------- ----------------- 1. Clerk requests next open order to 1.1 System queries database for oldest fulfill on warehouse tablet. pending sale order. 1.2 System displays order details, customer address, and required line items. 2. Clerk assigns courier carrier 2.1 System records assigned ShipperID. (e.g., FedEx Ground / UPS Air). 3. For each physical item boxed, 3.1 System matches scanned barcode to order. clerk scans item barcode into UI. 3.2 System records item as Shipped. 3.3 System flags inventory decrement event. 4. For unfulfillable/damaged items, 4.1 System updates item status to Backordered. clerk flags item as unavailable. 4.2 System initiates backorder record. 5. Clerk requests shipping label, 5.1 System communicates with courier API. submitting package dimensions 5.2 System records tracking number. and scale weight. 5.3 System prints courier barcode label and packing slip on dock printer. 5.4 System creates final Shipment record. 5.5 System dispatches tracking email. -------------------------------------------------------------------------------- EXCEPTION CONDITIONS: -------------------------------------------------------------------------------- 1.1a No Pending Orders Found: System informs clerk that all current orders are fulfilled; pauses queue. 3.1a Scanned Barcode Does Not Match Order: System sounds audio error chime, displays prominent warning that item is not on this customer's pick list, and prevents packaging progress. 5.1a Courier API Unreachable / Network Timeout: System queues shipping transaction in local offline spooler, flags order for delayed manifest synchronization, and prints temporary internal routing barcode to prevent warehouse bottleneck. ================================================================================ ``` --- ## 5.3 Activity Diagrams for Use Case Workflows ### 5.3.1 Role of Activity Diagrams in Detailed Modeling While the two-column table in the use case description provides clear textual steps, **Activity Diagrams** transform that workflow into an intuitive, visual representation. By utilizing **Swimlanes**, activity diagrams explicitly show the handoffs crossing the automation boundary between the human actor and the automated software system. --- ### 5.3.2 Activity Diagram: Create Customer Account (Figure 5-4) ```mermaid flowchart TD subgraph ActorLane ["Actor: Online Customer"] StartNode([● Start]) --> ClickRegister["Access website and click 'Create Account'"] EnterData["Enter personal data: Name, Phone, Email, Password"] EnterAddress["Enter physical mailing address and billing details"] SubmitForm["Click 'Complete Registration'"] ViewWelcome["View personalized welcome screen and read confirmation email"] EndNode([◉ End]) end subgraph SystemLane ["Automated Software System"] RenderForm["Display blank registration screen"] ValidateCredentials["Sanitize inputs Check database for duplicate email Verify password complexity rules"] ValidateAddress["Validate address format against postal database"] CreateRecords["Generate unique CustomerID Insert Customer, Account, and Address rows Generate security session token"] SendEmail["Transmit automated welcome & verification email"] end ClickRegister --> RenderForm RenderForm --> EnterData EnterData --> ValidateCredentials ValidateCredentials --> EnterAddress EnterAddress --> ValidateAddress ValidateAddress --> SubmitForm SubmitForm --> CreateRecords CreateRecords --> SendEmail SendEmail --> ViewWelcome ViewWelcome --> EndNode ``` --- ### 5.3.3 Activity Diagram: Ship Items (Figure 5-5) ```mermaid flowchart TD subgraph ClerkLane ["Warehouse Shipping Clerk"] StartShip([● Start]) --> RequestOrder["Request next open sale order to fulfill"] SelectShipper["Select courier service (FedEx / UPS / DHL)"] ItemLoop["For each item on pick list:"] ScanItem["Scan item barcode into terminal"] FlagBackorder["Flag item as unavailable / damaged"] NextItemCheck{"More items on pick list?"} ProvideDims["Enter package weight and box dimensions"] AffixLabel["Affix printed label to box and place on shipping pallet"] EndShip([◉ End]) end subgraph SystemLane ["Automated Warehouse System"] FindOrder["Retrieve next pending sale order Display line items and bin coordinates"] AssignCourier["Record ShipperID on shipment"] VerifyBarcode{"Barcode matches order item?"} MarkShipped["Record line item status = 'Shipped' Queue inventory decrement"] MarkBO["Record line item status = 'Backordered' Generate replenishment alert"] PrintDocs["Call Courier Web Service API Receive Tracking Number Print adhesive shipping label & packing slip Create Shipment record Send tracking email to customer"] end RequestOrder --> FindOrder FindOrder --> SelectShipper SelectShipper --> AssignCourier AssignCourier --> ItemLoop ItemLoop --> ScanItem ScanItem --> VerifyBarcode VerifyBarcode -- Match --> MarkShipped VerifyBarcode -- Out of Stock / Damage --> FlagBackorder FlagBackorder --> MarkBO MarkShipped --> NextItemCheck MarkBO --> NextItemCheck NextItemCheck -- Yes --> ItemLoop NextItemCheck -- No --> ProvideDims ProvideDims --> PrintDocs PrintDocs --> AffixLabel AffixLabel --> EndShip ``` --- ## 5.4 System Sequence Diagrams (SSDs) ### 5.4.1 What is a System Sequence Diagram? A **System Sequence Diagram (SSD)** is a UML interaction diagram that models the dynamic sequence of input data messages entering the system and output responses returning to an external actor during the execution of a use case. - **Scope**: An SSD documents **one specific use case** (or one scenario within a use case). - **Focus**: Defines the **functional interface** of the software application by specifying the exact input messages, method parameters, and returned data. --- ### 5.4.2 The System as a Black Box > [!IMPORTANT] > ### 💡 The Black Box Standard of System Sequence Diagrams > In Systems Analysis (Core Process 3), **the entire automated system is treated as a single monolithic "Black Box"**, modeled as the object `:System`. > - Analysts **do NOT show internal database tables**, internal software classes, or internal component-to-component calls in an SSD. > - The SSD depicts *only* what crosses the automation boundary between the external actor and the system boundary. > - *(Showing internal software classes like Controllers, Views, and Repositories is deferred to Systems Design in Chapters 12 and 13)*. --- ### 5.4.3 SSD Notation & Message Syntax (Figure 5-7) ```mermaid sequenceDiagram actor Actor as External Actor participant System as :System Note over Actor,System: System Sequence Diagram Standard Notation Actor->>+System: messageName(parameterList) Note right of System: System executes internal black-box processing System-->>-Actor: returnVariable := returnMessage(dataValues) ``` #### UML Message Syntax Breakdown A message is depicted as a horizontal arrow from the actor to the `:System` lifeline. The formal notation follows this syntax: $$st \; [ ext{true/false}] \;\; ext{response} := ext{messageName} ( ext{parameterList})$$ 1. **Asterisk (`*`)**: Indicates that the message repeats multiple times (iteration/loop). 2. **Condition Bracket (`[true/false]`)**: Guard predicate; the message is sent only if the condition is True. 3. **Response (`response :=`)**: Optional assignment variable capturing the return value. 4. **Message Name**: An action-oriented **Verb-Noun** phrase identifying the requested system service (written in camelCase, e.g., `createNewCustomer`, `recordShippedItem`). 5. **Parameter List**: Parenthesized list of specific input data arguments passed into the system (e.g., `(name, address, phone)`). 6. **Return Arrow (Dashed Line `--- >`)**: Represents output data returning to the actor. --- ### 5.4.4 Interaction Frames (Loop, Alt, Opt) (Figure 5-8) UML utilizes **interaction frames** (rectangles drawn around messages) to model complex logic: - **`loop [condition]`**: Repeats the enclosed messages for every item in a collection (e.g., `loop [for each line item]`). - **`alt [condition] / [else]`**: Alternative execution; models mutually exclusive `if-then-else` branches. - **`opt [condition]`**: Optional execution; fires only if an optional condition is met. --- ### 5.4.5 Four Steps to Develop an SSD from an Activity Diagram Developing an SSD is a systematic, mechanical translation from the swimlanes of an activity diagram: ```mermaid flowchart TD S1["Step 1: Identify all workflow arrows that cross the swimlane boundary from the Actor to the Automated System"] S2["Step 2: For each crossing arrow, formulate a descriptive input message name using Verb-Noun camelCase syntax (e.g., enterAddress)"] S3["Step 3: Define the exact parameter list containing all input data fields required by the system to process that step"] S4["Step 4: Model returned data using dashed return arrows, and wrap repetitive or conditional message sequences inside loop or alt frames"] S1 --> S2 --> S3 --> S4 ``` --- ### 5.4.6 Detailed Case 1: SSD for Create Customer Account (Figure 5-10) Derived directly from the activity diagram of Figure 5-4, three distinct input messages cross the automation boundary: ```mermaid sequenceDiagram autonumber actor Customer as Online Customer participant System as :System Customer->>+System: createNewCustomer(name, phone, email, password) System-->>-Customer: confirmationMsg, continueStatus Customer->>+System: enterAddress(street, city, state, postalCode, country) System-->>-Customer: validatedAddress, promptBilling Customer->>+System: submitRegistration(billingPreferences) System-->>-Customer: accountConfirmation(customerId, accountNo, statusMsg) ``` --- ### 5.4.7 Detailed Case 2: SSD for Ship Items (Figure 5-11) The SSD for the warehouse shipping workflow incorporates both a `loop` frame (repeating for each boxed item) and an `alt` frame (branching between shipped goods and backorders): ```mermaid sequenceDiagram autonumber actor Clerk as Shipping Clerk participant System as :System Clerk->>+System: getNextSale() System-->>-Clerk: saleDetails(saleId, customerName, address, lineItemsList) Clerk->>+System: setShipper(shipperId) System-->>-Clerk: shipperConfirmed rect rgb(245, 245, 245) note right of Clerk: loop [for each line item on pick list] alt item available and packed Clerk->>+System: recordShippedItem(barcodeId, quantity) System-->>-Clerk: itemShippedConfirmed else item damaged or out of stock Clerk->>+System: initiateBackorder(barcodeId, reasonCode) System-->>-Clerk: backorderRecorded end end Clerk->>+System: getShippingLabel(boxWeight, boxDimensions) System-->>-Clerk: shipmentComplete(trackingNumber, labelPrintedStatus) ``` --- ## 5.5 Validating Requirements with the CRUD Technique ### 5.5.1 The CRUD Concept (Create, Read, Update, Delete) **CRUD** is an industry-standard acronym representing the four fundamental lifecycle operations that an information system must support for any persistent data entity: - **C — Create**: The capability to insert, instantiate, and record new instances of a domain class into the database. - **R — Read / Report**: The capability to query, lookup, retrieve, search, and generate summarized reports from stored data. - **U — Update**: The capability to modify, edit, or adjust attribute values of existing records. - **D — Delete / Archive**: The capability to remove obsolete records or transition inactive records into long-term historical archives. --- ### 5.5.2 Cross-Checking Use Cases Against Domain Classes The **CRUD Technique** provides a rigorous cross-check between the **functional requirements (Use Cases from Chapter 3)** and the **structural data requirements (Domain Classes from Chapter 4)**. ```mermaid flowchart LR UseCases["Functional Use Cases (Chapter 3)"] <-->|CRUD Validation Cross-Check| Classes["Domain Model Classes (Chapter 4)"] ``` > [!IMPORTANT] > ### 💡 The CRUD Completeness Rule > In a complete and robust system specification, **every single domain class in the domain model must have at least one use case that performs Create (C), at least one use case that performs Read (R), at least one use case that performs Update (U), and at least one use case that handles Delete/Archive (D)**. > - If a class lacks a `Create` use case $\implies$ *Data can never enter the system!* > - If a class lacks a `Read` use case $\implies$ *Data is trapped forever, adding zero business value!* > - If a class lacks an `Update` use case $\implies$ *Errors and business changes can never be corrected!* > - If a class lacks a `Delete/Archive` use case $\implies$ *The database will bloat indefinitely with obsolete records!* --- ### 5.5.3 The Master CRUD Cross-Reference Matrix (Figure 5-13) The following comprehensive matrix maps RMO CSMS use cases against core domain classes. Each cell records whether the use case executes **C**reate, **R**ead, **U**pdate, or **D**elete: | CSMS Use Case Name | Customer | CustomerAccount | Sale | OrderItem | ProductItem | Shipment | Adjustment | |:---|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | **Create customer account** | **C** | **C** | | | | | | | **Look up customer** | **R** | **R** | | | | | | | **Update customer account** | **U** | **U** | | | | | | | **Archive customer (Delete)** | **D** | **D** | | | | | | | **Search for item** | | | | | **R** | | | | **Check out shopping cart** | **R** | **R** | **C** | **C** | **R / U** | | | | **Create phone sale** | **R** | **R** | **C** | **C** | **R / U** | | | | **Ship items** | **R** | | **R / U** | **U** | **U** | **C** | | | **Look up order status** | **R** | | **R** | **R** | | **R** | | | **Track shipment** | | | **R** | | | **R** | | | **Process account adjustment** | **R** | **U** | **R** | | | | **C** | | **Produce daily sales report** | | | **R** | **R** | | | **R** | #### Analytical Insights from the CRUD Table 1. **Validation Confirmation**: `Customer` has **C** (`Create customer account`), **R** (`Look up customer`), **U** (`Update customer account`), and **D** (`Archive customer`). It is 100% verified! 2. **Identification of Missing Functions**: Early drafts of RMO requirements lacked an `Archive customer` use case. The CRUD analysis immediately exposed this missing requirement, allowing analysts to specify it before design began. --- ### 5.5.4 Four-Step Procedure for CRUD Analysis ```mermaid flowchart TD Step1["Step 1: Identify all persistent domain classes from the Domain Model Class Diagram"] Step2["Step 2: List all identified use cases along the vertical axis of a matrix"] Step3["Step 3: For each use case, determine its exact data access role (C, R, U, D) for each class"] Step4["Step 4: Inspect each column. If any class lacks a C, R, U, or D, interview stakeholders to discover the missing use case or confirm if another system owns that responsibility"] Step1 --> Step2 --> Step3 --> Step4 ``` --- ## 5.6 Integrating Requirements Models (The Unified Picture) ### 5.6.1 Interdependence of Systems Analysis Models No single requirements model exists in a vacuum. Systems analysis is an interconnected discipline where **every model derives from or validates another model** (Figure 5-14): ```mermaid flowchart TD UCD["1. Use Case Diagram (Defines functional scope)"] --> UCDাescription["2. Use Case Description (Details flow of activities)"] UCDাescription --> AD["3. Activity Diagram (Visualizes swimlane workflows)"] AD --> SSD["4. System Sequence Diagram (SSD) (Defines input/output message signatures)"] DMCD["5. Domain Model Class Diagram (Defines business entities & data scope)"] --> StateMachine["6. State Machine Diagram (Models lifecycle states of complex classes)"] DMCD <-->|CRUD Cross-Validation| UCD SSD -.->|Parameters match class attributes| DMCD UCDাescription -.->|Pre/Post conditions reference classes| DMCD ``` --- ### 5.6.2 The Complete Requirements Architecture | Analysis Artifact | Core Question Answered | Primary UML Modeling Tool | Handed Off To | |:---|:---|:---|:---| | **Use Case Diagram** | *What functional services does the system provide to users?* | UML Use Case Diagram | Project Managers & Schedulers | | **Use Case Description** | *What exact business steps occur from start to finish?* | 10-Compartment Engineering Specification | QA Testers & Technical Authors | | **Activity Diagram** | *How does control and data flow between user and system?* | UML Activity Diagram (Swimlanes) | User Interface (UI/UX) Designers | | **System Sequence Diagram** | *What data parameters cross the automation boundary?* | UML System Sequence Diagram (`:System`) | Software Architects & API Developers | | **Domain Model Class Diagram** | *What data entities and associations must be stored?* | UML Class Diagram (Domain Model) | Database Administrators (DBAs) | | **State Machine Diagram** | *What lifecycle states govern complex business objects?* | UML State Machine Diagram | Business Logic Engineers | | **CRUD Matrix** | *Are all data classes fully created, read, updated, and purged?* | Cross-Reference Matrix | Lead Systems Analyst (Verification) | --- ## 5.7 Chapter Summary & Key Terminology Glossary ### Chapter Summary - **Detailed Use Case Modeling** bridges high-level requirements scope to low-level physical systems design. - **Use Case Descriptions** document the internal mechanics of a use case. **Fully developed descriptions** capture twelve distinct compartments, including **Preconditions** (mandatory starting state), **Postconditions** (guaranteed ending database state), **Flow of Activities**, and **Exception Conditions**. - **Activity Diagrams** visually model use case workflows, utilizing **Swimlanes** to clarify handoffs crossing the automation boundary between the actor and the system. - **System Sequence Diagrams (SSDs)** model the interaction between an actor and the automated system treated as a **Black Box (`:System`)**. SSDs formalize input message syntax (`* [condition] response := messageName(parameters)`), return messages, and frames (`loop`, `alt`, `opt`). - SSDs are systematically derived from activity diagrams in four steps: identifying crossing arrows, naming messages, formulating parameter lists, and modeling returns/frames. - The **CRUD Technique** (Create, Read, Update, Delete) cross-validates use cases against domain classes to ensure complete data lifecycle coverage. - All analysis models—Use Case Diagrams, Descriptions, Activity Diagrams, SSDs, Class Diagrams, State Machines, and the CRUD Matrix—integrate seamlessly to provide an exhaustive, unambiguous requirements specification. --- ### Key Terminology Glossary - **Activity Diagram**: A UML behavioral diagram illustrating the procedural workflow and decision logic of a use case using actor-system swimlanes. - **Black Box**: The analytical concept where the internal workings of the automated system are hidden from view during analysis, represented as a single `:System` lifeline. - **Brief Use Case Description**: A concise, one- or two-sentence description summarizing the main purpose and outcome of a use case. - **CRUD Technique**: An analytical validation technique (Create, Read, Update, Delete) that cross-checks functional use cases against domain classes. - **Exception Condition**: A formal branch in a use case description specifying how the system responds to validation errors, operational failures, or rejected transactions. - **Flow of Activities**: The step-by-step sequential breakdown of actor actions and corresponding system responses within a use case. - **Fully Developed Use Case Description**: The most comprehensive textual documentation of a use case, specifying twelve formal engineering compartments. - **Interaction Frame**: A UML sequence diagram construct (e.g., `loop`, `alt`, `opt`) enclosing message sequences to model iteration and conditional logic. - **Lifeline**: The vertical dashed line beneath an actor or object in a sequence diagram representing its existence over time. - **Postconditions**: The mandatory states and database record conditions that must be established and guaranteed upon completion of a use case. - **Preconditions**: The mandatory states and database records that must already exist in the system before a use case can commence execution. - **Scenario**: A unique, specific execution pathway or instance through a use case (e.g., online checkout vs. telephone order checkout). - **System Sequence Diagram (SSD)**: A UML interaction diagram that depicts the chronological sequence of input data messages and output responses crossing the automation boundary between an external actor and the `:System` black box.