This Requirements Management Plan Software Development document shows how Eduardo Montes established the processes for eliciting, documenting, tracing, and controlling the 156 requirements of the ProjectAdm SaaS platform across 28 sprints and five milestone gates. It defines who owns requirements, how changes to requirements are managed, and how traceability is maintained from business need through to final acceptance — making it a critical companion to the Requirements Documentation and the Scope Management Plan.

What Is a Requirements Management Plan?

A Requirements Management Plan is a component of the Project Management Plan in PMBOK 8's Planning Performance Domain. It describes how requirements activities will be planned, tracked, and reported. It establishes the elicitation techniques to be used, the tools for managing requirements, the change process for requirements modifications, the traceability approach, and the roles and responsibilities for requirements ownership and approval. Without a Requirements Management Plan, requirements tend to be informally managed — leading to scope creep, missed acceptance criteria, and disputes over what was originally agreed.

What This Requirements Management Plan Software Development Includes

The ProjectAdm Requirements Management Plan establishes complete governance for the 156-requirement baseline:

• Requirements Elicitation Approach — Primary: Henry Douglas as Product Owner conducting user story mapping workshops (2-day session in Sprint 1); Secondary: beta user interviews (Sprints 3–6, 12 participants); Tertiary: competitive analysis of Jira, Asana, and Notion features; all elicited requirements reviewed by Eduardo Montes before entry into baseline
• Requirements Documentation Tool — Primary: Requirements Documentation (Word) for formal baseline; supporting: Notion for living requirements discussions; GitHub Issues for technical requirements linked to code; Lucas Park's PHPUnit test suite as executable requirements verification
• Requirements Prioritization Method — MoSCoW applied to initial backlog: Must Have (142 requirements, Sprint 1–20 delivery); Should Have (9 requirements, Sprint 20–26); Could Have (5 requirements, Sprint 26–28 if capacity permits); Won't Have: native mobile apps, offline mode (explicitly excluded in Scope Statement)
• Requirements Traceability Matrix — Each requirement traced to: source stakeholder, WBS package, PHPUnit test ID, sprint delivery target, acceptance status; matrix maintained in Excel (Requirements Traceability tab); updated within 48 hours of any change; owned by Eduardo Montes
• Requirements Change Process — Requirements changes affecting scope baseline require formal Change Request (CCB review if cost/schedule impact); requirements clarifications (no scope change) handled via Henry Douglas → Eduardo Montes confirmation email; all clarifications logged in Notion requirements page with date and requestor
• Requirements Verification and Validation — Verification: Lucas Park runs PHPUnit suite against each requirement's test ID before sprint acceptance; Validation: Henry Douglas demos each completed story against acceptance criteria in sprint review; stakeholder validation: beta user testing panel (12 users) for UX-heavy requirements
• Requirements Status Reporting — Requirements completion percentage reported in biweekly Status Report to Henry Douglas; traceability matrix reviewed at each milestone gate; open/pending requirements highlighted in sprint review presentations

How Eduardo Montes Used This Requirements Management Plan Software Development

When ISS-003 (Safari drag-drop) caused 80 hours of unplanned rework in Sprints 8–9, Eduardo Montes used the Requirements Management Plan Software Development framework to determine that no requirements change was needed — the Safari fix was a verification failure (the requirement FR-003 was still correct) rather than a scope change. This distinction saved the team from processing an unnecessary change request and kept the requirements baseline stable. The traceability matrix also allowed Eduardo to instantly identify the 12 PHPUnit tests affected by CR-002 (Gantt chart), enabling Lucas Park to plan his test suite updates in Sprint 12 with one day's notice.

How to Use This Requirements Management Plan Software Development Document

When writing your own Requirements Management Plan Software Development document, define the boundary between a "requirements clarification" and a "requirements change" before the project starts. The ProjectAdm plan's rule — any change with scope/cost/schedule impact goes to CCB, everything else is a clarification confirmed by email — prevented the ambiguity that typically leads to informal scope creep on software projects.

Download the Template and Deepen Your Knowledge

Ready to create your own requirements management plan? Download the blank Requirements Management Plan Template (PMBOK 8).

• Download the Requirements Management Plan Template — PMBOK 8 (blank, ready to use)
• Read the full guide: Requirements Management Plan in PMBOK 8

Want to go deeper? The PMBOK Guide 8th Edition is the definitive reference for modern project management. Get your copy and use it alongside these examples to build a solid, practical understanding of every performance domain.

Format: Microsoft Word (.docx) | Project: Software Development (SaaS Platform) | PMBOK Edition: 8th (2025) | Domain: Planning