The standard functional use case is the default choice for business analysis. It bridges the gap between business goals and system functionality without overwhelming the reader.

Common Traps in Use Case Granularity

Analysts frequently struggle with use case granularity because they do not distinguish between business value and system action. This leads to documents that are either useless or unreadable.

The Trap of Over-Detailing

This occurs when a BA documents every click a user makes. For example, a use case named “Submit Form” that details clicking the “Next” button, typing in a field, and hitting “Enter”.

Consequences:

• The document becomes impossible to read for non-technical stakeholders.
• Changes in UI design (like button placement) force unnecessary requirement updates.
• Development teams treat it as a technical spec rather than a requirement.

The Trap of Over-Abstraction

Conversely, some analysts write use cases that are too vague, such as “Process Order.” They omit the critical steps, making it impossible for developers to understand the business logic.

Consequences:

• Developers make incorrect assumptions about validation rules.
• Acceptance criteria become vague, leading to failed tests.
• Business stakeholders feel their specific needs were ignored.

Defining the Right Level of Detail

To achieve the correct use case granularity, you must prioritize the user’s intent over the system’s mechanics. The goal is to describe the behavior, not the implementation.

Guidelines for Standard Business Requirements

Most business requirements fall into the “Standard” category. This level of detail is sufficient for design, development, and testing without requiring technical deep dives.

Follow these principles when writing your standard use cases:

1. Focus on the Goal: Start with the user’s primary objective. What are they trying to achieve?
2. Describe the Flow: Outline the step-by-step process required to achieve that goal.
3. Include Key Decisions: Document the critical decisions or branching paths the system must handle.
4. Omit UI Nitpicking: Do not describe the color of the button or the specific pixel coordinates of a field.

When to Use Low-Level Granularity

Occasionally, you must increase the detail level. This happens when the business logic is complex and requires strict validation rules that cannot be easily understood in a high-level summary.

Use low-level granularity when:

• The system performs complex calculations (e.g., tax calculations, loan interest).
• The workflow involves strict compliance rules with legal implications.
• The stakeholder requires visual confirmation of specific data states.

When to Use High-Level Granularity

High-level use case granularity is appropriate for project scoping and roadmap planning. It helps management understand the scope of the work without getting bogged down in details.

Use high-level granularity when:

• Defining the initial project scope and budget.
• Presenting the solution to executive sponsors.
• Planning the release strategy for multiple features.

Calibrating Scope and Depth: A Decision Matrix

To ensure your documentation maintains the right balance, apply this decision matrix. It helps you determine the correct level of detail based on the project context.

Evaluating Use Case Clarity

After writing a use case, review it against these criteria. This helps you adjust the use case granularity before sharing it with the team.

• Does it describe the “What”? If it describes the “How” (technical steps), it is too detailed.
• Can a tester write a test case? If you cannot derive a clear test case from it, it is too vague.
• Is it user-centric? The steps should be from the user’s perspective, not the system’s.
• Does it add value? If a step does not directly contribute to the user goal, remove it.

Examples of Adjusting Granularity

Consider the following examples to see how use case granularity impacts clarity and utility.

Example 1: Too Detailed (Low-Level)

Use Case: Create New Customer

1. User clicks the “New” button in the top right corner.
2. User types “John” into the “First Name” field.
3. User types “Doe” into the “Last Name” field.
4. System highlights the “Email” field in red.
5. User clicks the “Save” button.

Why it fails: This focuses on UI elements rather than the business goal. If the UI changes, the requirement breaks.

Example 2: Too Vague (High-Level)

Use Case: Create New Customer

1. User creates a new customer record.
2. System saves the data.
3. Confirmation message appears.

Why it fails: It misses critical validation rules (e.g., email format, duplicate check) needed for development.

Example 3: Balanced (Standard)

Use Case: Create New Customer

1. User initiates the creation of a new customer record.
2. System displays the entry form.
3. User provides valid contact information and selects a customer type.
4. System validates the email address format.
5. System checks for duplicate customer records.
6. System saves the customer and displays a success confirmation.

Why it succeeds: It focuses on the business logic (validation, duplication check) without mentioning specific UI elements.

Calibration Checklist for BAs

Use this checklist to validate your use cases before finalizing them.

1. Verify the Goal: Does the title reflect the user’s intent?
2. Check for UI Specifics: Remove any mention of buttons, colors, or specific screen locations.
3. Review Exceptions: Ensure all major error scenarios are captured.
4. Assess Completeness: Can a developer build the feature based solely on this document?
5. Stakeholder Review: Have non-technical stakeholders confirmed the flow makes sense?
6. Consistency: Is the terminology consistent across all use cases?

Adjusting for Technical Constraints

Sometimes, use case granularity must account for technical constraints. If a specific technology forces a specific workflow, you may need to note it.

However, do not let technical constraints dictate the entire use case. Focus on the business outcome.

If a technical constraint prevents a specific action, document the constraint as a “Precondition” or “Constraint” rather than embedding it into the main flow. This keeps the business requirement separate from the technical implementation.

Conclusion on Granularity

Finding the right balance in use case granularity is essential for successful business analysis. It ensures that your documentation is actionable for developers and understandable for stakeholders.

Always start with the business goal and work backward. Avoid the temptation to document every technical step. By focusing on the “What” and “Why,” you create requirements that are resilient to change and clear in their intent.

Key Takeaways

• Standard Granularity: Aim for the “Standard” level that describes user flow and business rules, excluding specific UI details.
• Focus on Intent: Document the user’s goal and the system’s response, not the button clicks required to get there.
• Balance is Key: Too much detail leads to rigidity; too little leads to ambiguity. Aim for the middle ground.
• Validation First: Ensure all critical validation rules and business logic are captured, even if not explicitly detailed in steps.
• Iterative Refinement: Be prepared to adjust the granularity level as the project evolves from planning to design.