Requirement Analysis: Concepts, Activities, and Techniques

What Is a Requirement?

Software requirements describe the capabilities a system must provide to solve a problem or achieve a goal, satisfying contracts, standards, specifications, or other formal documents. The ultimate aim is to deliver high‑quality software that meets the customer's real needs within budget and schedule.

Why Requirement Analysis Matters

Requirement analysis bridges the gap between stakeholder expectations and software design. It involves capturing, interpreting, and representing the customer's voice accurately.

Goals of Early‑Stage Requirement Analysis

From What to How: bridging system requirements engineering and software design.

Three orthogonal views: static (system information), functional (functions), and dynamic (behaviors) models for designers.

Software architecture: models can be transformed into data, architectural, and component‑level designs.

Iterative and incremental process: perform some design during analysis and some analysis during design.

Requirement Analysis Activities

Successful projects require requirements that are documented, actionable, measurable, testable, traceable, linked to business needs, and detailed enough for system design. Four core activities are:

Elicitation: communicating with customers and users to determine their needs (also called requirement gathering).

Analysis: identifying unclear, incomplete, ambiguous, or conflicting statements and resolving them.

Modeling: recording requirements in various forms such as natural‑language documents, use cases, user stories, or process specifications.

Review & Retrospective: reflecting on iteration outcomes and deciding improvement actions.

Main Tasks in Requirement Analysis

Identify customer needs.

Assess system feasibility.

Conduct economic and technical analysis.

Allocate functions to system elements.

Define schedules and constraints.

Create system definitions.

Requirement Analysis Techniques

Techniques help organizations capture stakeholder needs and communicate them using diagrams, models, or flowcharts rather than lengthy text.

Collected requirements are recorded in a Software Requirements Specification (SRS), use cases, or user stories, shared for approval, and managed through change‑control processes.

Business Requirements vs. Software Requirements

Business requirements define the "why" of a project, while software requirements define the "what" needed to satisfy those business goals.

Techniques for Discovering Business Requirements

Common techniques include:

Gap analysis using BPMN or ArchiMate to compare current and target business scenarios.

Business Motivation Model (BMM) to capture why and what an enterprise wants to achieve.

Customer Journey Mapping to visualize the end‑to‑end experience and identify pain points.

Data Flow Diagrams (DFD) to outline system boundaries and data movement at various abstraction levels.

Use Cases (UML) to specify expected system behavior from the user's perspective.

User Stories to capture concise, role‑goal‑benefit statements that drive agile discussions.

Gap Analysis with BPMN and ArchiMate

Gap analysis measures the distance between the current state and the desired future state. It helps identify performance gaps and improvement opportunities.

ArchiMate – Gap Analysis

ArchiMate is an open, independent enterprise‑architecture modeling language that can describe and visualize business‑domain and cross‑domain architectures, providing symbols needed for gap analysis.

BPMN – Current and Future Processes

Current process example: an online store receives a purchase order, checks inventory, packs items, and ships them with an invoice; if stock is insufficient, the sales rep asks the customer to modify the order.

Future process example: with a warehouse in place, resources are re‑allocated to improve the workflow, and a new model is created to illustrate enhancements.

Business Motivation Model (BMM)

BMM captures why an enterprise wants to become a certain state (End), what it must do to get there (Means), influences that may affect it (Influencer), and assessments of those influences.

Customer Journey Mapping

Customer journey maps tell a story of the customer's experience, revealing needs, hesitations, and concerns, and can surface potential software requirements.

Data Flow Diagrams (DFD)

DFDs are used early in the SDLC to outline system scope without detailed design, with levels (0‑level, 1‑level, etc.) representing increasing detail.

Use Cases

UML use case diagrams capture the "what" of system behavior from the user's perspective, providing a high‑level view of actors, use cases, and their relationships.

User Stories

User stories are short, natural‑language descriptions written from the user's perspective, focusing on what the user needs rather than how the system will deliver it, and fit well with agile methods such as Scrum and XP.

Similarity Between User Stories and Use Cases

User stories contain role, goal, and acceptance criteria.

Use cases contain equivalent elements: actors, event flows, and post‑conditions.

Differences Between User Stories and Use Cases

User stories are less detailed than use cases.

Stories intentionally omit many details to spark discussion during Scrum meetings.

Stories aim for frequent, small increments to obtain rapid feedback.

For more detailed discussions, join the community channels listed at the end of the original article.