2.110.2  Requirements Engineering Process

Manual Transmittal

February 19, 2013

Purpose

(1) This transmits new IRM 2.110.2, Requirements Engineering, Requirements Engineering Process.

Material Changes

(1) This IRM is the initial publication of the Requirements Engineering Process. The Requirements Engineering Process presents the Requirements and Demand Management’s methodology for performing requirements engineering best practices, such as those recommended by the Capability Maturity Model Integration from the Carnegie-Mellon Software Engineering Institute during the Milestones 1 through 4a phases of the Enterprise Life Cycle project management process.

Effect on Other Documents

None

Audience

This process description is applicable to all IRS managers, personnel, and executives who manage, directly support, or provide oversight to projects following the Enterprise Life Cycle, IRM 2.16.1.

Effective Date

(02-19-2013)

Terence V. Milholland
Chief Technology Officer

2.110.2.1  (02-19-2013)
Requirements Engineering Process

  1. Requirements Engineering Process

2.110.2.1.1  (02-19-2013)
Introduction

  1. Introduction

2.110.2.1.1.1  (02-19-2013)
Administration

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

2.110.2.1.1.2  (02-19-2013)
Purpose of Process Description

  1. The Requirements Engineering Process details project requirements engineering (RE) activities, and provides an operational definition of the major components of the RE process. This description specifies, in a complete, precise, and verifiable manner, the requirements, design, and behavioral characteristics of the RE process as it pertains to a Waterfall Approach of the Enterprise Life Cycle (ELC) project management process. Tailoring of this process in order to meet the individual needs of each project is covered in the Tailoring Guidelines Section of this document.

  2. 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. This document describes the artifacts of RADM.

  3. For a more comprehensive process description that includes all stakeholders involved in the RE process, refer to the RE Process Description found on the RADM web site at http://mits.web.irs.gov/brrm/cat/repd.htm.

2.110.2.1.1.3  (02-19-2013)
Document Overview

  1. This document describes a set of interrelated activities, which transform inputs into outputs, to achieve a given purpose and states the guidelines that all projects should follow regarding the RE process. The format and definitions used to describe each of the process steps of the RE process are described below:

    • Purpose – The objective of the process step.

    • Roles and Responsibilities – The responsibilities of the individuals or groups for accomplishing a process step.

    • Entry Criteria – The elements and conditions (state) necessary to trigger the beginning of a process step.

    • Input – Data or material needed to perform the process step. Input can be modified to become an output.

    • Process Activity – The list of activities that make up the process step.

    • Output – Data or material that are created (artifacts) as part of, produced by, or resulting from performing the process step.

    • Exit Criteria – The elements or conditions (state) necessary to trigger the completion of a process step.

2.110.2.1.2  (02-19-2013)
Process Overview

  1. Process Overview

2.110.2.1.2.1  (02-19-2013)
Work Products

  1. This section describes the work products needed to execute the process (known as inputs) as well as those produced by the RE process (known as outputs).

2.110.2.1.2.1.1  (02-19-2013)
Work Products Used by this Process (Inputs)

  1. The following directives, process descriptions, procedures, template and/or training materials, are used to assist in the execution of the RE process:

    • High level project Solution Concept – An ELC MS0 artifact which describes the project's future business vision, user needs, planned functionality and conceptual system solution.

    • Business Case (Exhibit 300) – For IRS Major IT investments, a structured, budgetary-based business case.

    • Project Charter - describes the full scope of a project in business and technical terms and the releases planned for the system(s) that the project will develop.

    • Project Tailoring Plan (PTP) – documents all modifications (along with justifications) to the ELC standard approach where project specific customizing is needed; especially with respect to desired management and governance of the project, as well as desired product lists and reviews.

    • Project Management Plan (PMP) - documents project scope, tasks, schedule, allocated resources and interrelationships with other projects, for the purpose of guiding both the project execution and project control.

    • Project Kickoff Meeting – minutes which document that IT leadership and stakeholders understand and are in agreement with the goals, objectives, scope, business capabilities and projected costs of the project and are prepared to fully support the execution of the project.

    • Requirements Plan (RP), Business System Concept Report (BSCR), Business System Requirements Report (BSRR) and Business System Report (BSR) Data Item Descriptions – templates which describe data elements necessary for completion of a RP, BSCR, BSRR or BSR.

    • RE Process Description – documents detailed instructions for performing RE activities throughout the entire ELC of a project.

    • Business Modeling Practice Guide – presents an introduction to the basic building blocks of process models and how they are represented in a set of graphical symbols/notation, and explains how these building blocks are used. Modeling guidance is also provided for: Visio stencils, business rules, process models and rule sets.

    • Requirements Handbook – describes the people, ELC, processes, activities, products, methods, techniques and technologies that together make up RADM’s RE methodology relative to a project’s performance of its business system requirements activities.

    • Requirements Repository Management Guide – documents the RADM standards for using a requirements repository to define, maintain and report requirements.

    • Requirements Peer Review Guide – provides a disciplined practice for detecting and correcting defects in requirements artifacts early in the software development process and includes a Peer Review Form to facilitate the review process.

2.110.2.1.2.1.2  (02-19-2013)
Work Products Produced by this Process (Outputs)

  1. The following work products (artifacts) are produced by the RE process and may be used as inputs to other processes, such as:

    • RP – documents a project’s RE approach, including the activities, methods, and techniques that will be used to perform and support requirements development and requirements management.

    • RE Process Work Breakdown Structure (WBS) - although an optional output, the RE Process WBS is typically created to outline the very detailed activities (with start and end dates), responsibilities and critical path reflecting RE process efforts. The RE Process WBS will correlate to the project WBS.

    • BSRR – documents a feasible, quantified, verifiable set of requirements that define business system/subsystem (s) being developed by the project. These requirements form the basis for the business system design, development, integration, and deployment.

    • BSR – documents business and technical requirements and a high level technical solution. The BSR is a combination of the BSCR, BSRR, and the Business System Architecture Report (BSAR) (which documents enterprise architectural components of the solution concept) and may be produced in lieu of a project’s separate BSCR, BSRR and BSAR.

    • Requirements Traceability Matrix – documents relationships between differing levels of requirements and amongst various requirements attributes.

    • If necessary, updated BSCR – describes a vision for the future system and its operation, and describes key aspects of how that vision may be realized. This may be updated based on a clearer understanding of the solution after requirement development activities occur.

2.110.2.1.2.2  (02-19-2013)
Roles and Responsibilities

  1. Many roles 1 are involved in the RE process. This section defines four key roles along with a description of their associated responsibilities with the RE process.

  2. Roles and Responsibilities

    Role Description Definition of Responsibility
    Project Manager Oversees requirements planning and approving the RP; ensure that project resources are assigned to perform requirements activities; and monitors requirements management, verification/validation activities throughout the life of the project.
    Requirements Development Manager Develops the RP; ensures RE practices are followed; manages the requirements development team and accomplishment of RE activities. The RD Manager is typically supported by a Business Analyst who coordinates the development of various models (e.g., process, organization, location, and business rules), a Technical Analyst who coordinates the development of technical architecture and design models (e.g., data, application, and technology), a Requirements Analyst who leads requirements elicitation workshops and documents requirements which will then be entered into the requirements repository, and a Repository Manager who configures and maintains the project’s requirements repository.
    Integrated Project Team (IPT) members Participate in requirements elicitation sessions. Subject Matter Experts and end users within the IPT are used heavily during the RE process, as well as members with enterprise architecture and security expertise. The IPT is also responsible for initially verifying, validating, and endorsing requirements.
    Project Configuration Control Board (CCB) Approves requirements baselines and any requested changes to baselined requirements. This governing body is typically comprised of stakeholder and IT executives.
  3. Note:

    1 Roles and responsibilities should be assigned to individuals who possess the knowledge and skills to perform the required tasks. Project roles may vary from project to project and are performed by a variety of skilled individuals occupying various position descriptions.

2.110.2.1.2.3  (02-19-2013)
Requirements Engineering Process Flow Diagram

  1. Requirements Engineering Process Flow Diagram 2

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

  2. Note:

    2 508 Compliance requires that a text version of a process flow diagram be included in any document or the diagram is not permitted. Refer to http://www.section508.gov for further direction.

    Note:

    3 Verify and Validate Work Products and Maintain Traceability are Requirements Management activities which are performed throughout the requirements process.

2.110.2.1.3  (02-19-2013)
Requirements Engineering Process Steps

  1. Requirements Engineering Process Steps

2.110.2.1.3.1  (02-19-2013)
Step 1: Perform Initial Scoping and Planning

  1. Perform Initial Scoping and Planning

2.110.2.1.3.1.1  (02-19-2013)
Purpose

  1. Initial scoping and planning is performed to determine and then document the project’s approach to performing RE activities and creating artifacts (deliverables and work products). Depending on a project’s scope (as documented in the BSCR), it may be necessary to modify the RE approach relative to the mandated set of artifacts requested by the ELC. The modifications (typically an altering of activities and/or artifacts) can be estimated using RADM’s RE Tailoring Application (RETA); and subsequently documented in the PTP and the RP.

  2. Along with the RE approach, a schedule or WBS is typically created to outline activities (with start and end dates), responsibilities and critical paths reflecting RE process efforts.

2.110.2.1.3.1.2  (02-19-2013)
Roles and Responsibilities

  1. The Project Manager, in conjunction with the RD Manager, is responsible for determining RADM’s level of support to the project and signing a Memorandum of Agreement (MOA) with RADM for their support. Invite RADM to the project kick-off meeting. The Project Manager will update the PTP if necessary, based on agreement with the RETA results.

  2. The RD Manager is responsible for preparing the RP; and along with the IPT, executing all activities in the RP as documented. Additionally, the RD Manager may coach the project on the use of RETA if project tailoring is applicable and ensures that the requirements repository is created.

2.110.2.1.3.1.3  (02-19-2013)
Entry Criteria

  1. Initial Scoping and Planning occurs after the following MS0 and MS1 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 PMP has been initiated or approved

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

2.110.2.1.3.1.4  (02-19-2013)
Input

  1. The following are inputs to this process step:

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

    • Project Kickoff Meeting Minutes

    • Project Charter

    • Solution Concept

    • PTP

    • PMP (optional)

    • Project WBS

    • RETA Application

2.110.2.1.3.1.5  (02-19-2013)
Process Activity

  1. Sign-off on RADM support needs

    • Determine, negotiate and sign-off on a MOA between the Project and RADM.

  2. Revise the PTP

    • Determine the project’s scope for RE MS2 activities and update the PTP as needed.

  3. Sign-off on project RP

    • Document the approach relative to the project’s RE MS2 activities and gain approval of the RP.

  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.

  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.

2.110.2.1.3.1.6  (02-19-2013)
Output

  1. The following are outputs to this process step:

    • Project-RADM MOA

    • Project RP

    • Project Requirements Repository

    • Updated PTP (optional)

    • RETA Tailoring Result Report (optional)

    • Tailoring Questions and Answers Report (optional)

    • RE Process WBS (optional)

    • Updated Project WBS (optional)

2.110.2.1.3.1.7  (02-19-2013)
Exit Criteria

  1. This process step is complete when:

    • The Project-RADM MOA has been approved.

    • The project’s RP has been approved.

    • The project’s requirements repository has been established.

2.110.2.1.3.2  (02-19-2013)
Step 2: Perform Current/Future State Analysis

  1. Perform Current/Future State Analysis

2.110.2.1.3.2.1  (02-19-2013)
Purpose

  1. The purpose of examining the current (as is) and future state (to be) is to show the effort required to implement the project’s solution through an impact analysis. This discussion occurs during the Domain Architecture Phase and will align to the six ELC solution perspectives (POLDAT – process, organization, location, data, application and technology). The results of this analysis frame the solution capabilities and functionality by describing the high level business, technical, and infrastructure aspects.

2.110.2.1.3.2.2  (02-19-2013)
Roles and Responsibilities

  1. The Project Manager is responsible for ensuring resources are allocated and available to perform the POLDAT analysis. The Project Manager is responsible for resolving any issues that arise during the BSCR preparation or approval processes.

  2. The RD Manager is responsible for ensuring the concept and scope of the solution are accurate and approved by all stakeholders. The RD Manager is also responsible for documenting the project solution concept and scope via the BSCR and to prepare it for approval by appropriate stakeholders.

  3. The IPT is responsible for ensuring the concept and scope of the solution is sufficiently characterizing the current state weaknesses and improvement opportunities of the target business area.

2.110.2.1.3.2.3  (02-19-2013)
Entry Criteria

  1. Generally, Perform Current/Future State Analysis occurs after the following event has occurred:

    • Validated and verified solution concept and scope

2.110.2.1.3.2.4  (02-19-2013)
Input

  1. The following are inputs to this process step:

    • Business drivers, objectives and critical success factors

    • Current state descriptions for POLDAT

    • Current state high-level business models and descriptions

    • Current state impacts

    • Current state weaknesses

    • Conceptual traceability to Enterprise Architecture

    • Future state key measures

    • Future vision and benefits

    • Updated capabilities

    • 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)

    • RETA Tailoring Report

2.110.2.1.3.2.5  (02-19-2013)
Process Activity

  1. Verify the work products of the solution scope/concept with appropriate stakeholders

  2. Validate the overall solution scope/concept with appropriate stakeholders

  3. Create the BSCR

    • Document business solution concept

    • Perform Customer Technical Review (CTR) for BSCR

    • Gain approvals for BSCR

2.110.2.1.3.2.6  (02-19-2013)
Output

  1. The following are outputs to this process step:

    • BSCR or

    • Initial content around Concept and Scope Sections of the BSR

2.110.2.1.3.2.7  (02-19-2013)
Exit Criteria

  1. This process step is complete when:

    • A CTR of the BSCR is performed and formal approval and acceptance of the BSCR is received.

2.110.2.1.3.3  (02-19-2013)
Step 3: Develop and Analyze Business and System Architectures and Requirements

  1. Develop and Analyze Business and System Architectures and Requirements

2.110.2.1.3.3.1  (02-19-2013)
Purpose

  1. The purpose of developing and analyzing business and system architectures and requirements is to fully describe the business and technical solution architectures (functional considerations), along with non-functional considerations (such as performance, reliability, and disaster recovery). These activities begin in the Domain Architecture Phase and are generally completed during the Preliminary Design Phase.

2.110.2.1.3.3.2  (02-19-2013)
Roles and Responsibilities

  1. The Project Manager is responsible for ensuring resources are allocated and available to perform the analysis and documentation. The Project Manager is responsible for resolving any issues that arise during the BSRR or BSR preparation or approval processes.

  2. The RD Manager is responsible for is responsible for ensuring the architectures and requirements of the solution are accurate and approved by all stakeholders. The RD Manager is also responsible for documenting the business and technical requirements and key traceabilities via the BSRR/BSR and to prepare the BSRR/BSR for approval by appropriate stakeholders.

  3. The IPT is responsible for ensuring the architecture and requirements of the solution are adequately defined.

2.110.2.1.3.3.3  (02-19-2013)
Entry Criteria

  1. Generally, Develop and Analyze Business and System Architectures and Requirements occurs when the project has a fully defined scope and a solid understanding of the area of impacts as identified in Step 2 activities.

2.110.2.1.3.3.4  (02-19-2013)
Input

  1. The following are inputs to this process step:

    • BSCR

    • RP

    • PMP

    • RETA application (recommended)

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

    • Requirement statements (input to the BSRR)

    • Traceability relationships (input to the BSRR)

2.110.2.1.3.3.5  (02-19-2013)
Process Activity

  1. Confirm requirements engineering approach (i.e. review the RP with the IPT/Project Manager)

  2. Develop and analyze process model

    • Define key terms

    • Confirm/refine impacts, issues and risks

    • Confirm/refine requirements statements

    • Establish traceability

  3. Develop and analyze initial business rule model

    • Identify rule sets

    • Establish traceability

  4. Develop and analyze organization model

    • Establish traceability

  5. Develop and analyze location model

    • Establish traceability

  6. Develop business scenarios

  7. Develop and analyze requirement statements

  8. Develop and analyze non-functional considerations

  9. Verify and validate requirements

  10. Identify and confirm release requirements

  11. Document Domain Architecture (DA)-BSRR

  12. Document DA-BSR (if applicable)

  13. Document DA-BSAR (Enterprise Architecture owns the document, but business rule sets are documented here)

  14. Support CTR activities for the DA-BSRR and DA-BSAR; or DA-BSR (if applicable)

  15. Support Life Cycle Stage Review

  16. Update project/release planning

    • Update project/release planning (as needed)

  17. Establish Functional Baseline Solution

    • An agreed to set of system-level requirements and system architecture documented in the BSCR, DA-BSAR, DA-BSRR (or DA-BSR) and a snapshot of the repositories for exiting the Domain Architecture Phase.

  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.

2.110.2.1.3.3.6  (02-19-2013)
Output

  1. The following are outputs to this process step:

    • RETA Tailoring Result Report (only if application is rerun during this step)

    • BSCR (only if significantly updated)

    • DA-BSR (if applicable)

    • DA-BSRR

    • DA-BSAR

    • RP (only if significantly updated)

2.110.2.1.3.3.7  (02-19-2013)
Exit Criteria

  1. This process step is complete when:

    • A CTR of the BSRR or BSR is performed

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

    • The establishment of a Functional Baseline

2.110.2.1.3.4  (02-19-2013)
Step 4: Confirm and Refine Requirements

  1. Step 4: Confirm and Refine Requirements

2.110.2.1.3.4.1  (02-19-2013)
Purpose

  1. The purpose of confirming and refining is to prepare detailed business rules, as well as, refinements to the process models, the term catalog and any business architectures in the BSAR. These activities take place during the Preliminary Design Phase.


More Internal Revenue Manual