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