• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,785
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
293
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Requirements Management Process Guide Draft This document prepared and owned by [Business Owner, Business Transition Manager or Appointed Reviewer (name & position)] [Agency/Organization/Division Name] [PROJECT NAME] VERSION: [VERSION REVISION 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/PCoE Page 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/PCoE Page 2 of 25
  • 3. Introduction The 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 user’s 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/PCoE Page 3 of 25
  • 4. Process Overview The following illustration provides an overview of the Requirements Management Process including the procedures and procedures steps. P ro c e s s R e q u ir e m e n ts M anagem ent P ro c e s s R e q u ir e m e n t s S u b P ro c e s s G a th e r in g R e q u ir e m e n ts R e q u ir e m e n t s R e q u ir e m e n t s C hange S t a k e h o ld e r N e e d s D e fin itio n A n a ly s is V e r if ic a t io n M anagem ent P ro c e d u re s M anage G a t h e r S ta k e h o ld e r D e fin e A n a ly z e V e r if y R e q u ir e m e n t s N eeds R e q u ir e m e n ts R e q u ir e m e n t s R e q u ir e m e n t s C hanges T ra n s fo rm N e e d s A s s ig n H ig h - L e v e l I d e n t if y V e r if y D e fin e C h a n g e in t o H ig h - L e v e l R e q u ir e m e n t s to S ta k e h o ld e r s R e q u ir e m e n t s R equest R e q u ir e m e n t s P 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 e S te p s R e q . in t o D e t a il D ocum ent N eeds R e q u ir e m e n t s O b ta in A p p r o v a l R equest R e q u ir e m e n ts C re a te C o m p le t e I m p a c t R e v ie w N e e d s a n d R e q u ir e m e n t s B a s e lin e A n a ly s is & O b t a in A p p r o v a l T r a c e a b ilit y M a t r ix R e q u ir e m e n ts R 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 te C hanges V e r if y a n d C o m m u n ic a te C hange ESS/PCoE Page 4 of 25
  • 5. Gather/Elicit Stakeholder Needs Purpose 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/PCoE Page 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, or survey to gather stakeholder needs. Other techniques exist for gathering stakeholder needs; the three mentioned here are offered as most frequently used examples of how to accomplish the task in a structured manner. • Use the selected gathering technique to gather stakeholder needs, including expectations, priorities, and constraints. • Document the needs. Stakeholder needs may be recorded in the Stakeholder 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 appropriate stakeholders and ensure that the documented needs are complete and correct. • Obtain stakeholder approval of the stakeholder needs from key stakeholders that have approval authority. • Baseline the approved stakeholder needs document by placing it under version or change control. ESS/PCoE Page 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-level requirements or a specific group of requirements. • Determine the validation approach for review of the high-level requirements. Approaches include one-on-one meetings, group meetings, distributing hard copy or electronic versions of the Needs document for individual review. Best practices state that meetings are the best approach for validating the set of requirements because the structure and language of requirements may not be understandable to both stakeholders and designers. Independent of the approach chosen, it is important to ensure all stakeholders have a ESS/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. Review the completed document with stakeholders to ensure that requirements have been stated correctly. Assign priorities to each high-level requirement. • The review may potentially discover additional requirements and/or needs. If additional requirements and/or needs are discovered through this review, repeat procedure steps, as appropriate. This may 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 analysis Evaluate 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 input The 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 category by evaluating each high-level requirement against each product category. If the high-level requirement can be assigned to more than one product category, the requirement must be made discrete. Reword or break down the high-level requirement into enough detail that it fits into only one product category. • Select a method to be used for organizing the software requirements section of the SRS. Evaluate the set of requirements within the “software 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 assigned product category section of the SRS. If a modeling tool was used to collect a category of requirements, add a reference to the model in the appropriate product category section of the SRS and attach a hard copy. • All high-level requirements will be removed from the Stakeholder Needs document by the end of this step to prevent duplication of information. 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 enable ESS/PCoE Page 10 of 25
  • 11. designers to design and testers to test that the system satisfies those requirements. • A detailed requirement states an essential capability, physical characteristic or quality factor at a level of precision sufficient to support project planning, impact analysis, change management activities, product design, code construction and the creation of test cases to satisfy those requirements. Each detailed requirement should be externally perceivable by users, operators, or other external systems. Use the requirement evaluation checklist to confirm that each requirement and the set of requirements meet the standard. • Document each detailed requirement in the appropriate section of the SRS. • Determine if new stakeholder needs were identified. Use the Gather Needs and Define Requirements procedures, as appropriate, to document the new stakeholder need and its corresponding high-level requirements. • Update the requirements traceability matrix (if a matrix has been created) with information pertaining to the detailed requirements. • Add the unique identifier and a brief description of its associated detailed requirements and link the information to its related high-level requirement. 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, item description 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 zeros when 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 item description as its search criteria. DR 2.2 The item-search program will provide a field to select items ESS/PCoE Page 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 available information. o Identify all needs with missing requirements, either because a need has no linked requirements or because a need is not completely 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 will be presented to each stakeholder review group. ESS/PCoE Page 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 align with the project’s business requirements, is it clear and complete? If further information is needed to proceed, rework the change request with the assistance of the submitting stakeholder. • 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 procedure ESS/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 the recommendation 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 stakeholders o Continue if the change is accepted otherwise  Document according to your section’s 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/PCoE Page 16 of 25
  • 17. • Follow established project management practices to plan and execute revisions to all affected plans, schedules, activities, budget, work products, and deliverables, as appropriate. o Update project plan to reflect approved changes to the stakeholder needs document, the SRS document, and requirements traceability matrix. o Update all deliverables and work products, as planned, to reflect 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 Outputs Procedure Name Inputs Outputs Gather Stakeholder Project or effort approval List of Stakeholders Needs Stakeholder Needs Documented approval Define Requirements Stakeholder Needs Stakeholder Needs Requirements Traceability Matrix Analyze Requirements Stakeholder Needs System Requirements Specification (SRS) Requirements Traceability Matrix Stakeholder Needs Requirements Traceability Matrix Verify Requirements SRS SRS ESS/PCoE Page 17 of 25
  • 18. Stakeholder Needs Stakeholder Needs Requirements Traceability Matrix Documented approval Requirements Traceability Matrix Manage Requirement Need for change to baseline Approved change decision Changes SRS Stakeholder Needs Revised SRS Requirements Traceability Matrix Revised Stakeholder Needs Documented approval Revised Requirements Traceability Matrix. Revised plans, activities, and work products ESS/PCoE Page 18 of 25
  • 19. Stakeholders Example Listing of System Stakeholders Stakeholder Example of information provided Customers: − Business − Goals, objectives, and scope of the system owners/sponsors/managers − Business conformance requirements − Subject Matter Experts − Typical usage scenarios − End users Technical Architects: Technical feasibility of requirements. Knowledge of − Network Specialists recurring domain problems, known solutions, and − Server Specialists (system level future changes/needs. Provides hardware, software, design) and communication (network, voice, dial-in, etc.) − Desktop Specialists requirements. − Support Specials (potentially includes help desk and installation support staff) Application Development staff: Technical feasibility of requirements − Systems Architects − Systems Analysts − Developers − Database experts (data analysts and 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, federal requirements, etc. Testing staff: Identify requirements to ensure functional and − Information systems (functional system level testing can be performed. testing) − Business systems (acceptance testing) Oversight staff Quality Assurance requirements, acceptance criteria, etc. ESS/PCoE Page 19 of 25
  • 20. Stakeholder Example of information provided Vendors Features of existing and anticipated Commercial off the Shelf (COTS) products, knowledge of competing products Trainers Defines training or facilities needs. Requirements Facilities experts may include contracting requirements, which may Contract specialists require stakeholders with knowledge in this area to be part of the stakeholder group. ESS/PCoE Page 20 of 25
  • 21. Roles & Responsibilities The 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 Role Responsibility Requirements A 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/PCoE Page 21 of 25
  • 22. REQUIREMENTS MANAGEMENT - ROLES & RESPONSIBILITIES Role Responsibility 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 Representative stakeholders 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. Managers Managers 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/PCoE Page 22 of 25
  • 23. REQUIREMENTS MANAGEMENT - ROLES & RESPONSIBILITIES Role Responsibility 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 and work products - Communicated to the affected groups and individuals - 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/PCoE Page 23 of 25
  • 24. REQUIREMENTS MANAGEMENT - ROLES & RESPONSIBILITIES Role Responsibility Change control During a project, the change control group is the project group steering committee or other project governance body. As a system moves from development to maintenance, a change control group, including key stakeholders, is responsible for ongoing requirements management. • Review impact analysis and make decisions about change proposals. • Communicate decisions. Lead Analyst During a project, the lead analyst’s primary responsibilities related to requirements management are to: • Identify stakeholders and key stakeholders, with assistance from the Project Manager. • Assist the Project Manager to decide whether to evaluate change proposals for impact or disapprove immediately. • Evaluate change proposals and make change recommendations. • Verify that baselines, plans, and work products are made consistent with approved changes. ESS/PCoE Page 24 of 25
  • 25. References Information used in the development of this document came from the following sources: 1. The Oregon Department of Transportation IS Requirements Management 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/PCoE Page 25 of 25