7.1 Requirements Definition and Acceptance Criteria

7.1 Requirements Definition and Acceptance Criteria

Definition (APM BoK7 glossary): Requirements are the stakeholders’ wants and needs clearly defined with acceptance criteria. BoK7 pairs this with requirements management, "the process of capturing, assessing and justifying stakeholders’ wants and needs", and with acceptance criteria, "the requirements and essential conditions that have to be achieved before a deliverable is accepted".

Notice that APM builds acceptance criteria into the definition of a requirement itself: a want or need that cannot be tested is not yet a requirement.

Every project is undertaken to deliver beneficial change, whether through the development of a physical asset, an IT system, or a corporate reorganization. However, projects do not succeed merely by producing outputs; they succeed when those outputs accurately fulfill the underlying business needs and expectations of their stakeholders. Defining, analyzing, documenting, and validating these requirements represents the foundation of project scope management.

Without a disciplined approach to requirements engineering, projects suffer from ambiguity, scope disputes, rework, budget escalation, and end-user dissatisfaction. For the APM Project Fundamentals Qualification (PFQ), candidates must understand how requirements are elicited and managed, the critical distinction between functional and non-functional requirements, how to define measurable acceptance criteria, and how bidirectional traceability guarantees deliverable integrity.

---

The Requirements Engineering Process

Requirements do not simply appear fully formed. They must be systematically captured, refined, and agreed upon through a structured requirements engineering lifecycle. The APM Body of Knowledge defines four primary stages in this process:

+-----------------------------------------------------------------------------------------+
|                         REQUIREMENTS ENGINEERING PROCESS                                |
+-----------------------------------------------------------------------------------------+
|  1. ELICITATION     |  2. ANALYSIS         |  3. SPECIFICATION    |  4. VALIDATION      |
|  - Stakeholder      |  - De-confliction    |  - Formal documents  |  - Reviews          |
|    interviews       |  - Feasibility check |  - User stories      |  - Prototyping      |
|  - Workshops        |  - Prioritization    |  - WBS alignment     |  - Formal sign-off  |
|  - Observation      |  - Gap analysis      |  - Acceptance rules  |  - Baselines locked |
+-----------------------------------------------------------------------------------------+

1. Elicitation (Gathering Requirements)

Elicitation is the proactive discovery and capture of stakeholder needs, desires, constraints, and expectations. Because stakeholders often struggle to articulate their actual needs—frequently confusing underlying problems with pre-conceived technical solutions—project professionals deploy multiple elicitation techniques:

• Interviews: Structured one-on-one sessions with key individuals to explore detailed operational requirements and personal perspectives;
• Workshops (Focus Groups): Collaborative sessions bringing diverse stakeholders together to uncover interdependencies, debate priorities, and foster shared ownership;
• Surveys and Questionnaires: Efficient tools for gathering statistical data and preferences from large, geographically dispersed user populations;
• Observation (Job Shadowing): Immersing analysts into the live operational environment to witness actual user workflows, pain points, and unstated manual workarounds;
• Prototyping and Wireframing: Building early mock-ups or clickable simulations to stimulate stakeholder thinking and extract concrete feedback;
• Document and Interface Analysis: Reviewing existing contracts, regulatory frameworks, standard operating procedures (SOPs), and legacy system architectures.

2. Analysis (Refining and Prioritizing)

Once elicited, raw requirements are typically unstructured, overlapping, contradictory, or technically unrealistic. During the analysis stage, the project team analyzes, categorizes, and refines them:

• De-confliction: Identifying and resolving contradictory demands between different stakeholder groups (e.g., finance requesting minimum capital expenditure while operations demands maximum component redundancy);
• Feasibility Assessment: Evaluating whether each requirement is technically viable, economically sensible, and achievable within proposed project constraints;
• Prioritization: Ranking requirements according to business value, strategic urgency, and dependency sequencing, frequently employing the MoSCoW technique (Must Have, Should Have, Could Have, Won't Have this time);
• Scope Boundary Definition: Explicitly distinguishing what falls within project scope and documenting what is excluded.

3. Specification (Documenting Requirements)

In the specification phase, analyzed requirements are translated into formal, unambiguous, and accessible documentation that serves as the basis for design, contracting, and testing. Depending on the delivery method, specifications take various forms:

• Business Requirements Document (BRD): High-level operational objectives and commercial justification written from the sponsor's perspective;
• Functional / System Specification: Granular, technical descriptions of inputs, processes, outputs, and system behaviors used by engineers and developers;
• User Stories (Iterative Delivery): Compact statements framed from the user's viewpoint ("As a [role], I want [feature], so that [benefit]"), supported by explicit acceptance criteria.

4. Validation (Confirming and Baselining)

Validation ensures that the documented requirements truly reflect stakeholder intent and are capable of satisfying the project business case. Key validation activities include:

• Formal Peer Reviews and Walkthroughs: Cross-functional scrutiny by technical architects, end-users, quality assurance testers, and commercial managers;
• Testability Checks: Ensuring every stated requirement can be objectively proven through inspection, demonstration, analysis, or testing;
• Formal Sponsor Sign-off: Securing explicit authorization from the Project Sponsor, which locks the requirements into the approved Scope Baseline.

---

Functional vs Non-Functional Requirements

A central distinction in requirements engineering is the separation between functional requirements and non-functional requirements.

Functional Requirements

Functional requirements specify what the product, system, or asset must do. They describe the active behaviors, features, workflows, data manipulations, calculations, and interactions that the deliverable must perform to fulfill user tasks.

Non-Functional Requirements

Non-functional requirements specify how well the product, system, or asset must perform its functions. Often referred to as "quality attributes" or "system characteristics," they define operational constraints, performance thresholds, security standards, reliability targets, usability criteria, and statutory compliance parameters.

[!IMPORTANT] A system that delivers 100% of its functional requirements can still be an utter operational failure if its non-functional requirements are ignored. For instance, an online banking portal that correctly processes fund transfers (functional) is unusable if page loads take two minutes or if transactions are vulnerable to cyber theft (non-functional).

Comparative Analysis: Functional vs Non-Functional Requirements

---

Defining Objective and Measurable Acceptance Criteria

Acceptance criteria are the explicit, pre-agreed conditions and operational thresholds that deliverables must satisfy before the customer, user, or sponsor will formally accept them and authorize project transition or stage completion.

The Hazard of Subjective Language

Ambiguous or subjective criteria are a primary source of project disputes, contractual conflict, and delayed handover. Terms such as "user-friendly," "fast response times," "high reliability," "attractive modern design," or "robust construction" are opinions rather than verifiable standards. Two reasonable professionals will inevitably interpret them differently.

Formulating Measurable Criteria

To ensure unambiguous evaluation, acceptance criteria must be formulated using the SMART framework:

• Specific: Clearly identifying the exact component, feature, or environmental condition under test;
• Measurable: Expressed using quantifiable metrics, units of measure, or binary pass/fail criteria;
• Achievable: Technically realistic within project constraints and industry physics;
• Relevant: Directly contributing to the project's strategic business goals;
• Time-bound: Defining the exact timeframe or operational duration over which performance must be demonstrated.

+-----------------------------------------------------------------------------------------+
|                         ACCEPTANCE CRITERIA REFINEMENT                                  |
+-----------------------------------------------------------------------------------------+
|   AMBIGUOUS (SUBJECTIVE) CRITERIA              |   OBJECTIVE (MEASURABLE) CRITERIA      |
|   - "The database must be fast."               |   - "Query response time < 250ms under |
|                                                |     a concurrency load of 2,000 users."|
|   - "The car battery must charge quickly."     |   - "Battery charges from 10% to 80%   |
|                                                |     in <= 22 minutes on a 150kW DC plug"|
|   - "The training material must be easy."      |   - ">= 90% of trainees achieve >= 80%|
|                                                |     on first-attempt knowledge check."  |
+-----------------------------------------------------------------------------------------+

Acceptance criteria must also define acceptable tolerances (e.g., standard dimension 500mm ± 0.5mm), the specific test methods to be applied, and the named individuals possessing formal sign-off authority.

---

Requirements Traceability Matrix (RTM)

A Requirements Traceability Matrix (RTM) is a structured grid or database that cross-references each individual requirement to its business origin, technical specification, Work Breakdown Structure (WBS) work package, finished deliverable, and validation test case.

Structure of an RTM

A typical RTM records essential metadata for every requirement:

• Requirement ID: A unique alphanumeric identifier (e.g., REQ-SEC-042);
• Requirement Description: Concise narrative detailing the functional or non-functional need;
• Business Objective / Source: The strategic goal, business case driver, or stakeholder who originated the requirement;
• WBS Work Package: The specific work package in the WBS responsible for delivering it;
• Deliverable Component: The physical or digital asset element produced;
• Verification / Test Case ID: The exact test script, inspection procedure, or audit protocol used to prove compliance;
• Compliance Status: The real-time status (e.g., Defined, Baselined, In Development, Verified, Accepted).

Bidirectional Traceability and Its Value

The APM emphasizes that traceability must operate in two complementary directions:

1. Forward Traceability (Business Need to Delivery): Traces forward from the business objective through specification and build to test cases. This ensures that no requirement is omitted or forgotten during execution. Every business promise has an allocated work package and a verification mechanism.

2. Backward Traceability (Deliverable to Business Need): Traces backward from a physical component or code module to the approved business requirement that justified its creation. This prevents scope creep and gold-plating, because any deliverable or feature that cannot demonstrate a direct lineage back to an authorized business requirement is immediately exposed as unauthorized and redundant.

Furthermore, the RTM is an indispensable instrument during Change Control. When a stakeholder submits a proposed change, the project manager uses the RTM to conduct instant impact mapping—rapidly pinpointing every affected design document, work package, downstream system, and test case across the project ecosystem.