3 - Use Case Scenarios and Requirements Gathering — Topics & Learning Outcomes

Module Topics

Introduction to Use Case Scenarios

• What Is a Use Case Scenario? — A Use Case Scenario is a narrative description of how a user interacts with a system to achieve a specific goal. It captures the sequence of steps, decisions, and outcomes involved in a single interaction path.
• Role of Use Cases in Requirements Gathering — Use cases serve as a primary vehicle for eliciting and documenting software requirements by grounding abstract needs in real user behavior. They ensure that requirements reflect actual usage rather than assumed functionality.
• Key Components of a Use Case — A well-formed use case includes a title, actor, preconditions, main success scenario, alternative flows, and postconditions. Each component ensures the scenario is complete and unambiguous.
• Use Cases vs. User Stories — Use cases and user stories are both tools for capturing requirements, but they differ in scope, format, and level of detail. Understanding the distinction helps teams choose the right tool for their methodology.

Identifying Stakeholders and Users

• Defining Stakeholders — Stakeholders are any individuals, groups, or organizations that have an interest in or are affected by the software system. Identifying all stakeholders early prevents overlooked requirements later in the project.
• Distinguishing Users from Stakeholders — While all users are stakeholders, not all stakeholders are users. Users are the actors who directly interact with the system interface, whereas other stakeholders may only experience its effects.
• Stakeholder Needs vs. User Goals — Stakeholder needs describe the broader business or organizational outcomes desired from the system, while user goals describe what individual users want to accomplish in a specific interaction. Both must be captured and reconciled.
• User Roles and Permissions — Different user roles often require different levels of access and capability within the same system. Mapping roles to use cases ensures the interface and security model reflect real-world responsibilities.
• Techniques for Stakeholder Identification — Several structured techniques help analysts systematically identify all relevant stakeholders and user roles. Using multiple techniques reduces the risk of omitting important participants.

Requirements Gathering Techniques

• Overview of Requirements Elicitation — Requirements elicitation is the process of discovering, extracting, and articulating what a system must do by engaging with stakeholders and users. Choosing the right elicitation technique for each context improves the quality and completeness of requirements.
• Interviews and Contextual Inquiry — Interviews allow analysts to engage directly with stakeholders to uncover goals, workflows, pain points, and constraints. Contextual inquiry extends this by observing users in their actual work environment.
• Workshops and Focus Groups — Collaborative sessions bring multiple stakeholders together to align on requirements, resolve conflicts, and generate use case ideas collectively. Facilitated workshops are especially effective for complex systems with diverse user groups.
• Surveys and Questionnaires — Surveys allow analysts to gather input from large numbers of stakeholders or users quickly and cost-effectively. They are best suited for validating assumptions or gathering quantitative data about usage patterns.
• Document Analysis and Existing System Review — Reviewing existing documentation, legacy systems, and process manuals provides a baseline of current functionality and workflows. This technique is especially valuable when modernizing or replacing an existing system.

Task Analysis

• What Is Task Analysis? — Task analysis is a technique for understanding how users accomplish goals by breaking their work into discrete, observable steps and decisions. It provides the behavioral foundation for writing realistic use case scenarios.
• Hierarchical Task Analysis (HTA) — Hierarchical Task Analysis decomposes a high-level goal into sub-tasks and further into individual actions, creating a tree structure that maps the full scope of a user's work. HTA is one of the most widely used task analysis methods in requirements engineering.
• Cognitive Task Analysis — Cognitive Task Analysis (CTA) focuses on the knowledge, decisions, and mental processes involved in performing a task, rather than just the observable actions. It is essential for tasks that require expertise, judgment, or complex problem-solving.
• Mapping Task Analysis to Use Cases — The outputs of task analysis feed directly into use case writing by providing the step sequences, decision points, and alternative paths that define each scenario. This mapping ensures use cases reflect real user behavior rather than assumed workflows.
• Validating Task Models with Users — Task models must be verified with actual users to ensure they accurately reflect real work practice rather than idealized or assumed behavior. Validation prevents use cases from being built on incorrect assumptions.

Writing Use Case Scenarios

• Structuring a Use Case Document — A Use Case document follows a consistent template that ensures every scenario is described with the same level of rigor and detail. Consistent structure makes use cases easier to review, trace, and maintain.
• Writing the Main Success Scenario — The main success scenario describes the ideal interaction path where everything goes as expected and the user achieves their goal without errors or exceptions. It is written as a numbered sequence of actor and system actions.
• Documenting Alternative Flows — Alternative flows describe valid variations from the main path that still result in the user achieving their goal or a defined outcome. They capture the realistic diversity of how users interact with a system.
• Documenting Exception Flows — Exception flows capture what happens when an error, system failure, or invalid input interrupts the normal interaction. They ensure the system handles failure states gracefully and the interface provides appropriate feedback.
• Specifying Preconditions and Postconditions — Preconditions define the state the system and user must be in before the use case can begin, while postconditions define the guaranteed state after the scenario completes successfully. Together they define the boundary conditions for each scenario.
• Writing Clear and Unambiguous Steps — Each step in a use case must be written precisely enough to be unambiguous to all readers, including developers, testers, and non-technical stakeholders. Ambiguity in step descriptions is a direct source of requirement defects.

Enumerating Usage Paths and Edge Cases

• What Are Edge Cases? — Edge cases are scenarios that occur at the boundary of normal operating conditions, involving unusual inputs, extreme values, or rare but valid user behaviors. Failing to account for edge cases is a frequent source of system defects and poor user experience.
• Techniques for Enumerating Usage Paths — Systematic enumeration of usage paths ensures that requirements coverage is complete rather than representative. Several structured techniques help analysts move beyond obvious scenarios to discover the full interaction space.
• User Diversity and Context Variation — Users differ in experience level, accessibility needs, device capabilities, and operating environments, all of which create distinct interaction paths. Designing for diverse users requires explicitly documenting how these differences affect use case flows.
• Documenting Frequency and Priority — Not all use cases are equally important or frequent, and documenting their relative frequency and business priority helps teams focus design and development effort appropriately. Priority ratings also guide testing and risk management.
• Reviewing for Completeness — A structured review process is needed to confirm that the complete use case set covers all identified actors, goals, tasks, and interaction contexts without redundancy or gaps. Completeness reviews should involve multiple stakeholders.

Documenting and Communicating Requirements

• Organizing a Use Case Repository — A use case repository organizes all scenarios in a structured, searchable, and version-controlled format that supports ongoing project work. Effective organization ensures that use cases remain a living reference rather than a static document.
• Traceability Between Requirements and Use Cases — Traceability links use cases to the stakeholder needs, system requirements, design decisions, and test cases they relate to. Maintaining traceability ensures that every requirement is implemented and tested.
• Communicating Use Cases to Stakeholders — Use cases must be presented in a format accessible to the intended audience, which varies from technical developers to non-technical business stakeholders. Tailoring communication style and detail level improves stakeholder engagement and review quality.
• Maintaining Use Cases Through Change — Requirements evolve throughout a project, and use cases must be updated to reflect approved changes in a timely and controlled manner. A change management process prevents use cases from becoming outdated or contradictory.
• Use Cases as Input to Design and Testing — Use case scenarios are a primary input for interface design, providing designers with the task flows and interaction contexts needed to create relevant prototypes and wireframes. They also serve as the basis for acceptance test case development.

Student Learning Outcomes

By the end of this module, students will be able to:

Course Outcomes (reference)