PMI's New "Requirements Management - a Practice Guide" - Another Layer of the Project Foundation

 

The newly minted “Requirements Management – a Practice Guide” from PMI has been available for free download for a few weeks now.  Have you downloaded it?  If so, what do you think? 

The Core Committee spent a lot of time and effort to produce it, so we owe copious amounts of gratitude to them, and the twenty-eight content reviewers, the PMI Standards Program Member Advisory Group and the three production staff. 

If you haven’t already downloaded it, click here.

You’ll find that this 56-page guide (not including the index and appendices) is written in a familiar way with textual descriptions, contextual and activity diagrams.  As stated in the introduction, this new guide serves as a bridge between the PMBOK ^® Guide and the recent Business Analysis for Practitioners: A Practice Guide. The PMBOK Guide addresses good practices for requirements management, and the BA for Practitioners Guide describes what a BA does and how to apply requirements development and management skills to project tasks.  Intended for PMs and anyone doing requirements work, the Requirements Guide defines processes for requirements development and management.   

What is a Requirement? According to PMI, it is “A condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.” 

Requirements Management is about establishing a baseline and then ensuring it is traced (did the project implement everything it was supposed to?), managed through change control (if anything changed from the baseline, was it done in a controlled and approved way?) and updated (did the desired product, service or result of the project change, and if so, were the requirements related to the change appropriately captured in a new baseline?).

Requirements Development involves eliciting and identifying requirements, planning, analysis, documenting, specifying requirements and the necessary validation and verification.

The activities described in the Guide, paraphrased:

1. Needs Assessment – Identifies the business problem or opportunity at a high level – normally before a project starts, but could be examined again if the situation changes before the start of the project or during the project.
2. Requirements Management Planning – Part of the plan for how the project will be managed (the “Project Management Plan”, this describes the activities that will be carried out for the overall approach to requirements development and management.
3. Requirements Elicitation – The drawing out of information from stakeholders to ensure a solid understanding of business needs, and to gain some idea of how the solution should address these needs.
4. Requirements Analysis – Breaking the business needs down into requirements that fulfill the goals and objectives and can be actioned.
5. Requirements Monitoring and Controlling – Ensure requirements end up in the solution and that any changes to requirements are made only when approved.
6. Solution Evaluation – Validation that the solution meets the expressed business needs, and possible identification of new requirements that could lead to future refinement or new solutions. 
7. Project/Phase Closure – Transition from a development state to a state off maintenance.

As you might expect, the Guide describes all interactions with the five Process Groups and ten Knowledge Areas.  The types of requirements defined are probably familiar to most people – those required by the business, usually expressed at a high level, those required by stakeholders, solution requirements, both functional and non-functional, transition requirements, project requirements, quality requirements and program requirements.

Techniques for eliciting requirements are also in the guide, comprising interviews, workshops, focus groups, brainstorming, questionnaires/surveys, analysis of documents and interfaces, prototypes and observation.

The Guide tells us that good requirements are unambiguous, consistent, correct, complete, measurable, feasible, traceable, precise and testable.  In an adaptive life cycle, they must be independent, negotiable, valuable, estimable, small and testable.

It also delves into backlog management and prioritization, and various models, including Scope (context, ecosystem, goals/objectives, features and use cases).  It discusses functional decomposition and feature trees, and various process models (process flow, use case, user story) and rule models (business rules, decision trees/tables), and a favorite of mine, data models (ERDs, data flow, data dictionary and state diagrams/tables). 

The Guide draws our attention as well to interface models, that is, what occurs between systems and/or users, considering report definition, flow of data between systems, user interfaces, and tools like wireframes, and the tabular N2 model.

There is much value to be found in this Guide.  I’ve only very briefly touched on bits and pieces of it here.   Armed with it, the PMBOK Guide and the Business Analysis Practitioners Practice Guide, a project team can’t go wrong when it comes to translating business needs to appropriately detailed requirements that can be traced, confirmed and verified - and, of course, translated into that infamous product, service or result required by the business.

Go get it while it is still free!