mySDLC Delivery Process

Requirements Document

Project Name: <Project Name>

Project Control #: <Assigned RPM Number>
ABC ID: <ABC ID>
Responsible Parties
Prepared By

Department/Group

Region

Telephone

Contributors

Department/Group

Region

Telephone

Description of Revision

Region

Approval & Date

Revision History
Version

Date

2013 Kaiser Foundation Health Plan, Inc.

This document contains information proprietary to Kaiser Permanente Health Plan/Hospitals. Information contained herein may be
used only for the benefit of Kaiser Foundation Health Plan, Inc. Duplication or dissemination for any other purpose is prohibited. For
internal use only.
Release Date: 04/12/2013, Version 6.6

Requirements Document
Document Template Final Sign-Off Section

Document Template Final Sign-Off Section

A signature indicates that you have reviewed and understand the contents of the
document and attest to the validity of these contents relative to the functional role you are
representing. If there are any aspects of this document that do not adequately reflect your
needs or are deemed unacceptable, this should be noted in the comments section below
your name.
Table 1 .Final Sign Off Table in order by role

Approved by
Business Application Owner: <Type name here>

Date:

Signature:
Comments:
Business Area Partner: <Type name here>

Date:

Signature:
Comments:
Business Segment Partner: <Type name here>

Date:

Signature:
Comments:
Development Manager and / or Development Team Lead: <Type name here>

Date:

Signature:
Comments:
IT Project Manager: <Type name here>

Date:

Signature:
Comments:
National Operations Project Manager: <Type name here>

Date:

Signature:
Comments:
Quality Consultant: <Type name here>

Date:

Signature:
Comments:
Realization Team Leader: <Type name here>

Date:

Signature:
Comments:

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 2 of 22

Requirements Document
Document Template Final Sign-Off Section

Approved by
Solution Consultant: <Type name here>

Date:

Signature:
Comments:
<Other Approval>: <Type name here>

Date:

Signature:
Comments:

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 3 of 22

Requirements Document
Contents

Contents
[To update the Contents, click inside the table of contents and press the F9 key.]
Document Template Final Sign-Off Section......................................................................................... 2

1 Document Overview.............................................................................6
1.1

Purpose..........................................................................................................6

1.2

Instructions....................................................................................................6

2 Executive Summary..............................................................................7
3 Business Requirement.........................................................................8
3.1

Requirement Sources...................................................................................8

3.2

Business Objectives.....................................................................................8

3.3

Context Diagram............................................................................................9

3.4

Events...........................................................................................................12

3.5

Processes.....................................................................................................12

3.5.1

<Process1>.......................................................................................................................... 13

4 Change Matrix.....................................................................................19
4.1

New Requirements......................................................................................19

4.2

Deleted Requirements.................................................................................19

4.3

Modified Requirements...............................................................................19

5 Appendix I Requirements List........................................................20

5.1

User Requirements......................................................................................20

5.2

Functional Requirements...........................................................................20

5.3

Non-Functional Requirements...................................................................21

5.4

System Requirements.................................................................................21

6 Appendix II Traceability Matrix.......................................................22

List of Tables
[To update the List of Tables, click inside the list of tables and press the F9 key.]
Table 1 .Final Sign Off Table in order by role............................................................................................ 2
Table 2. Requirement Sources.................................................................................................................... 8
Table 3. Customer Business Objectives...................................................................................................... 9

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 4 of 22

Requirements Document
Contents

Table 4. External Entities........................................................................................................................... 11

Table 5. Business Entities in Project Scope............................................................................................... 11
Table 6. Information Flows......................................................................................................................... 11
Table 7. Event List..................................................................................................................................... 12
Table 8. User Requirements...................................................................................................................... 13
Table 9. <Process1> Information Flows..................................................................................................... 15
Table 10. <Process1> Data Stores............................................................................................................ 15
Table 11. <Process1> Use Case................................................................................................................ 15
Table 12. <Process1> Functional Requirements.......................................................................................18
Table 13. <Process1> Non-Functional Requirements................................................................................18
Table 14. New Requirements..................................................................................................................... 19
Table 15. Deleted Requirements................................................................................................................ 19
Table 16. Modified Requirements.............................................................................................................. 19
Table 17. Modified Requirements.............................................................................................................. 20
Table 18. Modified Requirements.............................................................................................................. 20
Table 19. Modified Requirements.............................................................................................................. 21
Table 20. Modified Requirements.............................................................................................................. 21
Table 21. New Requirements..................................................................................................................... 22

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 5 of 22

Requirements Document
Document Overview

1 Document Overview
1.1 Purpose
The Requirements Document is critical to successfully define the business requirements
and support the development of the technical solution. This document should be the
single record of reference for requirements pertaining to this initiative. The process of
gathering requirements is one of progressive elaboration.
When completed, this document is placed under change control to preserve a record of
what has been agreed to, and approved.

1.2 Instructions
Delete the instructions blue text and this page when completing this template for an
initiative. Replace text in angle brackets (<>) with opportunity-specific content, or
delete if it not applicable. Retain other content in angle brackets unless there is a
compelling reason to remove.
SOLUTION REVIEW CRITERIA: Tables, figures, embedded files, and other non-text
objects should have text that describes the purpose of the object and any color or notation
conventions used in the object. Tables should also include descriptions of the columns if
not obvious to a layperson, and especially the meaning of encoded data values. Tables
and Figures should be captioned and listed in an appropriate table of contents. Standard
diagrams techniques can just be referenced (e.g., Ouellette context diagrams), but any
non-standard deviations (e.g., dashed lines) must be documented. Authors should use best
practices in the development of their documents. At a minimum:

Most recent mySDLC has been used

Contributors are identified by organization
Spelling has been checked
Template paragraph types have been used; custom formats are captured as

styles
Blank paragraphs are not used for inter-paragraph spacing

Figures and Tables are captioned

Embedded change bars include only if they are relative to a prior reviewed
version; documents up for first review should have no change bars

Work in progress is clearly identified, by highlight color or other means

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 6 of 22

Requirements Document
Appendix II Traceability Matrix

2 Executive Summary
Write the Executive Summary for a business audience, assuming no detailed knowledge
of the business opportunity area, and define any acronyms that are used. It should be brief
and descriptive, but it does not replace any content from later sections.
A recommended flow for the paragraphs:
Describe the general business context.

Describe the source of the business requirements. Where did the

requirements originate?

Describe the functionality that must be implemented in order to meet the

business needs (in summary)

SOLUTION REVIEW CRITERIA: Should be less than 1 page, clear and understandable
by a lay reader.

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 7 of 22

Requirements Document
Appendix II Traceability Matrix

3 Business Requirement
3.1 Requirement Sources
This section should identify the sources for the business requirements. For instance, if the
project is regulatory in nature then this section should include a summary of the
regulations that must be met by the requirements. If the project scope is to solve a
specific business problem, describe the background of the problem and where it
originated. These sources should be included in CaliberRM under the Sources category.
Sources can come from vision statements, business cases, and similar types of
information that business partners develop in the QI and Concept phase.
SOLUTION REVIEW CRITERIA: Clear understanding of where the requirements
originated.
Table 2. Requirement Sources

Source ID

Summary

3.2 Business Objectives

This section should summarize the high level business objectives found in the Concept
Description Document into a list. Business objectives represent high-level goals of the
organization or customer who requests the system. Business Objectives should be
achievable within the scope of the project, or should indicate the contribution of the
proposed project toward the Objective.
Ask:

What are the high level goals/objectives of the solution?

Why are we building the solution?
What is the GOAL of the Solution?
WHOSE goal is it?

List the Business Objectives in a table, numbered for traceability. This list should be
inclusive of all stakeholders viewpoints. In theory, every part of the solution created in
Definition and developed during Development should trace back to one or more of these

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 8 of 22

Requirements Document
Appendix II Traceability Matrix

Objectives. Enter objectives in CaliberRM under the Business Objective category.

Include the Priority from Caliber in the table.
SOLUTION REVIEW CRITERIA: Based on the clarity and precision of the
presentation, and its ability to serve as a guide for Definition activities. Business
Objectives should have the following properties:
If possible, Business Objectives should be grouped and tiered into logical
sets that define different levels of business benefit, corporate strategy, or other such
organization. If used, document the organization method used.

Goals should fall within the scope of the original Qualified Idea; Goals
outside of the QI should indicate how they were derived.

Business Objectives are entered into Caliber as Category 200 Business

Requirements, and presented in the CDD in tabular form, with numbering by Caliber
for traceability.

Business Objectives should be achievable within the scope of the project, or

should indicate the contribution of the proposed project toward the Objective.

Business Objectives generally should not refer to specific IT applications or

cite a specific solution.

The following table lists the customer business objectives for this project.
Table 3. Customer Business Objectives

Objective#

Requirement Description

Priority

3.3 Context Diagram

If multiple Context Diagrams, create separate subsections for each diagram (e.g. 2.3.1,
2.3.2, etc.).
The Context Diagram consists of a single bubble that defines the logical boundary of the
business area or application being modeled. Everything inside the bubble will be studied
and is in scope. Everything outside the bubble is adjacent systems (other people,
processes, systems, etc) that are recipients or sources of application information and is
out of scope. The arrows between the adjacent systems and the circle represent
interactions between the two with information flowing to and from. These interactions
are the result of events that occur internally or externally to the track. Triggering events
for these interactions will be described below.

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 9 of 22

Requirements Document
Appendix II Traceability Matrix

Each box represents an entity (e.g. department, organization vendor) that is external to
the scope of the project but triggers an event which must be responded to within the
project scope. Each box should be identified with the business organization name (not a
system name) and should be numbered.
Each line represents a business data flow and should be labeled with a clear description
of the type of data flowing into/out of the project scope (bubble). Once each line is
labeled, identify the event which triggers the flow and include the event number on the
flow. Number each flow.
The Context Diagram should have a supporting table included that lists of the flows on
the Context Diagram. The flow description should focus on the high-level event and
business response; showing all of the subsequent flows in response to an event is
probably too much detail. For instance, showing an acknowledgement response to a
business message is not appropriate.
Multiple Context Diagrams can be included for large programs, where the extra detail
adds to the clarity of the overall presentation. If done, include an overarching diagram
that places all the individual Context Diagrams in context.
The figure below is a sample context diagram.

Figure 1. Context Diagram Example

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 10 of 22

Requirements Document
Appendix II Traceability Matrix

Identify the External Entities that participate in the Context Diagram. These tables help
to scope the analysis work performed in Definition. Provide a list of the business units,
organizations, and potential deployment sites affected by the initiative. Entities should
not be IT applications, but the Business Area, Department, Function, Services provided
by the entity. The Business Impact should be a synopsis of the anticipated impact; this
impact should state known changes as a result of the project. Definition will produce the
complete impact analysis. Impacts to External Entities are responsibilities for that area to
help realize the objectives or conform to new or changed information flows. Use
appendices to capture detailed information on systems, sites and organizations, such as
business owners and contact information.
Table 4. External Entities

Name

Description

Business Impact

EE1
EE2

Identify the Business Entities that are in scope for the process. The business impact
should state known changes as a result of the project.
Table 5. Business Entities in Project Scope

Name

Description

Business Impact

EE1
EE2

List out each information flow identified on the Context Diagram along with a
description and business impact. The business impact should state known changes as a
result of the project. Indicate which business event number from the Event List table in
the next section that triggered the flow.
Table 6. Information Flows

Name

Description

Business Impact

Event

BF1
BF2

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 11 of 22

Requirements Document
Appendix II Traceability Matrix

3.4 Events
The following business events that occur trigger planned processes that will be impacted
as a result of this project. There are two types of events.
1. External Event - an event initiated by a specific originating adjacent system.
2. Temporal Event - an event initiated by the arrival or passage of a specific time.
These events are usually associated with in-bound data flows on the Context Diagram.
Outbound flows are associated with the response processing of these events. External
Events are identified with an identifier beginning with E and Temporal by a T.
List the entity which triggered the event, name of the event, and the associated process
which is required to respond the event. Describe the process as it pertains to the scope of
the project.
Table 7. Event List

Event
#

Triggering
Entity

Triggering Event

Process Name

Description

E1

3.5 Processes
This section details the processes that handle the above events. Generally a process will
have a single trigger event and will generate the required responses to that event.
Sometimes a single process may be used to handle similar events from different sources.
Processes should be named with a verb-noun combination with the verb representing
the work the system must do and the noun specifying the output of the work performed.
Each event identified above must be associated with a process which handles that
event. All outbound data flows on the Context Diagram must also be associated with
a process.
A process will generally be associated with a User Requirement. Often this
User Requirement serves as a high level description of the process. The detail of the
process should be described by a use case (described further below.)

The use case should list the steps involved in the process, the project impacts, the
business flows represented by each step and identify the functional or non-functional
requirement that is the result of the project impact. Focus on the high level steps in the
process or any steps that will require a change and will result in a requirement. Each
impact must have a corresponding requirement(s). Each requirement may be functional or
non-functional as described in section 3.4.

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 12 of 22

Requirements Document
Appendix II Traceability Matrix

3.5.1 <Process1>
3.5.1.1 Process Description
Provide a summary of the process, focusing on the changes that are necessary as a result
of the project. Identify what the task is that the user is trying to complete.
3.5.1.2 Triggering Event (s)
List the event(s) which triggered this process. In some cases there may be more then one
that triggers the same process.
3.5.1.3 User Requirements
User requirements describe user goals or tasks that the users must be able to perform. List
out each function the business must be able to perform as a user requirement. These
requirements should appear in CaliberRM under category User Requirements and should
reflect t
Table 8. User Requirements

User Req #

Requirement Description

Priority

DE-UR001

3.5.1.4 Event Response Diagram

Create an Event Response Diagram for the process identified. Each event response
diagram will have the following characteristics.
Create a bubble in the middle of the diagram labeled with the name of the
process which is required to respond to the event.

Each external entity (e.g. organization, department, vendor) which sends

information to or receives from the process will be represented by a box. Each box
will be labeled with the entity name (this should be a business entity and not an
application) and include an ID. These entities should be consistent with the entities
found on the context diagram and should be labeled consistently.

Each business flow in or out of the project scope bubble will be

represented by a line between the external entity and the process. These flows should
include all business flows identified for this event on the context diagram but are not
limited to these flows as the context diagram shows only high level flows. Add all
additional flows needed to accurately reflect information in and out of the process.
Business flows should not typically be shown going from one external entity to
another. However, for the sake of clarity, sometimes it is beneficial to indicate this.
Each line will have the following characteristics

If it is a new flow, indicate with a dotted line

If it is a modified flow, indicate with a dashed line

If there is no change to the flow, indicate this with a solid line

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 13 of 22

Requirements Document
Appendix II Traceability Matrix

Label the line with a clear title denoting the data represented by the flow

Number the flows in the order that the flow occurs

Indicate data stores with a rectangle with right side open. These data stores
indicate stores of information which are updated or read from during the process.

Below the diagram, provide a list of the business flows along with a
description and data elements included in the flow that are relevant to this process.

Below the diagram, provide a list of the data stores identified on the diagram
along with a description.

Below is a sample event response diagram.

Figure 2. Event Response Diagram Example

Describe each of the information flows identified on the diagram and include project
relevant data elements that are part of the flow. Identify whether the flow is new,
modified or existing in the Type field.
Include a unique ID for each flow or sort the flows alphabetically so they are easily found
in the list.
2013 Kaiser Foundation Health Plan, Inc. - Confidential
requirements_document

Release Date: 04/12/2013, Version 6.6

Page 14 of 22

Requirements Document
Appendix II Traceability Matrix

Table 9. <Process1> Information Flows

ID

Name

Description

Data Elements

Type

E1-1
E2-2

Describe the data stores, if any, used by the process.

Table 10. <Process1> Data Stores

ID

Name

Description

3.5.1.5 Use Case

Detail the process as a use case with each step being listed sequentially. The process
should be described from a business perspective. The normal flow of events should
specify the usual set of steps involved in successfully completing the user goal. Alternate
flows specify variations from the normal flow of events that result in user goal success.
Detail these alternate steps in the Alternate Flow section. Exception handling should be
described in the Exception Flows section.
Complex steps may require breaking out into a separate process use case. This is the
exception. These process use cases should be referenced in the action description.
Table 11. <Process1> Use Case

Actors
Identify the Actors this generally a list of the externally entities and data stores involved in the use
case
1. <Entity A>
2. <Entity B>
3. <Data Store A>

Assumptions

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 15 of 22

Requirements Document
Appendix II Traceability Matrix

Identify all assumptions associated with the process

1. <Assumption 1>
2. <Assumption 2>
3. <Assumption 3>

Pre-Conditions
Identify all Pre-conditions that must be met prior to the process beginning.
1. <Pre-condition 1>
2. <Pre-condition 2>
3. <Pre-condition 3>

Normal Flow of events

Step # Action

Project Impact

Info Flow
ID

Requirement
IDs

1.

Identify any impact to

the step as a result of
the project

Informatio
n Flow ID
from the
EventResponse
Diagram

Functional
and NonFunctional
Requirement
IDs from
Table in
following
Section

Describe what the process must do. If

the step is very complex you may want
to break out into a separate process use
case. If so, indicate the process use
case here.
<Your text here>

<Your text here>

<Your text
here>

<Your text
here>
2.

Alternate Flow of Events A1

Alternate Flow of Events A2

Exception Flow of Events EX1

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 16 of 22

Requirements Document
Appendix II Traceability Matrix

Post-conditions
Identify the post conditions that would indicate successful completion of the process including exception
handling post conditions.
1. <Post-condition 1>
2. <Post-condition 2>
3. <Post-condition 3>

Frequency Information
Indicate the processing frequency for this process.

Notes
Provide additional notes if desired that may be helpful in understanding this use case
1. <Note 1>
2. <Note 2>

3.5.1.6 Process Requirements

List the functional/non-functional requirements that are associated with each of the
impacts identified in the use case. These requirements should be entered into Caliber in
the Functional and Non-Functional Requirements Categories.
Functional requirements specify new functionality that must be delivered in order to
allow users to accomplish their tasks and allow high level objectives to be achieved. This
functionality may be met through a software application change or may be handled
manually by the business (e.g. a new member letter may be created manually by business
but still represents new functionality).
Non-functional requirements are statements of policy, guidelines, security, performance,
etc that define constraints that the functionality must work within.
System requirements are top level requirements for a product which has multiple subsystems which could include software, hardware and people. As a result of other
requirements of the system, your sub-system (project scope) may require additional
functional/non functional requirements to drive these system requirements. For
example: software is being developed to control some laboratory apparatus that
automates the tedious addition of quantities to an array of beakers. Because of overall
system requirements associated with other hardware sub-components, new software
functional requirements are needed to send signals to the hardware to move the chemical
dispensing nozzles, read positioning sensors and turn pump on and off. A system
requirement can be written in the following way. The software must {fit in this way in
the existing/enterprise system structure}
The following will be tracked with each requirement.
2013 Kaiser Foundation Health Plan, Inc. - Confidential
requirements_document

Release Date: 04/12/2013, Version 6.6

Page 17 of 22

Requirements Document
Appendix II Traceability Matrix

1. Requirement Number:
Each requirement has a unique number. That number conforms to a standard format.
For example, ABC-FR-XXX format for functional and ABC-NF-XXX for nonfunctional requirements, where ABC is a three-letter abbreviation for the initiative,
and XXX is a unique number. The numbering order is irrelevant, as long as the
numbers are unique. The number identifies the specific requirement throughout its
life.
2. Requirement Description:
This is the actual detailed requirement.
3. Implementation:
This indicates whether the requirement will be met by an Information Technology
system (S) or whether it will be managed manually by the business (B). If the system
or process is know, indicate it as well. This is an optional field to be used if this
information is available at the time of requirements gathering. This is subject to
change during the logical design process.
4. Region:
The region impacted by the requirement. This may be ALL or a specific region
name(s).
Table 12. <Process1> Functional Requirements

Req ID

Requirement Description

Implementation
(S/B)

Regions

Implementation
(S/B)

Regions

Table 13. <Process1> Non-Functional Requirements

Req ID

Requirement Description

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 18 of 22

Requirements Document
Appendix II Traceability Matrix

4 Change Matrix
This section identifies any changes to project requirements. Through change control,
requirements will change. Document all changes here with the reason and person
responsible for the change.

4.1 New Requirements

Table 14. New Requirements

Additional Date

Requirements #

Reason for Deletion

Added By

Reason for Deletion

Added By

4.2 Deleted Requirements

Table 15. Deleted Requirements

Deletion Date

Requirements #

4.3 Modified Requirements

Table 16. Modified Requirements

Modified
Date

Old
Requirements #

New Requirements #

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Reason for Change

Modified
By

Release Date: 04/12/2013, Version 6.6

Page 19 of 22

Requirements Document
Appendix II Traceability Matrix

5 Appendix I Requirements List

The following lists the full set of requirements from all use cases along with their meta
data.
Include any metadata associated with your requirements in this appendix. This metadata
may include (optional) additional attributes not captured with the use case such as Source
and Priority but is not limited to these.
Source - indicates the source of the requirement such as a specific regulation or business
policy. These should be identified in section 2.1 Business Sources. This is optional.
Priority a rating mechanism to determine how critical the requirement is to the
business solution. This information is valuable in making trade-off decisions. The impact
is based on whether the requirement is:
High (Essential) - Implies that the solution will not be acceptable unless the
requirement is provided.

Medium (Conditional) - Implies that the requirement would enhance the

solution, but, if absent, would not make it unacceptable.

Low (Optional) - Implies that the requirement may or may not be

worthwhile, depending on cost/benefit analysis.

5.1 User Requirements

Table 17. Modified Requirements

Req. #

User
Requirements

Source

Implementation
(B/S)

Priority

Processes
Impacted

Regions

Priority

Processes
Impacted

Regions

XXX-UR-XXX
XXX-UR-XXX

5.2 Functional Requirements

Table 18. Modified Requirements

Req. #

Functional
Requirements

Source

Implementation
(B/S)

XXX-UR-XXX
XXX-UR-XXX

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 20 of 22

Requirements Document
Appendix II Traceability Matrix

5.3 Non-Functional Requirements

Table 19. Modified Requirements

Req. #

NonFunctional
Requirements

Source

Implementation
(B/S)

Priority

Processes
Impacted

Regions

Implementation
(B/S)

Priority

Processes
Impacted

Regions

XXX-NF-XXX
XXX-NF-XXX

5.4 System Requirements

Table 20. Modified Requirements

Req. #

Systems
Requirements

Source

XXX-SR-XXX
XXX-SR-XXX

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Release Date: 04/12/2013, Version 6.6

Page 21 of 22

Requirements Document
Appendix II Traceability Matrix

6 Appendix II Traceability Matrix

Indicate in this table the relationships between requirements (i.e.: Business Requirement
#243 is linked to User Requirement #501 and Functional Requirements #1001, #1002,
#1003). Use only unique Requirements IDs in this table.
Table 21. New Requirements

Requirements
ID

Related
Business
Objectives

Related User
Requirements

2013 Kaiser Foundation Health Plan, Inc. - Confidential

requirements_document

Related
Functional
Requirements

Related NonFunctional
Requirements

Related
Systems
Requirements

Release Date: 04/12/2013, Version 6.6

Page 22 of 22