36C77618R0091-005.pdf

February 2017 Version 3.0

Business Requirements and

Architecture Management Plan ii February 2017

Revision History

NOTE: The revision history cycle begins after modifications are requested after the initial Business

Requirements and Architecture Management Plan has been finalized and approved.

Date Description Author

6/25/2014 Version 1 Requirements Development and Management and Business Architecture

3/11/2015 Version 2 Requirements Development and Management and Business Architecture

09/29/2016 Version 3 Requirements Development and Management and Business Architecture

02/24/2017 Version 3.1 Requirements Development and Management and Business Architecture

Architecture Management Plan iii February 2017

Table of Contents

1. Overview

1.1. Purpose

1.2. Intended Audience

1.3. Scope

2. Business Requirements and Architecture Life Cycle

2.1. Business Requirements and Architecture Methodology

2.2. Business Requirements and Architecture Package

2.3. Work Effort Team Responsibilities

3. Work Effort Stages: Assessment, Business Requirements and Architecture Development

3.1. Define and Prioritize VHA Needs

3.1.1. Understanding the Customer’s IT Business Need(s)

3.1.2. VHA Investment Governance

3.2. Work Effort Planning and Scope Coordination

3.2.1. Define Work Effort Scope and Schedule

3.2.2. Identify Stakeholders

3.2.3. Review Existing Documentation

3.2.4. Coordinate the Work Effort Planning

3.2.5. Hold Work Effort Kick-Off Meeting

3.3. Develop Business Requirements and Architecture

3.3.1. As-Is Process Model Development

3.3.2. To-Be Process Model Development

3.3.3. Business Epics and Sub-Epics

3.3.4. Detailed Business Requirements

3.3.5. Business Rules

3.3.6. Information Models

3.4. Finalize Business Requirements and Architecture Package

3.4.1. Quality Management Process

3.5. VHA and OI&T Collaboration

3.5.1. VIP Project Phase

3.5.2. VIP Product Phase

3.5.3. VIP Project Close Out

3.6. RAP Change Management Process

4. Summary Appendix A. Journey through Business Requirements Architecture Appendix B. High Level Process and Data Table Appendix C: Change Management Process Models Appendix D. Requirements and Architecture Tooling Appendix E. Glossary Appendix F. Requirements and Architectural Artifacts Appendix G. Acronyms Appendix H. References Appendix I. Approvals

Architecture Management Plan 4 February 2017

1. Overview

1.1. Purpose

The purpose of the Business Requirements and Architecture Management Plan (BRAMP) is to provide guidance for the development and management of business requirements and architecture to support senior Veterans Health Administration (VHA) leadership in the decisions to adopt, buy, or create solutions to address particular business needs or capabilities. The

BRAMP describes the guidelines and procedures used by the Requirements Development and

Management (RDM) and Business Architecture (BA) services within the Strategic Investment

Management (SIM) division of the Office of Informatics and Information Governance (OIIG).

This Business Requirements and Architecture Management Plan is written in a manner that it can be leveraged by other organizations performing business requirements and architecture support.

These services work in collaboration with the Office of Information and Technology (OI&T) for the collection and management of business requirements and architecture. A well-defined, integrated business requirements and architecture process, as outlined below, ensures effective and efficient development of artifacts that accurately describe the needs of both the business and clinical end-users. This process ensures enterprise level analysis, traceability, and effective communication throughout the requirements and project life cycle to ensure business needs are met by the delivered Information Technology (IT) solution, providing value to the following stakeholders:

Business Owners/Program Offices: The Requirements and Architecture Package

(RAP), a deliverable resulting from this management plan, can assist senior leadership in making informed business decisions by providing insight into the As-Is and To-Be business areas, and presents a business case for weighing the cost-benefit of funded or unfunded needs.

VHA Subject Matter Experts (SME): Efficient processes maximize clinical SME time, eliminating the need for multiple re-engagements to provide the same information.

Current and desired processes and requirements are documented effectively to ensure end users’ needs are clearly articulated.

Office of Information and Technology: Fosters an ongoing technical and clinical partnership to efficiently collaborate and discuss workflow processes and identify problems prior to the Veteran-focused Integration Process (VIP) Initiation and throughout the Software Development Life Cycle (SDLC). This type of collaboration results in consensual decision-making about the appropriate solution to meet functional needs.

1.2. Intended Audience

The intended audience of this document includes VHA business and program offices that require new or enhanced IT system(s) such as Connected Care, Office of Community Care, My

HealtheVet, Veterans Health Information Systems and Technology Architecture (VistA)

Evolution, and select departments within OI&T, for example, Information Technology Account

Management (ITAM), Enterprise Program Management Office (EPMO) Intake and Analysis, Product Development, and Service Delivery and Engineering (SDE).

Architecture Management Plan 5 February 2017

1.3. Scope

The BRAMP applies to work efforts involving analysis and elaboration to define and develop business requirements and architecture needed to implement or enhance health IT systems. This work effort involves collecting and adjudicating business needs, generating and managing business requirement statements, and developing and managing associated architecture products using agile techniques. These projects are staffed by teams called Work Effort Teams (similar to

Work Groups, Tiger Teams, or Integrated Project Teams [IPT]).

This document addresses the collaboration between VHA and OI&T to effectively utilize VHA business customers’ time in capturing the information needed to inform business requirements and architecture, business case documents, and solution architecture. As business requirements and architecture are delivered, OI&T is able to reference BRAMP artifacts and analyze IT capability requests, focusing on enterprise alignment with Department of Veterans Affairs (VA) solution standards and strategic priorities, cost estimation, and planning requirements in preparation for VIP project initiation.

For more information on OI&T processes and deliverables, please reference the VIP SharePoint.

The scope and content of this plan will be reviewed periodically and refined by the collaborative

BRAMP workgroup and VHA SIM.

2. Business Requirements and Architecture Life Cycle

2.1. Business Requirements and Architecture Methodology

BRAMP activities begin once an IT business need has been identified and a New Service

Request (NSR) has been submitted. Business requirements and architecture are collected and documented in three stages, which are noted below and discussed in more detail in Section 3.

1. Define and Prioritize VHA Needs

2. Coordinate Planning and Scope

3. Develop VHA Business Requirements & Architecture

The methodologies and techniques utilized by SIM during requirements and architecture development include “Business Process-framed Requirements” and Voice of Customer Analysis

(VoCA). The term, business process-framed requirements, refers to an approach that actively links processes to textual-based business requirements and information concepts. Voice of

Customer Analysis refers to proactive engagement of the customers and end users throughout the process to understand and validate customer requirements, expectations, areas of dissatisfaction with the current processes, and desired needs for a future state . In addition, an agile methodology is used to guide the Business Owner (BO) to continuously review and refine the business need to ensure approval of the final product, with minimal delays. Flexible and collaborative processes enable development and refinement of business processes, information models, and business requirements, resulting in delivery of an agreed upon business package (see

Section 2.2 for more information on business packages) of high value to the BO.

1 Guide to the Business Analysis Body of Knowledge [BABOK] – Agile Extension https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/HomePage.aspx

Architecture Management Plan 6 February 2017

Processes are developed at the outset to verify and validate the work effort scope and identify target areas for detailed decomposition. Generally, As-Is high-level processes are identified prior to the development of To-Be high-level processes. While the high level processes are being developed with the business customers and SMEs, requirements analysts and information architects are eliciting business requirements in the form of epics, sub-epics, user stories, acceptance criteria and data relationships for validation and approval. When process decomposition begins, the process architects elicit and develop the detailed processes and, as opportunities present themselves, information architects and requirements analysts review related user stories and information models that have been captured. This interplay among process, requirements, and information continues until the entire scope of the work effort has been decomposed to stakeholder satisfaction. The artifacts produced by these elicitation sessions are compiled into a RAP that is leveraged by OI&T for their development and acquisition processes.

The stages performed prior to starting business process-framed requirements activities (Define and Prioritize VHA Needs, Coordinate Planning and Scope, and Develop VHA Business

Requirements & Architecture) are crucial preparation stages for each work effort. Through extensive best practice and lessons learned capture, SIM has identified that these preparation stages are key to ensuring productive stakeholder sessions.

Another key component of our business process-framed requirements methodology is termed

“Maintaining a Line of Sight”. This is a critical set of activities performed throughout a work effort to ensure that processes, information, and requirements are not only integrated with each other, but that they are also integrated with the VHA Business Function Framework (BFF). The

BFF describes the operational functions of VHA, and as such, can be aligned to many functional inventories such as VA and VHA Strategic Priorities, and the VA System Inventory (VASI), among others. The value of maintaining a line of sight is that the Work Effort Analyst Team may discover that the work effort inherits unstated relationships that help provide greater context and impetus for IT prioritization and decision making. SIM is responsible for the development and maintenance of the BFF, and tracks the alignment of model-led requirement artifacts in the

Business Architecture Repository (BAR). The latest BAR release can be found at https://vaww.vha.esp.va.gov/sites/BA/default.aspx.

2.2. Business Requirements and Architecture Package

The Requirements and Architecture deliverables related to the delivery of VHA systems and capabilities are organized together in the RAP. A RAP fully defines the work effort from a business and/or functional viewpoint. A RAP is developed with work effort participants to include SMEs, and is approved by the VHA Business Owner. Once approved, a RAP is shared with OI&T to both inform project initiation and planning, as well as design and development.

Documentation contained in the RAP is maintained in the IBM Rational Suite by SIM. For more information on tooling, see Appendix D.

The RAPs are a compilation of the documents developed during the business requirements and architecture process. These documents are authored by the business community with participation from OI&T EPMO. A package may include the following items:

https://vaww.vha.esp.va.gov/sites/BA/default.aspx

Architecture Plan 7 February 2017

Table 1: Business Requirements and Architecture Package

Deliverable Definition Contents Responsible Tool VIP Phase

VIP Business Epic

This document describes the business needs and expectations in a brief, concise format that is required by the OI&T VIP Account Management Office (AMO).The VIP Business Epic is the vehicle by which the business opportunity is presented to IT Account Manager and Portfolio Director for prioritization.

An epic describes a large initiative that:

Describes the business opportunity and the VA strategic goals

Identifies if the project is mandated or legislatively required

Summarizes the problem or opportunity

Captures the criticality of the need

Epic Summary

Epic Value Statement

Alignment to VA/VHA Strategic Plans

Success Criteria

In Scope

Out of Scope

Non-functional Requiremen ts

Point of Contact

References

Sub-Epics (if applicable)

RDM Rational

DOORS

(formerly Composer)

Pre-VIP Initiation

Business Summary Report

This document captures and describes the business needs and expectations. It provides insight into the As-Is and To-Be business areas, identifying stakeholders and profiling primary and secondary-user communities. It details the capabilities that the stakeholders and target users need, and why these needs exist. It provides a foundation for the communication of functionality required in the solution to satisfy

Target Customers

Business Need

Key Benefits

Current Process

RDM Rational

DOORS

(formerly Composer)

Pre-VIP Initiation, VIP Planning

Architecture Management Plan 8 February 2017

Deliverable Definition Contents Responsible Tool VIP Phase the business needs. The Business Summary Report is the vehicle by which the business community gathers the supporting information needed to develop business epics.

Deficiencies

Program Benefits

Alignment to Strategic Goals

Success Criteria

In-Scope and Out of Scope Features

Non- Functional Requiremen ts

Requirements Traceability Matrix (RTM)

This document captures and describes the business needs (epics), business requirements (sub-epics), decomposed business requirements (user stories), acceptance criteria, and their relationships to each other. In addition, the RTM captures mappings of business requirements to business process models and the VHA BFF. The RTM is supported by a collaboration requirements model that is used by the business and OI&T.

This joint (VHA/OI&T) RTM will be used to track requirements through User Acceptance Testing (UAT). The RTM will also inform and be leveraged to ensure proper solution deliveries.

The RTM is an optional document, as requirements can be developed and shared in the Rational Tools.

Epics

Sub-Epics

User Stories

Acceptance Criteria

Mappings to

BFF,

Process and Information Models

RDM Rational

DOORS

(formerly Composer)

Pre –VIP Initiation, VIP Planning

Process Model Summary

A summary report describing the development of the As-Is and To-Be Business Process Models and their supporting Activity Description

Current and desired state

Business Process Architecture

Rational System

Pre –VIP Initiation, Architecture Management Plan 9 February 2017

Deliverable Definition Contents Responsible Tool VIP Phase

Report Tables for an effort. process models (BPA) Architect

Information Model Summary Report

Contains the informational perspective of the model-based representation of “To Be” business requirements and processes that may be created / transmitted / received / maintained.

Analysis of reusable units of information exchange.

Identification of potential information gaps against “As-Is” information sources.

Information models and data dictionary

Business Information Architecture

(BIA)

Rational System Architect

Pre –VIP Initiation, Architecture Management Plan 10 February 2017

2.3. Work Effort Team Responsibilities

Work Effort team members are critical in the development of the business requirements, business processes, and information models. It is imperative that assigned roles are identified as early as possible and that each work effort is led by an experienced facilitator. For further details on the roles and responsibilities refer to the BRAMP Responsible, Accountable, Supported, Consulted, and Informed chart (RASCI)

In order for the work effort to proceed efficiently, the following membership for Work Effort

Teams has been identified:

Work Effort Business Owner

Work Effort Analysts

Work Effort SMEs

Table 2, Table 3, and Table 4 below list high-level descriptions of the work effort roles.

Table 2: Work Effort Executive Component

Role Responsibility

Work Effort

BO

The Program Office representative (typically at a directorate level) who is responsible for the policy, processes, and practices of a given area. The BO has final sign-off approval of the requirements and architectural deliverables, provides strategic direction to the program, elicits executive support and funding, and monitors the progress and timelines throughout the life cycle of the request.

Table 3: Work Effort Analysts

Role Responsibility

Work Effort Coordinator

Coordinates and provides overall work effort support throughout the work effort life cycle

Coordinates communications with BOs, SMEs, and Work Effort Analyst Team to include meeting and agenda planning, planning and facilitating virtual and face-to-face meetings, and managing timeline and parking lot issues

Provides support to the Business Owners and stakeholders; serves as an interface to OI&T

Requirements Analyst

Elicits, develops, and manages business and non-functional requirements for the identified capability.

Business Process Architect

Elicits, designs, and optimizes business process models based on data and SME input.

Business Information Architect

Develops conceptual and business information models based on direct SME input, business requirements, process models, expected logical interfaces, and appropriate information exchange standards.

OI&T

Technical Architect

Provides technical and feasibility input during development of requirements and architecture. Gathers information to inform the technical architecture.

OI&T

Development

The OI&T Analyst will engage with the work effort team during elaboration. The OI&T Portfolio Lead will assign roles based on project focus and available resources.

2 https://vaww.vaco.portal.va.gov/sites/OHIA/sim/BRAMP/default.aspx https://vaww.vaco.portal.va.gov/sites/OHIA/sim/BRAMP/default.aspx

Architecture Management Plan 11 February 2017

Role Responsibility

Representative The development representative ensures proper requirements elaboration is being completed to the degree as needed for the IT project.

Table 4: Work Effort SME

Role Responsibility

Lead SME Provides deep capability expertise and leadership to ensure the functional community’s needs are met.

SMEs A stakeholder with specific expertise/knowledge in a particular area, an aspect of the problem domain, or potential solution alternatives; an individual who exhibits the highest level of expertise in performing a specialized job, task, or skill within the organization.

The SME closely assists with developing business requirements and architecture artifacts and continues that work during the development and testing stages.

3. Work Effort Stages: Assessment, Business Requirements and Architecture Development

Work Effort stages provide a structured process for gathering information for the identification of objectives and business needs to be documented. As shown in Figure 1 below, the business requirements and architecture artifacts are developed and decomposed to the level of detail sufficient so the business fully understands the needs, process, and information details and that the artifacts provide the right information to OI&T at the right time.

Figure 1: Work Effort Stages

Architecture Management Plan 12 February 2017

3.1. Define and Prioritize VHA Needs

This stage of the business requirements and architecture methodology includes identifying and understanding the customer’s business needs and facilitating the needs through VHA

Governance.

3.1.1. Understanding the Customer’s IT Business Need(s)

Business needs are documented descriptions of clinical, business, and administrative needs that support day-to-day operations and work activities of VHA. Business needs originate from mandates and initiatives that are external and internal to VHA including federal laws, regulations, directives, goals, strategic processes, or stakeholders such as clinicians, administrative staff, business office staff, and developers.

Once a business need is identified, the VHA business customer submits an NSR through the

Innovations and Development Request Portal (IDRP). NSRs are submitted to enhance existing health IT solutions or to develop/acquire new solutions based on changes to business processes, policies, legislative changes, and other drivers in order to meet VHA clinical and business needs.

Upon receipt of the NSR, the RDM Service reaches out to Veterans Integrated Service Network

(VISN)-level leadership or higher to confirm endorsement of the request. Endorsement signifies that the request has merit and the business need is worthy of further analysis. Confirmation of the appropriate level of support must be validated prior to accepting the NSR into the New

Service Request Database (NSRD). If the endorsement is not verified, the request is rejected in the IDRP. The list of authorized endorsers can be found here:

http://vista.med.va.gov/nsrd/GuidancePolicy.asp.

Upon verification of endorsement, the NSR moves into the Assessment Phase. The

Requirements Analyst conducts an environmental scan for similar work (NSRs, requirements, etc.), and works with the requestor to obtain and document additional information about the problem and business need/driver. If the NSR is urgent and requires immediate review, the NSR is referred to the appropriate review board(s) (Clinical Capability Management Board [CCMB], Business Capability Management Board [BCMB], Data Resources and Analytics Capability

Management Board [DRACMB], and Research and Education Capability Management Board

[RECMB]). If the NSR is not urgent, it is submitted to the Program Office for potential inclusion in the multi-year planning and budget request. In all cases, during the Assessment

Phase, the initial draft of the Business Summary Report is initiated and stored in the New Service

Request Database (NSRD).

3.1.2. VHA Investment Governance

VHA has implemented a framework by which IT business cases are collected from VHA

Programs (e.g., Pharmacy, Enrollment, Registries, Research), prioritized, recommended for funding and, subsequent to funding, tracked to ensure IT solutions are developed in a timely manner. This governing structure includes several workgroups, sub-committees, boards, and an authoritative decision making committee as outlined in Figure 2 below.

http://vista.med.va.gov/nsrd/GuidancePolicy.asp

Architecture Management Plan 13 February 2017

Figure 2: VHA IT Governance

The entities depicted in Figure 2 (and described below) reflect the organizations involved.

IT Committee: The IT Committee (ITC) is commissioned by the National Leadership Council

(NLC) and is charged with oversight of the VHA IT Governance Process. The ITC will first determine the strategy and mission of the committee, followed by outlining proper VHA use of technology, aligning IT investments to VHA mission requirements through the Policy, Planning, Budget & Execution (PPBE) process, making IT investment decisions, monitoring execution of

IT efforts, and assessing effectiveness and benefits of deployments. This charge is primarily accomplished through defining policies and enforcing compliance with those policies.

Integration Board: The Integration Board (IB) is charged with ensuring the prioritized IT needs submitted by the four Capability Management Boards (CMB) are consistent and appropriately integrated as a whole, performing minor adjustments to the priorities to achieve the overall budget target. The IB supports the ITC by analyzing and de-conflicting proposed IT needs, ensuring that the resulting list of prioritized VHA IT programs aligns with the VHA mission and strategic goals, as well as with OI&T budget constraints and applicable federal regulations.

Capability Management Boards: The CMBs are chartered by the ITC and charged with performing the prioritization of the VHA IT needs in alignment with the ITC criteria and policies and with reporting to the ITC on the progress of OI&T in developing IT solutions to meet

VHA’s needs. CMBs are comprised of key VHA leaders and field clinicians to prioritize and determine the scope of programs, using business criteria, for IT investment funding. The CMBs

Architecture Management Plan 14 February 2017 also provide a business council to review funded IT programs and make sure they are meeting their requirements, executing properly, and doing so within the approved schedule.

Health IT Strategy Sub-committee: The Health IT Strategy Sub-Committee is charged with defining the full strategic direction and mission of VHA IT for endorsement or veto by the ITC.

VISN Chief Health Informatics Sub-Committee: The VISN Chief Health Informatics (VCHI)

Sub-Committee is charged with assisting in determining proper use of technology and information and supporting the assessment of technology effectiveness and benefits of deployments for endorsement or veto by the ITC.

Architecture and Requirements Investment Working Group: The ARIWG is charged with both an ITC secretariat function and with performing analysis of IT needs. The ARIWG supports the CMBs by ensuring IT needs are de-conflicted for scope and analyzed for benefit

(alignment/impact) and risk (complexity/maturity).

Following VHA Governance prioritization and funding determinations, the SIM team works with each program office to review the Business Case Document and prioritize their needs and work.

As soon as funding is allocated, VHA SIM submits the VIP Business Epics for funded business needs to the Account Management Office to begin the IT process. Once an IT Project Manager is assigned to the business need, a work effort will be stood up to ensure the prioritized needs are further defined with business architecture and requirements.

3.2. Work Effort Planning and Scope Coordination

This stage of the business requirements and architecture methodology includes preparing for the business requirements and architecture work effort, defining work effort scope and schedule, identifying stakeholders, reviewing existing documentation, coordinating the work effort planning, and conducting the work effort kick-off meetings.

3.2.1. Define Work Effort Scope and Schedule

The Work Effort Analyst Team works with the business customer(s) to define the work effort scope and schedule. This may include the development of a formal scope statement, a proposal and/or overview of the work effort, description of resources, assumptions, constraints, dependencies and risks, deliverables, expected outcomes, and a tentative project schedule.

3.2.2. Identify Stakeholders

There are various stakeholders who proactively engage as partners during each work effort. The goal of this activity is to identify all individuals, program offices, and groups that have a vested interest in the requested functionality, and invite them to participate in the effort. Stakeholders provide contextual information about the business relative to the request, validate customer requirements, voice expectations, communicate areas of dissatisfaction with the current processes, and convey desired needs for a future state, in order for Analysts to develop deliverables and the RAP. Active stakeholder involvement ensures that the IT solution meets the business and end user needs.

One of the most important stakeholders is the VHA BO. The BO’s role is to identify relevant stakeholders, clarify the business need, and make decisions throughout the effort. They are involved in the work effort through solution deployment.

Architecture Management Plan 15 February 2017

The BO helps the Work Effort Analyst Team to identify a comprehensive list of stakeholders and

SMEs, to include identification of a Lead SME. The Lead SME also has decision making and approval authority in the absence of the BO, and is able to determine if there are any gaps in functional SME representation. During this process, dependencies such as availability and surrogate participation are also taken into consideration when confirming stakeholders.

In addition to the business (and where appropriate clinical SME representation), technical staff from OI&T is invited to be involved in the preparatory phase of the work effort, and continue their involvement throughout the process to ensure developed requirements are feasible and testable in the development/acquisition process. Early involvement from OI&T also supports the agile methodology for delivering capabilities in incremental packages.

Once the complete list has been confirmed, stakeholders and SMEs are engaged with the Work

Effort Analyst Team to form the Work Effort Team. Recurring meetings (working sessions) are scheduled and during these meetings, the Business Requirements and Architecture process and deliverable templates are reviewed with the Work Effort Team.

The Work Effort Analyst Team works with the Work Effort Team to elicit business needs and associated requirements, along with real-life examples or scenarios that depict how the IT enhancement would bring value to the identified processes. There is great value and knowledge management in ensuring the SMEs that participate in the business requirements and architecture work efforts continue to participate during the IT Project life cycle.

3.2.3. Review Existing Documentation

The Work Effort Analyst Team collaborates with BOs, stakeholders, SMEs and their internal teams to conduct a comprehensive environmental scan that builds upon the environmental scan conducted during the Assessment Phase. The scan may include research of databases such as the

NSRD, Business Architecture repositories, Innovations repository, VistA, and the Technical

Services Project Repository (TSPR) to gather policies, related and existing requirements, existing applicable models, and other information relevant to the work effort.

3.2.4. Coordinate the Work Effort Planning

Coordination between Work Effort Analyst Team members (e.g., SIM, OI&T representatives) is extremely important to ensure that the appropriate individuals are engaged and aware of work effort activities and information. Analyst team planning sessions will be conducted for the Work

Effort Analyst Team to ensure all team members understand the process, methodology, deliverables, roles, and responsibilities. During the planning sessions, guidelines are communicated that include a description of the roles and responsibilities of team members, the approach for developing and delivering the requirements and models, plans for a kick-off meeting, and the process and mechanism that will be used to share and store work product artifacts.

There may be times when we may partner with requirements and process architects external to SIM (i.e., Veterans Engineering Resource Center [VERC], Community Care Business

Systems Management [BSM]).

In order to support efficient requirements and architecture definition, appropriate SME resources are engaged in the work effort based on expertise and the increment that is currently under

3 See Work Effort Analyst Team Guidance for more detailed information.

Architecture Management Plan 16 February 2017 development. During the work effort planning period, a stakeholder matrix is developed to facilitate the efficient and effective use of SME resources.

The following documents are also shared and reviewed with the team at the beginning of the work effort:

a. Current version of the BRAMP

b. Requirements and Architecture Business Life Cycle

c. Draft Business Requirements and Architecture Work Effort Proposal, consisting of:

1. Validated Scope Statement

2. Work Breakdown Structure (WBS)

3. Team Roster

d. RASCI Matrix

e. Review Board (CCMB, BCMB, etc.) outputs

f. Existing relevant documentation (e.g., models, requirements, and policies)

These documents form the foundation for the initial preparation steps and are provided not only as reference materials, but as a starting point for each work effort. During the initial coordination meeting, the team will review the Requirements and Architecture business life cycle process and the RASCI Matrix to understand the roles, activities, and expectations of everyone on the team.

3.2.5. Hold Work Effort Kick-Off Meeting

A Work Effort kick-off meeting will be held with the entire Work Effort Team, which consists of stakeholders, business owners, SMEs, and any supporting staff. This meeting provides the opportunity to discuss the scope and objectives of the work effort, the role of each team member, and the iterative schedule.

3.3. Develop Business Requirements and Architecture

The development of Business Requirements and Architecture stage brings all of the business and technical stakeholders together to define the desired business needs/requirements and architecture for IT solutions. Requirements and architecture are captured by conducting virtual or in-person working sessions and interviews to interact with SMEs in order to understand and elicit business workflow/process details and requirements. Site visits may also be scheduled to observe end users and gain a better understanding of their normal working environment and the context around their need for an improved IT solution.

The Work Effort Team works together to facilitate the elicitation and documentation of information needs and high level and detailed business requirements based on discussions with

SMEs. Business process models provide analysts and SMEs with a logical and visual progression through the process. As the process is being documented visually, the Requirements

Analyst and Information Architect ask questions to capture the majority of the high-level and detailed text based requirements. Using this integrated approach reduces the number of SME sessions that would otherwise focus solely on requirements or solely on information architecture.

Process modeling offers important visual cues that inform understanding of the customer’s workflow. Following are benefits of utilizing this methodology:

Architecture Management Plan 17 February 2017

Through the progression from the As-Is Process and To-Be process, additional business requirements and information needs will be identified.

Process models will allow the Work Effort Team to visually identify pain points, bottle necks, and areas for improvement.

Work Effort Team and SMEs will be able to identify dependencies with other processes and out of scope requirements.

Allows for a requirements alignment to process models to ensure requirements are captured for every activity within the process.

Unknown needs and requirements (gaps) become more apparent.

3.3.1. As-Is Process Model Development

The As-Is process is a prerequisite to understanding how processes are executed in the current work flow or system. As-Is process models are developed by leveraging existing processes developed by Business Architecture or external organizations, as well as SME input and descriptions of current processes. The team analyzes the current state of the business need, including current architecture descriptions, performance, and business goals and objectives.

While the details of the current environment are being analyzed, the team captures the existing structure, resources, processes, pain points, bottlenecks, and improvement opportunities. This activity produces As-Is process models and associated Activity Description Tables.

3.3.2. To-Be Process Model Development

Utilizing the As-Is artifacts, the Work Effort Analyst Team elicits and documents the desired process through discussions with SMEs. If current capabilities are insufficient to meet the business needs, it is the responsibility of the team to identify where gaps exist and develop To-

Be models, references, and other descriptive information to address the deficiencies. Feedback and input from the SMEs are captured in the To-Be processes. The streamlined or improved processes are free of any constraints and activities that do not add value. The To-Be process models are an in-depth depiction of “what good looks like” from the business owner’s or SME’s perspective. These redesigns and enhancements are illustrated in the To-Be business process models. Depending on where the effort is in the SDLC, the Work Effort Analyst Team may be required to develop either high-level or detailed process models. The high-level process models provide an overarching view of the business processes being analyzed. These models are developed to assist in understanding business needs, the identification of business requirements, and activity inputs and outputs. Detailed process models allow traceability to normalized data objects in the information models and assist OI&T EPMO Intake with development of service architecture.

Architecture Management Plan 18 February 2017

Figure 3: Business Epic Decomposition

3.3.3. Business Epics and Sub-Epics

Epics are business needs articulated by a stakeholder that describe a business or end-user need to be fulfilled by an IT solution. An epic captures a large body of work to be completed during development and is typically too large to complete within a Sprint. It is further decomposed into smaller sub-epics and workable user stories. Epics will be traced to the BFF and the business process models. There are two types of business artifacts: (1) Portfolio Epics which include

Business Epics, Sub-Epics, and (2) User Stories. Business Epics and Sub-Epics directly deliver business value with strategic objectives and need to be described in general terms to initiate a further discussion about what types of features an epic implies.

The following table depicts the overarching differences between the types of artifacts.

Table 5: Portfolio Epics vs. User Story

Portfolio Epic (Includes Business Epic and Sub-Epic)

User Story

Generated by Business Requirements and Architecture Groups

VHA Business Requirements and Architecture team, or Program/Project Teams

Description Containers for large initiatives “Big user story”

Duration 6 months – 1 year 2 – 4 sprints

Format For <target customers>.

Who <statement of the need or opportunity>.

A process <is needed/for/to include links to process models, if applicable>.

That <statement of key benefit, that is, compelling>.

Unlike <primary alternative>.

Our process <does something better – the “why” – tie this to USH 5 Priorities/Enterprise Justification>.

As a...

I want...

So that...

Measurement Success Criteria Acceptance Criteria

Backlog Portfolio Team

Architecture Management Plan 19 February 2017

Portfolio Epic (Includes Business Epic and Sub-Epic)

User Story

Estimation Duration (Job Size) Story Points

Prioritization WSJF (Weighted Shortest Job First) Business Value

Decomposition Feature Feature/Theme User Story

Business Epics and Sub-Epics will be written in the following format:

Table 6: VHA Business Epic Format

<<Epic Name>>

Epic Summary <Include a summary that addresses:

NSR # (if applicable) and name of project or request.

Who is making or supporting the request (e.g., business owner and program office or department)?

What is being requested?

o What must be delivered or accomplished to provide value (this is not “how” it must be delivered)?

o Include a summary/history of the current situation/problem as well as a summary of the history/background of the system.

Why is this project necessary or desired (describe any research or analysis that has been or is planned to be conducted)?

When is this project needed (i.e., provide information about mandates and/or external deadlines if applicable)?

Where will the change occur (i.e., identify software applications/programs)>

This epic includes the following Sub-Epics:

1. <Sub-Epic Name>

Include a numbered list of the Sub-Epics associated with this epic. Hyperlink the Sub-Epic names to the Sub-Epic tables below by inserting a Bookmark on the Sub-Epic title and then creating an internal hyperlink.

Epic Value Statement

(Repository

ID)

NOTE: OI&T has provided the leading terms below (i.e., For, Who, A, That, Unlike, and Our Process). Epic Value Statements should conform to these guidelines whenever possible, with the understanding that there will be instances where the leading terms must be altered slightly to best convey meaning.

For <target users: identify the primary users (and secondary users, if applicable) of the product or end solution>.

Who <user role: Describe the common function of the target users’ role as it relates to the request.>

A <process: identify the business problem/issue/need. Do not include a technical approach describing how the process or solution should be implemented. Note: If you have a process model or more detailed process descriptions/scenarios, append them to the VIP Business Epic document>

That <statement of key benefit: identify the benefit the customer will receive from having the need or solution fulfilled.

Unlike <current process deficiencies: describe the current process and the pain points encountered, including workarounds, that are used or could be used to address the problem.>

Architecture Management Plan 20 February 2017

<<Epic Name>>

Our process <does something better, the “why”: Describe how fulfillment of this request would improve the current process at the program level.>

Alignment to

VA/VHA

Strategic Plans

<List strategic, tactical, and operational goals that will be met by implementing this Business Epic. Insert in the following order:

1. VA Breakthrough Initiatives (12)

2. USH Priorities: (1) Open ACCESS to Care; (2) Improve Employee ENGAGEMENT; (3) Consistency in BEST PRACTICES/Quality; (4) High- Performing Network; (5) Restore TRUST and CONFIDENCE (see VHA Vitals for clarification on the 5 priorities)

3. Blue Print for Excellence (10 strategies)

4. Performance measures

5. Directives, etc.

Strategic Goals include: (1) Provide Veterans personalized, proactive, patient-driven healthcare; (2) Achieve measurable improvements in health outcomes; (3) Align resources to deliver sustained value to Veterans.>

Success Criteria

<Identify acceptance parameters that would validate the implementation was complete and successful. Describe how the success of the Epic will be measured in SMART terms:

Specific: targets a specific area

Measurable: quantify or suggest an indicator of progress

Achievable: assure that an end can be achieved

Relevant: appropriate to the process or product

Timely: able to complete within a period of time>

In Scope <Describe the functionality/requirements needed to complete the request and create value. Document specific details about the desired changes or new functionality being requested and the requirements needed to fulfill the request.

The in scope items will become sub-epics>

Out of Scope <Identify capabilities that are not needed/required for this effort. Identify functionality that may be “nice to have”, but is not necessary.>

Non-functional Requirements

Applicable Office of Information and Technology Compliance Epics should be incorporated to meet the needs of the project.

<The above is template text and should not be edited.

Repository ID: NONF requirement

Add Security Review Rating for the epic. These can be found at https://vaww.vha.esp.va.gov/sites/RDM/internal%202/RDMGoalsFY15/Shared %20Documents/Security%20Review%20Rating%20for%20Epics.docx

Describe the characteristics or quality attributes of the system (e.g., related to availability, capacity, efficiency, interoperability, performance, security, testability, maintainability, monitorability, portability, reliability, and usability.

Applicable OI&T Compliance Epics should be incorporated to meet the needs of the project.>

Point of Contact

<Insert name & contact information for key point of contact>

References

<Insert links here, include link to NSR> https://vaww.vha.esp.va.gov/sites/RDM/RDM%20Templates/RE%20Templates/VA%20Breakthrough%20Priorities.pdf https://vaww.vha.esp.va.gov/sites/RDM/RDM%20Templates/RA%20Templates/16.11.30%20VHA%20Vitals%20Top%2015%2010.pdf https://vaww.vha.esp.va.gov/sites/RDM/RDM%20Templates/RA%20Templates/16.11.30%20VHA%20Vitals%20Top%2015%2010.pdf http://www.va.gov/health/docs/VHA_Blueprint_for_Excellence.pdf https://vaww.vha.esp.va.gov/sites/RDM/internal%202/RDMGoalsFY15/Shared%20Documents/Security%20Review%20Rating%20for%20Epics.docx https://vaww.vha.esp.va.gov/sites/RDM/internal%202/RDMGoalsFY15/Shared%20Documents/Security%20Review%20Rating%20for%20Epics.docx

Architecture Management Plan 21 February 2017

3.3.4. Detailed Business Requirements

Detailed business requirements include a decomposition of business requirements (epics and sub-epics) and business rules which result in user stories and acceptance criteria. These requirements are taken to a sufficient level of detail (description of the required behavior of the system which must be clear and readable) to create a set of working business requirements that are defined, prioritized, and testable for all functional capabilities that will be delivered as part of the current release or iteration. The business determines “what” needs to be done, and IT will be instrumental in describing “how” it can be done.

3.3.4.1. User Stories

User stories are brief, simple, and concise statements that describe requirements from a user perspective to capture and communicate customer requirements. User Stories will be developed in collaboration with OI&T. User Stories are written using the following format: As a <insert type of user>, I would like <insert statement of need>, so that I can <insert desired benefit>. For example, “As a member of the health care team caring for women Veterans (‘users’), I need to log in to the application using a unique identifier, so I can view a dashboard of women Veteran patients assigned to my panel, because it includes personal health information that must be accessed securely.”

3.3.4.1.1. Tasks/Acceptance Criteria

Acceptance Criteria define the boundaries of a user story and are used to confirm the completeness and intention of the user story. For example, “A user can log into the application using their VistA credentials.”

3.3.5. Business Rules

Business Rules are a specific, actionable, testable directive that is under the control of an organization and that supports a business policy

3.3.6. Information Models

Business Information elicitation and development is used to understand and document business information usage, structure, and information exchange requirements that are necessary to create well-designed IT solutions. Information modeling produces a visual depiction of the information requirements for a particular project/subject area where data are well defined and relationships to other information concepts are reflected. This may include the information necessary to achieve interoperability with outside agencies and organizations.

The following describes the As-Is and To-Be Information Models:

As-Is VistA (Hybrid) Information Models: The BA unit leverages a concept known as hybrid models to create the current (As-Is) state models of the VHA systems. Hybrid models reflect the business-related data elements captured and managed by the VistA system. System-related data elements are filtered from view in the hybrid model, such as attributes used to log transaction update dates and times. If the VistA data structure does not group related data elements into well-formed classes, the hybrid model restructures

4 Guide to the Business Analysis Body of Knowledge [BABOK] - Version 2.0

Architecture Management Plan 22 February 2017 the data into logically related groups of attributes. This new structure is more consumable to the business SMEs.

To-Be (Future State) Business Information Models: BIA work products clearly communicate business information requirements as part of the enterprise-wide integrated

Requirements and VHA Business Architecture. Although a number of different information artifacts will be developed as part of the business information modeling process, the primary goal is to develop a suite of Unified Modeling Language (UML) 2.0 based-class diagrams that define the work effort’s information requirements.

3.4. Finalize Business Requirements and Architecture

Package

All work efforts must conclude with the business RAP. The purpose of the RAP is to provide the requirements and architectural artifacts and a summary that describes the process that led to their development. The RAP should include the work effort purpose, the objectives sought, and the accomplishments achieved. For the elaboration phase, the RAP is a compilation of all of the work effort phases that may have been approved and shared with OI&T throughout the work effort. The Work Effort Analyst Team facilitates a comprehensive review process with external stakeholders to ensure all necessary components have been addressed (i.e., Security, Privacy) and the deliverables contain the information needed to be consumable by OI&T. Reviews are conducted by SMEs, Security, and OI&T EPMO.

3.4.1. Quality Management Process

SIM has a comprehensive quality management process to ensure that all requirements and architectural artifacts are consistent, adhere to industry and VHA SIM standards, and meet the overall objective of the work effort. For a complete and unbiased review, all components of the

RAP undergo a content/quality review by technical writer, analyst peers, SIM management, and work-effort stakeholders. During this review, the VHA BFF links are confirmed as appropriate and maintained throughout the life cycle and evolution of the architecture. The final RAP will be reviewed and approved by the BO(s). All final approved deliverables are stored in the business requirements repository and business architecture repository and are available to customers via the NSRD and the Rational Tools repositories.

The RAP constitutes a consolidated…