Use Cases in Requirements Engineering: A Practical Guide with Real-World Examples

When developing a new product or improving an existing process, engineers need to understand more than what the product is expected to do. They must also understand how people interact with it, how it responds to different situations, and what should happen when something goes wrong.

A manufacturing machine may need to stop when a quality check fails. A medical device may need to respond appropriately to an abnormal operating condition. An automotive system may need to assist a driver under specific conditions while remaining within its defined operating limits.

These situations have something in common: they describe interactions between an actor and a system to achieve a goal under defined conditions.

Use cases provide a structured way to capture such interactions. Although frequently associated with software development, they can also help engineers analyze physical products, integrated systems, and manufacturing operations.

This guide explains how use cases fit into requirements engineering, how to develop them, and how to connect them to requirements, traceability, and verification.

What Is a Use Case?

A use case describes how an actor interacts with a system to achieve a specific goal. It captures the sequence of interactions, the conditions under which they occur, and the expected outcome.

An actor is an external entity that interacts with the system under consideration. It may be a person, another system, a machine, or an external organization.

For example, consider a manufacturing station that assembles a mechanical component. A production operator initiates the cycle, the station performs the required operations, and an inspection system evaluates the completed component.

The use case might be called Produce and Inspect Component. It describes the interaction from the initiation of production through successful inspection or the handling of a problem that prevents acceptance.

A use case focuses on the goal and the interactions required to achieve it. It does not necessarily contain every technical detail. Performance limits, material properties, interface specifications, and safety constraints may need to be documented separately as requirements.

Why Are Use Cases Important in Requirements Engineering?

Requirements engineering involves understanding stakeholder needs, defining system requirements, analyzing interactions, and establishing a basis for verification and validation. Use cases contribute to this work in several ways.

1. Clarifying operational expectations

A requirement may state that a machine must produce a component. A use case explains how an operator starts the production cycle, how the machine proceeds through the operation, and what happens when required conditions are not satisfied. This context helps stakeholders identify missing assumptions and clarify expected behavior.

2. Identifying missing scenarios

Engineering teams often understand normal operation but overlook less frequent conditions. Use cases encourage questions such as:

• What happens when a required input is invalid?
• What if a resource is unavailable?
• How should the system respond when an operation is interrupted?
• What conditions must be satisfied before the operation can resume?
• What must remain true after an unsuccessful operation?

These questions are especially important when safety, product quality, or transaction integrity is involved.

3. Improving cross-functional communication

A complex product may involve mechanical, electrical, electronic, software, manufacturing, and quality engineering teams. A shared description of system interactions helps these teams understand how their responsibilities contribute to an overall operational goal.

4. Supporting verification and validation

Use cases help identify scenarios that should be evaluated during verification and validation. The normal flow may lead to functional tests, while alternative paths and exceptional conditions can reveal additional test scenarios.

However, a use case alone does not demonstrate that a product meets its requirements. Measurable acceptance criteria, test procedures, inspections, analysis, and other verification evidence may still be necessary.

The Main Components of a Use Case

The appropriate level of detail depends on the system’s complexity, risk, and development process. The following components provide a practical starting point. Organizations may adapt the template to their lifecycle and documentation standards.

Use case name

The name describes the goal the actor wants to achieve. Examples include Start Production Cycle, Administer Infusion, Configure Vehicle Parking Assistance, and Submit Insurance Claim. Prefer a clear, goal-oriented name over a vague label such as “System Processing.”

System boundary

Identify the system being described. The boundary determines what is inside the system under consideration and what is external to it. This distinction is important because an actor is external to the system boundary, even when that actor is another machine or software application.

Actor

The actor initiates or participates in the interaction. A use case may have a primary actor whose goal is being served and supporting actors or external systems that participate in the interaction.

Preconditions

Preconditions describe what must be true before the use case begins. For a production cycle, these might include the availability of required materials, completion of machine setup, and approval of the production configuration.

Preconditions should not hide behavior that the system itself must perform. If the machine must check its readiness before starting, that check belongs in the interaction flow.

Trigger

The trigger identifies the event that starts the interaction. For example, the production operator selects an approved production cycle and requests that it begin.

Main success flow

The main success flow describes the expected sequence when the operation proceeds normally. Each step should identify an actor action, a system response, or a meaningful interaction between them.

Alternative flows and exceptional conditions

Alternative flows describe variations in the interaction. Some may still achieve the goal, while others may describe an unsuccessful outcome. Exceptional conditions include errors, equipment faults, unavailable resources, and other situations that interrupt normal progress.

The terminology and document structure vary across organizations. A separate section called “Exception Flow” is not mandatory in every use case method.

Postconditions

Postconditions describe the expected state after the use case completes. Define the outcome for success and, where relevant, for failure or cancellation. For an unsuccessful production cycle, for example, the component may need to be identified as nonconforming and prevented from being released as an accepted product.

Practical Example: A Manufacturing Production Cycle

Hypothetical scenario: A manufacturing facility produces a mechanical component using an automated assembly station. The objective is to assemble the component, inspect its required characteristics, and release it for the next production stage if it meets the applicable acceptance criteria.

Define the system boundary first

For this example, the Automated Assembly Station is the system under consideration. The production operator and the separate Quality Inspection System are external actors. The inspection system provides a result to the assembly station or its production-control interface. In a real project, the boundary should reflect the actual architecture and allocation of responsibilities.

Use case specification

Main success flow

1. Operator: Selects the approved production configuration.
2. Assembly station: Checks whether the required operating conditions are satisfied.
3. Assembly station: Confirms that the required material identification and configuration are valid, where those checks are within its allocated responsibility.
4. Operator: Confirms that the required material is loaded and initiates the production cycle.
5. Assembly station: Performs the defined assembly operations.
6. Assembly station: Records the relevant production data.
7. Assembly station: Presents the completed component for inspection.
8. Quality Inspection System: Evaluates the specified characteristics against the applicable acceptance criteria.
9. Quality Inspection System: Returns a passing inspection result.
10. Assembly station: Records the result and identifies the component as accepted for the next production stage.

Alternative and exceptional scenarios

Scenario A – Required material is unavailable (branches from main flow Step 3)

1. The assembly station detects that the required material is unavailable or cannot be verified.
2. The station prevents the production cycle from starting.
3. The station provides an indication identifying the missing or unverified material.
4. The operator supplies or corrects the material condition.
5. The station repeats the applicable readiness checks. Production may proceed only when the required conditions are satisfied.

Scenario B – Inspection failure (branches from main flow Step 8)

1. The inspection system evaluates the component.
2. One or more characteristics fail to meet the applicable acceptance criteria.
3. The inspection system returns a failed result with the relevant failure information.
4. The assembly station records the result and prevents the component from being released as accepted.
5. The component follows the applicable nonconformance procedure.

What does this use case reveal?

The scenario identifies behaviors that might otherwise remain implicit:

• The station must verify required operating conditions before starting.
• The system must prevent production when mandatory material is unavailable or cannot be verified.
• The inspection process must evaluate defined characteristics against approved acceptance criteria.
• A failed inspection must not result in the component being released as accepted.
• Relevant production and inspection records must be maintained.

These behaviors can be refined into individual, verifiable requirements. The use case does not define the actual dimensional tolerances, material properties, or inspection measurement accuracy. Those belong in the appropriate product, process, or inspection specifications.

How to Write Effective Use Cases

Step 1: Identify the actor and goal

Determine who or what interacts with the system and what outcome they want to achieve. For example, a production operator wants to produce an accepted component. Focus the use case on that goal rather than attempting to document the entire factory operation.

Step 2: Define the system boundary

Establish which product, machine, subsystem, or process is being described. In a manufacturing environment, the boundary may include the assembly station but exclude the enterprise resource planning system. In an automotive project, it may be a single vehicle function or a larger integrated system. A clear boundary helps assign responsibilities and identify external dependencies.

Step 3: Establish preconditions and triggers

Document what must be true before the interaction begins and what event initiates it. Separate conditions that are assumed to exist from checks the system must perform.

Step 4: Describe the main flow

Write the expected interaction in chronological order. Identify the responsible actor or system for each step. Each step should be clear enough that stakeholders can understand the intended behavior without guessing what the system does.

Step 5: Identify alternative and exceptional scenarios

Examine important decisions, resource dependencies, operating limits, and failure conditions. Depending on the engineering domain, these may include invalid inputs, unavailable resources, equipment faults, environmental conditions, or interrupted operations. Prioritize scenarios based on their relevance to the system’s goals, risks, and operating context.

Step 6: Define expected outcomes

Describe the state of the system after successful completion, cancellation, or failure. Include the required disposition of affected products, records, or operational states where applicable.

Step 7: Derive and link requirements

Identify the detailed requirements needed to support each important behavior. Link the relevant use case and flow steps to those requirements, and identify suitable verification methods. This helps reveal missing requirements, unverified behavior, and unnecessary duplication.

Step 8: Review with relevant stakeholders

Involve people who understand the operational process, product design, quality expectations, safety constraints, and system interfaces. A use case should reflect the intended operation and agreed requirements, not merely the assumptions of its author.

Use Cases, Product Requirements, and Process Requirements

These concepts are related, but they should not be treated as interchangeable.

Use cases

Use cases describe interactions and operational scenarios. Example: An operator initiates a production cycle, the machine assembles a component, and the inspection system determines whether the component meets the acceptance criteria.

Product or system requirements

Product or system requirements specify the capabilities, characteristics, constraints, and performance expected of a product or system. Example: The assembly station shall apply a specified fastening torque within an approved tolerance range.

Process requirements

Process requirements specify conditions or controls governing how an activity must be performed. Example: Each completed component shall undergo the defined inspection before it is released to the next production stage.

Actual requirements must identify applicable values, tolerances, methods, and conditions where needed. A use case can establish the context for these requirements, but it should not replace them.

In practice, stakeholder needs may lead to both use cases and initial requirements. A use case can expose missing behavior and help refine requirements. Requirements can also constrain or clarify a use case. The resulting requirements are allocated to design elements and connected to appropriate verification methods and evidence.

The exact structure varies by engineering discipline and lifecycle model. The essential point is to maintain clear relationships between stakeholder goals, required system behavior, detailed specifications, and verification evidence.

How Use Cases Support Traceability and Verification

Use cases become more valuable when their relationships with other engineering artifacts are maintained. Consider the manufacturing example. The use case identifies the production sequence and the response to an inspection failure. From this, the team may identify requirements for machine readiness, material verification, inspection acceptance, and nonconforming-product handling.

The following simplified example shows how a behavior can be traced from a use case to a requirement and a test case. The IDs and statements are illustrative; a real project should use approved, measurable requirement values and project-specific verification procedures.

A broader traceability structure may look like this:

Stakeholder Need ↔ Use Case / Scenario ↔ System or Product Requirement ↔ Design Element ↔ Test Case ↔ Test Result / Verification Evidence

The relationships are not necessarily one-to-one. One use case may relate to several requirements, and one requirement may support multiple use cases. A requirement may also need more than one verification activity. The traceability model should reflect those relationships rather than forcing every artifact into a simple chain.

Traceability enables teams to assess whether requirements are addressed by the design and whether specified behavior has been verified. It also supports change impact analysis. If a production acceptance criterion changes, the team can identify affected requirements, use case scenarios, inspection procedures, and related evidence.

For a broader discussion, read Requirements Traceability: A Practical Guide with Real-World Examples.

Common Mistakes When Writing Use Cases

• Focusing only on normal operation: Important alternative paths and failure conditions may remain undocumented.
• Mixing goals with implementation details: A use case should describe the interaction and expected behavior. Detailed design decisions should be documented separately unless they are required constraints.
• Writing vague steps: Statements such as “The machine processes the component” provide little guidance unless the expected operation and outcome are clear.
• Ignoring system boundaries: Unclear boundaries make it difficult to determine which subsystem or external actor is responsible for a behavior.
• Treating a use case as a complete requirements specification: Performance limits, tolerances, material properties, safety constraints, and inspection criteria may need separate requirements.
• Duplicating the same rule across multiple artifacts: Repeated statements can become inconsistent when requirements change. Use clear references and traceability relationships wherever practical.
• Failing to connect behavior to verification: If an important outcome cannot be evaluated against defined criteria, the team may need to clarify the requirement or establish a suitable verification method.

When Should You Use Use Cases?

Use cases are especially useful when a system involves meaningful interactions, multiple operational steps, alternative outcomes, or dependencies on external actors. They can help teams working on:

• Automotive systems and vehicle functions.
• Medical devices and healthcare equipment.
• Industrial machinery and production systems.
• Consumer products and connected devices.
• Enterprise software and information systems.
• Integrated systems involving hardware, software, and human operators.

Not every requirement needs a use case. A material composition requirement, dimensional tolerance, or performance threshold may be more effectively expressed directly as a measurable requirement. Use cases are most useful when the interaction itself needs to be understood, reviewed, and evaluated.

Reusable Use Case Specification Template

Use the following checklist as a starting point when documenting a use case. Adapt it to the project's process, system complexity, and risk. The fields are not a mandatory standard format.

Use case review checklist

• Is the system boundary explicit?
• Does the use case describe an actor goal rather than an internal system function alone?
• Are the primary and supporting actors correctly identified?
• Are preconditions genuinely conditions that exist before the use case starts?
• Does each flow step identify who or what performs the action?
• Are important alternative and exceptional scenarios covered?
• Are success and failure postconditions clear?
• Are detailed, measurable requirements linked to the relevant behavior?
• Can the important requirements be verified using defined methods and acceptance criteria?

Conclusion

Use cases help engineering teams describe how actors interact with a system to achieve specific goals. Their value extends beyond software: they can provide useful operational context for physical products, integrated systems, and manufacturing processes.

By documenting the main flow, alternative paths, exceptional conditions, and expected outcomes, teams can uncover missing assumptions and clarify the behavior required from a system.

However, use cases work best alongside detailed requirements, risk analysis, design specifications, and verification activities. They describe the operational context; the associated requirements establish the measurable conditions the product or process must satisfy.

When these artifacts are connected through traceability, teams can understand not only what a product or process must achieve, but also how its required behavior will be evaluated.

Related Articles

• Requirements Traceability: A Practical Guide with Real-World Examples
• Artifact Reuse in Requirements Engineering: Build Once, Reuse Across Projects
• Explore more practical Requirements Engineering guides on ReqSphere

Further Reading

• Object Management Group – Unified Modeling Language (UML)
• Object Management Group – Systems Modeling Language (SysML)
• IIBA – Business Analysis Body of Knowledge (BABOK)