7 Secrets To Defining Preparing An RFP Delivery

7 Secrets to Defining Requirements
for Package Software Selection

Determining Business Requirements and Using These to Procure Complex
Packaged Software
Thank you for joining us. We’ll be starting soon!
· Technical Support Problems for this Webinar? webinars@projecttimes.com

· Audio is provided through your computer speakers only.
· PMI PDU and IIBA CDU submission instructions will be provided on the last slide.
7 Secrets
Session Agenda
INTRODUCTION
SECRET #1 DESCRIBE THE PROCESS
SECRET #2 DESCRIBE THE DATA REQUIREMENTS
SECRET #3 USE THE ‘SUPER’ SME
SECRET #4 FIND THE ESSENTIAL REQUIREMENTS
SECRET #5 FIND THE CRITICAL BUSINESS RULES
SECRET #6 PRIORITIZE THE REQUIREMENTS
SECRET #7 STRUCTURE THE RFP IN BUSINESS TERMS
QUESTIONS AND ANSWERS
2
Introduction
Why we are here
Session Objectives
Project Managers need to understand what should be
included in an RFP for the selection of a Vendor for
application software
Business Analysts need to understand the essential
techniques and specific guidelines for gathering and
defining the right kind of requirements for inclusion in an
RFP
3
Introduction
Why we are here (continued)
Session Objectives
Project Managers and Business Analysts need to know
what level of detail is needed in an RFP, the essential
contents of an RFP and how to prioritize and weight the
requirements in an RFP
Key Stakeholders in Commercial Off-The-Shelf (COTS)
selection and implementation projects need to know how
to evaluate Vendor solutions in a meaningful way
4
Introduction
Learning Objectives
What you will learn

The differences between defining requirements for an RFP
and defining requirements for custom-developed software
The most effective approach for collecting requirements for
inclusion in an RFP
The essential types of requirements, the sufficient level of
detail, and the best format for writing requirements for
inclusion in an RFP
5
Introduction
Learning Objectives (continued)
What you will learn

How to organize requirements to enable an unbiased
evaluation of Vendor solutions
How to prepare an RFP
The essential contents of an RFP
How to prioritize and weight the requirements in an RFP
6
7 Secrets
Session Agenda
INTRODUCTION
7
Secret #1
Describe the Process

What is a Request for Proposal?
A request for proposal (RFP) is an invitation for suppliers,

often through a bidding process, to submit a proposal on a
specific commodity or service.
Why create an RFP?
Creating an RFP requires the organization to specify what

it proposes to purchase. If the requirements analysis has
been prepared properly, it can be incorporated quite easily
into the RFP document.
9
Secret #1

Why describe the process?
The organization proposes to purchase a software solution to

a business problem
The business wants to automate a business process that
would otherwise have to be manually
The ‘requirements’ represent what the system must do with
what information, according to the rules and policies unique to
the organization
Correct, valid requirements are found in the business process
descriptions
Focusing on the ‘what’ [the process] vs. the ‘how’ [the
features] allows for an evaluation of the business functionality –
not simply a review of the vendor modules/hierarchies of
features
10
Secret #1
Steps to Describe the Process
A. Define the Scope of Analysis
B. Describe each Use Case
11
Secret #1
How to Describe the Process

A. Define the Scope of Analysis
1. Understand the business need at a high level

understand the problem/opportunity behind the
initiative
define/confirm the business objectives
2. Determine the breadth and depth of the process

develop a high-level scenario (breadth)
develop a list of significant variations (depth)
determine the list of candidate use cases
3. Determine the Interfaces

develop a Context Diagram (sources of the input
and consumers of the output)
determine the list of candidate interfaces
12
Secret #1

1. Understand the Business Need
Review all documentation prepared in support of the

initiative
often the source of valuable information regarding
problems/opportunities, objectives, etc.
Speak to the key business leaders

confirm/describe the key business objectives
will be vital to assist in prioritizing the requirements later in
the process
13
Secret #1

2. Determine the breadth and depth of the process
Develop a High-Level Scenario

an end-to-end description of the process
described in 10 – 20 steps
follows the main success flow
document the variations
Variations = those things that can occur that will cause
the business to have to do the process differently
14
Secret #1
Develop the High-level Scenario

Demo: Hotel Management System
TASKS
TASKS Guest Reservation Process
1.
1. Describe
Describe the
the High-level
High-level Res Clerk receives Guest contact
Scenario
Scenario System determines room availability
2.
2. Determine
Determine the
the candidate
candidate Use
Use Res Clerk determines payment method
Cases
Cases System generates confirmation number
3.
3. Describe
Describe the
the Context
Context Model
Model Desk Clerk checks Guest in to the Hotel
System assigns room to Guest
4.
4. Determine
Determine the
the candidate
candidate
Interfaces Guest uses hotel service
Interfaces
Housekeeper cleans the room
System generates a Statement of
Variations Charges
new Guest / changed Guest Desk Clerk checks Guest out
Telephone reservation / online Desk Clerk receives Guest payment
Room type not available System closes the reservation
…..etc.
15
Secret #1
Determine the list of candidate Use Cases

TASKS
TASKS CANDIDATE USE CASES
1.
1. Describe
Describe the
the High-level
High-level
Scenario 1.Taking a Reservation
Scenario
2.Taking a Reservation Online
2.
2. Determine
Determine the
the candidate
candidate Use
Use 3.Checking a Guest in to the Hotel
Cases
Cases 4.Providing Services to a Guest
3. 5.Preparing a Statement
3. Describe
Describe the
the Context
Context Model
Model
6.Checking a Guest out of the Hotel
4.
4. Determine
Determine the
the candidate
candidate 7.Modifying a Reservation
Interfaces
Interfaces 8.Cancelling a Reservation
9.Receiving Promos and Specials
10.Providing Reports to Hotel
Management
11.……etc.
16
Secret #1

3. Determine the Interfaces
Develop a Context Diagram

Represents the role of the process in context with the
outside world
Models the flows of information to and from the process
to those things the process cannot control
Not restricted to electronic interfaces (any sharing of
information should be described)
17
Secret #1
Determine the Interfaces

TASKS
TASKS
1.
1. Describe
Describe the
the High-level
High-level
Scenario
Scenario
2.
2. Determine
Determine the
the candidate
candidate Use
Use
Cases
Cases
3.
3. Describe
Describe the
the Context
Context Model
Model
4.
4. Determine
Determine the
the candidate
candidate
Interfaces
Interfaces
18
Secret #1
Determine the candidate Interfaces

TASKS
TASKS CANDIDATE INTERFACES
1.
1. Describe
Describe the
the High-level
High-level
Scenario
Scenario 1.Guest
2.Marketing
2.
2. Determine
Determine the
the candidate
candidate Use
Use 3.Accounting
Cases
Cases 4.Financial Institution
3.
3. Describe
Describe the
the Context
Context Model
Model 5.…….etc.
4.
4. Determine
Determine the
the candidate
candidate
Interfaces
Interfaces
19
Secret #1

B. Describe each Use Case
What is a Use Case?

A Business Use Case is:
a partitioned group of actions that yield a result of value to a
particular Actor – one piece of a process
a method of describing a process
a collection of related scenarios - possible sequences of steps
that a Actor must complete to achieve an outcome of value
A Business Use Case describes WHAT not HOW
20
Secret #1
Describe each Use Case
The steps that comprise a use case can be described at

varying levels of detail
High Level
Mid Level
Detailed
21
Secret #1

The Levels of Detail Described
High Level – “The system must display the details of the

Customer’s last Order”
This requirement specifies that the system must “do something with
some information”
Actor - Verb - Entity
Mid Level – “The system must display the details of the

Customer’s last Order when the Customer is an existing
Customer”
some information under certain circumstances”
Actor - Verb - Entity - Condition
but it does not specify which Order details need to be displayed
22
Secret #1

The Levels of Detail Described (continued)
Detailed – “The system must display the Products ordered, the

quantity of each product, and any Options for each Product that was
specified on the Customer’s last Order when the Customer is an
existing Customer”
some information under certain circumstances”
Actor - Verb - Entity - Condition
and it specifies the details of the Order that need to be displayed
The difference between a mid level requirement statement and a

detailed requirement statement lies in the visibility given to a screen
display or a calculation/algorithm – what needs to be displayed and the
actual calculation/algorithm are fully described in the detailed
requirement
23
Secret #1
Describe each Use Cases
Steps to Describing a Business Use Case
1. Select a business use case

2. Determine the actors
3. Define the pre-conditions and post-conditions
4. Elicit the primary scenario
5. Elicit the variations
6. Describe the business use case detail
24
Secret #1
Describe each Use case

Guest Reservation Process
Res Clerk receives Guest contact
System determines room availability
Describing Use Cases Res Clerk determines payment method
System generates confirmation number
Select a Business Use Case Desk Clerk checks Guest in to the Hotel
Determine the Actors System assigns room to Guest
Define the Pre-conditions Guest uses hotel service
and Post-conditions Housekeeper cleans the room
Elicit the Primary scenario System generates a Statement of Charges
Elicit the Variations Desk Clerk checks Guest out
Describe the Business Use Desk Clerk receives Guest payment
Case detail System closes the reservation
TAKING A RESERVATION
25
Secret #1

Describing Use Cases Res Clerk receives Guest contact
Select a Business Use Case Res Clerk determines payment method
Determine the Actors System generates confirmation number
Define the Pre-conditions Desk Clerk checks Guest in to the Hotel
and Post-conditions System assigns room to Guest
Elicit the Primary scenario Guest uses hotel service
Elicit the Variations Housekeeper cleans the room
Describe the Business Use System generates a Statement of Charges
Case detail Desk Clerk checks Guest out
Desk Clerk receives Guest payment
System closes the reservation
Questions:
“Who is involved?”
“Who provides information?”
Actors:
“Who receives information?”
Reservation Clerk
Guest
System
26
Secret #1

Describing Use Cases
Res Clerk receives Guest contact
Select a Business Use Case
Res Clerk determines payment method
Determine the Actors
System generates confirmation number
Define the Pre-conditions
Desk Clerk checks Guest in to the Hotel
and Post-conditions
System assigns room to Guest
Elicit the Primary scenario
Elicit the Variations Guest uses hotel service
Describe the Business Use Housekeeper cleans the room
Case detail System generates a Statement of Charges
Desk Clerk checks Guest out
Desk Clerk receives Guest payment
Questions: System closes the reservation
“What must be in place for the use
case to begin?” TAKING A RESERVATION
“What causes this use case to start?” Pre-condition:
“What is the successful outcome of Guest makes a request
this use case?” Post-conditions:
Reservation details recorded
Confirmation number provided
27
Secret #1

Describing Use Cases TAKING A RESERVATION
Select a Business Use Case Primary Scenario

Define the Pre-conditions Res Clerk receives Guest call
and Post-conditions Res Clerk identifies the Guest
Elicit the Primary scenario System validates the Guest information
Elicit the Variations Res Clerk determines request details
Describe the Business Use System determines if a room is available
Case detail Res Clerk obtains payment method
System authorizes the Guest credit card
System generates a confirmation number
Questions:
Res Clerk confirms reservation details
“What must happen to achieve the
System records reservation details
goal/outcome?”
“What (does the actor) need to do
next?”
“What might happen next?”
28
Secret #1


Select a Business Use Case Variations:

Define the Pre-conditions contact by phone / online
and Post-conditions new Guest / changed Guest information
Elicit the Primary scenario room type
Elicit the Variations bedroom
Describe the Business Use
meeting room
Case detail
ballroom
Room type not available
Question: Payment methods
“What could occur that would cause Credit card
you to do this process differently?” Debit card
Cash
Credit card does not authorize
etc…….
29
Secret #1


System validates Guest information
Select a Business Use Case When the Res Clerk has entered
Determine the Actors the Guest’s telephone number, the system will
Define the Pre-conditions determine if a matching record exists
and Post-conditions When a match is found, the system will
Elicit the Primary scenario display the matching Guest information
Elicit the Variations If no match is found, the system will display
Describe the Business Use an error message ‘no match found’
Case detail If multiple potential matches are found, the
system will display all possible matches
The Res Clerk will determine from the Guest
Questions: the matching occurrence
“What info do you need to do this The Res Clerk will select the matching Guest
step?” occurrence
“What do you do with it?” The system will display the matching Guest
“What is the successful outcome of information
etc…….
doing this step?”
30
7 Secrets
Session Agenda
INTRODUCTION
30
Secret #2
Describe the Data Requirements

Steps to Describe the Data Requirements
1. Discover the entities required for the use

case
2. Describe each entity
3. Describe each data element
32
Secret #2

Step 1 Discover the entities required for the Use Case
Techniques:
Question:
“What information do you need to know about in order to
complete this use case?”
Ask the question in the context of a use case

Listen for nouns
Determine if the noun is an entity or a data element
[xx] of what? Æ ‘xx’ is the data element, ‘what’ is the entity
33
Secret #2

Step 2 Describe each Entity
Techniques:
Define the entity

Question:
“What do you mean by [entity name]?”
Discover related data elements

Question:
“What do you need to know about [entity name]?”
34
Secret #2

Step 3 Describe each Data Element
Techniques:
Define the data element

“What do you mean by [data element name]?”
Determine if it is optional or mandatory
“Must [entity x] always have [data element x]?”
Determine if it is single or multi-valued
“Could there be many [data element x] in a single [entity
x]?”
Describe related business rules
“And what would that mean?”
35
Secret #2

Sample Output
Customer
Definition
An individual or group who has placed an order with us or requested a catalogue of our services.
Data
The system shall provide for the following data elements and business rules:
Data Description Optional Single Rules
Element /Mand or
Multi-
(O/M)
valued
Customer First & last name M 1 Must have one and only one name
Name
Address(s) Street, city, state, zip M N Must have at least one address (mailing
address) and may have many (mailing,
billing, etc.).
Balance Due Current A/R balance M 1 Must have a balance (even if it is zero).
Order(s) Foreign key pointer to O N May never have placed an Order (simply
Placed Order Entity to connect made a request for a catalogue). May have
with actual orders placed many orders.
placed
36
7 Secrets
Session Agenda
INTRODUCTION
36
Secret #3
Use the ‘Super’ SME

What is a ‘Super SME?
A resource who has significant knowledge of the

business area under discussion
Someone who can “think outside the box” of the
existing process
An expert who can help the participants understand
best practices in the industry
Where do I find the ‘Super’ SME?
Could be an internal resource or a consultant
38
Secret #3

Why do I need a ‘Super’ SME?
To help describe the future state for the process under
discussion
To assist in determining the level of granularity for the
requirements
To assist in determining the essential requirements that
must be included in the RFP
To assist in determining the critical business rules that
must be included in the RFP
To assist in the prioritization of essential functional
requirements
39
Secret #3

When should I engage the ‘Super’ SME?
As soon as possible in the planning phase of the

project
Available to assist in developing the vision and
objectives for the project
Available to assist in the development of the
requirements management plan
Actively involved in the elicitation phase of the project,
including describing the process, determining and
prioritizing the essential requirements
40
7 Secrets
Session Agenda
INTRODUCTION
40
Secret #4
Find the Essential Requirements
What is a Requirement?
IEEE defines a “requirement”* as:
1. A condition or capability needed by a user to solve

a problem or achieve an objective
2. A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, a standard, a specification, or other
formally imposed document
3. A documented representation of a condition or
capability as in (1) or (2)
*IEEE Std 610.12
42
Secret #4

What types of Requirements should be specified?
Functional Requirements
Data Requirements
Non-Functional Requirements
Usability
Reliability
Performance
Supportability
Security
Serviceability
Reporting Requirements
Design Requirements*
43
Secret #4

What is a Design Requirement?
A Design Requirement* is “a requirement that

specifies or constrains the design of a system or
system component”
*IEEE Std 610.12
44
Secret #4

What is an Essential Requirement?
all requirements specified during the elicitation

phase are important to the business
not all requirements specified are essential for
inclusion in an RFP
vendor software will never meet all of the
business’ requirements – but it should meet all of the
essential requirements
the essential requirements are those that must be
met - without which the software would not be
purchased
essential requirements may include design
requirements
45
Secret #4
How do I find the Essential Requirements?
engage the Super SME to assist the business in

determining what is essential
weed out the ‘nice-to-haves’ – those parts of the
process that are not best practice and do not provide
‘value add’ to the business
look especially at the design requirements – is
there a valid business reason why the proposed
software must do something in a particular way?
46
Secret #4

The Levels of Granularity
Determine the level of granularity to which you will

specify the functional requirements in the RFP
Could be at the level of the:
Business Use Case
Business Use Case Step
Individual, stand-alone Requirement, or
NOT AT ALL!
Engage the Super SME to assist in determining
the level of granularity
Need to consider the level of granularity for the
data and reporting requirements as well
47
Secret #4

Non-Functional Requirements
Things that are required for the product to work the

way the business needs it to
Software quality attributes
Typical categories include:
Usability
Reliability
Performance
Supportability
Security
Serviceability
Consider Industry Standards – IEEE, ISO, etc.
48
Secret #4

The Format for Functional Requirements – Syntax
The system must ...
[..do something..] action verb

capability
[..with some information..] business entity/attribute
[..under certain circumstances…] when/if condition
[..according to certain rules..] business rules constraint
“The system must allow the Reservation Clerk to select one

instance from a list of potential matching Guests when the
Reservation Clerk has determined the appropriate occurrence.”
49
7 Secrets
Session Agenda
INTRODUCTION
49
Secret #5
Find the Critical Business Rules

What is a Business Rule*?
From the business perspective, a business rule is guidance that there

is an obligation concerning conduct, action, practice, or procedure within
a particular activity or sphere.
Two important characteristics of a business rule are:
There ought to be an explicit motivation for it.
It should have an enforcement regime stating what the
consequences would be if the rule were broken
From the information system perspective, a business rule is a
statement that defines or constrains some aspect of the business.
It is intended to assert business structure, or to control or influence the
behavior of the business.
*Business Rules Group, 2009
51
Secret #5
What is a critical Business Rule?
all business rules specified during the elicitation phase

are important to the business
not all business rules specified are essential for
inclusion in an RFP
the critical business rules are those that must be met -
without which the software would not be purchased
52
Secret #5
How do I find the Critical Business Rules?
engage the Super SME to assist the business in

determining what is critical
consider industry standards, imposed regulations,
internal business policies
53
7 Secrets
Session Agenda
INTRODUCTION
53
Secret #6
Prioritize the Requirements
Steps to Prioritize the Requirements
1. Understand the Purpose and Strategy

for Prioritization
2.Determine the Business Importance Factors
3.Determine the Priority Weighting
55
Secret #6

Step 1
Understand the Purpose and Strategy for Prioritization
Why prioritize?
To understand the relative importance to the
business of the requirements to be included in the
RFP
Determine the overall level of granularity to which you
will prioritize the functional requirements
Follow the granularity determinations made in
Secret #4 at Slide 47
At the level of the:
Business Use Case
Business Use Case Step
Individual, stand-alone Requirement
56
Secret #6
Step 2
Determine the Business Importance
Determine what Factors the Business feels are
important in prioritizing the requirements
The factors that drive the characteristics, scope and
functionality of the software product
Often expressed as the business benefits or
objectives:
cost savings, revenue impact, ease of use,
productivity goals, utility, etc.
Determine the Customer Importance of each
(weighted ranking of the Factors)
57
Secret #6
Step 3
Determine the Priority Weighting
The rating score is based on an agreed scale:
1-5
Optional/Mandatory
High/Medium/Low
MoSCoW
(Must have, Should have, Could have, Would
be nice to have)
Or some other scale that makes sense
58
7 Secrets
Session Agenda
INTRODUCTION
58
Secret #7
Structure the RFP
Suggested Structure
Introduction – General Information
Administrative Details
Timelines
Who to Contact
How to present the Proposal
Requirements
Evaluation Criteria
Include a ‘POP’ clause
Selection Criteria
Draft Terms* (optional)
60
Secret #7
Structure the RFP
Suggested Structure for the Requirements

Structure the Requirements in your business
terms
Based on your business processes
Not based on the Vendor modules or hierarchy

of features
61
7 Secrets
Session Agenda
INTRODUCTION
61
Q&A
Questions ?
63
Q&A
About IAG Consulting
Objectives
12 Years of living requirements excellence:
Completed over 1,200 requirements projects
Worked with over 300 of the Fortune 500 companies
Trains over 1,200 business analysts annually
Somewhat in excess of 700 clients using our methods
50 staff members all 100% focused on excellence in business
requirements
Annually invested 10% of our revenue in developing our
methods, processes and techniques to assure that these are
harmonized and industry best practices
64
Q&A
Important Information
To claim your PDU credit’s, visit PMI website: www.pmi.org

• PDU Credits: 2 credits (Category 3)
• Provider ID: 1811 (Diversified Business Communications)
• Program ID: WID00052
2 CDU's towards CBAP® recertification

Notice from IIBA: The content of the course are aligned with the BABOK®,
this 2 hr sessions qualifies for 2 CDU's towards CBAP® recertification
65
Q&A
Important Information
Keith Ellis (kellis@iag.biz)

Vice President, Marketing & Strategic Alliances
With:
Brad MacNamara (bmacnamara@iag.biz)
Senior Consultant
IAG Consulting
905 842 0123
THANK YOU
66

7 Secrets To Defining Preparing An RFP Delivery

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7 Secrets To Defining Preparing An RFP Delivery

Uploaded by

Copyright:

Available Formats

7 Secrets to Defining Requirements

for Package Software Selection

Thank you for joining us. We’ll be starting soon!

· Technical Support Problems for this Webinar? webinars@projecttimes.com

SECRET #1 DESCRIBE THE PROCESS

SECRET #2 DESCRIBE THE DATA REQUIREMENTS

SECRET #3 USE THE ‘SUPER’ SME

SECRET #4 FIND THE ESSENTIAL REQUIREMENTS

SECRET #5 FIND THE CRITICAL BUSINESS RULES

SECRET #6 PRIORITIZE THE REQUIREMENTS

SECRET #7 STRUCTURE THE RFP IN BUSINESS TERMS

QUESTIONS AND ANSWERS

Why we are here

Why we are here (continued)

What you will learn

Learning Objectives (continued)

What you will learn

SECRET #1 DESCRIBE THE PROCESS

SECRET #2 DESCRIBE THE DATA REQUIREMENTS

SECRET #3 USE THE ‘SUPER’ SME

SECRET #4 FIND THE ESSENTIAL REQUIREMENTS

SECRET #5 FIND THE CRITICAL BUSINESS RULES

SECRET #6 PRIORITIZE THE REQUIREMENTS

SECRET #7 STRUCTURE THE RFP IN BUSINESS TERMS

QUESTIONS AND ANSWERS

Describe the Process

A request for proposal (RFP) is an invitation for suppliers,

Why create an RFP?

Creating an RFP requires the organization to specify what

Describe the Process

 The organization proposes to purchase a software solution to

Describe the Process

Steps to Describe the Process

A. Define the Scope of Analysis

B. Describe each Use Case

How to Describe the Process

1. Understand the business need at a high level

2. Determine the breadth and depth of the process

3. Determine the Interfaces

How to Describe the Process

 Review all documentation prepared in support of the

 Speak to the key business leaders

How to Describe the Process

 Develop a High-Level Scenario

Develop the High-level Scenario

Determine the list of candidate Use Cases

How to Describe the Process

 Develop a Context Diagram

Determine the Interfaces

Determine the candidate Interfaces

How to Describe the Process

What is a Use Case?

A Business Use Case describes WHAT not HOW

Describe each Use Case

The steps that comprise a use case can be described at

Describe each Use Case

High Level – “The system must display the details of the

Mid Level – “The system must display the details of the

but it does not specify which Order details need to be displayed

Describe each Use Case

Detailed – “The system must display the Products ordered, the

Actor - Verb - Entity - Condition

The organization proposes to purchase a software solution to

Review all documentation prepared in support of the

Speak to the key business leaders

Develop a High-Level Scenario

Develop a Context Diagram

Ask the question in the context of a use case

Define the entity

Discover related data elements

Define the data element

A resource who has significant knowledge of the

As soon as possible in the planning phase of the

all requirements specified during the elicitation

engage the Super SME to assist the business in