Collecting and managing requirements

Requirements describe the conditions or capabilities that a product, service or result must have to satisfy stakeholders' needs. They are the starting point for scope, and weaknesses in requirements are one of the most common root causes of project failure: features nobody wanted, features everybody assumed but nobody wrote down, and arguments at acceptance about what was promised. This lesson covers types of requirements, elicitation techniques, how to analyze and prioritize requirements, how to document them so they can be tested, and how a traceability matrix keeps requirements connected to deliverables and tests. Stakeholder identification and engagement were covered in PMP-121; here we focus on turning stakeholder needs into clear requirements.

Types of requirements

Requirements come in layers. Business requirements state the higher-level needs of the organization, such as why the project exists. Stakeholder requirements state the needs of particular groups. Solution requirements describe the features and characteristics of the product, split into functional requirements (what it must do) and nonfunctional requirements (how well it must do it, such as performance, security, accessibility and reliability). Transition requirements describe temporary capabilities needed to move from the current state to the future state, such as data conversion and training. Project requirements describe actions or conditions the project itself must meet, such as milestone dates or contractual obligations. Quality requirements describe the criteria used to confirm that deliverables are acceptable.

Nonfunctional requirements are easily forgotten because stakeholders rarely state them unprompted. Nobody says "the kiosk must not crash" or "the community room must meet fire code occupancy limits" until it fails. Good elicitation asks about performance, availability, security, privacy, accessibility, maintainability and compliance for every major feature.

Eliciting requirements

Elicitation draws requirements out of stakeholders, documents and observation. No single technique is enough; experienced practitioners combine several, choosing according to the stakeholders, the product and the time available.

For Project Compass, the team used several. Interviews with the branch manager and facilities staff captured operational needs. Two focus groups, one with parents of young children and one with older adults, explored what would make the branch welcoming. A workshop with IT, facilities, finance and branch staff agreed the self-service approach. Observation at an existing branch showed that staff spent much of their time helping patrons find holds, which shaped the layout. Paper and clickable prototypes of the app were tested with patrons before any code was written. Document analysis covered the lease, the building code and accessibility standards.

Group decision-making techniques help when stakeholders disagree. Unanimity requires everyone to agree; majority requires more than half; plurality picks the largest block even if it is not a majority; autocratic decisions are made by one person. The nominal group technique has participants generate ideas silently, share them in turn and then rank them, which reduces the influence of dominant personalities. Multicriteria decision analysis scores options against weighted criteria. On the exam, recognize the trade-off: broader agreement takes longer but builds commitment.

Analyzing and prioritizing requirements

Raw elicitation results are messy: duplicates, conflicts, vague wishes and hidden solutions ("we need a dashboard" when the need is "I must know which holds are waiting"). Analysis cleans them up. Each requirement should be traced to a need, checked for conflicts and refined until it is clear and testable.

Good requirements share a few characteristics. They are unambiguous (one interpretation), measurable or verifiable (you can test whether they are met), complete enough to build from, consistent with other requirements, feasible within constraints, and traceable to a source. Compare "the app should be fast" with "the app shows search results within two seconds for 95 % of searches on a 4G connection". Only the second can be tested.

Prioritization is unavoidable because time and money are limited. MoSCoW sorts requirements into must have, should have, could have and won't have this time. The Kano model distinguishes basic needs (expected, cause dissatisfaction if absent), performance needs (more is better) and delighters (unexpected features that please). Paired comparison and weighted scoring help when many requirements compete. In adaptive projects, the product owner orders the backlog by value, risk, dependencies and cost, revisiting the order each iteration.

Prioritization should involve the stakeholders who own the value, not just the project team. A frequent exam scenario has two stakeholders pressing for conflicting requirements. The best response usually brings them together to clarify the underlying needs and agree priorities against the project's objectives, escalating to the sponsor only if they cannot agree within the project's authority.

Documenting requirements

Requirements documentation can take many forms: a formal requirements specification, use cases, user stories with acceptance criteria, process models or annotated prototypes. Whatever the form, it should record the requirement, its source, its priority, its acceptance criteria, and its status. A requirements management plan describes how requirements will be collected, analyzed, documented, prioritized, approved, traced and changed. It sets out who can approve requirements and how changes to them will go through change control.

User stories are common in adaptive work. A typical format is "As a role, I want capability, so that benefit", followed by acceptance criteria. For Project Compass: "As a parent with a stroller, I want to see whether a picture book is on the shelf before I visit, so that I do not make a wasted trip." Acceptance criteria might include showing shelf status updated within five minutes of a checkout and indicating the shelf location. Good stories are independent, negotiable, valuable, estimable, small and testable, often remembered as INVEST.

Traceability

A requirements traceability matrix links each requirement to its source, to the deliverables or WBS elements that satisfy it, and to the tests that verify it. Traceability answers three practical questions. Is every requirement being delivered? Is everything we are delivering justified by a requirement? How will we prove each requirement has been met? It also supports impact analysis: when a requirement changes, the matrix shows which work and tests are affected.

# Requirements traceability check for Project Compass (invented data)
reqs = {
    "R1": ("Patrons borrow items at self-service kiosks", "Must"),
    "R2": ("Kiosks read RFID tags on all collection items", "Must"),
    "R3": ("Branch open 72 hours a week", "Must"),
    "R4": ("Mobile app shows real-time availability", "Should"),
    "R5": ("Accessible service desk at seated height", "Must"),
    "R6": ("Community room bookable online", "Could"),
}
wbs_links = {"R1": ["3.2"], "R2": ["3.1", "3.2"], "R3": ["5.3"],
             "R4": ["4.2"], "R5": ["2.4"]}
tests = {"T01": ["R1"], "T02": ["R1", "R2"], "T03": ["R4"],
         "T04": ["R5"], "T05": ["R9"]}

tested = {r for linked in tests.values() for r in linked}
print("Req  Priority  WBS        Tests")
for rid, (text, prio) in reqs.items():
    w = ", ".join(wbs_links.get(rid, [])) or "-"
    t = ", ".join(k for k, v in tests.items() if rid in v) or "-"
    print(f"{rid:4s} {prio:8s}  {w:10s} {t}")

print()
print("No WBS element:", [r for r in reqs if r not in wbs_links])
print("Not tested:    ", [r for r in reqs if r not in tested])
print("Orphan tests:  ", [k for k, v in tests.items() if not set(v) & set(reqs)])

Req  Priority  WBS        Tests
R1   Must      3.2        T01, T02
R2   Must      3.1, 3.2   T02
R3   Must      5.3        -
R4   Should    4.2        T03
R5   Must      2.4        T04
R6   Could     -          -

No WBS element: ['R6']
Not tested:     ['R3', 'R6']
Orphan tests:   ['T05']

The check reveals three problems. R6 (bookable community room) has no WBS element and no test: either it is out of scope and should be recorded as an exclusion, or work is missing from the WBS. R3 (72 opening hours a week) is linked to the opening work package but has no test; because it is an operating commitment, the verification might be a staffing plan review rather than a system test, and the matrix should say so. T05 tests a requirement R9 that does not exist, which suggests either a missing requirement or wasted testing effort. Each finding is cheap to fix in planning and expensive to discover at acceptance.

Managing requirements through the project

Requirements are rarely complete at the start, and they change as stakeholders learn. In predictive projects, approved requirements become part of the scope baseline, and changes go through change control with impact analysis. In adaptive projects, the backlog is expected to change, but the product owner still controls what enters an iteration, and the team protects the iteration from mid-sprint changes. In both, the project manager watches for requirements creep, where new requirements slip in informally, and for missing stakeholders whose requirements surface late.

Validating requirements with stakeholders before building saves money. Walkthroughs, reviews of prototypes and acceptance criteria workshops catch misunderstandings while they are still cheap. The cost of fixing a requirement error grows sharply the later it is found, because more work has been built on top of it.

Requirements also have owners. Someone must have authority to decide what a requirement means when the team is unsure. In Project Compass, the branch manager owns operational requirements, the IT manager owns technical and security requirements, and the product owner owns the app backlog. The sponsor resolves conflicts that the owners cannot settle.