PMComplete™ - PMComplete Pty Ltd

People, Performance, Portfolios, Processes, Products and Projects

Requirements Management

What

Requirements Management is the Process of managing the initial definition and then the ongoing maintenance of the project's requirements. Requirements Management is sometimes known as "Requirements Definition".

"Requirements" are different to "Scope":

Scope refers to the project and includes the Application System requirements.
Scope includes other things.
(Application System) requirements may include manual processes.
(Application System) requirements may include functionality not being delivered in the current project lifecycle phase or "Release".
(Application System) requirements may include functionality not deliverable by the purchased software package (they are still requirements, but may become out of Scope because of this fact).

Process Diagram

Requirements Management consists of the following major Procedures:

Why

You need to manage "scope creep" (also known as "featuritis") to ensure you do not exceed your timebox.

When and Where

This technique is used throughout the following project lifecycle phases:

How

Record all of the Functions early (however roughly) at the start of a project. This helps everyone associated with the project to get a good feel for the scope of the Application System.

Business Staff can see that all of their requirements are being addressed (and sometimes they also surprise themselves at how complex their operations really are).
The Project Co-ordinator can use them to calculate development estimates leading to delivery times and costings.
Technical Staff can use the completed Function Decomposition to quickly develop program structure charts. The resultant program structure charts constitute the hierarchical and logical program module design for the processing required for each Function.

Define all scope inclusions.

Define all scope exclusions.

Ownership

Managing Expectations (Customers, vendors, staff, Stakeholders, each Business Area).

Managing Conflicts between different expectations.

Managing Conflicts between different requirements.

Impacts of requirements.

Requirements Traceability

Managing Contracts for embedded requirements.

Review Statement of Work (SOW) for embedded requirements.

Implicit Requirements

Aesthetics
Personal biases
Personal preferences
Hardware and system software platform
Legacy Application Systems (for common "Look and Feel", and interfacing)
Skills (Business Staff and Technical Staff)
Experience
Perceived career path
Design choices
Project Budget
Assumptions
Perceptions

Generic Requirements

Features
Functions
Benefits
Data
Processes

Negotiating

What is included
What is excluded
What is deferred
Cost/Benefit Analysis
Functional Priorities
What then How

Basic Problem of Defining Requirements With Words

Inconsistencies
Incompleteness
Natural language
Meaning of words
Ambiguities
Implications
Inferences

Be careful with the following:

May/Can
Must/Should/Could/Shall

Functional Requirements

Functional requirements are defined by the following:

Non-Functional Requirements

Non-Functional Requirements are defined by the following:

Quality Requirements

Quality requirements are normally defined in the "Non-Functional Requirements" sections of the documents lists under "Recording" (below).

A check list of quality requirements can be found under "Quality Definition".

Constraints

Constrains include:

Deadlines
Project Budget
Platform (IT Infrastructure)
Staffing
Enterprise policy
IT Department Processes
Methodology
Legal/Contracts
Performance
Capacity

Added Value Requirements

Added Value requirements include:

Benefits Acquisition
Cost/Benefit Analysis
Added value chain
Primary and secondary benefits
Stakeholder buy-in
Meeting Business Objectives
"Why is the Client undertaking this project?"
Desired outcome

The major Requirements Management Procedures are:

Concepts and Themes

The following important Concepts and Themes apply to the Requirements Management process:

What then How
Future (Not Current) Requirements
Technology Independence
Tool Independence
Joint Ownership and Responsibility
Timing - 1 elapsed month maximum
Only the Best Team Members Will Do
Project Team structure, composition as well as Roles and Responsibilities is extremely important.
Every project is an Organisation Change Management project. Technology just happens to be the driver in many instances.

Elicit Requirements Procedure

You need to help Business Staff to articulate their requirements.

Use Joint Application Design (JAD) workshops because they are a more effective way to elicit requirements than Interviewing.

During the elicitation process, you need to Manage the Expectations of the people who are defining their requirements.

Beware of Business Staff presenting "needs" which are:

Problems they have
Solutions
How the solution will work

Identify critical requirements versus desirable requirements.

The following activities are always performed in all Phases of the Analysis Stage:

Each of these follows a Breadth Then Depth approach.

This can best be shown by the following diagram:

The sequence of these procedures within the overall Requirements Management process is important.

Defining Moment of Truth Activities first gets the Project Team members thinking about Processes.
Identifying System User Roles before Functions gets the Project Team members thinking about Functions ready for Function Decomposition.
Functions gets the Project Team members thinking about data ready for Data Modelling.
Doing Non-Functional Requirements last allows you to cleanup the "left overs".
The above process is iterative, as shown by the backchannels (dotted lines) which indicate amendments.

Record Requirements Procedure

A project's functional requirements are normally defined explicitly (in increasing levels of depth) by the contents of:

A project's Non-Functional Requirements are normally defined explicitly in a separate document.

Requirements are also defined by the deliverables which are to be produced by the project.

Requirements are also defined by any Contract which govern the conduct of the project.

Break up paragraphs so that there is only one requirement per paragraph.

Number every paragraph in every document so that a requirement can be traced backwards through each of the above documents.

Number every paragraph in every document so that Test Cases and Test Scripts can be traced back to specific requirements.

In all Test Cases and Test Scripts reference the original specific requirement in the source document (see "Recording" above for details).

Where Used

Requirements are used in the following places:

Project Lifecycle Phase	Why Used
Package Acquisition	Used as input to define Request For Information (RFI), Macro Evaluation Criteria and Micro Evaluation Criteria so package can be evaluated against these and ensure that no requirements are missed.
Business Case	Used to size and then cost the effort required to Develop the Application System (usually by Counting Function Points).
Development	Becomes "The Specification" of what to develop.
Customisation	Assists in defining the gap between what is in the package and what needs to be developed (ie, Customised).
Testing	All Test Cases and Test Scripts reference the original specific requirement in the source document (see "Recording" above for details).

Sayings

"Producing software form a specification is like walking on water... it's easier if its frozen."
"There is no such thing as a shortcut in software development, period."

Scaling

Also See

Requirements Management is one of the significant Processes that exist throughout PMMentor (PMM). To print a "Handout Pack" on this Process, create and print a title page and then click on the "Print" button (to print this topic to act as a Table of Contents) and then click on each of the following topics in turn. When the topic is displayed, click on the "Print" button, then click on the "Back" button to return to this topic and choose the next topic to print.

Business Area Analysis Phase

Capacity Management Plan

Capacity Planning

Change Control Board (CCB)

Change Request Form

Change Request Register

Common Processes and Cycle Times

Configuration Change Register