2.110.2  Requirements Engineering Process (Cont. 1)

2.110.2.1 
Requirements Engineering Process

2.110.2.1.3 
Requirements Engineering Process Steps

2.110.2.1.3.4 
Step 4: Confirm and Refine Requirements

2.110.2.1.3.4.2  (02-19-2013)
Roles and Responsibilities

  1. The Project Manager is responsible for ensuring resources are allocated and available to perform the confirmation and refinement activities. The Project Manager is responsible for resolving any issues that arise during any updates to the BSRR, BSR or BSAR preparation or approval processes. The Project Manager is responsible for adhering to Configuration Management directives.

  2. The RD Manager is responsible for ensuring the architectures and requirements of the solution are refined, accurate and approved by all stakeholders. The RD Manager is also responsible for maintaining the requirements repository and following the RP in terms of change and configuration management issues.

  3. The IPT is responsible for analyzing business rules for completeness, redundancy, consistency, and business validation. The IPT is also responsible for refining (as appropriate) the PD-BSRR, business content within the PD-BSAR, and PD-BSR.

  4. The Project CCB is responsible to approve the requirements baseline and any requested changes to baselined requirements. This governing body is typically comprised of stakeholder and IT executives.

2.110.2.1.3.4.3  (02-19-2013)
Entry Criteria

  1. The confirmation and refinement of requirements occurs when the DA-BSRR, DA-BSR, and DA-BSAR are completed.

2.110.2.1.3.4.4  (02-19-2013)
Input

  1. Any of the following requirements-related information/data:

    • Capability Statements

    • Requirement Statements

    • Process Models

    • Business Rule/Rule Sets

    • Terms

    • Traceability Relationships

    • BSCR

    • DA-BSAR

    • DA-BSRR (including Reusable Program Level Requirements)

    • DA-BSR (including Reusable Program Level Requirements)

    • Logical Design

2.110.2.1.3.4.5  (02-19-2013)
Process Activity

  1. Clarify and update business rules

  2. Update process model as appropriate

  3. Identify and define any new terms

  4. Refine detailed requirements statements

  5. Verify and validate Requirements

  6. Document Preliminary Design (PD)-BSRR

  7. Document PD-BSR (if applicable)

  8. Document PD-BSAR

  9. Review Design Specification Report (DSR)-1 (to confirm requirements traceability relationships)

  10. Support CTRs for PD-BSRR, PD-BSAR, and DSR-1

  11. Establish Allocated Baseline Solution

    • An agreed to set of refined and/or derived requirements allocated to specific software, hardware, or interfaces documented in the PD-BSAR, PD-BSRR (or PD-BSR) and a snapshot of the repositories for exiting the Preliminary Design Phase.

  12. Support project MS3 Exit activities

    • Support the MS3 Milestone Readiness Review and the Milestone Exit Review to ensure all requirements engineering recommendations and guidelines have been addressed.

2.110.2.1.3.4.6  (02-19-2013)
Output

  1. Repositories containing any of the following:

    • Capability Statements

    • Requirement Statements

    • Process Models

    • Business Rule/Rule Sets

    • Terms

    • Traceability Relationships

    • PD-BSRR

    • PD-BSR

    • PD-BSAR

    • DSR-1

2.110.2.1.3.4.7  (02-19-2013)
Exit Criteria

  1. This process step is complete when:

    • A CTR of the PD-BSRR or PD-BSR and DSR-1 is performed

    • Formal approval of the PD-BSRR or PD-BSR is received via appropriate stakeholders and project management

    • Change Management procedures are followed in the event that the Functional Baseline needs updating -- available in the projects requirements repository

    • The establishment of an Allocated Baseline

2.110.2.1.3.5  (02-19-2013)
Step 5: Refine and Allocate Requirements

  1. Step 5: Refine and Allocate Requirements

2.110.2.1.3.5.1  (02-19-2013)
Purpose

  1. The purpose of refining and allocating is to document any new constraining requirements or requirements that impact the actual design of the solution. Any new requirements would require a change to the established baseline. The requirement statements within the Detailed Design (DD)-BSRR will become a part of the Allocated Baseline. RE activities are focused on managing and maintaining the requirements.

2.110.2.1.3.5.2  (02-19-2013)
Roles and Responsibilities

  1. The Project Manager is responsible for ensuring resources are allocated and available to perform the refinement and allocation activities. The Project Manager is responsible for resolving any issues that arise during any updates to the DD-BSRR, DD-BSR or DD-BSAR preparation or approval processes. The Project Manager is responsible for adhering to Configuration Management directives.

  2. The RD Manager is responsible for is responsible for ensuring the updates to the BSRR and BSR are accurate and approved by all stakeholders. The RD Manager is also responsible for maintaining the requirements repository and following the RP in terms of change and configuration management issues.

  3. The IPT is responsible for analyzing and refining (as appropriate) the BSRR, business content within the BSAR, and BSR.

  4. The Project CCB is responsible to approve the requirements baselines and any requested changes to baselined requirements. This governing body is typically comprised of stakeholder and IT executives.

2.110.2.1.3.5.3  (02-19-2013)
Entry Criteria

  1. The refine and allocate requirements process step occurs when the PD-BSRR, PD-BSR, PD-BSAR, and DSR-1 are completed.

2.110.2.1.3.5.4  (02-19-2013)
Input

  1. The following are inputs to this process step:

    • PD-BSRR

    • PD-BSR

    • PD-BSAR

    • DSR-1

2.110.2.1.3.5.5  (02-19-2013)
Process Activity

  1. Verify requirements

  2. Validate requirements

  3. Confirm traceability

  4. Allocate requirements

  5. Update/refine Allocated Baseline Solution

2.110.2.1.3.5.6  (02-19-2013)
Output

  1. The following are outputs to this process step:

    • DD-BSRR/BSR

    • DSR-2

2.110.2.1.3.5.7  (02-19-2013)
Exit Criteria

  1. This process step is complete when:

    • A CTR of the DD-BSRR/BSR and the DSR-2 is performed

    • Formal approval of the DD-BSRR/BSR and DSR-2 is received via appropriate stakeholders and project management

    • Change Management procedures are followed in the event that the Functional Baseline needs updating -- available in the projects requirements repository

    • A refined Allocated Baseline

2.110.2.1.3.6  (02-19-2013)
Process Measurement

  1. Project Management will regularly review quantifiable data related to different aspects of the RE process in order to make informed decisions and take appropriate corrective action, if necessary.

  2. Requirements Volatility: A measure of how change is occurring to a set of baselined requirements. This is measured by the number of changes occurring to the requirements baseline.

  3. Optional Measure for Business Systems Modernization Projects: A measure for estimating scope variance is based on the measurement of scope at each release/MS exit. A comparison of these scope metrics from one MS to the next is then analyzed. When the scope of a release changes from one MS to the next, it is taken as an indicator of Scope Variance. The Capabilities (CAP) Scope Variance (MSa to MSb) = [# of CAP (MSb) - # of CAP (MSa)] / # of CAP (MSa)].

2.110.2.1.3.7  (02-19-2013)
Training

  1. The following training is recommended to perform the RE process and may be requested by registering through ELMS or via the RADM web site training link. See the RADM Program Office, “How We Can Help”, URL: http://mits.web.irs.gov/brrm/index.htmfor additional training and guidance.

    • Requirements Engineering Overview (ELMS Course ID 23267)

    • Project-in-a-Box (ELMS Course ID 23268)

2.110.2.1.4  (02-19-2013)
Requirements Engineering Procedure

  1. Introduction

2.110.2.1.4.1  (02-19-2013)
Administration

  1. All proposed changes to this document should be directed to the Requirements and Demand Management (RADM) owner of this procedure and pursued via the Integrated Process Management process to clearly define interfaces, roles, responsibilities, and coordinate participation and collaboration between stakeholders.

2.110.2.1.4.1.1  (02-19-2013)
Purpose of Procedure

  1. This document defines the step-by-step instructions on how to conduct the activities used to implement the Requirements procedure in RADM. The purpose of a procedure document is to institutionalize and formalize the preferred method of performing tasks that staff is using. The objective is to have everyone using the same tools and techniques and follow the same repeatable steps so that the organization can quantify how well the procedure is working and train future staff members who may not currently know the routine. Ensuring consistency is a critical component for ensuring optimum efficiency.

  2. Tailoring of this procedure in order to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document.

  3. For the purpose of this document, roles such as Project Manager and Requirements Development (RD) Manager are provided to describe a set of responsibilities for performing RE related activities. Roles and/or responsibilities should fit your business terminology.

2.110.2.1.4.1.2  (02-19-2013)
Requirements Engineering Procedure Overview

  1. Requirements Engineering Procedure

2.110.2.1.4.1.3  (02-19-2013)
Purpose

  1. The Requirements Engineering Procedure will outline requirements engineering (RE) activities, and provide steps for completing major components of the RE process. This procedure will specify, in a complete, precise, and verifiable manner, the requirements, design, and behavioral characteristics of the RE process.

2.110.2.1.4.1.3.1  (02-19-2013)
Related Process Artifacts

  1. Related Artifacts are:

    • Requirements Plan (RP)

    • Business System Concept Report (BSCR)

    • Business System Requirements Report (BSRR) or Business System Report (BSR)

2.110.2.1.4.1.3.2  (02-19-2013)
Related Directives

  1. Related Directives are:

    • Requirements Engineering Directive dated June 21, 2011

    • Requirements Process Description dated April 19, 2012

2.110.2.1.4.1.4  (02-19-2013)
Entry Criteria

  1. Generally, the Requirements Engineering procedure occurs after the following events have occurred:

    • The Project is included in the IRS Mission, Vision & Strategy Investment Portfolio (E300/E53)

    • A high level project Solution Concept report has been completed and includes a solution concept which is mapped to Enterprise Architecture

    • A Project Charter has been approved

    • A Project Management Plan (PMP) has been initiated or approved

    • The project has conducted it’s initial project kick-off meeting

2.110.2.1.4.1.5  (02-19-2013)
Input

  1. The following are inputs to this Requirements Engineering procedure:

    • Modernization, Vision and Strategy materials such as the E300/E53

    • Project Kickoff Meeting Minutes

    • Project Charter

    • Solution Concept

    • Project Tailoring Plan (PTP)

    • PMP (optional)

    • Project Work Breakdown Structure (WBS) (optional)

    • The Project-RADM Memorandum of Agreement (MOA) has been approved for levels 2 and 3 service offerings

    • Requirements Engineering Tailoring Application (RETA)

    • Capability statements

    • Concept principles, constraints, and assumptions along with privacy and security (high level dependencies)

    • High level issues and risks

    • Release strategy defined (at the highest level, or per the solution concept)

    • Existing business or technical models, policy (IRMs) and/or other high level project documentation

2.110.2.1.4.1.6  (02-19-2013)
Activities

  1. This Procedure covers activities as follows:

  2. Activities

    A1 Perform Initial Scoping and Planning
    A 2 Perform Current/Future State Analysis
    A 3 Develop and Analyze Business Architecture and Requirements
    A 4 Confirm and Refine Requirements
    A 5 Refine and Allocate Requirements

2.110.2.1.4.1.7  (02-19-2013)
Output

  1. The primary outputs of this Requirements Engineering procedure are:

    • Updated PTP (if applicable)

    • RP

    • RETA Tailoring Result Report (Recommended)

    • RE Process WBS (Recommended)

    • BSCR

    • BSRR

    • BSR (if applicable)

2.110.2.1.4.1.8  (02-19-2013)
Exit Criteria

  1. The Requirements Engineering procedure is exited when:

    • The establishment of an Allocated Baseline

    • Approved Project-RADM MOA for levels 2 and 3 service offerings

    • The project’s RP has been approved

    • The project’s requirements repository has been established

    • A Customer Technical Review (CTR) of the BSCR is recommended by RADM and formal approval of the BSCR is received

    • A CTR of the BSRR or BSR is performed and formal approval of the BSRR or BSR is received via appropriate stakeholders and project management

    • RADM approval of the Business System Architecture Report (BSAR)

    • The establishment of a Functional Baseline

    • Change Management procedures are followed in the event that the Functional Baseline needs updating -- available in the projects requirements repository

2.110.2.1.4.2  (02-19-2013)
Procedure Flow Diagram

  1. A1 -- Perform Initial Scoping and Planning

    Figure 2.110.2-2
    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. A 2 -- Perform Current/Future State Analysis

    Figure 2.110.2-3
    This image is too large to be displayed in the current screen. Please click the link to view the image.

  3. A 3 -- Develop and Analyze Business Architecture and Requirements

    Figure 2.110.2-4
    This image is too large to be displayed in the current screen. Please click the link to view the image.

  4. A 4 -- Confirm and Refine Requirements

    Figure 2.110.2-5
    This image is too large to be displayed in the current screen. Please click the link to view the image.

  5. A 5 -- Refine and Allocate Requirements

    Figure 2.110.2-6
    This image is too large to be displayed in the current screen. Please click the link to view the image.

2.110.2.1.4.3  (02-19-2013)
Activity and Steps

  1. This section delineates the activity steps, including roles and tools or templates, needed to perform each step of this Procedure.

    A 1: Perform Initial Scoping and Planning (See Figure 2.110.2–2)  
    Steps Roles
    1. Sign-off on RADM Support Needs
    Determine the level of RE Support and sign-off on an MOA between the Project and RADM. RADM has three levels of service that provided to projects; see RADM Home Page, http://mits.web.irs.gov/brrm/index.htm, RE Program Office, "How We Can Help" for a complete description of each level of service.
    Project Manager
    2. Revise the Project Tailoring Plan (PTP)
    Determine the project’s scope for current milestone or phase activities and update the PTP as needed. Depending on a project’s scope, it may be necessary to modify the RE approach relative to the mandated set of artifacts requested by the ELC. The tailoring (typically an altering of activities and/or artifacts) can be enhanced by using RADM’s RETA. For further guidance, go to the RADM Program Office web-site, http://mits.web.irs.gov/brrm/index.htm, RE Tools, and RE Tailoring.
    RD Manager
    3. Sign-off on project Requirements Plan (RP)
    Document the project’s approach to performing (RD) and requirements management (RM) activities and gain approval of the RP. Refer to the IT PAL, http://itpal.ds.irsnet.gov/, for the Requirements Plan DID.
    Project Manager
    RD Manager
    4. Set up the Requirements Repository
    Establish the project’s requirement repository in Requisite Pro or use the RADM Excel Requirements Repository, a Microsoft Excel based tool. Refer to the RADM Program Office Home Page, http://mits.web.irs.gov/brrm/index.htm, under Requirements Engineering Catalog, Reference Procedures and Guides and Requirements Repository Management Guide for specific guidance.
    RD Manager
    5. Support project MS1 Exit activities
    Support the MS1 Milestone Readiness Review and the Milestone Exit Review to ensure all RE recommendations and guidelines have been addressed. Refer to the Milestone Readiness Review procedure on the IT PAL, http://itpal.ds.irsnet.gov/, by selecting ACIO View, S&P, Life Cycle Model and then Milestone Exit Review procedure for specific guidance.
    Project Manager
    RD Manager
    A 2: Perform Current/Future State Analysis (See Figure 2.110.2–3)  
    Steps Roles
    1. Verify the work products of the solution scope/concept with appropriate stakeholders
    Work products that address capabilities/solution concept/requirements/current/future/state/release strategy, etc. are reviewed to ensure that they are correct and complete in terms of the proposed solution as a whole and accurately reflect the stakeholder needs and expectations. Verification techniques used include peer reviews and checklists. Refer to the Requirements Peer Review Guide and the Requirements Handbook on the IT PAL List, http://itpal.ds.irsnet.gov/, for further guidance.
    Note that verification occurs on an ongoing basis as the solution is defined and this activity step is confirmation of the ongoing work.
    IPT Members
    RD Manager
    2. Validate the overall solution scope/concept with appropriate stakeholders
    Establish the approach to presenting and validating the results of all solution concept analysis to affected stakeholders. Execute and then capture and summarize how this validation was executed, that is, how these stakeholders were engaged and their understanding and concurrence established. All scope issues are resolved at the end of this activity. Refer to the Requirements Peer Review Guide and the Requirements Handbook on the IT PAL List, http://itpal.ds.irsnet.gov/, for further guidance.
    Note that validation occurs on an ongoing basis as the solution is defined and this activity step is confirmation of the ongoing work.
    Project Manager
    RD Manager
    IPT Members
    3. Create the Business System Concept Report (BSCR)- Refer to the BSCR DID on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.
    • Document business solution concept - Document project solution concept and scope, stakeholders, critical success factors (CSFs), principles, constraints, and assumptions (PCAs), etc. into the project BSCR template. The BSR DID is an alternative to the BSCR, BSAR and BSRR DIDs for some projects. Refer to the BSR DID on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.

    • Perform Customer Technical Review (CTR) for BSCR - A CTR is performed by IRS stakeholders to provide an in-depth review of selected technical and business artifacts produced by a project. Refer to the Customer Technical Review Procedure on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.

    • Gain approvals for BSCR - Secure signatures of formal approval from all of the appropriate stakeholders on the BSCR

    RD Manager
    A 3: Develop and Analyze Business Architecture and Requirements (See Figure 2.110.2–4)  
    Steps Roles
    1. Confirm requirements engineering approach (i.e. review the RP and BSCR with the IPT/Project Manager)
    It is recommended that RETA be executed again at this stage of development. The project will have a better understanding of the intended project development activities, and will be able to provide more precise answers to posed questions than they were able to provide during Project Initiation.
    RD Manager
    2. Develop and analyze process model
    (Refer to the BSAR or BSR DIDs on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.)
    • Identify major process threads (event result/pairs)

    • Partition process analysis (among analysts)

    • Define processes and flows

    • Define key terms

    • Confirm/refine improvement opportunities

    • Confirm/refine impacts, issues and risks

    • Confirm/refine requirements statements

    • Refine Enterprise Architecture traceability relationships

    • Identify business transition actions

    • Establish traceability (Refer to the RADM Program Office Home Page, http://mits.web.irs.gov/brrm/, RE Program Office, How We Can Help, Information Sharing and Outreach)

    • Peer review model work products

    IPT Members
    RD Manager
    3. Develop and analyze initial business rule model
    (Refer to the BSAR or BSR DIDs on the IT PAL List, http://itpal.ds.irsnet.gov/ ,for specific guidance.)
    • Establish business rule and term management procedures

    • Identify rule sets

    • Assign rule sets to process

    • Define rule set characteristics

    • Establish traceability

    • Peer review model work products

    • Develop Business Rule Capture Plan

    RD Manager
    4. Develop and analyze organization model
    (Refer to the BSAR or BSR DIDs on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.)
    • Define organization model

    • Define organizational users

    • Define new roles

    • Define new responsibilities

    • Define staffing requirements

    • Define new skills

    • Define training

    • Establish traceability

    • Peer review model work products

    IPT Members
    RD Manager
    5. Develop and analyze location model
    (Refer to the BSAR or BSR DIDs on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.)
    • Define Locations

    • Define location model

    • Define types of locations

    • Define main facilities

    • Describe new locations and their roles

    • Define production capacity

    • Define operating costs

    • Define planned capital expenditures

    • Define expansion capabilities

    • Define location impacts

    • Establish traceability

    • Peer review model work products

    IPT Members
    RD Manager
    6. Develop business scenarios
    Develop scenarios that describe a number of discrete paths through a process flow that executes specific business rules. Scenario descriptions at this level are created before business rules have been developed. Describe the scenario in general terms – the characteristics of the triggering event along with the expected output. Refer to the RADM Program Office web-site, http://mits.web.irs.gov/brrm/, RE Catalog, Reference Procedures and Guides, and Business Modeling Guidance.
    IPT Members
    RD Manager
    7. Develop and analyze requirements
    (Refer to the BSAR or BSR DIDs on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.)
    • Identify requirement statements

    • Establish traceability

    • Confer with testing team as to testability of requirements

    • Peer review work products

    IPT Members
    RD Manager
    8. Develop and analyze non-functional considerations
    (Refer to the BSAR or BSR DIDs on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.)
    Analysis of non-functional considerations provides the basis for establishing non-functional requirement statements, and all of these non-functional considerations will need to be captured at some level as requirement statements. The requirement statements captured in the BSRR must then reference this additional material in the BSAR that fully clarifies, details and defines the requirement.
    IPT Members
    RD Manager
    9. Verify and validate requirements
    • Review requirements for completeness and correctness (verification)

    • Confirm or modify requirements as required

    • Ensure traceability exists as appropriate for project requirements

    • Review verification requirements for satisfaction of required solution (validation)

    Project Manager
    IPT Members
    RD Manager
    10. Identify and confirm release requirements
    (Refer to the Requirements Handbook, section 5.7 for guidance)
    • Prioritize requirements

    • Evaluate prioritized requirements against other input considerations

    • Establish consensus with stakeholders

    • Confirm release requirements

    Project Manager
    RD Manager
    11. Document Domain Architecture (DA)-BSRR
    Capture and document the project solution requirements for confirmation and approval by all stakeholders. Refer to the BSRR DID on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.
    RD Manager
    12. Document DA-BSR (if applicable)
    BSR DID is an alternative to the BSCR, BSAR and BSRR DIDs for some projects. Refer to the BSR DID on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.
    RD Manager
    13. Document DA-BSAR
    Business models/scenarios, rules and rule sets are documented in the Enterprise Architecture owned DA-BSAR. RADM provides a concurrence signature on the DA-BSAR. Refer to the BSAR DID on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.
    RD Manager
    14. Support CTR activities for the DA-BSRR and DA-BSAR; or DA-BSR (if applicable)
    Performed by IRS stakeholders to provide an in-depth review of selected technical and business artifacts produced by a project. A senior RADM Manager will sign off on the BSRR, DA-BSAR or DA-BSR.
    RADM recommends maintaining “requirements” (models, rules, terms and statements, etc.) in a repository and then producing the project artifacts from the repository data.
    Project Manager
    RD Manager
    IPT Members
    15. Support Life Cycle Stage Review
    Performed by IRS stakeholders to provide a broad, horizontal review across the technical and business aspects of the solution to verify its completeness, correctness, and consistency given its point in the life cycle. A Life Cycle Stage Review (LCSR) deals with all artifacts that comprise the solution. In addition, each LCSR specifies a set of solution criteria for review. These criteria may not be eliminated unless they are not applicable to the work performed by the project. A successful LCSR results in approving the solution; subsequently, the appropriate baseline may be established or updated. Refer to the LCSR Procedure on the IT PAL, http://itpal.ds.irsnet.gov/, by selecting ACIO View, S&P and Life Cycle Model for specific guidance.
    Project Manager
    RD Manager
    IPT Members
    16. Update project/release planning (as needed)
    Update the PMP and the RP to reflect the enhanced understanding of the project solution and effort required to complete the project. Also provide input to the project Transition Management Plan, which is a description of the approach used to ensure the solution is successfully transferred to, operated, and used by the IRS as the standard way to do business. Refer to the Transition Management Plan Template on the IT PAL, http://itpal.ds.irsnet.gov/, by selecting ACIO View, S&P and Transition Management for specific guidance.
    Project Manager
    RD Manager
    17. Establish Functional Baseline Solution
    An agreed to set of system-level requirements and system architecture are documented in the BSCR, DA-BSAR, DA-BSRR (or DA-BSR) and snapshot of the repositories for exiting the Domain Architecture Phase.
    Project Manager
    RD Manager
    18. Support project MS2 Exit activities
    Support the MS2 Milestone Readiness Review and the Milestone Exit Review to ensure all requirements engineering recommendations and guidelines have been addressed.
    Project Manager
    RD Manager
    IPT Members
    A 4: Confirm and Refine Requirements (See Figure 2.110.2–5)  
    Steps Roles
    1. Clarify and update business rules
    Refer to the BSAR DID on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.
    • Capture business rules and rule sets

    • Clarify and update rules

    • Identify and define terms

    • Analyze and verify rules

    • Validate and refine rules

    Project Manager
    RD Manager
    IPT Members
    2. Update process model as appropriate
    Refer to the BSAR DID on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.
    • Re-verify and re-validate, as necessary, process model with subject matter experts

    Project Manager
    RD Manager
    IPT Members
    3. Identify and define and new terms
    • Update BSR or BSRR with new terms

    Project Manager
    RD Manager
    IPT members
    4. Refine detailed requirements statements
    Refer to the BSAR DID on the IT PAL List, http://itpal.ds.irsnet.gov/, for specific guidance.
    • Identify derived requirement statements

    • Establish traceability

    • Peer review work products

    Project Manager
    RD Manager
    IPT Members
    5. Verify and validate requirements
    • Review requirements for completeness and correctness (verification)

    • Confirm or modify requirements as required

    • Ensure traceability exists as appropriate for project

    • Review verification requirements for satisfaction of required solution (validation)

    Project Manager
    RD Manager
    IPT Members
    6. Document Preliminary Design (PD)-BSRR
    Capture and document the project solution requirements for confirmation and approval by all stakeholders.
    RD Manager
    IPT members
    7. Document PD-BSR (if applicable)
    BSR DID is an alternative to the BSCR, BSAR and BSRR DIDs for some projects.
    RD Manager
    IPT Members
    8. Document PD-BSAR
    Document the detailed business rules within the business rule sets identified during the DA phase, as well as refinements to the process model, term catalog and any other architecture in the BSAR.
    RD Manager
    IPT members
    9. Review Design Specification Report (DSR)-1
    Confirm requirements traceability relationships.
    Project Manager
    RD Manager
    10. Support CTRs for PD-BSRR, PD-BSAR, and DSR-1
    Performed by IRS stakeholders to provide an, in-depth review of selected technical and business artifacts produced by a project. A senior RADM Manager will sign off on the BSRR, DA-BSAR or DA-BSR. The DSR-1 is reviewed from a RE perspective to confirm requirements traceability relationships.
    RADM recommends maintaining “requirements” (models, rules, terms and statements, etc.) in a repository and then producing the project artifacts from the repository data.
    Project Manager
    RD Manager
    IPT Members
    11. Establish Allocated Baseline Solution
    An agreed to set of refined and/or derived requirements allocated to specific software, hardware, or interfaces documented in the PD-BSAR, PD-BSRR (or PD-BSR) and a snapshot of the repositories for exiting the PD Phase.
    Project Manager
    RD Manager
    IPT Members
    Project CCB
    12. Support project MS3 Exit activities
    Support the MS3 Milestone Readiness Review and the Milestone Exit Review to ensure all requirements engineering recommendations and guidelines have been addressed.
    Project Manager
    RD Manager
    IPT Members
    Project CCB
    A 5: Refine and Allocate Requirements (See Figure 2.110.2–6)  
    Steps Roles
    1. Verify and Validate Requirements
    • Review requirements for completeness and correctness (verification). Peer Reviews are highly recommended.

    • Confirm or modify requirements as required.

    • Ensure traceability exists as appropriate for project.

    • Review verification requirements for satisfaction of required solution (validation). Techniques recommended for verification are story-boarding or formalized walkthroughs of scenarios.

    • This task includes verifying and validating the solution, including models, statements, considerations, risks, PCAs, etc.

    Project Manager
    RD Manager
    IPT Members
    2. Confirm traceability
    A third BSRR (Detailed Design [DD]-BSRR) is prepared during the DD Phase, prior to MS4A, to reflect traceability to the physical design. Any new constraining requirements or requirements that impact the actual design of the solution are recorded and traced to higher-level requirements.
    RD Manager
    IPT Members
    3. Allocate requirements
    • Document DD-BSAR or DD-BSR

    • Support CTRs for DD-BSRR or DD-BSR

    • A senior RADM Manager will sign off on the DD-BSRR or DD-BSR

    • The DD-BSRR becomes part of the Physical Design Allocated Baseline

    RD Manager
    IPT Members
    4. Update/refine Allocated Baseline Solution
    An agreed to set of refined and/or derived requirements are allocated to specific software, hardware, or interfaces documented in the DD-BSRR (or DD-BSR) and a snapshot of the repositories for exiting the PD Phase.
    RE activities focus on managing and maintaining the requirements. Any new requirements may require a Change Request (CR). Refer to the project's Change Management Plan for guidance.
    RD Manager
    Project CCB
    5. Support project MS4A Exit activities
    Support the MS4A Milestone Readiness Review and the Milestone Exit Review to ensure all RE recommendations and guidelines have been addressed.
    Project Manager
    RD Manager
    IPT Members
    Project CCB

2.110.2.2  (02-19-2013)
Tailoring Guidelines

  1. This procedure may be tailored to meet specific project requirements. If tailoring is used, refer to the tailored approach according to what has been documented in the Project Tailoring Plan. This plan must identify all tailoring decisions and explain the rationale and impact of each. The approved tailoring decision must ultimately be reflected in the project WBS and the project schedule, as well as any other related work products and deliverables. Details on what is required when tailoring the IRS ELC Framework is documented in the IRS ELC Guide. Similarly, key RADM artifacts (i.e., the BSCR and BSRR DIDs include an appendix to capture tailoring rationale for the acceptable execution of the RE process at the deliverable/work product level. If a project team decides to tailor any of the RADM artifacts, the tailored DID must be approved by RADM. All tailoring requests, with supporting rationale, should be submitted in writing to and approved by the process and artifact owner.

2.110.2.3  (02-19-2013)
CMMI, ITIL, PMI Compliance

  1. The Capability Maturity Model Integration (CMMI) can be used to judge the maturity of an organization’s processes and related procedures and process assets and can be used to plan further improvements. CMMI sets the standard for the essential elements of effective and mature processes, improved with quality and efficiency.

  2. The Information Technology Infrastructure Library (ITIL) contains a collection of best practices, enabling organizations to build an efficient framework for delivering IT Service Management (ITSM) and ensuring that they are meeting business goals and delivering benefits that facilitate business change, transformation, and growth.

  3. The Project Management Institute (PMI) organization advances the project management profession through globally recognized standards and certifications.

  4. This process asset is used to indicate that all artifacts are developed or acquired, incorporating CMMI, ITIL, PMI requirements, to meet the business objectives of the organization and that they represent investments by the organization that are expected to provide current and future business value to the IRS.

2.110.2.4  (02-19-2013)
Definition, References

  1. Definitions, References

2.110.2.4.1  (02-19-2013)
Definitions

  1. A Glossary is available in Appendix A.

2.110.2.4.2  (02-19-2013)
References

  1. The following resources are either referenced in this document or were used to create it.

    Business System Concept Report (BSCR) DID, V3.0, 3/11/2010

    Business System Requirements Report (BSRR) DID, V1.1.1, 9/1/2009

    Business System Report (BSR) DID, V1.0, 2/4/2010

    Business System Architecture Report (BSAR) DID, V2.1, 6/24/2010

    Customer Technical Review (CTR) Procedure, V2.1, 2/17/2009

    Enterprise Life Cycle Artifacts by Phase, V4.5, 1/8/2012

    Internal Revenue Manual 2.16.1, Enterprise Life Cycle, 4/25/2012

    Life Cycle Stage Review (LCSR) Procedure, V2.1, 2/17/2009

    Milestone Exit Review (MER) procedure, V3.0, 1/14/2010

    Milestone Readiness Review (MRR) procedure, V3.0, 4/14/2010

    RADM Web page, RE Program Office

    Requirements Engineering Process Description, V2.1, 4/19/2010

    Requirements Engineering Tailoring Application (RETA) User Guide, V2.4, 9/9/2009

    Requirements Handbook, V2.0, 3/31/2007

    Requirements Peer Review Guide, V1.0, 3/31/2007

    Requirements Plan DID, V3.0, 7/25/2011

    Requirements Repository Management Guide, V2.0, 11/9/2011

    Transition Management Plan, V7.0, 2/14/2011

2.110.2.5  (02-19-2013)
Exhibits

  1. Exhibits A &B

2.110.2.5.1  (02-19-2013)
Exhibit A: Glossary

  1. Glossary

    Terms Definition
    Allocated Baseline One of the configuration management features of the Solution Layer of the ELC Framework. Contains requirements that have been refined and/or derived from system-level requirements, requirements allocated to specific software, hardware, or interfaces from a CS or higher-level CI, as well as additional design constraints. The baseline established at ELC MS4A exit.
    Artifact A work product created by a process or procedure step, e.g., design specifications, etc.
    Business System Architecture Report A report that specifies the business and technical architectures, including business processes, organizations, locations, applications, data, and technologies for a particular business area or business system.
    Business System Concept Report A report that describes a vision for the future system and its operation, grounded in an awareness of the current situation and customer/user needs, and describes key aspects of how that vision may be realized.
    Business System Report A report that provides an alternative to preparation of a separate BSCR, BSAR and BSRR for projects or releases where a single, integrated document will not introduce significant risk with regard to definition of system scope or architecture. The BSR documents the vision or concept, architecture and requirements analysis that form the basis for subsequent business solution design, development, integration, and testing.
    Business System Requirements Report A report that documents a feasible, quantified, verifiable set of requirements that define and bound the business system or subsystem(s) being developed, or enhanced by the project. These requirements form the basis for the business system design, development, integration, and deployment.
    Customer Technical Review One of the features in the Solution Layer of the ELC Framework. A CTR is a review performed by IRS stakeholders on an artifact or a small group of closely related artifacts produced by a project with the purpose of facilitating approval of the artifact by ensuring early stakeholder feedback as well as early identification and resolution of issues and actions.
    Data Item Description Describes data elements necessary for completion of a report.
    Functional Baseline One of the configuration management features of the Solution Layer of the ELC Framework. Comprises the initial system-level requirements and system architecture describing a CS’s or CI’s functional, inter-operability and interface characteristics. The baseline established at ELC MS2 exit.
    Life Cycle Stage Review An LCSR is a review of the technical and business aspects of the entire solution being developed to verify that it is appropriately constituted (i.e., complete, consistent, and correct) given its point in the life cycle, and to approve the solution for baselining. LCSRs occur at the end of life cycle stages.
    Process A collection of activities that begin with inputs and produce outputs.
    Requirements and Demand Management A Business Analysis Center of Excellence; its mission is to provide guidance and oversight to projects following the ELC with the goal of helping projects achieve a quality requirements baseline that reflects the needs of the business/customers and results in the deployment of solutions that meet those needs.
    Requirements Engineering A methodology that includes Requirements Development and Requirements Management activities.
    Requirements Engineering Tailoring Application A software application used to provide guidance on modifying (usually scaling back) ELC related project activities and work products relative to RE.
    Requirements Plan The Requirements Plan documents the activities, methods, and techniques that will be used to perform and support requirements development (RD) and requirements management (RM).
    Stakeholder An individual or organization that has an interest in the successful development of the completed information system. Stakeholders provide the needs and features (aka capabilities) of the system. They also are responsible for validating and approving requirements.
    Tailoring Plan A plan that documents all tailoring decisions, explains the nature of all modifications, and provides justification for each change.
    Tool An application or job aid for a specific purpose (e.g. checklist, template).
    Traceability Is the creation and maintenance of "A discernible association among two logical entities such as requirements, system elements, verifications, or tasks."
    User An individual who is using the current system or who will be using the future system. Users provide information on the "as is " situation and the business need to help define the requirements for the "to be" situation.
    Validation Process to ensure that the solution being developed or changed will satisfy functional and other requirements.
    Verification Ensures that each step in the process of building the solution components yield the right products.

2.110.2.5.2  (02-19-2013)
Exhibit B: Abbreviation and Acronyms

  1. Abbreviations and Acronyms

    Acronyms Definition
    BSAR Business System Architecture Report
    BSCR Business System Concept Report
    BSRR Business System Requirements Report
    BSR Business System Report
    CAP Capabilities
    CCB Configuration Control Board
    CSFs Critical Success Factors
    CTR Customer Technical Review
    DA Domain Architecture
    DD Detailed Design
    DID Data Item Description
    DSR Design Specification Report
    ELC Enterprise Life Cycle
    IPT Integrated Project Team
    LCSR Life Cycle Stage Review
    MOA Memorandum of Agreement
    MS Milestone
    PAL Process Asset Library
    PCAs Principles, Constraints, and Assumptions
    PD Preliminary Design
    PMP Project Management Plan
    PTP Project Tailoring Plan
    RADM Requirements and Demand Management
    RD Requirements Development
    RE Requirements Engineering
    RETA Requirements Engineering Tailoring Application
    RM Requirements Management
    RP Requirements Plan
    WBS Work Breakdown Structure

More Internal Revenue Manual