2010 UBO/UBU Conference

Title: Information Management’s (IM’s) Requirements Management and Delivery Framework: Developing the Blueprints for IT Systems

Session: W-4-1100

2

Objectives

Provide a high-level overview of Requirements Management

Present IM’s Requirements Delivery Framework Present Benefits of Requirements Management and

Delivery Framework Provide overview of the Requirements lifecycle Discuss the roles and responsibilities associated with

IM’s Requirements Delivery Framework Illustrate how IM aligns with MHS’s strategy

3

What Is Requirements Management?

“Requirements Management are the activities that control requirements development including change control, requirements attributes definition, and requirements traceability.” Business Analysis Body of Knowledge (BABOK)

4

Why Is Requirements Management Important?

Requirements Management allows you to solve the right problem and build the right Information Technology (IT) solution via the following activities:– Eliciting, organizing, and documenting required

functionality and constraints – Tracking and documenting trade-offs and decisions– Easily capturing and communicating business

requirements

5

Requirements Management Benefits

IM follows a streamlined and repeatable requirements process which:– Complies with MHS IM/IT mandate – Improves product quality– Controls development and sustainment costs– Improves cycle time

Requirements Benefits to the IT Process Lifecycle

IM directly supports the top three highest value, highest complexity IT

lifecycle functions

}

6

IM’s Requirements Delivery Framework

7

8

Requirements Delivery Framework Benefits

The Requirements Delivery Framework provides a standardized, documented methodology that is tailored, transparent, and template-driven and addresses the following challenges:– Outdated requirements– Inconsistent documentation – Lack of stakeholder involvement, feedback, and

approval– Requirements that do not meet all of the quality

criteria

IM’s Requirements Delivery Quality Criteria

9

Criteria Definition

Identified Each requirement is uniquely identified via an alphanumeric expression

Clear All readers of a requirement should arrive at the same interpretation of its meaning.

Concise Each requirement must contain only words necessary to clearly communicate what is needed.

Complete All known requirements are documented and all conditions under which a requirement applies are stated.

Consistent The requirements can be met without causing conflict with any of the other requirements.

Correct Each requirement must accurately describe the functionality to be built. Only the source (customer, user, stakeholder) of the requirement can determine its correctness.

Testable The requirement must be written so that testers can demonstrate that the system satisfies the requirement.

Feasible Meeting the requirement should be achievable.

Singular Each requirement expresses a single, unique idea.

Solution-free Each requirement expresses the what and why of the need; not how to do it.

IM’s Requirements Lifecycle

10

Pre-Investment

Pre-Execution

Re-Costing

Acquisition

Pre Investment Business Requirements Specification (BRS)

Pre Execution BRS

ASR PIRTRRCDRPDRSRRITR

Costing

Strategic Planning

Submissions Management Requirements Delivery

Business Architecture / Management of Data and Information

BPR

Lifecycle Management

BPR Assessment Form (As-Is, To-Be Business Processes)

Initial Business Case

Submit Need

Assess

Final Business Case

Governance

Milestones

Analyze Approve

Planning >> Elicitation >> Analysis >> Specification >> Validation

Requirements Lifecycle: From a Bright Idea to a Baselined Set of Requirements

11

Planning

Elicitation

AnalysisSpecification

Validation

Approval

BRS

Baseline

Iterative Process

Submit Support Request Form

Analyze Submission

Present Submission to

Appropriate Portfolio Board

Approve Submission

Iterative Process

Iterative Process

Iterative Process

After a submission is approved, it enters the first phase of the requirements process – Planning.

This lifecycle can be used for any software development methodology including the following:

• Waterfall• Agile• Spiral• Incremental

Planning

12

Requirements Planning is a preparatory phase of the requirements lifecycle during which stakeholders, roles and responsibilities, communication methods, requirements approach, and metrics are identified.

Activities

•Identify High-level Business Requirements

•Identify Stakeholders

•Develop Project Scope

•Create Requirements Management Plan

•Configure and Verify Traceability Structure

Mechanisms

•Client-led interviews

•Working groups

•Stakeholder / user interviews

•Stakeholder / user surveys

Artifacts

•Requirements Management Plan1

•Communications Plan1

•Business Case

•Metrics

1 One Requirements Management Plan and one Communications Plan are required.

Elicitation

13

Requirement Elicitation is a phase of learning, uncovering, extracting, surfacing, and discovering the needs of customers, users, and other potential stakeholders.

Activities

•Initiate project•Form workgroup

•Define project objective and Scope

•Identify Stakeholders

•Choose elicitation techniques

•Explore attributes, capabilities and business rules

Mechanisms

•Client-led interviews

•Working groups

•Stakeholder / user interviews

•Stakeholder / user surveys

Artifacts

•Stakeholder List

•Project Charter, Plan, and Schedule

•Questionnaires/Surveys

•Agendas/Meeting Minutes

Analysis

14

Requirements analysis is the compilation of tasks that go into determining the needs or conditions for the final solution. During this phase analysis models with screenshots, high-level use case packages, and business process diagrams are created, requirements are prioritized, and impacts and risks are assessed.

Activities

•Create analysis model

•Screenshots•High-level use case diagram

•Business process flows

•Prioritize requirements

Mechanisms

•Client-led interviews

•Analysis tools (i.e. Rational Rose)

•Rapid Prototyping Tools

Artifacts

•Process Maps

•Use Cases (as-is and to-be)

•Context Diagrams

•Business Rules

•Prioritized Requirements

Specification

15

Requirements Specification defines what the product needs to do without addressing how it will be done. During this phase, all business requirements are compiled and ambiguities from possible conflicting requirements of various stakeholders or users are resolved.

Activities

•Document workflow requirements

•Eliminate ambiguities & store requirements

•Write use cases with normal flow, alternate flows, and any additional business rules

•Complete process flow diagrams

Mechanisms

•Requirements Management Repository (e.g., DOORS)

•AKO/DKO

Artifacts

•Business Requirements Specification (BRS)

•Enterprise Architecture Models

Validation

16

Requirement Validation is ensuring that the stated requirements support and are aligned with the goals and objectives of the business.

Activities

•Peer review requirement specifications

•Inspect requirement specifications

•Iterate requirements as needed

Mechanisms

•Peer review sessions

•Client lead reviews

Artifacts

•Approved BRS

•Requirements Traceability Matrix (RTM)

Roles and Responsibilities Within IM

17

Role Responsibilities

Information Management Division

• Serve as a liaison between the Warfighter, clinical-business mission owners, Services’ stakeholders, and the OCIO

Information Manager (IM)

• Identify and define the functional and performance requirements that support the MHS Core Functional Areas (i.e., Clinical, Force Health Protection, Business) through their representation of their respective DASDs

• Serve as, or identify, additional SMEs. • Participate on various IPTs and IRD Workgroups to support

requirements related activities in the process

IM Analyst • Serve as experts on MHS capabilities and functional requirements in one or more of the MHS Core Functional Areas (e.g., Clinical, Force Health Protection, and Business)

• Assist Information Managers with developing both high-level and detailed functional requirements and manage capabilities

• Review, validate, and prioritize submissions, and develop the IRD CONOPS and assist with its subsidiary artifacts, which may include JCIDS documents

• Assists with creating POM and Fiscal Year (FY) Investment Portfolio submissions

IM’s Strategic Alignment with MHS

IM aligns with MHS’s strategic action plans:– Governance

Implemented Governance structure– Innovation

Enterprise wide collaboration– Interoperability

Seamless exchange of information– Maximize Portfolio Value

Improve development and sustainment costs– Requirements and Business Architecture

Requirements Delivery Framework– Streamline IM/IT Lifecycle

Improved cycle time and product quality

18

19

Business Capabilities Supported by IM

Medical Service Accounts (MSA) – The MSA function consists of billing and collecting funds for medical and dental services, including elective cosmetic procedures, from:  DoD beneficiaries (where applicable…this is usually DoD civilians assigned to overseas installations); civilian emergency patients; other patients authorized treatment in MTFs (foreign military officers).  MSA provides a complete and reliable financial record of transactions including collection control, accounts receivable, and deposits.

Medical Affirmative Claims (MAC) – The mission of the Medical Affirmative Claims is to enact the Federal Claims Collection Act (31 USC 3711-3720A).  The goal of MAC is to recover the reasonable value of medical care rendered for injuries or illnesses provided at Government expense to DoD beneficiaries under circumstances creating a third party tort liability.  Example:  If an active duty member was involved in a motor vehicle accident (for which the Government provided healthcare), the Government is required to seek restitution for those costs from the insurance company of the person at fault.

Third Party Collection Program (TPCP) – The TPCP requires MTFs to bill Other Health Insurance for outpatient visits or inpatient stays to include pharmacy, lab, and radiology services.  Example:  My wife maintained health care insurance while I was on active duty even though she was entitled to free healthcare as my spouse (she had the insurance because she traveled extensively for work and wasn’t always near an MTF) so when my wife went to the MTF where we were assigned, the MTF was allowed to bill her insurance company for her care.

Q&A

Questions?

20

Speaker Information

Session ID: M-4-1100

<Name and Contact information Redacted>

21

Acronyms

22

Acronym Definition

ASR Alternative Systems Review

BRS Business Requirements Specification

CBT Computer Based Training

CDR Critical Design Review

IM Information Management

ITR Initial Technical Review

OV Operational View

PIR Post Implementation Review

PDR Preliminary Design Review

RTM Requirements Traceability Matrix

SIR System Incident Report

SRR System Requirements Review

TRR Test Readiness Review

https://dap.dau.mil/aphome/das/Pages/DAUOnlineGlossary.aspx

Glossary

Term Definition

Business RequirementHigher-level statement of goal, objective, or need of the enterprise. It describes why the project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success

Business Requirements Engineering A requirements engineering sub-activity consisting of the cohesive collection of all tasks that are primarily performed to produce the requirements and other requirements work products for the customer organization’s business enterprise

Configuration Management The management activity consisting of the cohesive collection of all tasks that are primarily performed to manage an endeavor’s baselines of configuration items

Change Control Board (CCB) Any team that determines when and if changes are to be implemented to base-lined work products

Functional Decomposition A requirements analysis technique for breaking down large required functions into smaller sub-functions

Functional Requirement A requirement that specifies a function that a business, application, or component must be able to perform

Non-Functional RequirementCondition that does not directly relate to the behavior or functionality of the solution, but rather describes environment conditions under which the solution must remain effective or qualities that the systems must have

Requirement A condition or capability needed by a stakeholder to solve a problem or achieve an objective.

Requirements Analysis The requirements engineering task during which the reused and elicited raw requirements are analyzed

Requirements Engineering The activity consisting of the cohesive collection of all tasks that are primarily performed to produce the requirements and other related requirements work products for an endeavor

Requirements Evaluation The quality control task during which the requirements work products are evaluated

Requirements Management The requirements engineering task during which requirements are base-lined, placed under configuration control, and maintained during subsequent iteration

23

Glossary

Term Definition

Requirements Specification

The requirements engineering task during which the analyzed requirements for a system, application, application domain, or component are published in requirements specifications (and related requirements documents)

Requirements Traceability Matrix (RTM)

A table that correlates any two base-lined documents that require one-to-many, many-to-one, or many-to-many relationships to determine the completeness of the relationships

Requirements Validation

The requirements engineering task during which the correctness of the identified and/or analyzed requirements is verified by their stakeholders

Submission Any idea that fosters a change (addition, modification, or removal) to a capability, policy, process, or system

System Design Document (SDD)

A design work product that is comprehensive description of how the system requirements in the SRS are transformed into more technical system design specifications from which the system is built. It is used to document both high-level system design and low-level detailed design specifications.

System Requirement

Statement that describe the behavior and information that the solution will manage. It describes capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.

System Requirements Specification (SRS)

The requirements work product that formally specifies the system-level requirements of a single system or an application The requirements specification is the foundation on which the architecture, design, and implementation are built.

DOORS (Dynamic Object Oriented Requirements System)

A powerful requirements management tool used to capture, link, analyze, and trace requirements that ensures conformance to requirements and compliance with regulations and standards.

Technical Specifications Design requirements that define how the AIS must be built to satisfy both business and user requirements.

Test Script Set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied

User RequirementStatement of need of a particular stakeholder or class of stakeholders. It describes the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the System Requirements.

24