Defining & Managing Requirements with Use Cases

Requirements Fundamentals

Requirement

A capability or condition that a system must meet to satisfy a contract, standard, specification, or stakeholder need. Requirements are the foundation for building software that users actually want to use.

Why Requirements Matter

Requirements are the foundation of any software project. How well they are defined is the key to building the right system; poor requirements are a leading cause of project failure, rework, and dissatisfied users.

Defining the Right Problem

Before specifying a solution, analysts must understand the real business problem, its stakeholders, and its context — solving the wrong problem well still results in a failed system.

Functional Requirements

Statements of what the system must do — its behaviors, services, and features. In a use-case approach, most functional requirements are captured within use cases.

Non-Functional Requirements

Quality attributes and constraints such as performance, security, usability, reliability, and compliance. These 'non-use-case' requirements are often captured in a Supplementary Specification.

Types / Levels of Requirements

Requirements exist at different levels — business needs, user/stakeholder needs, features, and detailed software requirements — and use cases sit primarily at the user-goal level connecting needs to system behavior.

Stakeholder

Anyone materially affected by the system's outcome — users, customers, sponsors, regulators, operators. Identifying stakeholders is essential to eliciting complete and correct requirements.

Elicitation

Requirements Elicitation

The activity of discovering requirements from stakeholders and other sources. It is active discovery, not passive collection, because stakeholders often cannot fully articulate what they need.

Elicitation Techniques

Methods for gathering requirements including interviews, workshops (JAD), brainstorming, observation, questionnaires, prototyping, and reviewing existing systems and documents.

Interviews

One-on-one or small-group conversations to gather needs and context. Effective interviews use prepared open and closed questions and active listening to surface tacit knowledge.

Requirements Workshops

Facilitated group sessions (such as JAD) that bring stakeholders together to elicit and agree on requirements quickly, building shared understanding and reducing later conflict.

Prototyping

Building a partial or throwaway model of the system to elicit feedback, clarify ambiguous requirements, and validate understanding before full development.

Use Case Modeling

Use Case

A description of a sequence of interactions between actors and the system that delivers an observable result of value to a particular actor. It captures functional requirements in the language of users' goals.

Actor

Someone or something outside the system that interacts with it to achieve a goal — a user role, another system, or a device. Actors represent roles, not specific individuals.

Primary vs. Secondary Actor

The primary actor initiates a use case to achieve a goal; a secondary (supporting) actor provides a service to the system during the use case, such as an external system.

Use Case Model

A model consisting of actors, use cases, and their relationships, plus a diagram and supporting text. It defines the system's functional scope and the value it provides to each actor.

Use Case Diagram

A UML diagram showing actors, use cases, and their associations, providing a quick visual overview of system scope and who interacts with which functions.

Identifying Use Cases

Finding use cases by asking what goals each actor wants to accomplish with the system. Each user goal that yields observable value is a candidate use case.

Writing Use Cases

Use Case Specification

The detailed text of a use case, typically including name, brief description, actors, preconditions, postconditions, basic flow, alternate flows, and special requirements.

Basic Flow (Main Success Scenario)

The primary, most common path through a use case in which everything goes as expected and the primary actor achieves their goal. It tells the 'happy path' story step by step.

Alternate Flows

Variations and exceptions to the basic flow — handling errors, optional behavior, and less common paths — that ensure the use case covers the full range of system behavior.

Preconditions

Conditions that must be true before a use case can begin, such as the actor being authenticated. They define the starting state assumed by the flow.

Postconditions

Conditions guaranteed to be true after the use case completes (success or failure), describing the resulting state of the system and clarifying the outcome.

Scenario

A specific, single path through a use case — one instance of execution. The basic flow plus a chosen set of alternate flows constitutes a particular scenario.

Use Case Levels (Goal Level)

Use cases can be written at different altitudes — summary, user-goal (sea level), and subfunction. User-goal level is the sweet spot, describing what an actor accomplishes in one sitting.

Use Case Relationships

Include Relationship

A relationship where a use case explicitly incorporates the behavior of another (common) use case, factoring out shared steps to avoid duplication (e.g., 'Validate User').

Extend Relationship

A relationship where optional or conditional behavior in one use case extends a base use case at defined extension points, without the base use case needing to know about the extension.

Generalization

An inheritance-like relationship where a specialized actor or use case inherits and refines the behavior of a more general one, used sparingly to keep models clear.

Supplementary Requirements

Supplementary Specification

A document capturing requirements that don't fit naturally in use cases — non-functional requirements, design constraints, and system-wide quality attributes (often organized using FURPS+).

FURPS+

A model for classifying requirements: Functionality, Usability, Reliability, Performance, Supportability, plus design, implementation, interface, and physical constraints (the '+').

Vision Document

A high-level artifact capturing the problem, stakeholders, key features, and goals of the system, providing the context within which detailed requirements and use cases are developed.

Managing Requirements

Requirements Management

The systematic approach to eliciting, organizing, documenting, and controlling changes to requirements throughout the project, keeping the team aligned to current, agreed needs.

Scope Management

Defining and controlling what is and isn't included in the system. Clear use-case scope helps prevent scope creep and supports prioritization and release planning.

Traceability

Linking requirements forward and backward — from business needs to use cases to design, code, and tests — so the impact of a change can be assessed and coverage verified.

Managing Changing Requirements

Establishing a baseline and a change-control process so requirement changes are evaluated for impact, approved, and traced, rather than allowed to drift uncontrolled.

Prioritizing Requirements

Ranking requirements by value, risk, and cost so the most important capabilities are addressed first, supporting incremental delivery and informed scope trade-offs.

Quality

Characteristics of Good Requirements

Good requirements are clear, complete, consistent, correct, verifiable, feasible, necessary, and unambiguous. Use cases improve clarity by framing requirements as concrete user interactions.