REQUIREMENTS

DEVELOPMENT
PLAN
TEMPLATE
VERSION 1.0
 REQUIREMENTS DEVELOPMENT PLAN

This template was created to enable departments to more easily develop their project
plans. The Department of Technology, Consulting and Planning Division, created this
template based on its experiences. The template relies on industry best practices
combined with decades of experience on California state information technology
projects. The way it was structured is to enable a department to complete the
information related to its project without having to write background information
related to the discipline. A department may use as much or as little of the template as it
wishes.

Template Instructions:

 Instructions for completing this template – written for the author of the project
plan - are encased in [ ] and the text is italicized and bolded.
 Examples are provided as a guideline to the type of sample information presented
in each section and the text is italicized.
 Boilerplate standard language for each section is written in the document font and
may be used or modified, as necessary.
 A department’s project specific information goes within the brackets << >>.
 Informational text is italicized within square brackets [ ] for informational purposes
to the person who has to create the plan and includes background information,
explanation, rationale, etc.

Page
8/8/2006
 REQUIREMENTS DEVELOPMENT PLAN

APPROVAL SIGNATURES
CONTRACTOR DATE
<<Deliverable Owner>>
<<Signature>>
<<John Doe, Manager>>

<<Vendor Project Manager>> <<Signature>>

<<Vendor Managing Director>> <<Signature>>

STATE PROJECT MANAGER

Date: <<Date>> To: <<PM NAME>>, Project Manager

I approve this deliverable and have no further questions or comments.

I approve this deliverable conditionally, contingent on the review and approval of the
following corrections (see comments).
I reject this deliverable for the following reasons identified (see comments).

<<SIGNATURE>> <<DATE>>

Comments

Page
8/8/2006
 REQUIREMENTS DEVELOPMENT PLAN

DOCUMENT HISTORY
DOCUMENT APPROVAL HISTORY
Prepared By

Reviewed By

Approved By <<Typically the Project Sponsor>>

DOCUMENT REVISION HISTORY

DOCUMENT
DATE REVISION DESCRIPTION AUTHOR
VERSION
5/1/2014 1.0 Initial Version CPD

Page
8/8/2006
 REQUIREMENTS DEVELOPMENT PLAN

TABLE OF CONTENTS
1. INTRODUCTION............................................................................................................................ 1
1.1. PURPOSE................................................................................................................................................. 1
1.2. SCOPE........................................................................................................................................................ 1
1.2.1. IN-SCOPE.................................................................................................................................................. 1
1.2.2. OUT-OF-SCOPE...................................................................................................................................... 2
1.3. RELATIONSHIP TO OTHER PROJECT PLANS..........................................................................2
1.4. DOCUMENT MAINTENANCE..........................................................................................................3
1.5. REFERENCES......................................................................................................................................... 4

2. ROLES AND RESPONSIBILITIES................................................................................................ 4

2.1. PROJECT EXECUTIVE STEERING COMMITTEE......................................................................4
2.2. PROJECT SPONSORS...........................................................................................................................5
2.2.1. EXECUTIVE SPONSOR.........................................................................................................................5
2.2.2. PROJECT BUSINESS SPONSOR........................................................................................................5
2.3. PROJECT DIRECTOR........................................................................................................................... 6
2.4. PROJECT MANAGER........................................................................................................................... 6
2.5. REQUIREMENTS DEVELOPMENT LEAD...................................................................................6

3. REQUIREMENTS DEVELOPMENT PLANNING.......................................................................7

3.1. IDENTIFY STAKEHOLDERS.............................................................................................................8
3.2. IDENTIFY AND PLAN ELICITATION APPROACH...................................................................9
3.3. IDENTIFY AND PLAN ELICITATION DOCUMENTATION................................................11
3.4. SCHEDULING REQUIREMENT ELICITATION ACTIVITIES AND TASKS....................12

4. REQUIREMENTS DEVELOPMENT PROCESS.......................................................................12

4.1. ELICITING STAKEHOLDER REQUIREMENTS.......................................................................13
4.1.1. ELICITING STAKEHOLDER REQUIREMENTS TASK...........................................................13
4.2. DEFINE ADDITIONAL STAKEHOLDER REQUIREMENTS................................................14
4.2.1. DEFINE CONSTRAINTS...................................................................................................................15
4.2.2. DEFINE OPERATION AND SUPPORT ACTIVITY SEQUENCES........................................15
4.2.3. IDENTIFY HUMAN-SYSTEM INTERACTIONS........................................................................16
4.2.4. SPECIFY CRITICAL QUALITIES....................................................................................................17
4.3. ANALYZE AND MAINTAIN STAKEHOLDER REQUIREMENTS......................................17
4.3.1. ANALYZE ELICITED REQUIREMENTS......................................................................................19
4.3.2. RESOLVE REQUIREMENTS PROBLEMS...................................................................................19
4.3.3. PROVIDE FEEDBACK........................................................................................................................20
4.3.4. VALIDATE REQUIREMENTS..........................................................................................................20
4.3.5. DOCUMENT REQUIREMENTS......................................................................................................21
4.3.6. MAINTAIN REQUIREMENTS DATA............................................................................................21

APPENDIX A. REQUIREMENTS CHARACTERISTICS..............................................................A-1

APPENDIX B. COTS, MOTS, CUSTOM CONSIDERATIONS.....................................................B-1

Page
8/8/2006
 REQUIREMENTS DEVELOPMENT PLAN

1. INTRODUCTION
1.1. PURPOSE
The purpose of the Requirements Development Plan is to describe the roles and responsibilities for
the <<Project Name>> Project requirements development effort and define the planning, activities,
and tasks that will be performed as part of this effort. The planning, activities, and tasks include:
planning how the activities will be performed (the processes), defining what approach will be taken
with various stakeholders and stakeholder groups or classes (groups/classes 1) to elicit their
requirements, identifying how the elicited requirements will be analyzed, and defining how the
requirements will be documented, reviewed, validated/approved, and controlled to form the initial
baseline set of Project requirements. The requirements referenced in this Plan are the
requirements that <<will/may>> be included within a Request for Proposals (RFP) 2, which are
generally referred to as stakeholder and system level requirements. For that reason, this Plan
complies with ISO/IEC/IEEE 15288-20083 instead of ISO/IEC/IEEE 12207-2008 as the former is a
Stakeholder/System-level Standard while the latter is a Software-level Standard.

A requirement is defined as, “A condition or capability that must be met or possessed by a system
or system component to satisfy a contract, standard, specification, or other formally imposed
documents” (IEEE 610.12-1990 [R2002]). Therefore, requirements identify, in objective terms, the
criteria that will be used to measure the success of the Project. The main objective or goal in
defining requirements is to communicate to the developing organization what the stakeholders
need.

1.2. SCOPE
1.2.1. IN-SCOPE
The scope of the processes, activities and tasks defined within this Requirements Development Plan
are the following items:

[Identify the list of items that will be included within the scope of this Plan. See below
for examples.]
 The elicitations of requirements for the system from all stakeholders defined in the <<Project
Name>> Project Charter (or include a list of the stakeholders if a Project Plan or the Project
Charter, which may define this list, does not currently exist).

1
The term group/classes, or group/class is used intentionally within this document to be consistent with
industry standards and to express the idea that collections may consist of groups of humans and/or classes of
non-human objects, such as interfaces consisting of real time and batch interfaces which in themselves have
requirements.
2
The State may elect to assume responsibility for some of the requirements and not include them as part of
an RFP. Regardless, they are still Project Requirements and still need to be treated the same as those that are
the responsibility of a vendor.
3
While this Plan adheres to the ISO/IEC/IEEE Standard, the planning, activities, and tasks are more focused
on common sense, experience, and expertise gained from developing requirements for numerous major
systems.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

 The Project Scope, as defined with the Feasibility Study Report (FSR) and Project Charter, shall
be used to limit the scope of the requirements documented in the output of the effort described
within this Plan. If a detailed Scope Statement does not exist, the scope must be defined in
detail in this section because it is essential to moving forwards with requirements
development.
1.2.2. OUT-OF-SCOPE
The following items are not within the scope of this Requirements Development Plan and are
therefore excluded:

[Provide a list of items that are related to Requirements Development but are not
included in this Plan. This includes those which may be identified in other Project
Plans, such as the following:]
 The Requirements Management process, which defines the activities and tasks used to control
and manage changes to the baseline requirements, is not included within this Plan but is
documented in the Requirements Management Plan.

1.3. RELATIONSHIP TO OTHER PROJECT PLANS

[The objective of this Section is to provide the reader with a clear understanding of
how this Plan integrates with the other Project Management disciplines. However, as
this Plan will commonly be one of the first plans created and the durations of the
activities/tasks under this Plan are relatively short, there may not be any other related
documented plans to cite, except for possibly the Project Charter. Therefore, while it
may not be possible to cite other plans, the approach the project will use must be
documented here in order to clarify and communicate how the activities and tasks
identified in this Plan will be executed and communicated to the project stakeholders.
Describe the relationship of the Requirements Development Plan to the other Project
Plans that have been or will be created for the Project. This can be done multiple ways,
in text by identifying the other plan and how they are related, or graphically. For
example:]
Requirements Management Plan:
 The Requirements Management Plan identifies the process and controls that will be enforced
on the Project to manage changes to the requirements baseline. Once requirements are
created and finalized by this Plan, they will be formally baselined, and as shown in , the
baseline requirements will be managed and controlled from change by the Requirements
Management Plan for the remainder of the Project.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

Figure : Relationship between Requirements Development and Management

Schedule Management Plan

 [Describe how the activities, tasks, and resources necessary to perform this
effort will be documented and managed under Schedule Management. If a
Schedule Management Plan does not yet exist, describe how the Requirements
Development activities and tasks will be captured and documented in the
project schedule and how it will be maintained under the umbrella of Schedule
Management.]
Communications Management Plan

 [If one exists, describe how the communications with the stakeholders will be
managed between the needs of this Plan and the communications described in
the Communications Management Plan.]
Governance Plan

 [Describe how conflicts/issues between -requirements will be handled and how

the baseline requirements will be validated and approved in accordance with a
Governance structure.]

1.4. DOCUMENT MAINTENANCE

This document will be reviewed <<quarterly>> and updated as needed. Since the Requirements
Development effort may be a relatively short duration effort, compared to the development life
cycle, lessons learned are not as applicable for driving updates to this Plan. However, this Plan does
need to be consistent with the activities and tasks actually performed to support overall lessons
learned for future Projects. Therefore, if changes to the Requirements Development activities and
tasks occur or if Requirements Development Plan changes are driven by other Project Management
Plans as they are developed, this Plan will be updated.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

This document contains a Revision History Log. When changes occur, the version number will be
updated to the next increment and the date, change description, and the author who made the
change recorded in the Log.

1.5. REFERENCES
The following are references used in the creation of this Plan:

 IEEE 610.12-1990 [R2002], IEEE Standard Glossary of Software Engineering Terminology

 ISO/IEC/IEEE 29148:2011(E), Systems and software engineering - Life cycle processes –

Requirements engineering

 ISO/IEC 15288:2008(E), IEEE STD 15288-2008, Systems and software engineering - System
life cycle processes

[Only list the references that are actually used and cited within this document.]

2. ROLES AND RESPONSIBILITIES

[Identify the individuals and groups and describe their specific roles and
responsibilities for Requirements Development. This is not meant to be a job
description of what the individual or group does on the Project but rather a summary
of the roles and responsibilities with respect to Requirements Development.
Below is a listing of the most commonly used project individuals/groups that should be
considered, though all may not necessarily be needed for a specific Project, and others
may need to be added based on the specific Project. Projects must clearly identify the
roles and responsibilities associated with each. However, do not be generic, meaning,
do not identify responsibilities such as “among the reviewers of …” as this does not
convey any ownership responsibility. If there are groups, such as an Executive
Steering Committee or reviewer groups, then identify the groups and cite where the
members of the groups are defined, (e.g. the Project Charter, Deliverables
Management Plan, etc.) Also, do not duplicate roles and responsibilities that are part
of and defined within another Project Management Plan, such as the approver of a
Change Request should be defined in the Change Management Plan so do not repeat it
here; as the role and responsibility changes in the life cycle, it will be difficult to keep
multiple plans consistent.]

2.1. PROJECT EXECUTIVE STEERING COMMITTEE

2.1.1. ROLE
The Executive Steering Committee’s role is to provide the final approval of the Project
requirements.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

2.1.2. RESPONSIBILITY
Their responsibility is to understand the approach used to elicit the requirements from all of the
Stakeholders as well as the approach used to develop and finalize the requirements. Then, when
presented with the requirements, they will review a representative sample of the requirements to
provide the final level of assurance that the requirements will communicate the stakeholders’ needs
to any potential vendor. If the requirements are deficient, they will identify issues and problems
that need to be corrected. Once acceptable, the Executive Steering Committee will be responsible
for approving the Project requirements, which will then become baselined and fall under formal
Requirements Management control.

2.2. PROJECT SPONSORS

2.2.1. EXECUTIVE SPONSOR
2.2.1.1 ROLE
The Executive Sponsor’s role is to ensure this Plan is executed in a timely and efficient manner and
that the objectives are achieved.

2.2.1.2 RESPONSIBILITY
The Executive Sponsor will provide the necessary support to the Project Manager to ensure that
resources are available to support the execution of this Plan and to provide the advocacy to all of
the internal and external units and organizations that are required to participate in the
requirements development effort.

2.2.2. PROJECT BUSINESS SPONSOR

2.2.2.1 ROLE
The Business Sponsor’s role is to provide the overall business leadership to ensure the
requirements meet the needs of all users.

2.2.2.2 RESPONSIBILITY
The Business Sponsor is responsible for ensuring that this Plan identifies an approach that will
addresses all of the organizational business users, their needs, and the organization’s business
support needs (e.g., Legal, IT Operations, Public Relations, etc.). The Business Sponsor also
provides advocacy to the business and support components of the organization to ensure that the
documented requirements will meet the overall organization’s needs. Ultimately, the Sponsors
(Business and Executive) are responsible for approving this Plan and ensuring that the activities
and tasks are executed by the Project Manager.

2.3. PROJECT DIRECTOR

2.3.1. ROLE
The Project Director’s role is to provide support for the Project Manager by aiding in the removal of
obstacles and resolving issues or problems during the development of the project requirements
that are beyond the control of the Project Manager.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

2.3.2. RESPONSIBILITY
The Project Director is responsible for tracking the progress of the requirements development
effort, identifying significant deviations, and assisting the Project Manager in resolving obstacles,
issues, and problems in order to keep the effort on schedule without compromising the quality
(completeness, correctness, readability, etc.) of the resulting requirements.

2.4. PROJECT MANAGER

2.4.1. ROLE
The Project Manager’s role is to plan, schedule, resource, monitor, and track the progress of the
requirements development effort.

2.4.2. RESPONSIBILITY
The Project Manager is responsible to work with the Requirements Development Lead to review
the requirements development approach, verify that all stakeholders are accounted for and the
planned elicitation approach appears sound for each, and ensure that the tools necessary to
develop, document, and maintain the requirements throughout the process are available. The
Project Manager will schedule the activities, tasks, and resources necessary to execute the effort
and monitor and track the execution. If obstacles, issues, or problems arise, the Project Manager
will either resolve them or escalate them to the Project Director or Sponsors for resolution.

2.5. REQUIREMENTS DEVELOPMENT LEAD

2.5.1. ROLE
The Requirements Development Lead’s role is to lead or perform the activities and tasks defined
within this Plan.

2.5.2. RESPONSIBILITY
The Requirements Development Lead is responsible for executing all of the activities and tasks
within this Plan and complying with the planned process. The Lead will work with the Project
Manager to define and identify the resources needed to accomplish each activity and task, verify the
tools are available, and assist in the scheduling of the execution of the effort.

3. REQUIREMENTS DEVELOPMENT PLANNING

[Key to planning the requirements development effort is to understand the number of
stakeholders and stakeholder classes/groups1 that must be elicited to develop the
stakeholder and system requirements. In addition, the elicitation approach may, and
likely will, be different for different stakeholders and stakeholder classes/groups.
Therefore, it is important to plan how the requirements will be elicited for each
stakeholder and stakeholder class/group.
1
Stakeholder classes/groups are groups of individuals with a shared or common interest in the system; often
they perform the same business function for an organization, such as a Cashiering group or information
technology Support group.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

The selection of an approach is determined by understanding of the individual

stakeholders and stakeholder class/group composition and how they may be best
approached to elicit their requirements. It is also important to plan for iteration
and/or the re-execution of tasks when performing requirements elicitation, also called
elicitation recursion. Rarely will stakeholders be able to identify all of their
requirements in a single iteration or meeting. Therefore, when planning the
requirement elicitation, consideration must be made for the number of iterations
necessary to achieve the level of requirements’ specificity necessary to define the
stakeholders’ needs2. Further, each iteration cycle may use a different approach with
differing objectives, as illustrated in , with respect to the level of detail being defined
during each iteration cycle. Changes to the approach and the planned level of
requirements detail that will be elicited and collected at different iteration levels must
be planned.
The State Technology Approval Reform Project, specifically the Stage Gate process, will
dictate when specific requirement types must be submitted to proceed past a Stage
Gate. The Requirements Development planning must take into account what types of
requirements must be submitted for each gate.]
This section identifies the planning that has been performed to prepare for the Requirements
Development effort. The planning identifies the stakeholders, the approach that will be used to
elicit requirements from each stakeholder or stakeholder group/class, how the elicited
requirements will be documented, how the elicitation sessions will be scheduled, and progress
tracked and reported to the stakeholders.

2
Again, this is for planning purposes; the actual number of iterations and/or recursions will be determined
by the ability to elicit the requirements and the completeness obtained.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

Define Process
Data & Rules

Define Process
Requirements

Iteration 3 Iteration 2 Iteration 1 Develop Process

Flows

Document
Processes

Document Process
Requirements

Document Process
Data & Rules

Figure : Conceptual View of Iteration with Differing Levels of Detail3

3.1. IDENTIFY STAKEHOLDERS

The individual stakeholders and stakeholder groups/classes that have a legitimate interest in the
system throughout its life cycle have been identified, verified, and validated.

[Add a paragraph to identify how these stakeholders and stakeholder classes/groups

were identified, verified, and validated to ensure this list is complete and there are no
stakeholders missing and no unnecessary stakeholders identified.]
The following table identifies the stakeholders and stakeholder groups/classes for the Project and
their interest in the Project execution and/or the artifacts produced.

The following are examples:

Stakeholder Interest
XYZ Unit As a user of the system, they have an interest in ensuring that the system
performs the XYZ functionality necessary for the unit to perform their business
function and that reports can be generated.
Chief Deputy As an Executive Sponsor, he/she has an interest in ensuring the Project cost,
3
While Figure 2 is not meant to imply a “Spiral” software development model, it does result in a similar effect
of reducing risk through each progressive spiral. In this case, it helps to reduce the risk that the requirements
will be incorrect or incomplete.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

Stakeholder Interest
Director schedule, quality, risks and issues are carefully monitored, managed, and that
…
Cashiering Unit …
IT Support Unit The IT Support unit has an interest in ensuring the system can be supportable
by the organization and that all artifacts delivered will be usable and
accurately reflect the procedures necessary to be supported by the units’
resources.
Enterprise The EA has an interest in ensuring the new system will meet the performance
Architect (EA) and other operational needs of the organization.
Training Office The Training Office has an interest in ensuring that the system documentation
and training material is developed, with appropriate tools available as
necessary to train all of the impacted stakeholders.
Project The PM has an interest in managing the execution of the Project and ensuring
Manager that there are sufficient artifacts created and delivered that will allow the
necessary tracking, managing, and reporting for the Project.
Etc. …

CalTech CalTech has an interest in the Project by ensuring ….

DOF …

[Identify all of the stakeholders and their interests in the Project. Ensure you not only
look at the development effort but also the maintenance and operations and other
post-deployment users. If the Project developed a Product-based work breakdown
structure (WBS), this would be an excellent starting point for identifying these
stakeholders. Think about the notion that these stakeholders will be elicited for
requirements for their area of interest. However, do not identify specific products,
such as a System Administration Manual for the IT Unit, but focus on the types of
products and services. From a WBS perspective, this would be a level-2 or level-3 view
of the products and/or services.]

3.2. IDENTIFY AND PLAN ELICITATION APPROACH

For each stakeholder and stakeholder group/class identified in Section , the following approach will
be used to elicit their requirements. As noted previously, the elicitation process may be iterative
and/or recursive and repeated as necessary to ensure all of their requirements have been captured.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

The following are examples:

Stakeholder Elicitation Approach and Iteration/Recursion

XYZ Unit The initial approach that will be used is a top-down business decomposition
method. Business process flows will be developed for the “as-is” process. User
required changes to this “as-is” process will also be documented. This will be
the first level of iteration.
Then, “as-is” Use Cases will be developed that will identify and document the
unit’s interactions with the system.
…
Chief Deputy Requirements will be elicited by a meeting with the Chief Deputy Director to
Director identify/describe the specific data he or she expects to be generated and
reported on by the Project to the Chief Deputy Director, the frequency of
reporting, and the criteria for exception reporting. The frequency of reporting
….
Cashiering Unit …
IT Support Unit Requirements will be initially elicited through the requirements teams’ review
of the IT Units’ organizational procedures and manuals where initial
requirements shall be captured.
Then, additional meetings will be held that will review the existing Units’
processes and procedures, which shall then be validated.
Through the use of recursive requirements brainstorming sessions where each
step of the Units’ process is reviewed, additional requirements will be elicited.
….
Enterprise …
Architect (EA)
Training Office …
CalTech …
DOF …

[There are literally hundreds of techniques and methods that can be used to elicit
requirements, though most involve some form of an interviewing technique. Note that
not all techniques work well with all stakeholders; the Project must understand the
stakeholders and stakeholders classes/groups and identify an approach suitable for
the specific stakeholder or class/group. As an example, a top-down business process
model to detail user interactions, data, and rules might work well with specific
business users but this same approach would not work well for an Executive Sponsor
or the IT organization that may be maintaining the solution. For ideas, reference the

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

ISO/IEC/IEEE Standards as well as documents such as the Business Analysis Body of

Knowledge (BABOK).
For the specific Project, clearly identify the technique(s) that will be used for each
stakeholder or stakeholder group/class and plan for iteration and refinement of the
technique as more is known about the needs. While elaborate models are discussed in
literature and standards, understand your stakeholders and determine what will work
best for them.]

3.3. IDENTIFY AND PLAN ELICITATION DOCUMENTATION

[Define how the requirements and supporting artifacts will be documented and how
and where they will be stored.]
As each identified stakeholder and stakeholder group/class is elicited, the requirements and
supporting artifacts shall be documented in various forms and formats. In the early iterations, it is
anticipated that the documentation created will be primarily graphical in nature, such as flow
charts, pictures from white boards, etc. These types of documents will be captured in the form that
they were developed (e.g., Visio, PowerPoint, photo (jpeg), etc.). However, as the requirements are
refined, they will be documented in a MS Word format to allow for later analysis. When
documenting requirements at all levels, the requirement context will always be kept with the set of
requirements being collected.

[The Project needs to define the format and structure of the final elicited requirements
documents, which are the documents that will be provided to the requirements
analysis activity. This is important for a number of reasons: 1) it establishes a
common and consistent expectation of the types of data that must be collected for each
context area; 2) it supports the analysis activity and tasks by providing a consistent
input into the categorization and filtering of requirements defined in section ; 3) it
reduces the amount of re-writing that the analysis team will need to do to ensure
context and requirements sets are defined; and, 4) it simplifies the identification of
missing or incomplete requirement sets during both elicitation and analysis. While
the Use Case approach to documenting the final elicited requirements is identified
here, any artifact that keeps the requirements context with the set and types of
requirements elicited is sufficient.]
The final requirements document for each requirements context area will be documented in Use
Cases in accordance with the template provided in <<define where the template is located>>.

All of the requirement artifacts collected shall be stored in a secure repository, <<identify where>>.
The artifacts that will be captured will consist of all tools, techniques, diagrams, flow charts, photos,
documents, files, etc. that were used in the elicitation process. While some of these artifacts will be
used as reference later during the analysis activity, others will be formalized to define or support

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

the requirements and will be incorporated into the final requirements document (e.g., the baseline
requirements document).

During the elicitation effort (as further defined in Section ), the collected requirements will not be
reviewed or analyzed in any way other than to ensure that the captured requirements are clear,
complete, and understandable. Section identifies the specific effort to analyze the requirements
based on the artifacts captured and stored.

3.4. SCHEDULING REQUIREMENT ELICITATION ACTIVITIES AND TASKS

[As with all activities and tasks, they must eventually be scheduled and the resources
allocated to ensure the outcome meets the needs of the Project. Based on the above
information, identify how the actual activities and tasks will be scheduled and
resources committed to accomplish the objectives of the requirements development
effort. This becomes very important as the Project has likely not been in the mode of
managing to a schedule since this effort is very early in the Project. So, if a Project
schedule does not exist or is not being actively managed, define how the Project will
schedule the activities, tasks, and resources necessary to execute this Plan.
Also include information on how progress will be managed, tracked, and reported to
the Project Manager and stakeholders.]

4. REQUIREMENTS DEVELOPMENT PROCESS

Requirements Definition (aka Requirements Development) is defined within ISO/IEC/IEEE 29148-
2011 and 15288-2008 as having the following purpose:

“It [the Stakeholder Requirements Definition process] identifies stakeholders, or

stakeholder classes, involved with the system throughout its life cycle, and their needs,
expectations, and desires. It analyzes and transforms these into a common set of
stakeholder requirements that express the intended interaction the system will have with
its operational environment and that are the reference against which each resulting
operational service is validated.”

To accomplish this purpose, the Requirements Development process defined within this Plan
includes the following elements:

 Eliciting stakeholder requirements

o Including identifying1 stakeholders and stakeholder classes and working with them
to define the requirements.

 Defining stakeholder requirements

1
The identification of stakeholders and stakeholder classes/groups was done in Section .

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

o Defining constraints, activity sequences, interactions between stakeholders, and

non-functional needs.

 Analyzing and maintaining stakeholder requirements

4.1. ELICITING STAKEHOLDER REQUIREMENTS

The referenced ISO/IEC/IEEE Standards define the first task within this activity to be:

“Identify the individual stakeholders or stakeholder classes who have a legitimate interest
in the system throughout its lifecycle”.

This task was identified under Requirements Development Planning, Section , to support the
planning for the overall Requirements Development effort, which must consider the number of
stakeholders that will be involved.

The other task under this activity is the actual elicitation effort, which can be viewed as the
execution of the planned activities and tasks of elicitation with the identified stakeholders and
stakeholder classes/groups.

4.1.1. ELICITING STAKEHOLDER REQUIREMENTS TASK

[This section must identify how the planning will be executed and how supplementary
information will be maintained. While this is typically the largest effort for
requirements development, the planning was done in the previous section so this
section only needs to address the execution and support items, such as agendas,
meetings, issues, action items, minutes, preparation material, distribution, etc.
This section defines how the meeting(s) with stakeholder and stakeholder
classes/groups will be held. Stakeholder requirements will be identified, documented
and controlled as defined in Section . During elicitation, the objective is to have the
stakeholders identify their needs, wants, desires, expectations, and perceived
constraints for the system. The objective is not to perform any pre-screening or
analysis during the elicitation activity; the analysis effort is performed later in the
Requirements Development process.
For example, to elicit requirements from the stakeholders and stakeholder classes or
groups, meeting(s) will be held, in accordance with the schedule for each stakeholder
and stakeholder class/group being elicited. During each meeting, the identified and
planned requirements elicitation approach, as further described within this Section,
will be used and the requirements will be documented. As meetings are held, it is
expected that a large number of issues and/or action items will be identified. These
issues and action items will be captured and documented in meeting minutes and
tracked by the Requirements Development Lead.
A meeting agenda may consist of:

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

 Introduction, Schedule, Procedures, and Expectations

 Review of Open Issues, Action Items, Suspense Dates, Status
 Overview of Approach to be Used for this Meeting
 Elicit requirements by executing the defined approach
 Review of Captured documentation
 Review of new Issues, Action Items, Suspense Dates
 Set Expectations for Next Meeting and/or Follow-up Efforts
While the meetings with specific stakeholders and stakeholder classes/groups may
differ significantly based on the stakeholder and the approach planned, the intent of
this general agenda is to prepare the users for what will be going on during the
meeting, how the meeting will be conducted, and what the standard processes are for
review of any previous open items, elicitation of requirements, and approval of
documented changes, as well as any follow-up validation of requirements. It is simply
to communicate to the stakeholders what is going on and what is planned for the
future.]
[Identify how Issues, Action Items, and Suspense Dates will be documented.]
[Identify how conflicts will be resolved within stakeholder classes/groups. While the
requirements should not be analyzed during elicitation, conflicts can also arise
between individuals within a stakeholder class/group. Therefore, a general approach
should be defined to resolve conflicts within a class/group. Section addresses conflicts
between stakeholders and stakeholder classes/groups.]
[Identify how the meeting minutes and meeting artifacts will be captured, maintained,
and verified with the stakeholders.]
All of these artifacts will be used for later analysis to define the formal stakeholder/system
requirements and to support requirements traceability under the Requirements Management Plan
processes.

4.2. DEFINE ADDITIONAL STAKEHOLDER REQUIREMENTS

Within this section, there are tasks and/or statements that define constraints on the requirements
and aid in identifying requirements that are commonly missed during the requirements elicitation
effort. These tasks/statements support both the requirements elicitation task in Section as well as
the analysis activity in Section .

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

4.2.1. DEFINE CONSTRAINTS

The following identifies constraints on the system that must be captured in the form of system
requirements. While these constraints in themselves are typically not suitable as requirements,
they shall be used to define or derive requirements for the system.

[Identify the constraints on the system/solution. These constraints may come from a
variety of sources but are commonly identified within an FSR or other project approval
documents or from Departmental internal decisions. The constraints identified here
will be used as the “filters” when performing the requirements analysis effort and
therefore the more complete they are, the more useful they will be when reviewing the
requirements elicited. Typical and common examples include:
 The system/solution must be hosted within the OTech Managed Services
environment.
 Existing legacy system data exchange interfaces with external trading partners
shall not be modified or changed in any way.
 The system/solution must be consistent with and use the operating systems,
databases, and programming languages currently supported by the
Department.]
4.2.2. DEFINE OPERATION AND SUPPORT ACTIVITY SEQUENCES
The following identifies operational and support scenarios that are out of the normal or routine
business processing flows. These scenarios aid in identifying additional system requirements
necessary to meet the unusual or non-routine needs of Project stakeholders. The intent of adding
these scenarios is to broaden the view of the requirements that need to be defined for the project.

[Define a representative set of operation and support scenarios. These are not
business process flows of other business-related scenarios. The objective of these
scenarios is to aid in potentially identifying requirements that may not have been
identified by any stakeholder or stakeholder group. Examples would include scenarios
related to availability of the system, especially around key periods such as the end-of-
the-month reporting, legal audits that may be performed, Public Record Act (PRA)
requests, public-facing attempts to hack the system, user interactions with the system
for training purposes, etc. These are primarily non-functional types of scenarios that
are looking at the system as a “black box”.
As an example:
Scenario X: The Department’s Legal Office (Source) has received a Public
Records Act request (Stimulus) for business license data. The system is in
normal operations mode (Environment Conditions) and the Legal Office
accesses the Reporting subsystem (System Artifact Involved) and generates a

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

report (Response) that provides the requested data. The data included within
the report only includes data that is publicly releasable and complies with all
legal statutes (Response Measure).
From this sample, while the Legal Office may have been identified as a stakeholder,
this scenario is used to help ensure that all of the necessary requirements to cover
such a situation are identified.
While it may appear difficult to develop such scenarios, the best approach is to draw
the system as a box on a whiteboard and ask what could happen to the system, from
the operation and support perspectives and then from different stakeholders’
perspectives. Start with brief scenarios (e.g., “external hackers attempt to force a
denial-of services”, “regional power outage”, “major technology supplier goes out of
business”, “end-of-month and the system goes down”), and further elaborate on those
scenarios that appear reasonable or could potentially become real that the system
development needs to consider; never delete any identified scenario but simply archive
the ones that are not expanded. Document the resulting scenarios within this section.
Again, the objective is to try to find gaps in requirements that may be missed by
eliciting requirements from the stakeholders. By documenting the scenarios in this
section, additional attention will be focused on ensuring that the requirements
necessary are defined or, during analysis, gaps identified. This effort will never be
100% complete and perfect; however, the more gaps found early, the easier they can
be closed.]
4.2.3. IDENTIFY HUMAN-SYSTEM INTERACTIONS
The following identifies the high-level requirements for the interfaces between human users and
the system to be developed. Information systems have a significant human-to-system interface
(visual and well as manual) and the requirements for these interactions must be elicited and
documented.

[Included in this section are the usability requirements that must be considered for the
system. Typically, this is not a long list of items but for some systems there may be
unique human-system interactions that must be specified. An example of a typical
requirement for Web-accessible systems is a requirement for Section 508 (29 U.S.C.
‘794 d) and/or W3C Web Content Accessibility Guidelines 1.0 compliance. Other
examples may include different levels of training and/or resource skills available to
use, maintain, and operate the system. Identify either the human-system interaction
requirements or the approach that will be taken to identify these usability
requirements. Again, these are typically requirements that are missed when eliciting
requirements from the stakeholders.]

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

4.2.4. SPECIFY CRITICAL QUALITIES

[In this section, identify if there are any areas that are deemed “critical”. For example,
a system that is externally facing that also holds personally identifiable information
(PII) data may have security as a critical requirement. While these requirements
should have been identified in Section , there may be a small subset that would be
identified as critical, which are mainly security related for State IT systems. If there
are, identify and/or reference them here.]

4.3. ANALYZE AND MAINTAIN STAKEHOLDER REQUIREMENTS

Once the requirements have been defined and elicited, all of the requirements will be analyzed and
maintained. Requirements analysis involves a series of steps and the approach that will be used is
illustrated in .
illustrates that all of the requirements so far elicited and defined, at the top of the Figure, will be
reviewed and placed into sets, which are groups of common requirements related to a specific
business or other context; if the elicitation process defined above kept the requirements context
with the requirements collected, this step is typically a relatively simple effort, especially if Use
Cases or a similar requirements documentation approach was used. To perform this filtering and
the creation of requirement sets, the controlling inputs are the requirements context artifacts
collected during elicitations, such as the business process flows, stakeholder classes/groups,
defined scenarios, operations and support approaches, etc. The objective of this initial filtering and
setting approach is to allow a more exhaustive and complete analysis to identify missing or
incomplete requirements later in the analysis process; it is virtually impossible to analyze and find
missing, incomplete, conflicting, or other requirement problems in a large number of individual
requirements without partitioning them into subsets around some common context prior to the
analysis. The result is a collection of requirements grouped in sets and each set has its own unique
context (e.g., a business context for cash management, or patient in-processing). Besides being
necessary to perform analysis, it is also critical that the requirements context be captured with the
requirements sets in order to facilitate reviews with the stakeholders, and to provide improved
communications to potential vendors when defined within an RFP.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

Figure : View of Requirements Analysis

The initial requirement sets will then pass through another filter that reviews each individual
requirement to verify that the requirement text is well formed, meaning the requirement does not
use ambiguous words, it is complete, readable and correct (within the requirements set context),
and generally adheres to the controlling inputs, which are characteristics of individual
requirements defined in .

The results of this final filtering stage are sets of well-formed individual requirements, again with
the requirements context retained. Each set is then analyzed to verify that the set as a whole is well
formed, as defined in , and to identify missing requirements, conflicts between requirements within
the set, level-setting2 of requirements within the set, the identification of prioritizations, and other
attributes.

2
Level-setting of requirements simply means that the requirements within a set are specified at roughly the
same level of detail, except where necessary to be otherwise.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

For each requirement, the following attributes will be set:

[The Project should define the attributes that will be set at this step. Attributes are
simply a method for characterizing requirements, which can be used to support other
activities, such as testing for high priority or criticality requirements, or for reporting.
provides a sample list of potential attributes that should be considered.]
After this analysis, problems in the form of requirements gaps in completeness, conflicts or
inconsistency, affordability (not just from a cost perspective, but schedule, risk, M&O, etc.), scope,
etc. will be identified. These problems will be resolved with the stakeholder and stakeholder
class/group that provided the requirement for the requirement context identified with the
requirements set. If conflicts exist between stakeholders or stakeholder classes/groups, they will
be resolved in accordance with the method defined in Section . Once resolved, each requirement
set, including the requirements set context, will be reviewed per Section , and validated per
Section , with the stakeholder and stakeholder class/group that has a legitimate interest in the
requirements.

Once validated, the requirements sets, with all reference material will be baselined and provided to
the Requirements Management process to control per Sections and .

4.3.1. ANALYZE ELICITED REQUIREMENTS

[The Project needs to define how they are actually going to perform each of the steps
identified above based on the artifacts that they will collect from the requirements
elicitation effort and other requirements either captured within this document or
through other defined means. Minimally, define 1) how requirements will be grouped
within sets with the same requirements context, 2) how individual requirements will
be analyzed to ensure they are well-formed, and 3) how each set will be analyzed to
ensure the sets are well-formed.]
4.3.2. RESOLVE REQUIREMENTS PROBLEMS
[The Project needs to identify the approach they will use to resolve problems identified
in the analysis step. It is extremely important to always keep the requirements context
in mind when resolving problems as well as the entire set of requirements; do not
attempt to identify missing requirements with the stakeholders without presenting the
requirements context and the requirements that already have been identified for the
set as this will result in requirements being identified that will likely be inconsistent
with the other requirements in the set. The resolution of problems should not result in
the need to re-work the analysis effort.
It is important to understand that requirements negotiation can be used as a tool.
Negotiation might be needed among stakeholders requiring mutually incompatible
features, or when there are conflicts between desired performance requirements,
constraints, available budget, and delivery schedule.

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

This section must also identify how conflicts between stakeholders and stakeholder
classes/groups will be resolved.
Regardless of how the problems are resolved, the Project must identify that records
will be kept on how they were resolved and by whom or what the agreement was.]
4.3.3. PROVIDE FEEDBACK
[Sometimes agreements cannot be reached on conflicting requirements, unrealistic
requirements will not be changed, or continually requested requirements are beyond
the Project scope. The Project needs to define how these will be handled. If the Project
has an issue management or an escalation process in place, these might be cited.
However, if neither of these exists at this point in the Project, an approach must be
defined within this Plan.]
4.3.4. VALIDATE REQUIREMENTS
[Describe how the Project plans to validate the requirements. As stated previously, it is
important to keep requirement sets and their context together when performing any
requirements validation effort; validation should not be simply a review of a long list
of individual requirements as context adds significant value for understanding what is
specifically being required.
The most common way to validate requirements is by performing a series of
requirements reviews that are focused on the requirements context and the individual
requirements within that context. For example, a requirements review session context
may be for patient in-processing and all of the requirements related to this context will
be reviewed and validated. As always, issues or action items are likely to be generated
from these meetings so this section must define how these will be captured, tracked,
and resolved.
Finally, the sign-off or formal acceptance or approval of the requirements and issues
or action items must be described within this section; this sign-off or formal
acceptance or approval must be made by the stakeholders that have an interest in the
requirement context and the individual requirements documented.]
4.3.5. DOCUMENT REQUIREMENTS
[This section must identify the documentation that will be kept and maintained
throughout the requirements analysis effort, which will also end up being passed to
the Requirements Management process for tracking and controlling. While a Project
may consider keeping little documentation other than the final requirements, it is
important that the document necessary to support the attribute assessments, at a
minimum, be retained. For example, documentation related to the source of the
requirement(s), a requirements priority, issues related to a specific requirement such

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

as the stakeholders’ firmness or uncertainty may relate to a volatility attribute, etc.

The Project must consider the attributes that will be kept of the requirements and
minimally identify the documentation necessary to support these attributes and
identify them within this section.
Also include here how the final document will capture context in addition to just the
requirements. For example, specify if Use Cases or other types of documents will be
used that capture the requirements context, requirements data, business rules, etc.
Again, these are the artifacts that will form the initial baseline set of requirements
that will end up being incorporated into an RFP. Therefore, they must communicate
the stakeholders’ needs to potential vendors who may not have any understanding of
the stakeholder processes or needs, which is why keeping the requirements context
with the requirements is so important and stressed throughout this Plan.]
4.3.6. MAINTAIN REQUIREMENTS DATA
[The Project must identify how the requirements, requirements sets, set context, and
all additional supporting information will be delivered to the Requirements
Management process. While the resources performing both requirements
development and requirements management may be the same, from a process
perspective, they are different processes. The main point to this description is for
specifying how this “snapshot in time” of the requirements will be captured in order
for the transferred artifacts to be complete. In practice, requirements are typically
approved incrementally and transferred as each set is approved. Therefore, if this
approach is going to be used, it must be described here. However, a word of caution is
that once passed to the requirements management process, the requirements are
baselined and cannot be changed without change control procedures being followed.
So, if an approved requirements set is passed to requirements management and a
later review of a different set identifies a problem with the set already approved and
baselined, then a change request should be created. By following the process
described within this document regarding keeping requirements in sets with each set
having a consistent and non-overlapping context, this risk is low.]

APPENDIX A. REQUIREMENTS CHARACTERISTICS

The ISO/IEC/IEEE 29148-2011 Standard identifies requirements characteristics for
individual requirements and requirement sets as well as requirement language criteria and
requirement attribute examples. While the Standard cannot be reproduced here due to
copyright restrictions, the following is a high-level list of the areas defined within the
Standard.
5.5.2 Characteristics of individual requirements

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

 Necessary
 Implementation Free
 Unambiguous
 Consistent
 Complete
 Singular
 Feasible
 Traceable
 Verifiable
5.2.6 Characteristics of a set of requirements

 Complete
 Consistent
 Affordable (not cost-wise but within constraints)
 Bounded
5.2.7 Requirement language criteria

 State “what” is needed and not “how”

 Avoid vague and general terms, such as:
o Superlatives
o Subjective language
o Vague pronouns
o Ambiguous adverbs and adjectives
o Open-ended, non-verifiable terms
o Comparative terms
o Loopholes
o Incomplete references
o Negative statements
5.2.8 Requirement attributes

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

5.2.8.1 Examples of requirements attributes

 Identification
 Stakeholder Priority
 Dependency
 Risk
 Source
 Rationale
 Difficulty
5.2.8.2 Examples of requirements type attributes

 Functional
 Performance
 Usability/Quality-in-Use
 Interface
 Design Constraint
 Process
 Non-Functional
 Quality
 Human Factors

Page of 21
 REQUIREMENTS DEVELOPMENT PLAN

APPENDIX B. COTS, MOTS, CUSTOM CONSIDERATIONS

The following chart identifies requirements development considerations that must be
accounted for based on the type of solution being considered or solicited:
CONSIDERATIONS FOR COTS, MOTS, AND CUSTOM IMPLEMENTATION

 For COTS products, the requirements are defined in as-is terms with
respect to business processes and other organizational processes. One
of the most important requirements to put on contracts are the
Organizational Change requirements and one of the first deliverables
from the vendor should be the mapping of the as-is to the to-be
COTS processes, with the to-be processes an approval item. This deliverable
must be provided as early as possible but it must be complete, mapping
all of the critical steps, data collection elements, and all other critical
items from the as-is to the to-be process. This is needed early to support
the organizational change work that must be performed to prepare the
users for the change.

 MOTS essentially follows the same process as COTS, developing

MOTS requirements and processes with respect to the as-is organizational
processes.

 This document was written to directly support a custom implementation;

CUSTOM
there are no additional considerations that need to be taken into account.

Page