- 1. Requirements ManagementProcess GuideDraftThis document
prepared and owned by [Business Owner, Business Transition Manager
or Appointed Reviewer (name & position)]
[Agency/Organization/Division Name][PROJECT NAME]VERSION:
[VERSIONREVISION DATE: [DATE]NUMBER]Executive Sponsor [Name]
[Email][Telephone] Signature:Date:Project Manager/Business
Transition Manager/Communication Officer [Name] [Email][Telephone]
Signature:Date:Stakeholder/Stakeholder Group [Name]
[Email][Telephone] Signature:Date: ESS/PCoEPage 1 of 25
2. Table of Contents Process
Overview.........................................................................................4
Purpose.....................................................................................................5
Stakeholder...............................................................................................5
Stakeholder
Need......................................................................................5
Process.....................................................................................................6
Define
Requirements....................................................................................7
Purpose.....................................................................................................7
High-Level
Requirements..........................................................................7
Requirements Traceability Matrix
(Optional).............................................7
Process.....................................................................................................8
Analyze
Requirements.................................................................................9
Purpose.....................................................................................................9
Process...................................................................................................10
Verify
Requirements...................................................................................12
Purpose...................................................................................................12
Verify and
Validate..................................................................................12
Baseline
..................................................................................................12
Process...................................................................................................12
Manage Requirement
Changes..................................................................14
Manage...................................................................................................14
Process...................................................................................................15
Process Inputs and
Outputs.......................................................................17
Stakeholders...............................................................................................19
Example Listing of System Stakeholders
...............................................19 Roles &
Responsibilities.............................................................................21
References.................................................................................................25
ESS/PCoEPage 2 of 25 3. IntroductionThe purpose of this document is
to provide guidelines, tips, and techniques helpful in the
requirements management process.Requirements have many different
purposes in the lifecycle. They begin as high level needs of the
users. As the system is defined they become an abstract solution
describing the functions the system must perform to solve the users
problems. Eventually they become a list of the components that must
be built. At each level the requirements emerge in a slightly
different form.The steps of the requirements management process
interact with each other and with other project management and
development processes. Each process may involve effort from one or
more individuals or groups of individuals, based on the needs of
the project. Each step in the requirements management process will
occur at least once in a project, but it may occur many
times.Although the process steps are presented as discrete elements
with well- defined interfaces, in practice they may overlap and
interact in complicated ways. No two projects take place under the
same circumstances, and no two information systems have the same
characteristics. While the requirements management procedures and
tools provide a basic path through the requirements management
process, the process should be adjusted based on the development
approach taken and the needs of each project.The requirements
management process was created generically to be used for both
small and large projects within each section. Once you understand
the concepts of gathering and documenting requirements, you can
best decide how to accomplish the tasks around requirements
management. The guidelines that follow are intended to help you
make decisions regarding the use of the requirements management
process. ESS/PCoEPage 3 of 25 4. Process OverviewThe following
illustration provides an overview of the Requirements Management
Process including the procedures and procedures steps. P ro c e s
sR e q u ir e m e n ts M anagem entP ro c e s s R e q u ir e m e n
t sS u b P ro c e s s G a th e r in gR e q u ir e m e n tsR e q u
ir e m e n t s R e q u ir e m e n t sC hange S t a k e h o ld e r N
e e d sD e fin itio nA n a ly s isV e r if ic a t io n M anagem
entP ro c e d u re sM anage G a t h e r S ta k e h o ld e rD e fin
eA n a ly z e V e r if yR e q u ir e m e n t sN eedsR e q u ir e m
e n tsR e q u ir e m e n t s R e q u ir e m e n t sC hanges T ra n
s fo rm N e e d sA s s ig n H ig h - L e v e l I d e n t if y V e r
if yD e fin e C h a n g ein t o H ig h - L e v e lR e q u ir e m e
n t s to S ta k e h o ld e r sR e q u ir e m e n t s R equest R e q
u ir e m e n t sP r o d u c t C a t e g o r ie s P ro c e d u re R
e f in e H ig h - L e v e l C o lle c t a n d V a lid a t e H ig h
L e v e l V a lid a t e R e q . & A n a ly z e C h a n g eS te
p s R e q . in t o D e t a ilD ocum ent N eedsR e q u ir e m e n t
s O b ta in A p p r o v a l R equestR e q u ir e m e n ts C re a
teC o m p le t e I m p a c t R e v ie w N e e d s a n dR e q u ir e
m e n t sB a s e lin e A n a ly s is & O b t a in A p p r o v a
lT r a c e a b ilit y M a t r ix R e q u ir e m e n tsR e c o m m e
n d a tio n ( O p t io n a l)M ake C hange D e c is io n In c o rp
o ra teC hanges V e r if y a n dC o m m u n ic a te C hange
ESS/PCoEPage 4 of 25 5. Gather/Elicit Stakeholder NeedsPurpose The
purpose of the gather stakeholder needs process is to identify and
document stakeholder needs to address a problem or opportunity. As
part of this process, stakeholder needs are prioritized, reviewed
for conflicts, and validated with the stakeholders. Stakeholder A
Stakeholder is a person who has a specific interest in a system and
who is affected by decisions about and changes to that system.
Stakeholders include end users, business partners, customers,
regulatory groups, suppliers, technology support, developers,
producers, testers, and maintainers. The stakeholder may be an
internal or external party.A Key Stakeholder is a person who
participates in the decision to approve or disapprove requirements
on the behalf of other stakeholders. If individual users disagree
on requirements, the key stakeholders decide. The key stakeholders
are expected to resolve requirements conflicts from those they
represent and are authorized to do so.Another name for key
stakeholder could be product champions. These are the people who
have a clear vision of the new system and are highly enthusiastic
because they see how the new product will benefit them and their
peers. Stakeholder Need A stakeholder need is a lack of something
felt to be necessary including expectations, priorities, and
constraints. Needs are really the highest level of requirement,
captured in the voice of the stakeholder.Each stakeholder need is
likely to decompose into multiple high-level requirements, which
may be further refined into multiple detailed requirements.Needs
are what you will measure acceptance against, once the project
completes.ESS/PCoEPage 5 of 25 6. Process The gather stakeholder
needs process is begun when a project to produce a new system or a
request to modify an existing system has been approved.The first
step in this process is to identify stakeholders. Identify key
system stakeholders who include the sponsor or primary beneficiary
of a system, stakeholders that control or commit resources, or who
have decision-making authority for other stakeholders. Identify
stakeholder representatives who can represent the needs of other
stakeholders. Identify stakeholders with a vested interested in, or
who will be affected by, the final product.The second step in this
process is to gather and document needs. Select a gathering
technique such as interviews, JAD sessions, orsurvey to gather
stakeholder needs. Other techniques exist forgathering stakeholder
needs; the three mentioned here are offered asmost frequently used
examples of how to accomplish the task in astructured manner. Use
the selected gathering technique to gather stakeholder
needs,including expectations, priorities, and constraints. Document
the needs. Stakeholder needs may be recorded in theStakeholder
Needs template or other appropriate document.The next step in this
process is to review and validate the needs with stakeholders and
to obtain an approval. Review documented stakeholder needs with the
appropriatestakeholders and ensure that the documented needs are
completeand correct. Obtain stakeholder approval of the stakeholder
needs from keystakeholders that have approval authority. Baseline
the approved stakeholder needs document by placing itunder version
or change control. ESS/PCoEPage 6 of 25 7. The results of the
gather stakeholder needs process are that a list of stakeholders is
identified, and stakeholder needs are documented, approved and
baselined.Define Requirements Purpose The purpose of the define
requirements process is to identify the high-level requirements
associated with each stakeholder need, to verify the requirements
against a set of criteria, and to validate the high-level
requirements. High-Level Requirements Each stakeholder need should
decompose into multiple high-level requirements, which may be
further refined into multiple detailed requirements depending upon
the level of detail needed. Whereas a need addresses the
stakeholders vision of the system, high-level requirements specify
a capability, physical characteristic, or quality factor and define
the need.High-level requirements language are still written in a
manner for all stakeholders to understand. In addition, the
requirements begin to provide the information that a developer will
need in order to design and construct a system. Further refinement
of the initial requirements will lead to detailed requirements.
Requirements Traceability Matrix (Optional) The matrix provides a
format to trace requirements from needs to requirements, design
specifications, code modules, and test scripts. This is optional
for larger projects due to the effort to maintain the matrix. Using
a traceability matrix helps ensure that all requirements have been
considered throughout the system development process. ESS/PCoE Page
7 of 25 8. Process The define requirements process is begun when
stakeholder needs are documented, agreed to, and baselined.The
first step in this process is to decompose needs into high-level
requirements. Determine requirements strategies by identifying the
strategies that will be used to collect requirements. The choice of
the text-based strategy utilizes standard word-based statements.
The use of a model-based strategy utilizes diagramming models for
products such as data and business processes. Identify high-level
requirements by evaluating each stakeholder need. Record each
requirement and a unique identifier in the Stakeholder Needs
document. Each need may have one to many requirements to fully
define the need. Each requirement must be stated so that it can
eventually be associated with a specific product such as data,
software, hardware, or facilities. The requirement must be defined
to support a potential solution and can be measured and/or
evaluated. Record changes to stakeholder needs. Record the
discovery of additional needs found by transforming needs into
requirements or restating needs to support the development of
high-level requirements. Stakeholder needs may need to be restated
if the need cannot be transformed into specific requirements. New
needs must be discussed and approved by appropriate stakeholders
and the new version of the Stakeholder Needs document baselined.The
second step in this process is to validate high-level requirements
with stakeholders. Identify the stakeholders who will review and
validate the high-levelrequirements or a specific group of
requirements. Determine the validation approach for review of the
high-levelrequirements. Approaches include one-on-one meetings,
groupmeetings, distributing hard copy or electronic versions of the
Needsdocument for individual review. Best practices state that
meetingsare the best approach for validating the set of
requirements becausethe structure and language of requirements may
not beunderstandable to both stakeholders and designers.
Independent ofthe approach chosen, it is important to ensure all
stakeholders have aESS/PCoE Page 8 of 25 9. clear understanding of
the structure and content of the set of high-level requirements.
Review and validate documented high-level requirements. Reviewthe
completed document with stakeholders to ensure thatrequirements
have been stated correctly. Assign priorities to eachhigh-level
requirement. The review may potentially discover additional
requirements and/orneeds. If additional requirements and/or needs
are discoveredthrough this review, repeat procedure steps, as
appropriate. Thismay include following the Gather Stakeholder Needs
process.The next step in this process is to create a requirements
traceability matrix. (Optional) Modify the traceability matrix
template to suit the needs of the project by identifying additional
information that may be required for tracking purposes. Document
needs and high-level requirements by entering a brief description
of each need, its unique identifier, and the priority of that need.
Enter each high-level requirement associated to the need, the
unique high-level requirements identifier, and its associated
priority.The results of the define requirements process are that
high-level requirements associated with stakeholder needs are
identified and documented. A traceability matrix may also be
established.Analyze Requirements Purpose The purpose of the analyze
requirements process is to refine high-level requirements into a
level of detail sufficient to enable designers to design a system
and testers to test that the system satisfies those requirements,
and to support project planning and impact analysisEvaluate the
high-level requirements, assign them to product categories, and
document them in the associated product category section of the
System Requirements Specification (SRS). Product categories are the
section breakdowns within the SRS. Potential product categories
that may ESS/PCoE Page 9 of 25 10. be included in the SRS are
System, Software, Data, Hardware, Services, Processes, Trained
Personnel, Materials, Facilities. Process The analyze requirements
process is begun when the stakeholder needs and associated
high-level requirements have been identified and documented. Still
use the needs document. If the traceability matrix was used to
record the high-level requirements, it will be used as inputThe
first step in this process is to evaluate high level requirements
to identify their associated product category. Assign each
high-level requirement to its associated product categoryby
evaluating each high-level requirement against each
productcategory. If the high-level requirement can be assigned to
more thanone product category, the requirement must be made
discrete.Reword or break down the high-level requirement into
enough detailthat it fits into only one product category. Select a
method to be used for organizing the software requirementssection
of the SRS. Evaluate the set of requirements within thesoftware
product category and select a method of organization. Document the
high-level requirements in the SRS. Move the high-level
requirements to the appropriate subsection of the assignedproduct
category section of the SRS. If a modeling tool was used tocollect
a category of requirements, add a reference to the model inthe
appropriate product category section of the SRS and attach ahard
copy. All high-level requirements will be removed from the
StakeholderNeeds document by the end of this step to prevent
duplication ofinformation.The second step in this process is to
decompose high-level requirements into more detail, resulting in
well-formed detailed requirements that are of sufficient detail to
enable designers to design and testers to test that the system
satisfies those requirements. Refine high-level requirements into
detailed requirements Decompose high-level requirements into more
detail, resulting in well-formed detailed requirements that are of
sufficient detail to enableESS/PCoE Page 10 of 25 11. designers to
design and testers to test that the system satisfies
thoserequirements. A detailed requirement states an essential
capability, physicalcharacteristic or quality factor at a level of
precision sufficient tosupport project planning, impact analysis,
change managementactivities, product design, code construction and
the creation of testcases to satisfy those requirements. Each
detailed requirementshould be externally perceivable by users,
operators, or otherexternal systems. Use the requirement evaluation
checklist toconfirm that each requirement and the set of
requirements meet thestandard. Document each detailed requirement
in the appropriate section of theSRS. Determine if new stakeholder
needs were identified. Use the GatherNeeds and Define Requirements
procedures, as appropriate, todocument the new stakeholder need and
its corresponding high-levelrequirements. Update the requirements
traceability matrix (if a matrix has beencreated) with information
pertaining to the detailed requirements. Add the unique identifier
and a brief description of its associateddetailed requirements and
link the information to its related high-levelrequirement.The
following is an example of high-level requirement refined into
detailed requirements: H.L. 1 The system shall provide online
capability to add a new office inventory item.DR 1.1 The add-item
program will require entry of the item number, itemdescription and
base inventory level to add a new office inventory item.DR.1.2 The
add-item program will initialize the total in stock field to
zeroswhen adding a new office inventory item. H.L. 2 - The system
shall provide the capability to perform an online search for office
inventory item information.DR 2.1 The item-search program will
require an item number or itemdescription as its search criteria.DR
2.2 The item-search program will provide a field to select items
ESS/PCoEPage 11 of 25 12. currently in stock (item order records
with a date disbursed of zeros). DR 2.3 The item-search program
will provide fields to select a date or date range search on the
date ordered, date received or date disbursed fields. DR 2.4 The
item-search program will display the item number, item description,
total in stock and base inventory level information. DR 2.5 The
item-search program display will contain one line of data (vendor,
date ordered, date received, cost per item, date disbursed) per
order selected using the above criteria.The results for this
process are that high-level requirements are assigned to product
categories, documented in the SRS, and decomposed into detailed
requirements. Verify Requirements Purpose The purpose of verifying
requirements is to prove that the requirements are recorded
correctly and to ensure that the requirements specify the system
that the stakeholders need and expect. Verify and Validate Compare
the SRS to the baselined needs, and evaluate the requirements using
defined evaluation criteria. Provide stakeholders an opportunity to
ensure that the requirements reflect the system that the
stakeholders need and expect and to obtain their approval that the
requirements are complete enough to move to the next stage of
development. Baseline Baseline (place under version or change
control) the approved requirements according to the defined
configuration management process. Process The verify requirements
process is begun when the detailed requirements are documented in
the SRS document, the requirements traceability matrix ESS/PCoE
Page 12 of 25 13. is updated (if used), and the stakeholder needs
are updated and baselined (placed under version or change
control).The first step in this process is to compare requirements
to the stakeholder needs document. If incomplete requirements are
identified, apply the appropriate Requirements Management (RM)
procedure steps to fix or record the additional requirements in the
SRS. Use the traceability matrix, Stakeholder Needs Document and
SRS to compare the requirements to the stakeholder needs to ensure
that all needs are addressed. Each need is linked to one or more
requirements. Each requirement actually applies to its linked need
(or needs). Each need is completely specified by its linked
requirements. o Fix any links that can be corrected with the
availableinformation. o Identify all needs with missing
requirements, either because aneed has no linked requirements or
because a need is notcompletely specified by its linked
requirements. Use the Requirements Evaluation Criteria to improve
the quality of the requirements by evaluating each individual
requirement and the set of requirements. The degree to which you
apply these criteria depends upon the needs of the project. If
incomplete requirements are found, apply the appropriate RM
procedure steps to fix them or record the incomplete requirements
in the SRS. Some requirements cannot be completed until more
information is known or a decision reached. This is acceptable as
long as all parties are in agreement that the incomplete
requirements will be clarified later, when more is known. Update
the traceability matrix to reflect any new or changed links.The
second step in this process is to review and validate both verified
and incomplete requirements with the stakeholders. Obtain
stakeholder approval. Identify the stakeholder groups and specify
the requirements that willbe presented to each stakeholder review
group. ESS/PCoEPage 13 of 25 14. Plan how to present requirements
to each group of stakeholders and the best approach to obtain
approval (e.g., during a JAD, email, etc.), considering the needs
of the project. Plan the review process and schedule all needed
workshops. Communicate review and approval expectations as
appropriate. Present the requirements for stakeholder review as
planned.o Record requirements found during the review that need
additional clarification or are incomplete. If incomplete
requirements are found, apply the appropriate RM procedure steps to
fix or record the incomplete requirement within the incomplete
requirements section of the SRS. Obtain approval of the SRS and, if
updates were made, to the Stakeholder Needs document.The next step
in this process is to baseline (place under version or change
control) the approved requirements according to the configuration
management process. Follow the configuration management process to
baseline (place under version or change control) the approved SRS
and the Stakeholder Needs document (if it has changed).The outcomes
for this procedure are that the SRS is approved, the stakeholder
needs document is updated and approved, and the documents are
baselined, (placed under version or change control) according to
the configuration management process, and the traceability matrix
is updated.Manage Requirement Changes Manage The purpose of
managing requirements is to provide a funneling and filtering
mechanism to ensure that the most appropriate changes are adopted
and that the impact on the project is minimized by: Selecting
change requests to evaluate; Evaluating the impact of the proposed
change on current needs, requirements, plans, activities, and work
products; Determining whether to approve, reject, or defer the
proposed change; ESS/PCoE Page 14 of 25 15. Getting formal approval
of the decision; Incorporating changes into baselines; Revising
plans, activities, and work products to be consistent with the
approved change; Verifying the changes and communicate approved
changes to affected groups. Process The Manage Requirements Change
process is begun when there is a perceived need to change the
baselined stakeholder needs or requirements. The first step in this
process is to define the change request by completing a change
request and submitting it for evaluation. Complete a change request
according to the change management process. Submit the change
request to the Project Manager for evaluation. The second step in
this process is to analyze the change request by receiving a change
request and evaluating it using the change management process.
Receive change request from the stakeholder. Use evaluation
criteria to determine if the request should be evaluated further.o
For example, is the request in scope, is it feasible, does it
alignwith the projects business requirements, is it clear
andcomplete? If further information is needed to proceed, reworkthe
change request with the assistance of the submittingstakeholder.
Accept, reject or defer the change request for further evaluation.o
Continue if change request is accepted, otherwise Document
according to the change management process Inform stakeholders End
of Manage Requirement Changes procedureESS/PCoE Page 15 of 25 16.
The next step in this process is to complete an impact analysis of
the proposed change, use that information to make a decision about
whether to proceed with the change, and recommend approval,
rejection, or deferral of the proposed change. Complete an impact
analysis of the proposed change on current baselined needs,
baselined requirements, project plans, activities, and work
products. Based on the results of the impact analysis, provide a
recommendation to the submitting stakeholder.o Document the
recommendation and the reason for therecommendation in the change
request. Review completed change request with submitting
stakeholder. The next step in this process is to make the change
decision by approving, rejecting, or deferring the requested change
request. Review the change request containing the results of the
impact analysis and the change recommendation. Accept, reject or
defer the proposed change. Communicate the decision to all
stakeholderso Continue if the change is accepted otherwise Document
according to your sections defined change management process. End
of Manage Requirement Changes procedure The next step in this
process is to ensure that approved changes are incorporated into
baselines and project plans. Use the appropriate steps of the
Gather Needs, Define Requirements, Analyze Requirements, and Verify
Requirements procedures to incorporate approved changes into the
baselined stakeholder needs and SRS documents, and the requirements
traceability matrix. ESS/PCoEPage 16 of 25 17. Follow established
project management practices to plan andexecute revisions to all
affected plans, schedules, activities, budget,work products, and
deliverables, as appropriate.o Update project plan to reflect
approved changes to thestakeholder needs document, the SRS
document, andrequirements traceability matrix.o Update all
deliverables and work products, as planned, toreflect changed
requirements. The next step in this process involves verifying that
all aspects of the approved change were incorporated into affected
baselines, plans, and products and that the change was communicated
to the stakeholders. Inspect affected baselines, plans, and
products to ensure that the appropriate products were updated to be
consistent with the approved change request. Communicate results of
the review to all affected groups. The outcomes for this procedure
are that key stakeholders have approved or disapproved any change,
approved changes are incorporated into baselined requirements,
decisions about proposed requirements changes are communicated, and
development plans, activities, budget, and work products are
consistent with the changed requirements.Process Inputs and
OutputsProcedure Name Inputs Outputs Gather Stakeholder Project or
effort approval List of Stakeholders Needs Stakeholder Needs
Documented approval Define RequirementsStakeholder NeedsStakeholder
Needs Requirements Traceability Matrix Analyze Requirements
Stakeholder NeedsSystem Requirements Specification
(SRS)Requirements Traceability Matrix Stakeholder Needs
Requirements Traceability Matrix Verify
RequirementsSRSSRSESS/PCoEPage 17 of 25 18. Stakeholder
NeedsStakeholder NeedsRequirements Traceability Matrix Documented
approval Requirements Traceability Matrix Manage Requirement Need
for change to baselineApproved change decision
ChangesSRSStakeholder NeedsRevised SRSRequirements Traceability
Matrix Revised Stakeholder Needs Documented approvalRevised
Requirements Traceability Matrix.Revised plans, activities, and
workproducts ESS/PCoE Page 18 of 25 19. Stakeholders Example
Listing of System Stakeholders StakeholderExample of information
provided Customers: Business Goals, objectives, and scope of the
systemowners/sponsors/managers Business conformance requirements
Subject Matter Experts Typical usage scenarios End users Technical
Architects:Technical feasibility of requirements. Knowledge of
Network Specialistsrecurring domain problems, known solutions, and
Server Specialists (system level future changes/needs. Provides
hardware, software,design) and communication (network, voice,
dial-in, etc.) Desktop Specialistsrequirements. Support Specials
(potentiallyincludes help desk andinstallation support staff)
Application Development staff: Technical feasibility of
requirements Systems Architects Systems Analysts Developers
Database experts (data analystsand DBAs) Standards experts:
Conformance requirements, design and OIS Management implementation
constraints, future standards Project Management Office staff
External Partners: Interoperability requirements with other
systems; Other DHS sections information needs (e.g., reports),
safety External Agency partners requirements, legal requirements,
federalrequirements, etc. Testing staff: Identify requirements to
ensure functional and Information systems (functionalsystem level
testing can be performed.testing) Business systems
(acceptancetesting) Oversight staffQuality Assurance requirements,
acceptance criteria,etc. ESS/PCoE Page 19 of 25 20.
StakeholderExample of information provided VendorsFeatures of
existing and anticipated Commercial offthe Shelf (COTS) products,
knowledge of competingproducts Trainers Defines training or
facilities needs. Requirements Facilities experts may include
contracting requirements, which may Contract specialists require
stakeholders with knowledge in this area tobe part of the
stakeholder group. ESS/PCoEPage 20 of 25 21. Roles &
ResponsibilitiesThe roles involved in requirements management
process and procedures are identified in the following table. The
role titles presented here are generic; your section may use other
titles.REQUIREMENTS MANAGEMENT - ROLES & RESPONSIBILITIES
RoleResponsibility RequirementsA subset of the project team,
responsible for gathering and group refining requirements. As a
system moves from development to maintenance, individuals are
identified for ongoing requirements management. The primary
responsibilities of the requirements group are to: Prepare for
needs gathering sessions. Gather, document and validate needs with
stakeholders. Decompose stakeholder needs into well-defined high-
level requirements, correct deficiencies, assign high-level
requirements to products, create and document detailed
requirements. Verify, correct, and re-verify detailed requirements.
Validate detailed requirements, and assist the project manager to
negotiate stakeholder approval of verified requirements. Ensure
requirements change proposal is well defined. Coordinate impact
analysis, and make recommendation to change control group.
ESS/PCoEPage 21 of 25 22. REQUIREMENTS MANAGEMENT - ROLES &
RESPONSIBILITIES RoleResponsibility Stakeholder Stakeholder
includes business partners, customers, end users, regulatory
groups, suppliers, technology support, developers, testers, and
maintainers. The stakeholder may be an internal or external party.
Stakeholders have the following responsibilities. Communicate
needs, expectations, priorities, constraints and requirements to
the requirements group Review and validate needs and requirements.
Initiate change proposals. Key stakeholder Key stakeholder is a
person who participates in the decision to approve or disapprove
requirements on the behalf of other stakeholders: Validate and
approve needs and requirements. Approve changes to requirements.
Stakeholder A stakeholder who represents the needs of a group of
Representativestakeholders and who acts on their behalf within a
project. Stakeholder representatives have all the responsibilities
of stakeholders and the following additional responsibilities:
Validate needs and requirements. Validate changes to requirements.
ManagersManagers involved with system delivery. Their primary role
is to resolve disagreements and prioritization issues that cannot
be negotiated and resolved by the requirements group or project
manager. ESS/PCoEPage 22 of 25 23. REQUIREMENTS MANAGEMENT - ROLES
& RESPONSIBILITIES RoleResponsibility Project manager The
project manger has the primary responsibility for initiating,
planning, executing and controlling a project. Their main
responsibilities related to requirements management are to: Assist
the Lead Analyst to identify stakeholders and key stakeholders.
Manage document approval. Review activities for managing the
written requirements on both a periodic and event driven basis. Use
the approved written requirements as the basis for updates to plans
and activities. Receive change proposals and with assistance of the
Lead Analyst decide whether to evaluate them for impact or
disapprove immediately. Ensure that changes to the written
requirements are: - Identified - Evaluated - Assessed for risk -
Documented - Approved - Incorporated into the project plan,
activities andwork products - Communicated to the affected groups
andindividuals - Tracked to completion. Monitor and resolve
baselined unverified requirements issues through established
project management change control process Negotiate changes to
project cost, schedule and resource commitments that result from
approved changes to requirements. ESS/PCoEPage 23 of 25 24.
REQUIREMENTS MANAGEMENT - ROLES &RESPONSIBILITIES Role
Responsibility Change control During a project, the change control
group is the project groupsteering committee or other project
governance body. As asystem moves from development to maintenance,
a changecontrol group, including key stakeholders, is responsible
forongoing requirements management. Review impact analysis and make
decisions about changeproposals. Communicate decisions. Lead
Analyst During a project, the lead analysts primary
responsibilitiesrelated to requirements management are to: Identify
stakeholders and key stakeholders, withassistance from the Project
Manager. Assist the Project Manager to decide whether to
evaluatechange proposals for impact or disapprove immediately.
Evaluate change proposals and make changerecommendations. Verify
that baselines, plans, and work products are madeconsistent with
approved changes. ESS/PCoE Page 24 of 25 25. ReferencesInformation
used in the development of this document came from the following
sources:1. The Oregon Department of Transportation IS
RequirementsManagement Process.2. The State of Oregon Information
Resources Management Division(IRMD) SDLC
methodology:http://egov.oregon.gov/DAS/IRMD/docs/doc/sd_large_development_process.doc
ESS/PCoEPage 25 of 25