MS PJM

PJM6005 – Project Scope Management

Week 2 - Project Requirements
Dr. Farhad Eizakshiri, PMP, PMI-ACP.
Lecture Topics

• Overview of project requirements and elicitation

• Requirements elicitation activities
• Requirements elicitation techniques
• Requirements analysis techniques
• Requirements Management

3
Overview of Project
Requirements and Elicitation
 Customer
Requirements

5
WHAT’S A REQUIREMENT ???
• Requirement: a condition or capability that is required to be present
in a product, service, result to satisfy a contract of other formally
imposed specification.

Scope is Expressed as Requirements

• Requirements are sentences that describe, in measurable detail,
exactly what's needed. There are many different types of requirement
statements.
• Business
• Project
• Product (Technical/ Functional)
 What is Requirements Elicitation?
• Elicitation is a discovery process used to bring forward or produce
information relevant to the project or program by drawing out
information from stakeholders and other sources.
• Identify the causes of the business problem or the reasons for
addressing an opportunity, as well as the information to be used to
derive a sufficient level of requirements to enable a solution to be
developed and implemented.
• Uses progressive elaboration, as all requirements are generally not
known or revealed at the onset of a project or program.

7
Requirements Management: A Practice Guide, PMI (2016)
 Requirements Elicitation Success Factors
• Planning and Preparation
• Active Stakeholder Engagement
• Defined Business/Organizational Need
• Domain Knowledge

8
Requirements Management: A Practice Guide, PMI (2016)
Requirements Elicitation
Activities
1. Plan for Elicitation
• Before the actual elicitation, more detailed preparation is required
such as drafting agendas, scheduling conferences for elicitation
workshops, inviting stakeholders, etc.
• Careful consideration should be given to the following elements:
• Activities
• Requirements sources
• Resources
• Expected deliverables

10
Requirements Management: A Practice Guide, PMI (2016)
2. Define Types of Requirements
REQUIREMENT TYPE DESCRIPTION

Business Requirements The business requirements from the project Business Case or Charter is
included to ensure the project team does not loose sight of the business
needs as the project progresses.
Stakeholder Requirements
Describe the needs of a stakeholder or stakeholder group

Project Requirement Conditions that project deliverables must have to satisfy a contract or other
Overall Project Need formally imposed documents. Actions, processes or other conditions the
project needs to meet – milestone dates, constraints, contractual
obligations
Solution requirements Describe the features and functions that the product, service, or result
needs to exhibit to satisfy the business and stakeholder requirements.
These are often grouped into two categories: functional (describe features
of product) and nonfunctional requirements (describe certain
environmental conditions or required attributes such as security, legal, etc.).
 Types of Requirements
COMPONENT DESCRIPTION
Regulatory Address any laws, policies, or other restrictions applicable to the product, project, or
Requirement business. These are usually non-negotiable.
Legally Required
Transition and Temporary capabilities (i.e. data conversion, training requirements) to transition from
Readiness current to future state
Requirements
Quality Any condition or criteria to validate successful completion of a deliverable or other project
Requirements requirements (i.e. tests, certification, validations)
Exclusions The exclusions section identifies technical, project and regulatory requirements NOT
addressed by the project.
3. Conduct Elicitation Activities
• Collect input by consulting a broad range of stakeholders, as well as
reviewing existing systems, historical records, and documentation.
• In a plan-driven or predictive environment, elicitation activities are
typically conducted as early as possible in the project.
• Requirements are expected to evolve as the project progresses, both to include
increasing levels of detail and to address changes.
• The elicitation of requirements should cease once the solution has been defined
to a sufficient level so it can be built.
• In an adaptive life cycles, elicitation activities occur continuously
throughout the project life cycle in conjunction with requirements
analysis. The initial work is performed to define the vision, scope, and
high-level business needs of the problem or opportunity.
• As the project evolves, the scope is further evaluated and decomposed into a set
of requirements, also known as the product backlog, one iteration at a time.

14
Requirements Management: A Practice Guide, PMI (2016)
4. Document and Communicate Results
• The outcome of elicitation activities should be recorded to properly
examine and synthesize the relevant information during the
analysis process.
• Documented in a number of forms, including audio recordings,
meeting minutes, interview notes, and survey responses

15
Requirements Management: A Practice Guide, PMI (2016)
Requirements Elicitation
Techniques
Elicitation Techniques: Pros & Cons
Elicitation Techniques: Pros & Cons
Elicitation Techniques: Pros & Cons
Elicitation Techniques: Pros & Cons
Elicitation Techniques: Pros & Cons
Elicitation Techniques: Pros & Cons
Elicitation Techniques: Pros & Cons
Elicitation Techniques: Pros & Cons
Elicitation Techniques: Pros & Cons
Requirements Analysis
Techniques
Requirements Analysis
• Analysis is the process used to examine, decompose, and
synthesize information to further understand it and the features
and capabilities of the solution.
• Similar to elicitation, analysis is performed using a progressive and
iterative approach to examine the information to lower levels of
detail to develop a set of requirements.
• The iteration and analysis continues until a sufficient level of
requirements needed to formulate the solution is obtained.
• In an adaptive life cycle, elicitation and analysis occur throughout
the project or program as part of defining the initial backlog,
grooming the backlog to refine requirements, and analyzing details
for each iteration.
27
Requirements Management: A Practice Guide, PMI (2016)
Analysis Techniques
• Many techniques are used to perform requirements analysis.
• These techniques primarily assist with prioritization and modeling
of requirements.
• Since decisions regarding priorities are often complex, a structured
approach may be necessary to simplify the process:
• MoSCoW
• Voting
• Timeboxing

28
Requirements Management: A Practice Guide, PMI (2016)
Requirements should be prioritized (MoSCoW)
• Must: Product cannot be used unless this requirement is satisfied
M
• Should: Requirement should be satisfied; awkward without it
S
• Could: Requirements would be nice to have; enhances product
C
• Won’t (Wait): Requirement can wait until a later iteration of product
W
What Makes a “Good” Requirement?

• A strong requirement:
• Defines what specific, measurable “something” is needed to address the gap
identified during the Collect Requirements process.
• Requirements must be so measurable that they can be verified
through testing.
• “Good” requirements have many different attributes.

30
Breaking Down a Requirements Statement

What How to Say It…

S Specific Describe a key feature or characteristic.

Identify which stakeholder(s) will perform the requirement.

M Measurable Include a number, quantity, percentage, etc.

A Achievable Not always described in the requirements statement.

Ask “has this ever been done before?”

R Realistic This is not always written.

“Realistic” refers to the balance between the time, resources,
and effort required to fulfill the requirement.
Ask “can we do this with the money and time available?”

T Timely Include a date or timeframe (i.e., “within 90 days).

31
Examples of Requirements
Draft Requirement Improved Requirement
• When the user accesses any screen,
• All screens must appear on the it must appear on the monitor
monitor quickly within 2 seconds

• On the loss of power, the backup • On the loss of power, the backup
system must maintain power system must maintain power for 20
minutes

• After 3 unsuccessful attempts to

login, a Javascript must run and lock • After 3 unsuccessful attempts to
login, the user must be locked out of
the user out the system
29
Requirements Management
 The Requirements Management Plan (RMP)
• Describes how project and product requirements will be analyzed,
documented and managed
• Components may include:
• How requirements activities will be planned, tracked reported
• Requirements collection methods
• Requirements prioritization process
• Metrics – what they are and how they will be used
• Collection timetable
• Requirements traceability structure

PMBOK Guide, 6th ed. 3

5
 Requirements Traceability

Business Goal

Requirement

Specification

Design

Build

Test
Requirements Traceability Acceptance Criteria
• Tracks Business Goals through finished Product
• Helps to control Scope Creep Success Criteria
• Important for Scope Validation
3
6
 Requirements Traceability Matrix

37
Business Analysis for Practitioners:: A Practice Guide, PMI
https://www.opencodez.com/software-testing/create-requirement-traceability-matrix-rtm-free-sample-download.htm
38
 In Class Team Activity
• For the business/service project you selected in the week 1 class
activity, and based on today’s lecture, conduct the following:
1) Describe the process that you will use to elicit, analyze and document the
project requirements.
2) Identify and describe at least 4 requirements collection techniques you
intend to use to collect project requirements from key stakeholders.
3) Use one of the proposed elicitation techniques to collect project
requirements.
4) List 8 to 10 Functional Requirements (e.g., Features)
5) List 3 to 5 Non-Functional Requirements (e.g., Performance, Durability,
Maintainability, etc.).
6) Develop a Traceability Matrix.
7) Be prepared to discuss your Team’s work with the entire Class (5-7
minutes per team)
39
Thank You