ATTACHMENT D - Business Requirements and Architecture Management Plan_v4_20180901.pdf

Bu Business Requirements and Architecture Management

Plan (BRAMP)

Veterans Health Administration

Office of Health Informatics

Strategic Investment Management

Version 4.0

Business Requirements and

Architecture Management Plan ii September 2018

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

09/01/2018 Version 4 Requirements Development and Management and Business Architecture

Architecture Management Plan iii September 2018

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. Business Requirement and Architecture Phases

3.1. VHA Needs and Prioritization Phase

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. Process Model Development

3.3.2. Business Requirements

3.3.3. Requirements Prioritization

3.3.4. Information Models

3.4. Finalize Business Requirements and Architecture Package (RAP)

3.4.1. Quality Management Process

3.5. Requirements and Architecture Traceability

3.6. VHA and OIT Collaboration

3.6.1. VIP Project Phase

3.6.2. VIP Product Phase

3.6.3. VIP Project Close Out

3.7. RAP Change Management Process

4. Summary

Appendix A. Journey through Business Requirements Architecture

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 iv September 2018

Architecture Management Plan 5 September 2018

1. Overview

1.1. Purpose

The purpose of the Business Requirements and Architecture Management Plan (BRAMP) is to communicate the methodology used in the development and management of business and clinical requirements and architecture that supports senior Veterans Health Administration

(VHA) leadership in the decisions to adopt, buy, or create solutions to address business needs or capabilities. VHA is in the business of providing healthcare therefore all references to business in this document include clinical, business, and operational needs.

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 Health Informatics (OHI). 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 (OIT) 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, identification of business gaps in selected solution, 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) as well as downstream consumers such as contract staff, development teams, and external customers.

Architecture Management Plan 6 September 2018

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.

This document addresses the collaboration between VHA and OIT 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, OIT can 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 OIT 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.

https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/HomePage.aspx

Architecture Management Plan 7 September 2018

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-driven Requirements” and Voice of Customer Analysis

(VoCA). The term, business process-driven 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 state1. 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.

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 OIT for their development and acquisition processes.

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

1 Guide to the Business Analysis Body of Knowledge [BABOK] – Agile Extension

Architecture Management Plan 8 September 2018

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-driven 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 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 OIT 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 OIT EPMO. A package may include the following items:

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

Architecture Plan 9 April 2018

Table 1: Business Requirements and Architecture Package

Deliverable Definition Contents Responsible Tool VIP Phase

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, VIP Planning

Process Model Summary Report

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

Current and desired state process models

Business Process Architecture

(BPA)

Rational System Architect Pre–VIP Initiation, VIP Planning

Requirements Traceability Matrix (RTM)

This document captures and describes the business requirements decomposed business requirements, 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 OIT. This joint (VHA/OIT) 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

• Epics

• Sub-Epics

• User Stories

• Acceptance Criteria

• Business Rules

• Mappings to BFF, Process and Information Models

RDM Requirements Repository Pre –VIP Initiation, VIP Planning

Architecture Management Plan 10 September 2018

Deliverable Definition Contents Responsible Tool VIP Phase optional document, as requirements can be developed and shared in the Rational Tools.

VIP Business Epic and

VIPR

Addendum

*the VIPR Addendum is an OIT requirement.

It is crafted along with the VIP Business Epic but not stored in the

VHA

requirements repository*

These documents describe the business needs and expectations in a brief, concise format that is required by the OIT 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

• Critical Success Factors

• Key Results Indicators

• Business Function Alignment

• In Scope

• Out of Scope

• Non-functional Requirements

• Point of Contact

• References

• Sub-Epics (if applicable)

RDM Requirements Repository Pre-VIP Initiation

Architecture Management Plan 11 September 2018

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)2.

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

The Work Effort Analyst team is comprised of business analysts with expertise in project management, business and clinical requirements, business process and information architecture.

This team supports the requirements gathering sessions conducted during the Work Effort and is responsible for producing the requirements and architecture deliverables.

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 OIT

Requirements Analyst

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

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 12 September 2018

Role Responsibility

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.

Integration and Reference Analyst

Reviews and validates mappings and alignments to the BFF. IR meets regularly with

RDM to review NSR alignments to BFF. The IR team also meets at the conclusion of a work effort with the BPV team to review mappings and alignments for process models.

OIT Technical Architect

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

OIT

Development Representative

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

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.

Architecture Management Plan 13 September 2018

3. Business Requirement and Architecture Phases

Work Effort phases provide a structured process for gathering information for the identification of objectives and business requirements to be documented. Business requirements and architecture artifacts are developed and decomposed to the level of detail sufficient so the business fully understands the needs, processes, and information details and that the artifacts provide the right information to OIT at the right time.

3.1. VHA Needs and Prioritization Phase

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 a request (e.g., 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 to meet VHA clinical and business needs. A preliminary functional mapping to the BFF is determined and the NSR moves into Level 1 (or 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 similar requirements are identified, the Requirements Analyst will work with appropriate stakeholders to consolidate, as needed. NSRs are aligned to the appropriate review board(s) and reviewed prior to/during business case submission on an as needed basis.

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

Once documentation is complete, it is submitted to the Program Office for potential inclusion in the multi-year planning and budget request. Governance and funding decisions are made annually for all requests included in Program Office business case submissions (see Section

3.1.2). In all cases, during Level 1, the high level requirements are populated in the VA requirements repository.

Architecture Management Plan 14 September 2018

3.1.2. VHA Investment Governance

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

Programs, prioritized, and recommended for funding. A business case captures the reason for initiating a project or task. The logic of the business case should justify the allocation of money or effort in support of a specific business need. Business cases are the vehicles by which

Program Offices submit requests for prioritizing and funding for unmet IT development needs that will reference a set of requirements the Program Office determines are a priority.

Subsequent to funding, business cases are 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 1 below.

Figure 1: VHA IT Governance

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

IT Committee (ITC): This entity 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 request, 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 (IB): This entity is charged with ensuring the prioritized IT needs submitted by the four Capability Management Boards (CMB) are consistent and appropriately integrated, 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

Architecture Management Plan 15 September 2018 list of prioritized VHA IT programs aligns with the VHA mission and strategic goals, as well as with OIT budget constraints and applicable federal regulations.

Capability Management Boards: These entities are charged with performing the prioritization of IT needs in alignment with the ITC criteria and policies and with reporting to the ITC on the progress of OI&T in achieving IT needs related to capabilities.

Health IT Strategy Sub-Committee: This entity 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 (VCHI): This entity 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: This entity 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 dependencies.

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

Once funding is allocated, VHA SIM develops/finalizes VIP Business Epics and submits the documentation to the Account Management Office (AMO) to begin the IT process. Once a preliminary funding decision has been confirmed, 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 includes a collection of requirements as identified by the business customer.

This collection of requirements will drive the Work Effort scope, which is supported by the

Work Effort Analyst Team who 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.

The Business Function Framework (BFF) is frequently used to better define the work effort scope. This hierarchical construct enables the alignment of the business needs to the relevant business functions. The alignment helps to understand and narrow the scope of the work effort, as well as to identify potential dependencies and stakeholders.

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

Architecture Management Plan 16 September 2018 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, 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 Business Owner (BO). The BO’s role is to identify relevant stakeholders, clarify the business requirement, and make decisions throughout the effort. They are involved in the work effort through solution deployment.

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 can 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 OIT 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 OIT 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. 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 requirements 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 Level 1. The scan may include research of databases such as the NSRD, Business Architecture repositories, Innovations repository, VistA, and VIP Dashboard 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, OIT 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

Architecture Management Plan 17 September 2018 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.3 If necessary, partnerships with requirements and process architects external to SIM may be formed.

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 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 the business and technical stakeholders together to define the desired business requirements and architecture for

IT solutions. Requirements and architecture are captured by conducting virtual or in-person working sessions and interviews with SMEs 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.

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

Architecture Management Plan 18 September 2018

The Work Effort Team works together to employ a process-driven approach 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 most 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.

The BRAMP process-driven methodology offers important visual cues that inform understanding of the customer’s workflow. Following are benefits of utilizing this methodology:

• Business requirements and information needs will be identified through the progression and development of as-is and to-be processes.

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

• Allows for alignment across requirements and architecture artifacts

• Unknown needs and requirements (gaps) become more apparent.

3.3.1. Process Model Development

A process model visually depicts the activities that need to occur to achieve an objective.

Processes generally reflect a current state process (As-Is) or a proposed future state process (To-

Be). Processes are developed using Business Process Model and Notation (BPMN) 2.0.

Depending on how complex the effort is, the Process Architects may be required to develop high-level and 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

Architecture Management Plan 19 September 2018 understanding business needs, the identification of business requirements, and activity inputs and outputs. Detailed process models are a decomposition of the high-level activities within the high-level diagram. Detailed process models allow traceability to requirements, information models, and the BFF, and assist OIT with the development of services and solutions.

3.3.1.1. As-Is Processes

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 created by incorporating SME input and descriptions of current processes, as well as leveraging existing processes developed by Business

Architecture or external organizations. The Work Effort Analyst Team coordinates with stakeholder to obtain existing documentation and materials. Process architects analyze 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 process architects capture the existing structure, resources, processes, pain points, and bottlenecks. This activity produces As-Is process models and associated Activity Description

Tables.

3.3.1.2. To-Be Processes

Utilizing the As-Is artifacts, the Process Architects elicit and document the desired process through iterative discussions with SMEs. If current capabilities are insufficient to meet the business needs, it is the responsibility of the Process Architects to identify where gaps exist and develop To-Be models, references, and other descriptive information to address the deficiencies.

The goal of the To-Be processes is to incorporate improvement and re-engineering opportunities and to eliminate or reduce the prevalence of the As-Is issues, pain points, and gaps.

3.3.2. Business Requirements

Business Requirements are high-level statements that describe the goals and objectives of the business and the enterprise level. Business Requirements define WHAT the business is trying to achieve and WHY it is needed. Business Requirements address both business and clinical requirements and are articulated by a stakeholder to describe a business or end-user need to be fulfilled by an IT solution. All requirements will be categorized in the following manner.

3.3.2.1. Business Requirement

Business requirements will be written in the user story format and traced to the business activity at the function level, business process and information models.

3.3.2.2. Detailed Business Requirement

Detailed business requirements include a subdivision of business requirements 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

Architecture Management Plan 20 September 2018 iteration. The business determines “what” needs to be done, and OIT will be instrumental in describing “how” it can be done.

o 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 EHRC/PEO. User Stories are written using the following format: As a <insert type of user>, I need <insert statement of need>, so that I can <insert desired benefit>. For example, “As a member of the health care team caring for female Veterans, I need to log in to the application using a unique identifier, so I can view a dashboard of female Veteran patients assigned to my panel, because it includes personal health information that must be accessed securely.”

o 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.2.3. Non-Functional Requirements

A requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are also referred to as qualities of a system. Some examples of non-functional requirements are maintenance, monitoring, transaction speed, response time, training curriculum, help desk support, data protection, metrics, quality, privacy, etc.

3.3.2.4. Business Rules

The purpose of a business rule is: “To define the rules that govern decisions in an organization and that define, constrain, or enable operations.” Business Rules are specific, actionable, testable directives that are under the control of an organization and support a business policy4.

(Reference: Guide to the Business Analyst Body of Knowledge (BABOK)- Version 2.0).

3.3.2.5. Interface and Technical Requirements

All requirements related to interfaces or technical needs will be transitioned to the OIT for management and tracking.

3.3.3. Requirements Prioritization

Functional requirements will be prioritized using the Must Have, Should Have, Could Have, Won’t Have (MoSCoW) method. MoSCoW is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement.

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

Architecture Management Plan 21 September 2018

3.3.4. 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 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:

3.3.4.1. As-Is VistA (Hybrid) Information Models

The BA service leverages a concept known as hybrid models to create the current (As-Is) state models of the VHA VistA system. 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 the data into logically related groups of attributes. This new structure is more consumable to the business SMEs.

3.3.4.2. 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 many 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.3.4.3. Information Artifacts developed during BRAMP:

3.3.4.3.1. Conceptual Information Model (CIM)

An abstracted view of the information model (intended for higher level audiences); It simplifies the information view by concentrating on high-level information concepts, and by removing class details.

3.3.4.3.2. Logical Information Model (LIM)

The Logical Information Model represents the detailed view of information requirements including all classes, attributes, and relationships.

3.3.4.3.3. Normalized Data Object (NDO) Diagram

A Normalized Data Object Diagram describes – Provides a consolidated model of information that is explicitly or implicitly required in the process models and functional requirements.

Architecture Management Plan 22 September 2018

3.3.4.3.4. Data Dictionary

The Data Dictionary is a detailed listing of all classes, attributes and enumerations for an information modeling effort. The Data Dictionary is generated, in the form of a spreadsheet, from the information model utilizing the tooling capability (customized Business Intelligence

Reporting Tool (BIRT) system integrated in the RSA). A typical Data Dictionary spreadsheet contains the following sections: Classes (names and definitions), Attributes (names and definitions and Enumerations (names, values and descriptions) as identified in the model.

3.3.4.3.5. Business Information Model (BIM)

The VHA Business Information Model represents an integrated repository of VHA’s information categorized by information domains. It is a visual representation of the logical categorization of business information and its relationships/dependencies on other data related to the subject area.

It is used to depict “To-Be” business information requirements, and potential gaps between the

“To-Be” and the “As-Is” information environments. BIA releases updated versions of the BIM on a quarterly basis.

3.4. Finalize Business Requirements and Architecture

Package (RAP)

All work efforts must conclude with the business RAP, a principal set of documents comprised of business requirements and process and information models that define the purpose of the work, the objectives sought, and the accomplishments to be achieved. The actual requirements and models in their native format are an integral part of the finished product and are made available as part of the system development process to ensure proper traceability from functional requirements to system requirements and implementation. As IT projects commence, the RAP is a compilation of all the work effort deliverables that may have been approved and shared with

OIT 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 OIT. Reviews are conducted by SMEs, Security, and OIT 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 Integration and Reference (IR) analysts have an ongoing Quality Review Process that reviews the alignment of process models to the Business Function framework and other

Architecture Management Plan 23 September 2018 architecture. After the work effort mappings are reviewed, the new mappings to the Business

Function Framework (BFF) are incorporated into the Business Architecture Repository which is published semi-annually. The IR team also meets regularly with the RDM team to review their business requirements with accompanying mappings to the BFF. This information is also available in the BAR and published quarterly.

3.5. Requirements and Architecture Traceability

The VA utilizes requirements and architecture tooling to automate the traceability of requirements through the project lifecycle. VHA SIM provides a customer facing interface that also allows program offices, business customers, requestors and stakeholders to view the status of their requirements and pull reports at any time. See Appendix D for Tooling information.

3.6. VHA and OIT Collaboration

3.6.1. VIP Project Phase

Once the business requirements and high-level process models are finalized and approved, the IT

Business Analysis Team (BAT) assists the BO in submitting a request through the OIT Account

Management Office (AMO) for review, assessment, and prioritization by the IT Account

Managers (ITAM). Requests approved by the ITAM will be submitted into OIT’s intake portal by the AMO.

VIP project initiation is kicked off when an EPMO IT Project Manager is assigned. Initiation will include the development readiness transition activities where the Work Effort Analyst Team shares information on existing business requirements, existing process and information architecture, and existing business case documents and technical architecture. The collective team will discuss if further elaboration is needed and if VHA is able to resource elaboration with business analysts and architects. OIT will determine what additional information is required to proceed with development and assign resources appropriately to meet those needs. The EPMO

IT Project Manager is directed to the NSRD and VHA business requirements repository in

Rational DOORs and Rational Team Concert (RTC) for existing business requirements and architecture deliverables and supporting documents.

3.6.2. VIP Product Phase

Once a final RAP is delivered and approved, the VIP product phase begins, and EPMO will begin development and release cycles. For more information on OIT processes and deliverables, please reference the VIP SharePoint.

3.6.3. VIP Project Close Out

The project closeout activity involves collaboration and communication between OIT and Work

Effort Analysts to understand the outcomes and results from an OIT release. The team will determine if original requirements and architecture were satisfied and will ensure the integrity of the architecture by reflecting the current production environment. During the project closeout, designated team members from both organizations review appropriate release documents to https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/HomePage.aspx

Architecture Management Plan 24 September 2018 determine if changes are needed to existing architecture artifacts. Any proposed updates to

BRAMP artifacts may be submitted using the Change Management Process (see Section

3.6). The request will follow the appropriate process, and further decisions and updates will be made.

Figure 2: VIP Process integrated with BRAMP

3.7. RAP Change Management Process

The intent of the RAP Change Management process is to define the mechanisms for consistent management of NSR and deliverable changes.