Note51

0.0 by Claude

5 min read

Chapter 3: Requirement Capture - Use Case

1.0 Modelling Concepts

1.1 Models vs Diagrams

Models

  • Provide a complete view of a system at a particular stage and perspective
  • Used to represent something (real or imaginary)
  • Reasons for using models:
    • Quicker and easier to build
    • Can be used in simulations
    • Can evolve as we learn
    • Represent things from any domain

Diagrams

  • Illustrate or document some aspect of a system
  • Use abstract shapes to represent real-world things/actions
  • Follow Object Management Group (OMG) standards
  • Reasons for using diagrams:
    • Communicate ideas
    • Generate new ideas and possibilities
    • Test ideas and make predictions
    • Understand structures and relationships

1.2 Types of Models in System Development

Requirements Model

  • Complete view of requirements
  • May include Use Case diagrams and Class diagrams
  • Includes textual descriptions plus diagram sets

Behavioural Model

  • Shows how system responds to external events and time passage
  • Initial model may use Communication Diagrams
  • Includes:
    • Collaboration diagrams
    • Sequence diagrams
    • State chart diagrams

1.3 UML (Unified Modeling Language)

UML consists of graphical language to represent concepts in object-oriented information system development.

UML 2.x supports 9 diagram types:

  1. Use case diagram
  2. Activity diagram
  3. Sequence diagram
  4. Collaboration diagram
  5. Class diagram
  6. Object diagram
  7. State chart diagram
  8. Component diagram
  9. Deployment diagram

2.0 Current Systems vs Required Systems

2.1 Requirements Definition

Requirements = A condition or capability that must be met by a system to satisfy a contract, standard, or specification

2.2 Current Systems Analysis

Purpose of understanding current systems:

  • Understand how existing system works
  • Ensure shortcomings/defects aren’t carried to new system
  • Identify new system functional and non-functional requirements

Information gathering methods:

  • Observations
  • JAD (Joint Application Development)
  • Document analysis

2.3 Classification of Requirements

Functional Requirements

  • Describe what a system should do
  • Specify system functions including:
    • Processing
    • Interfaces (I/O)
    • Reports
    • Data storage
  • Documented in: Use Case Diagrams, Class Diagrams, Interaction Diagrams, State Chart Diagrams

Non-Functional Requirements

  • Describe system characteristics not related to functionality
  • Define how well the system provides functional requirements
  • Categories:
    • Operational: Physical/technical environments
    • Performance: Speed, capacity, reliability
    • Security: Access control and authorization
    • Cultural/Political: Legal requirements and policies

Usability Requirements

  • Match system to how people work
  • Include:
    • User characteristics
    • User tasks
    • Situational factors
    • Acceptance criteria
  • Focus on Human-Computer Interaction (HCI)

3.0 Use Case Diagrams

3.1 Purpose of Use Case Diagrams

  • Document system functionality from users’ perspective
  • Document system scope
  • Supported by use case descriptions documenting user-system interaction

3.2 Types of Use Cases

Overview Use Case

  • Used for high-level requirements agreement
  • Less detailed

Detail Use Cases

  • Document all detailed information needed
  • More comprehensive

3.3 Use Case Development Process

Iteration 1

  • Identify obvious use cases
  • Create simple use case descriptions

Iteration 2

  • Add additional use cases
  • Maintain simple descriptions
  • Develop prototypes

Iteration 3

  • Structure use cases
  • Create structured descriptions
  • Refine prototypes

4.0 Use Case Diagram Notation

4.1 Actors

Primary Actor

  • Has goals fulfilled through system services
  • Notation: Stick figure with name
  • One actor may represent multiple people

Supporting Actor

  • Provides service/information to system
  • Often a computer system, organization, or person
  • Notation: Rectangle with <<actor>> stereotype

4.2 Use Cases

  • Notation: Oval/ellipse with name inside
  • Naming convention: Active verb + noun phrase
  • Represent sequence of actions providing value to actor
  • Should be prioritized based on:
    • Business process importance
    • Revenue generation support
    • Cost reduction potential
    • Technology risk/novelty

4.3 Relationships

Communication Associations

  • Lines between actors and use cases
  • Arrow shows communication initiator (points away from initiator)
  • Represents communication link between instances

Include Relationship <<include>>

  • One use case always includes another’s functionality
  • Can separate common sequences used in many use cases
  • Base use case is incomplete without included use case
  • Included use case is required

Extend Relationship <<extend>>

  • Provides optional/additional functionality
  • Base use case is complete by itself
  • Extending use case is optional/supplementary
  • Extension points show where extension occurs
  • Can have conditions for extension

Generalization

  • Shows inheritance between use cases or actors
  • Child inherits from parent and may override behavior
  • Base use case can be abstract (incomplete) or concrete (complete)
  • Specialized use case required if base is abstract

4.4 System Boundary

  • Rectangle around related use cases
  • Shows sub-system grouping
  • In CASE tools, often redundant as use cases are in separate diagrams

5.0 Use Case Descriptions/Specifications

5.1 Key Principles

A use case must:

  • Deliver value to an actor
  • Represent major functionality complete from beginning to end
  • Represent the goal of actor-system interaction
  • Be a meaningful and measurable objective

5.2 Use Case Description Format

Essential Components:

  1. Name of use case
  2. Brief description
  3. Actors (primary and supporting)
  4. Preconditions (optional) - conditions before use case starts
  5. Main flow of events
    • Actor actions
    • System responses
  6. Alternative flows (exceptions/variations)
  7. Postconditions (optional) - conditions after completion

5.3 Main Flow Formats

Option 1: Simple Paragraph

  • Narrative description of interaction

Option 2: Two-Column Table

  • Actor Action | System Response
  • Step-by-step breakdown
  • Numbered steps for clarity

6.0 Drawing Use Case Diagrams - Process

  1. Identify actors and use cases
  2. Prioritize use cases based on business value
  3. Develop each use case starting with high-priority ones
  4. Add structure using relationships:
    • Generalization
    • Include relationships
    • Extend relationships
    • Sub-systems

7.0 Prototyping

7.1 Purpose of Prototyping

  • Working model of system part
  • Program with limited functionality
  • Tests how system will work
  • Supports use case modeling

7.2 Uses of Prototypes

  • Elicit requirements from users
  • Test system architectures against non-functional requirements
  • UI prototypes can use different languages than final system

7.3 Prototyping Tools

  • Visual Studio
  • PowerPoint
  • HTML
  • Word processors

8.0 Summary - Key Exam Points

Important Concepts to Remember:

  1. Use Case Diagram = View of Use Case Model in Requirements Model
  2. Two types of use cases: Overview and Detail
  3. Three requirement types: Functional, Non-functional, Usability
  4. Two actor types: Primary (users) and Supporting (systems/services)
  5. Three main relationships:
    • Include (required functionality)
    • Extend (optional functionality)
    • Generalization (inheritance)

Common Mistakes to Avoid:

  • Don’t define use cases at too low level (single steps)
  • Don’t use Include to create hierarchical decomposition
  • Remember: Extend = optional, Include = required
  • System boundary is rectangle, not oval
  • Use case names should be verb + noun

Use Case Description Must-Haves:

  • Actor identification
  • Clear main flow
  • Alternative scenarios
  • Pre/post conditions where relevant
  • Value delivery to actor

Graph View

Backlinks