Requirements Analysis and Design Definition: From Raw Input to a Specification Worth Building

Eliciting requirements is the visible part of business analysis. Interviewing stakeholders, running workshops, building prototypes: these are the activities most people think of when they picture a business analyst at work. But elicitation produces raw material, not finished requirements. The work of turning that raw material into a specification that designers and developers can build against is the subject of this blog.

Requirements analysis and design definition is the fifth BABOK knowledge area. It covers everything that happens after requirements are gathered and before they are handed to the development team: organizing, modeling, verifying, validating, prioritizing, and defining design options. Done well, it produces requirements that are complete, coherent, testable, and unambiguous. Done poorly, it produces a list of wishes that nobody can build against.

Organizing Requirements: Structure Before Detail

Requirements gathered through interviews, workshops, and observation arrive in a disorganized state. Different stakeholders use different terminology. Some requirements overlap. Some conflict. Some are at a business level while others jump straight to system-level detail. Before any modeling or analysis can be productive, this material needs structure.

A medium-sized project typically demands hundreds of requirements. Readers can only understand these fully when the requirements document is organized logically. The best structure for user requirements follows the natural patterns of use, structured like a scenario or use case.

Classification Approaches

There are several ways to classify and organize requirements. The right approach depends on the project and the stakeholders.

Stakeholder-Based Classification

Organizing requirements by stakeholder type makes it easy to see whether all voices have been heard and to assign responsibility for sign-off. It also helps with prioritization, because different stakeholders have different weights of authority depending on the project’s goals.

The two broad categories of stakeholders are external (government, customers, vendors) and internal (management, users, other departments). Within each category, the BA should identify the specific groups whose requirements are relevant to the project, and document who their representatives are as early as possible.

Sequence-Oriented Classification

Sequence-based classification organizes requirements from high level to detailed, following the hierarchy of the organization. This hierarchy typically runs:

1. Regulations, industry standards, and corporate policies
2. Business requirements (strategic, tactical, and operational)
3. User requirements
4. System functional requirements
5. System quality of service requirements
6. Assumptions and constraints
7. Transition requirements

This structure is powerful because it creates natural traceability. Every system requirement should trace to a user requirement, which should trace to a business requirement, which should trace to an organizational goal or regulatory obligation. If a system requirement cannot be traced upward, it is either scope creep or evidence of a missed requirement at a higher level.

Transition requirements deserve special mention. They deal with the capabilities the solution must have to successfully migrate from the old state to the new one. How much downtime can the business afford during cutover? Is there a need to run old and new systems in parallel? Does historical data need to be converted? These requirements are temporary by nature. They become irrelevant once the transition is complete. But they are often missed until they create expensive implementation problems.

Purpose-Based Classification

Purpose-based classification organizes requirements by the type of functionality they represent. What does the order clerk need? What does the finance department require? What are the reporting requirements? What are the security requirements? This approach maps well to how stakeholders think about their work and makes it easy to structure interviews by functional area.

Modeling Requirements

Models are visual or structured representations of requirements that communicate things text alone cannot. A requirement that takes a paragraph to describe in words can often be communicated more precisely and more reviewably in a diagram. Models also catch different categories of errors. A well-drawn activity diagram will reveal process gaps and exceptions that a text list of requirements would never surface.

The key is selecting the right model for the right purpose. No single model type is sufficient for a complex system. Combining model types gives a more complete picture than any one model alone.

Cas d’utilisation

Use cases show how the system will be used by entities external to it. Those entities may be people, organizations, or other systems. A use case should be a standalone action that has business value on its own. Place Order, Pay Invoice, and Check Drug Interaction are examples. Use cases should not be decomposed into sub-use cases; they represent a complete, externally-initiated action.

A use case has two components: the diagram and the template. The diagram shows the big picture: which actors interact with which use cases and what the system boundary is. The template is where the real value lies. A complete use case template includes:

• Use case ID and description – unique identifier and overview of what the use case accomplishes
• Precondition – what must be true before the use case begins
• Postcondition – what will be true after the use case completes successfully
• Success criteria – how the actor defines a successful outcome
• Main scenario – the normal flow, also called the happy path
• Alternative scenarios – valid conditions that occur less frequently than the main scenario
• Exceptions – error conditions and how the system responds to them
• Applicable business rules – business rules that constrain or inform this use case
• Frequency – how often this use case will be executed, which drives performance requirements
• Primary and secondary actors – who initiates the use case and who supports it
• Security, backup, and recovery requirements – special non-functional considerations
• Assumptions and constraints – what environment is assumed and what limits apply

Use cases are developed iteratively. A high-level pass defines scope and gets executive commitment. A broad pass identifies all use cases and actors. A deep pass explores each scenario in detail and captures non-functional requirements. The final iteration serves as the translation point between business analysis and systems design.

Strengths of use cases include their intuitiveness for customers and their natural connection to test case development. Weaknesses include potential duplication of data and non-functional requirements across use cases and the risk of going into too much detail too quickly.

Activity Diagrams

Activity diagrams, also called swim lane or workflow diagrams, are among the most frequently used and most effective modeling techniques. They are intuitive for customers, show process flow in a way that mirrors how people think about their work, and are excellent for capturing communication points between different organizations or systems.

A well-drawn activity diagram shows:

• The sequence of process steps from start to end
• Who or what is responsible for each step (via swim lanes)
• Decision points where the process can branch in different directions
• Loops where the process returns to an earlier step
• Parallel activities that can happen simultaneously
• Documents and data objects created or consumed by each step