Part 2. Information Technology

Chapter 110. Requirements Engineering

Section 2. Requirements Engineering Process

2.110.2 Requirements Engineering Process

Manual Transmittal

August 13, 2019

Purpose

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

Material Changes

(1) Inclusion of IRM internal control requirements and modified the format and structure per IRM template.

(2) Revised content to address agile, lean, and traditional methods of requirements engineering.

Effect on Other Documents

IRM 2.110.2 dated February 19, 2013, is superseded

Audience

The Requirements Engineering Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for developing IT business processes.

Effective Date

(08-13-2019)

Chief Information Officer

2.110.2.1 (08-13-2019)

Program Scope and Objectives

  1. This document describes the formal process for implementing the requirements of the Requirements Engineering (RE) process. It provides an operational definition of the major components of the process and how to perform each step in the process. This document also describes the logical arrangements of steps that are essential to successfully completing the process and achieving its desirable outcome.

  2. Purpose - The purpose of this process is to establish the Requirements Engineering Program Office’s (REPO) authority and responsibility for the definition, execution, and oversight of the Requirements Development and Requirements Management process areas, hereafter referred to as RE. This process clarifies expectations for REPO to support the establishment and advancement of the RE discipline, and the expectations of all Programs and Projects that develop or maintain systems within the Internal Revenue Service (IRS).

  3. Audience - The Requirements Engineering Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for developing IT business processes.

  4. Policy Owner - REPO under Business Planning and Risk Management

  5. Program Owner - REPO is responsible for the development, implementation, and maintenance, of this process. Approval of this process, including updates, rests with the REPO Office.

  6. Primary Stakeholders - All programs and projects that develop or maintain systems are required to perform requirements engineering processes and associated activities in accordance with this process.

  7. Program Goals - REPO is responsible for defining, developing, updating, and institutionalizing the RE discipline to facilitate program/project implementation of quality requirements that accurately reflect the needs of the business and its customers. The RE discipline includes, but is not limited to, requirements elicitation, definition, and management leveraging traditional and agile methods, lean principles, supported by model-based approaches, business rules, visualization, and textual-based requirements. This process, along with REPO training, guidance, coaching, material, and tools, supports all defined Enterprise Life Cycle (ELC) paths at the IRS.
    .

2.110.2.1.1 (08-13-2019)

Background

  1. A process is defined as “A set of related activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

2.110.2.1.1.1 (08-13-2019)
Process Description

  1. Although couched here with the constraints as a “process”, at its most essential, RE is focused on discovering what it is that should be developed (and not how it should be developed). RE will usually result in one or more work products being produced. These products, taken together, represent the software's specification. These work products, however, do not have to be formal written documents — indeed, the work products can be a set of models, a mathematical specification, a collection of use cases or user stories, or even a software prototype.

2.110.2.1.1.2 (08-13-2019)
Goal

  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.
    The Requirements Engineering Program Office’s RE Methodology seeks to provide a tailorable set of techniques and approaches that upholds industry best practices and principles for capturing what needs to be developed.

2.110.2.1.1.3 (08-13-2019)
Objectives

  1. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • A clear understanding between the business and developers on what needs to be built.

    • Prioritized needs/requirements based on achieving the business objectives.

    • Requirements captured and baselined in a form appropriate to the development activity inclusive of many forms such as business rules, models, user stories, visualizations, and others.

    • Sufficiently defined requirements to support development and testing.

    • Requirements change mechanisms that facilitate implementation with minimal overhead.

2.110.2.1.2 (08-13-2019)

Authority

  1. All proposed changes to this document must be submitted in writing, with supporting rationale, to the Requirements Engineering Program Office (REPO).

2.110.2.1.3 (08-13-2019)

Roles and Responsibilities

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

    Name Description
    Project Manager

    • Allocates project resources to perform requirements activities.

    • Ensures adequate RE training.

    • Oversees approval of RE-related Data Item Descriptions and Certifications.
    Business Owner (May also serve as Product Owner in Agile if designated to do so)

    • Owns the business process and provides insight into business architecture.

    • Provides business objectives, needs, and priorities.

    • Validates requirements.
    Requirements Manager

    • Responsible for the collection of requirements.

    • Ensures adherence to proper definition of requirements components.

    • Understands proper use of requirements repositories and the REPO standard.

    • Maintains configuration management principles for requirements components.

    • Maintains consistency in release allocation to requirements.

    • Creates baselines of the repository and baseline reports.

    • Verifies trace relationships completeness and appropriateness.

    • Communicates requirements management standards to project members.

    • Provides input to the requirements plan.

    • Performs impact assessments.

    • Coordinates requirements estimation and metric activities.

    • Monitors status and provides requirements-related status reporting to management.
    Development Team

    • Performs as cross-functional group of people that completes all aspects of work.

    • Supports impact analysis, requirement definition, decomposition, and management.

    • Performs verification activities.

    • Supports validation activities with the Business and/or Product Owner and any other subject matter experts.

    • Execute associated scrum team responsibilities when in an agile approach.
2.110.2.1.4 (08-13-2019)

Program Management and Review

  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

    Process Management  
    Statement: The RE process will have a single Process Owner and a separate Process Manager responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on ROI to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.
    People:  
    Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process.
    Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding RE will not be successful.
    Process:  
    Statement: Modifications to the RE process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.
    Rationale: The process must meet operational and business requirements.
    Technology and Tools:  
    Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention.

    The tools used by this process are the following:

    • Collaborative Lifecycle Management Rational Doors Next Generation

    • Collaborative Lifecycle Management Rational Team Concert

    • Collaborative Lifecycle Management Rational Quality Manager

    • IBM System Architect

    • Microsoft Visio

    • Justinmind

    • Rational Publishing Engine

    • Rational Reporting for Development Intelligence
    Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.
2.110.2.1.5 (08-13-2019)

Program Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.

2.110.2.1.5.1 (08-13-2019)
Controls

  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    Capability Maturity Model Integration CMMI for Development, Version 1.3. CMU/SEI-2010-TR-033. Software Engineering Institute, Carnegie Mellon University. 2010 Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many United States Department of Defense (DoD) and U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization.
    Agile Manifesto, Values, and Principles, 2001 The highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support what they need and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
    Lean Principles, 2000-2018 Specify value from the standpoint of the end customer by product family. Identify all the steps in the value stream for each product family, eliminating whenever possible those steps that do not create value. Make the value-creating steps occur in tight sequence so the product will flow smoothly toward the customer. As flow is introduced, let customers pull value from the next upstream activity. As value is specified, value streams are identified, wasted steps are removed, and flow and pull are introduced, begin the process again and continue it until a state of perfection is reached in which perfect value is created with no waste.
2.110.2.1.5.2 (08-13-2019)
Metrics

  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the RE process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL.

2.110.2.1.5.3 (08-13-2019)
Tailoring Guidelines

  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the RE owner.

  2. This process may be tailored to meet specific project requirements. The tailoring must identify all tailoring decisions that fall outside the adaptability built into the current products and processes adopted from REPO standards and explain the rationale and impact of each. Key REPO artifacts (e.g., requirements plan, business system report) body text and appendices are able to capture most tailoring and rationale. Tailoring outside provided adaptability must be approved by REPO.

2.110.2.1.6 (08-13-2019)

Terms/Definitions/Acronyms

  1. Terms/Definitions/Acronyms

2.110.2.1.6.1 (08-13-2019)
Terms and Definitions

  1. Terms defined in this document.

    Term Definition
    Agile Method A set of software development principles emphasizing ongoing collaboration between the customer and the self-organizing, cross-functional delivery teams. Agile promotes early and frequent value delivery, empowerment, frequent value delivery, technical excellence, and process adaptability throughout the life-cycle of the project. There are several specific agile methods and practices.
    Artifact A work product created by a process or procedure step (e.g., plans, design specifications).
    Baseline Baselines are a part of the configuration management process and help control the solution as it is produced. A baseline establishes what versions of what work products comprise the solution at a specific point in the life cycle. As mentioned previously, work products that are configuration items are placed under configuration management control when they are approved. The solution, however, may contain many different work products of different types—source code, documentation, tests, manuals, etc. -- each with its own version or revision number. The baseline identifies those work products included in the solution and the applicable version or revision of each.
    KISAM The Knowledge, Incident/Problem, Service and Asset Management (KISAM) Tool is the official defect reporting tool for the IRS.
    Lean The core idea of lean is to eliminate/reduce non-value-added activities (termed "wastes") and thus increase customer value.
    Process A collection of activities that begin with inputs and produce outputs.
    RACI The RACI model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. The actions are: R - Responsible for the action (may do the task), A - Accountable for the action (including approval), C - Required to be Consulted on the action, I - Required to be Informed of the action. If a task does not have an Accountable role indicated, then the Responsible role is assumed to be accountable for the task.
    Requirements Engineering A methodology that includes requirements development and requirements management activities
    Requirements Engineering Program Office The Requirements Engineering Program Office of Business Planning and Risk Management is the IRS authority on providing standards and guidance to RE activities, process modeling, and requirements-related solutions. We oversee requirements development and requirements management efforts on all business change, software development, systems integration, and legacy system upgrades throughout IRS Information Technology. Through our efforts, we deliver a homogeneous RE methodology to effectively execute all requirements-related activities for an IRS project.
    Tool An application or job aid for a specific purpose (e.g., checklist, template)
    Traditional method The traditional method uses a linear approach where the stages of the software development process must be completed in a sequential order (i.e., waterfall development).
    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.
    Visualization Visualization is the process by which project teams assemble visual models to represent the desired features (i.e., requirements) of a user interface. Visualization is a collaborative approach that allows stakeholders to define requirements, describe how they appear on a screen, and demonstrate how they interact with other requirements on that screen or across screens. Visual requirements reduce the dependency on text requirements while providing a clearer, shared vision of the desired end state. Visualizations are not intended to evolve into fully functional solutions but are meant to help users visualize requirements and take into account the user experience of the final product.
2.110.2.1.6.2 (08-13-2019)
Acronyms

  1. Acronyms and definitions identified in this document.

    Acronyms Description
    RACI Responsible, Accountable, Consulted, and Informed
    RE Requirements Engineering
    REPO Requirements Engineering Program Office
2.110.2.1.7 (08-13-2019)

Related Resources

  1. Sources that were used to develop and/or support this process.

    • Agile Central Hub Website - An enterprise level, cross-functional initiative established to support the coordination, integration, and progression of agile efforts to enable an efficient and effective IRS transformation. It provides a forum for online training, guidance, open sharing, improvement communities, outreach to the Agile Central Team, and other information.

    • Agile Manifesto, Values, and Principles, 2001

    • Capability Maturity Model Integration CMMI for Development, Version 1.3, CMU/SEI-2010-TR-033, Software Engineering Institute, Carnegie Mellon University, 2010

    • Lean Principles, 2000-2018

    • Requirements Engineering Program Office (REPO) Website – Provides requirements engineering guidance and templates by ELC development path, Requirements Engineering Library, training and information sharing, RE Tools information, REPO service offerings for project support, and access to the REPO Front Door.

     

2.110.2.1.8 (08-13-2019)

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. List below the training resources available for this process:

    • Agile Central Hub Website - An enterprise level, cross-functional initiative established to support the coordination, integration, and progression of agile efforts to enable an efficient and effective IRS transformation. It provides a forum for online training, guidance, open sharing, improvement communities, outreach to the Agile Central Team, and other information.

    • Agile Manifesto, Values, and Principles, 2001

    • Capability Maturity Model Integration CMMI for Development, Version 1.3, CMU/SEI-2010-TR-033, Software Engineering Institute, Carnegie Mellon University, 2010

    • Lean Principles, 2000-2018

    • Requirements Engineering Program Office (REPO) Website – Provides requirements engineering guidance and templates by ELC development path, Requirements Engineering Library, training and information sharing, RE Tools information, REPO service offerings for project support, and access to the REPO Front Door.

2.110.2.2 (08-13-2019)

Process Workflow

  1. A process workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

2.110.2.2.1 (08-13-2019)

Main Process Diagram

  1. Proper RE execution is not necessarily a process represented by a flow but is instead a set of fundamentals that help achieve a desired result. The RE process is represented as a whole in the diagram below where many activities occur almost simultaneously in high-functioning teams. Different events may trigger all or only part of the activities seen below. Any inputs or outputs are presented as ones that supply or result most often from execution of the activities as a whole.

  2. Figure 2.110.2-1

    This is an Image: 60078001.gif
     

    Please click here for the text description of the image.

2.110.2.2.2 (08-13-2019)

Inputs

  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    Name Description Supplier
    Initiating Events Initiators of work can include but are not limited to work requests, change requests, KISAM Tickets, or even conversational inputs such as sprint review/planning, and ongoing collaboration with the business. In general, these initiating events can be summarized as any expression of need. Business Owner
2.110.2.2.3 (08-13-2019)

Outputs

  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder, or, they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    Name Description Recipient
    Defined Scope Predominately reserved for new or major development, in which major system inputs, outputs, system, and organizational interfaces are identified. End-state visions and major development constraints are also a part of the scope definition. Business Owner
    Captured Requirements Requirements can exist in many forms whether textual, rule-based, models-driven, or visual. Captured requirements implies that they are incorporated into the project/program’s requirements repository but can also exist in associated tools. Intermediate project storyboard representation is also included. Captured requirements are also grouped into baselines in conjunction with the other activities such as allocation and prioritization. Development Team Business Owner
    Established Priorities The Business establishes the priorities to achieve the business objectives. The development team may also have technical dependencies which drive what work may need attention and allocation. Though not true priorities, they do influence what needs to be accomplished, so they are being placed into this output of general priorities. Development Team Business Owner
    Validated Requirements Similar to establishing priorities, validation is needed by the business to confirm the mutual understanding that what will be developed will satisfy the business objectives. Demonstrations as seen in visualizations, and walk-throughs of systems and models are ideal, though pure documentation may also suffice. Like the other activities, validation should start before coding, and continue throughout the development process. Development Team Business Owner
    Monitored Progress Monitoring progress based on the size and complexity of the requirements is fundamental and occurs in all development approaches. The monitored data not only supplies information about the current work effort but is used to improve future work effort estimations and predictability. Development Team Requirements Manager
    Captured Trace Relationships Trace relationships are not prescribed but should naturally fall out of artifacts needed by the project and the need for understanding how they relate to others (e.g., a test case is naturally associated with requirement being tested). Trace relationships are also captured in the requirement repository and can include referential associations. Development Team Requirements Manager
    Allocations for Production Requirements may be allocated to a current release, sprint, or other work partition; allocated to a future release or allocated to a product backlog for future consideration and prioritization. Business Owner Development Team Requirements Manager
2.110.2.2.4 (08-13-2019)

Activities

  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Activities are measurable in terms of efficiency and effectiveness. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.

    ID Name Description
    NA Gather Needs Business needs can be gathered from many sources. It may be from documents such as an IRM, or from conversations with the business. Even a bug recorded as a test case expresses a “need” to correct the system. Project should be open to a variety of possible need expressions. Needs may or may not initially be at a level of decomposition to support development. Decomposition to fully understand business logic as business rules, and other details are often gathered during development cycle, performed iteratively, and conducted at a point in development when they are needed for better efficiency.
    NA Validate and Refine Requirements Validation confirms that what has been understood and defined by the development team will meet the objectives of the business. Validation is performed by the business, but often assisted by the development team by walking through models, incremental system builds, and other mechanisms. Validation should begin early in the lifecycle and continue as an ongoing activity throughout development. Validation is not the same as testing – see REPO guidance for more on validation. Refinements are included in this activity as validation often results in new or modified requirements, though it agreeably overlaps with Gathering Needs.
    NA Manage Requirements Managing requirements includes a variety of results that are often contingent upon each other. As a fundamental, managing requirements starts with capturing requirements and related artifacts with trace relationships in the requirements repository. With that information, the project can leverage data to monitor and control progress, perform estimations, and create baselines. This activity overlaps and often happens concurrently with Gathering Needs, Prioritization, and Allocation.
    NA Prioritize and Allocate Requirements The Business establishes the priorities to achieve the business objectives. The development team may also have technical dependencies which drive what work may need attention and allocation. Though not true priorities, they do influence what needs to be accomplished, so they are being placed into this activity of prioritizing. Requirements are allocated to a current release, sprint, or other work partition; allocated to a future release or allocated to a product backlog for future consideration and prioritization. Like the other activities, prioritizing and allocation overlaps with the other activities, and often occurs both concurrently and iteratively throughout development.
2.110.2.2.5 (08-13-2019)

Procedure

  1. The tasks described for each activity should not be viewed as a flow of steps that once executed result in the desired outcome; but instead, tasks that work in conjunction with other tasks in the same activity, and most often invoke other tasks from other activities in a variety of combinations that vary between project development approaches, development environments, requirement initiating events, and other influencing factors.

  2. The requirements engineering discipline does not lend itself to a procedural nature that is universally applicable to all projects. In accordance with REPO guidance, and in alignment with the developmental direction of the IRS, projects should NOT attempt to view RE procedurally or as a sequence of steps to follow; but instead, a body of best practices and guidelines that a project can draw upon to produce the most efficient definitional solution for addressing the widely diverse universe of IRS development efforts.

2.110.2.2.5.1 (08-13-2019)
Gather Needs

  1. Task Name and Description: Collaborate with Business Owner.

    ID Role RACI Duties
    NA Development Team R Collaboration with the Business Owner to harvest needs on a scheduled or ad-hoc basis.
    NA Business Owner C Makes themselves available and prepared to provide information on an on-going basis.

  2. Task Name and Description: Collaborate with other Stakeholders.

    ID Role RACI Duties
    NA Business Owner R Identifies other Stakeholders including organizations and systems with whom the development may need to exchange information. Is also involved in the conversation as needed.
    Note: The responsible person can vary depending upon the stakeholder.
    NA Development Team I Participates in the information gathering; particularly ensuring technical needs are discovered.

  3. Task Name and Description: Gather information from relevant and authoritative documented sources (e.g., IRMs, Legislation).

    ID Role RACI Duties
    NA Development Team R Combs through official source documentation and uses requirements analysis techniques to harvest information.
    NA Business Owner A Provides known sources to the development and serves to interpret material.

  4. Task Name and Description: Formulate and/or Decompose needs into appropriate artifacts such as process models, business rules and rule sets.

    ID Role RACI Duties
    NA Requirements Manager R Leads the analysis and execution of decomposition, or direct utilization, leveraging industry and REPO best practices and guidelines.
    NA Development Team C Participates in the decomposition to include technical considerations when pertinent, and for general familiarization of business decomposition model for implementation into the application architecture.
    NA Business Owner I Provides input into the business aspects of the decomposition.

  5. Task Name and Description: Record needs in Requirements Repository.

    ID Role RACI Duties
    NA Requirements Manager R Provides primary input in the repository either directly or via consultation to the Business and/or Development Team on the correct utilization of artifacts, attributes, and traceability. Recording needs also includes the capture of artifact attributes.
    NA Development Team I Can also manage capture of requirements information.
    NA Business Owner A Often tasked and assumes responsibility of their own requirements capture in the repository; again, in alignment with the standards overseen by the Requirements Manager.
2.110.2.2.5.1.1 (08-13-2019)
Cross-Functional Flow Diagram

  1. Refer to Main Process Diagram 2.110.2.2.1.

2.110.2.2.5.2 (08-13-2019)
Validate and Refine Requirements

  1. Task Name and Description: Confirm defined requirements and associated models (inclusive of rules) for satisfaction of business objectives.

    ID Role RACI Duties
    NA Business Owner R, A Responsible for validating that the requirements will satisfy the business objectives.
    NA Development Team A Some technical requirements may be better validated by the development team, but still ultimately are concurred with and owned by the Business Owner.

  2. Task Name and Description: Facilitate walkthrough and understanding of defined models and requirements (inclusive of rules).

  3. ID Role RACI Duties
    NA Development Team R, C Guides the walkthrough of the validation by the Business Owner.

  4. Task Name and Description: Incorporate refinements to requirements as a result of validation activities.

    ID Role RACI Duties
    NA Requirements Manager R Validation may result in refinement and changes that are still well-within scope but help achieve the desired result. The refinements are captured by whoever is performing the Requirements Manager role whether that be a dedicated Requirements Manager, the Business Owner, or a member of the Development Team.
    NA Business Owner C Refinements are concurred by the Business Owner.
    NA Development Team C Development Team participates in refinement and concurrence for consistent understanding across the project.
2.110.2.2.5.2.1 (08-13-2019)
Cross-Functional Flow Diagram

  1. Refer to Main Process Diagram 2.110.2.2.1.

2.110.2.2.5.3 (08-13-2019)
Manage Requirements

  1. Task Name and Description: Track progress.

    ID Role RACI Duties
    NA Requirements Manager R Tracks progress as measured through the accomplishment of requirements. This equates to the measuring tangible results and outcomes. It is not necessarily tied to traditional work breakdown structure style scheduling, and cost tracking. This progress tracking may also be handled by Scrum Masters and can take on many different forms. The tracking also includes process improvement and course corrections that can result from tracked observations, and often folds back into the other activities.
    NA Project Manager A Ultimately accountable for the project progress, and delivery of the product being tracked.
    NA Business Owner I Informed of progress regularly and can react to any needed course corrections.
    NA Development Team I Not only informed of progress, but also contributes directly to the state of developed items to feed progress tracking.

  2. Task Name and Description: Track volatility and/or scope creep.

    ID Role RACI Duties
    NA Requirements Manager R Volatility and scope creep can be identified and measured in a variety of ways depending upon the project’s approach to development and is often folded into the development cycle; as is particularly the case on agile projects. Identification, or recognizing when volatility and scope creep has occurred, is assumed as part of this tracking task. Changes can sometimes exceed the scope tolerance of the project, and therefore need to be tracked and measured so tolerance exceedance can be identified. The tracking also includes process improvement and course corrections that can result from tracking observations, and often fold back into the other activities. These forms of identification and tracking are integral to one another that is the responsibility of whoever is performing the Requirements Manager role.
    NA Business Owner A The business needs to be informed of volatility and scope creep impacts that can jeopardize the project and business objectives.
    NA Project Manager I Informed of progress regularly and can react to any needed course corrections.
    NA Development Team I Not only informed of progress, but also contributes directly to the state of developed items to feed progress tracking.

  3. Task Name and Description: Manage changes to requirements.

    ID Role RACI Duties
    NA Business Owner R The business is responsible for ensuring that objectives are still in the forefront even with changes; and therefore, accountable for imposing changes that can jeopardize the project. As with other activities and tasks, this strongly dovetails and is performed in conjunction with Prioritization, Allocations, and Gathering of Needs.
    NA Requirements Manager A Facilitates estimation and overall impact analysis of changes, and ensures changes and impacts are captured properly in the requirements repository according to REPO guidance.
    NA Development Team C Contributes to the determination of impacts and estimates of any changes.
    NA Project Manager I Informed of impacts and estimates. The Project Manager also takes this information and ensures consistency is applied to other project-related plans.

  4. Task Name and Description: Ensure end-to-end traceability.

    ID Role RACI Duties
    NA Requirements Manager R Responsible for ensuring all participants are tracing artifacts in a minimal fashion to other artifacts. May or may not physically apply trace relationships. Performs audits and checks of trace relationships.
    NA Development Team C May share responsibility of trace relationship capture and integrity.
    NA Business Owner C May share responsibility of trace relationship capture and integrity.
2.110.2.2.5.3.1 (08-13-2019)
Cross-Functional Flow Diagram

  1. Refer to Main Process Diagram 2.110.2.2.1.

2.110.2.2.5.4 (08-13-2019)
Prioritize and Allocate Requirements

  1. Task Name and Description: Prioritize needs.

    ID Role RACI Duties
    NA Business Owner R Prioritizes the captured needs for achieving the business objectives. This directly influences allocation to development cycles and releases.
    NA Development Team C Provides technical dependencies to the Business Owner that do not directly influence business priorities, but does often influence the sequence of development, and subsequently influence the allocation of requirements to development cycles and releases.
    NA Requirements Manager I Helps capture priorities consistently in the requirements repository.

  2. Task Name and Description: Allocate needs to development and releases.

    ID Role RACI Duties
    NA Requirements Manager R Based on priorities, and with consideration of dependencies, requirements are allocated to development cycles and releases. Other allocations such as those to people or organizations are typically handled through artifact attributes and can occur during this allocation activity, when needs are gathered, or even other activities.
    NA Business Owner A Makes the allocation decision and may apply the allocation physically in the repository.
    NA Development Team I Informed of what has been put into the development pipeline.
    NA Project Manager I Informed of what has been put into the development pipeline.
    Note: There is also allocation to such things like parts of the architecture and design; this is handled through traceability.
2.110.2.2.5.4.1 (08-13-2019)
Cross-Functional Flow Diagram

  1. Refer to Main Process Diagram 2.110.2.2.1.