Requirement Analysis: Concepts, Activities, and Techniques

What is Requirement Analysis?

Requirement analysis, also called requirements engineering, is the process of defining what users expect from a new or modified software system. It involves determining the conditions that a product or project must satisfy, handling conflicting stakeholder needs, and recording, validating, and managing software or system requirements.

Goals of Early Requirement Analysis

From What to How: Bridging the gap between system requirements engineering and software design.

Three Orthogonal Views: Providing models for static (system information), functional (functions), and dynamic (behaviors) perspectives.

Software Architecture: Transforming models into data, architectural, and component-level designs.

Iterative and Incremental Process: Performing some design during analysis and some analysis during design.

What is a Requirement?

A software requirement is the capability needed to solve a problem or achieve a goal. In other words, it is the ability a system or component must possess to meet contracts, standards, specifications, or other formally imposed documents, aiming for high‑quality software delivered on time and within budget.

One of the biggest challenges for developers is sharing a common vision of the final product with all stakeholders—developers, end users, managers, and customers—so that no one is surprised at delivery.

Therefore, methods are needed to accurately capture, interpret, and represent the customer's voice when specifying software product requirements.

Requirement Analysis Activities

Requirement analysis is critical to the success of a system or software project. Requirements should be documented, actionable, measurable, testable, traceable, linked to identified business needs, and detailed enough for system design. Four types of activities are involved:

Requirements Elicitation: Communicating with customers and users to determine their needs (also called requirements gathering).

Requirements Analysis: Identifying unclear, incomplete, ambiguous, or contradictory statements and resolving them.

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

Review and Retrospective: Team members reflect on what happened during an iteration and decide on improvement actions.

Requirement analysis is a team effort that combines hardware, software, human factors, engineering expertise, and interpersonal skills. Main activities include:

Identifying customer needs.

Assessing system feasibility.

Conducting economic and technical analysis.

Allocating functions to system elements.

Defining schedules and constraints.

Creating system definitions.

Requirement Analysis Techniques

Requirement analysis helps organizations determine actual stakeholder needs and enables development teams to communicate using diagrams, models, or flowcharts rather than lengthy text.

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

Business Requirements vs. Software Requirements

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

For example, a business requirement to create a member directory for a trade association translates into software requirements that define access rights, registration processes, data ownership, and the delivery medium (e.g., website or printed catalog).

Techniques for Discovering Business Requirements

Various techniques can be used, such as:

Gap Analysis using BPMN or ArchiMate: Comparing current (baseline) and target business scenarios to identify performance gaps and improvement opportunities.

ArchiMate – Gap Analysis

ArchiMate is an open, independent enterprise architecture modeling language that describes and visualizes architecture across and within business domains, providing symbols needed for gap analysis.

BPMN – Current and Future Process Analysis

Current Process

An example of an online store’s current process: a sales rep receives a purchase order, checks inventory, packs the order if stock is sufficient, and ships it with an invoice; otherwise, the rep asks the customer to modify the order.

Future Process

Assuming business growth and a new warehouse, the future process models enhancements for better resource allocation.

Business Motivation Model (BMM)

BMM captures the "why" (goals) and "what" (objectives) of an enterprise’s methods, providing decision rationale, traceability, and impact assessment.

Deriving decisions and reasons for reacting to change, improving clarity, and learning from experience.

Tracing decision outcomes to operational impacts such as process or organizational changes.

Customer Journey Mapping

Customer journey maps use storytelling and visuals to illustrate a customer's experience over time, revealing needs, hesitations, and pain points, and can serve as a source of software requirements.

Techniques for Identifying Software Requirements from Business Requirements

Data Flow Diagrams (DFD)

DFDs are used early in the SDLC analysis phase to define system scope, providing a high‑level overview that can be refined into lower‑level diagrams.

Use Cases

UML use case diagrams capture the intended behavior of a system from the user's perspective, specifying "what" the system should do without detailing "how".

User Stories

User stories are short, natural‑language descriptions of what a user needs to accomplish, focusing on the "who", "what", and acceptance criteria, and are compatible 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 in Scrum meetings.

Stories aim for frequent, small increments and rapid feedback, unlike the more detailed pre‑specification of use cases.

For more details, visit the original article at https://architect.pub/requirement-analysis-techniques .