When stakeholders disagree on the scope of a use case, the business analyst must visualize the boundary using a Use Case Diagram and define specific scenarios. This technique reveals exactly where expectations diverge, allowing you to document trade-offs and negotiate a shared understanding before development begins.

Recognizing Signs of Use Case Scope Conflict

Symptoms of Misalignment in Requirements

You often encounter a use case scope conflict when stakeholders speak past one another. One stakeholder describes a process that ends at “data entry,” while another assumes the process includes “data validation and reporting.”

In meetings, these disagreements appear as repetitive arguments about what belongs inside a specific feature. The team cannot agree on the “Do” boundary for a specific actor.

• Repetition: The same question about responsibility arises repeatedly in different meetings.
• Feature Creep: Stakeholders add “just one more small step” to a scenario repeatedly.
• Ambiguity: Actors claim responsibilities that overlap significantly with other domains.

If you do not address these signs early, they will lead to rework, missed deadlines, and a product that satisfies no one completely.

The Cost of Unresolved Scope Boundaries

Ignoring a use case scope conflict forces developers to guess requirements. This leads to incorrect implementation or the need for expensive refactoring later.

The development team often builds to the last person who spoke or the loudest voice, rather than the agreed-upon standard. This creates technical debt and stakeholder frustration.

Visualizing Boundaries with Use Case Diagrams

Step 1: Draw the High-Level Diagram

Start by placing the specific Use Case in the center of the whiteboard. Draw the stick figures representing the primary actors involved in the conflict.

Draw lines connecting the actors to the Use Case. This visual representation highlights exactly who interacts with what. It transforms a verbal dispute into a concrete visual object.

Ask the stakeholders to point to the lines and explain who is responsible for what. This simple action often reveals the source of the disagreement immediately.

Step 2: Identify the Boundary Line

The most effective way to resolve use case scope conflict is to draw a line separating the system from the external environment. Everything inside the box is the system; everything outside is the actor or external system.

Ask the stakeholders to place the disputed steps inside or outside this line. This forces a binary decision: Is this function part of the system, or is it an action performed by the actor?

Deconstructing Scenarios to Clarify Scope

Action: Define the Primary Flow (Happy Path)

Write down the primary flow of the use case step-by-step. Ensure every step starts with the actor performing an action on the system.

Example: “Actor enters ID,” “System checks ID,” “System displays data.”

If a stakeholder adds a step that seems outside this logical sequence, ask: “Does this step happen inside the system boundary?” If the answer is no, move it out.

Action: Document Alternative Flows

Conflict often arises in error conditions or exceptions. Document these as “Alternative Flows” distinct from the primary flow.

• Step A1: System detects invalid input.
• Step B1: System displays error message.

By isolating these flows, you clarify that the system handles the error, not the human actor. This prevents stakeholders from claiming they need to build manual workarounds for system errors.

Action: Map Preconditions and Postconditions

Define the preconditions (what must be true before the use case starts) and postconditions (what is true after it ends).

If a stakeholder argues that a step is too complex, ask if it is a precondition. If it is a precondition, it is likely outside the scope of the specific use case.

Facilitating Stakeholder Negotiation

Strategy 1: Role-Playing the Boundaries

Instead of arguing about words, ask stakeholders to physically move a stick figure on the diagram.

“If this step is performed by the user, move the user stick figure.” This kinesthetic approach helps stakeholders understand the distinction between “doing” and “being done by the system.”

Strategy 2: The “Who, What, Where” Technique

For every disputed step, ask three specific questions:

• Who initiates this step?
• What entity performs the logic?
• Where does the data reside?

If the logic happens on the server, the system performs the step. If the logic happens in a human’s brain, the actor performs the step. This clarity resolves ambiguity instantly.

Documenting Decisions and Trade-offs

Recording the Decision Rationale

Once the scope is agreed upon, document the rationale in the requirements specification. Explain why a specific step was moved inside or outside the boundary.

This documentation serves as a reference if the conflict resurfaces later. It provides an audit trail for why the scope was defined the way it was.

Noting Trade-offs Explicitly

Sometimes, stakeholders will agree to a scope but express hesitation. Document these trade-offs clearly.

• Scope Reduction: “We agreed to exclude manual reporting because it is out of scope, but we will handle it via email.”
• Scope Expansion: “We agreed to include data validation, but this will increase the timeline by two days.”

Explicitly stating the trade-offs ensures stakeholders feel heard and makes the cost of change transparent.

Handling Revisions and Evolution

Managing Changing Scopes

Scopes are rarely static. New business rules or regulatory changes often force a re-evaluation of the use case boundaries.

When a change occurs, revisit the Use Case Diagram. Do not simply add the new step to the end. Re-evaluate if the new step belongs to a different use case entirely.

If the change is significant, consider splitting the original use case into two separate, more focused use cases.

Version Control for Diagrams

Maintain version history for your Use Case Diagrams. This allows you to track how the boundaries evolved over time.

This history is crucial for new team members who need to understand why certain scope decisions were made previously. It prevents the use case scope conflict from reoccurring due to forgotten context.

Common Pitfalls in Scope Definition

Pitfall: Confusing Use Cases with User Stories

Do not confuse a Use Case (a system function) with a User Story (a user goal). Use Cases focus on system behavior, while User Stories focus on user value.

Misinterpreting this distinction leads to scope creep. Keep the Use Case focused on the interaction, not the business outcome.

Pitfall: Overlapping Actors

Avoid having multiple actors perform the exact same action unless they have different permissions. This leads to unnecessary complexity.

If two roles do the same thing, consider if they should be merged into a single abstract actor for diagram clarity.

Key Takeaways

• Visualize the Conflict: Use diagrams to make disagreements visible and concrete.
• Define Boundaries: Clearly distinguish between system actions and actor actions.
• Document Rationale: Record why scope decisions were made to prevent future disputes.
• Facilitate Negotiation: Use role-playing and structured questioning to align stakeholders.
• Manage Trade-offs: Be transparent about the cost and effort of scope changes.
• Resolve Scope Conflict: Turn verbal arguments into agreed-upon model elements.