Requirements Document

mySDLC Delivery Process

Requirements Document

Project Name:

Project Control #:

ABC ID:

Responsible Parties

Prepared ByDepartment/GroupRegionTelephone

ContributorsDepartment/GroupRegionTelephone

Revision History

VersionDateDescription of RevisionRegionApproval & Date

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:

Signature:

Comments:Date:

Business Area Partner:

Signature:

Comments:Date:

Business Segment Partner:

Signature:

Comments:Date:

Development Manager and / or Development Team Lead:

Signature:

Comments:Date:

IT Project Manager:

Signature:

Comments:Date:

National Operations Project Manager:

Signature:

Comments:Date:

Quality Consultant:

Signature:

Comments:Date:

Realization Team Leader:

Signature:

Comments:Date:

Solution Consultant:

Signature:

Comments:Date:

:

Signature:

Comments:Date:

Contents[To update the Contents, click inside the table of contents and press the F9 key.]

2Document Template Final Sign-Off Section

1Document Overview61.1Purpose61.2Instructions62Executive Summary73Business Requirement83.1Requirement Sources83.2Business Objectives83.3Context Diagram93.4Events123.5Processes123.5.1

134Change Matrix194.1New Requirements194.2Deleted Requirements194.3Modified Requirements195Appendix I Requirements List205.1User Requirements205.2Functional Requirements205.3Non-Functional Requirements215.4System Requirements216Appendix II Traceability Matrix22

List of Tables

[To update the List of Tables, click inside the list of tables and press the F9 key.]

2Table 1 .Final Sign Off Table in order by role

Table 2. Requirement Sources8Table 3. Customer Business Objectives9Table 4. External Entities11Table 5. Business Entities in Project Scope11Table 6. Information Flows11Table 7. Event List12Table 8. User Requirements13Table 9. Information Flows15Table 10. Data Stores15Table 11. Use Case15Table 12. Functional Requirements18Table 13. Non-Functional Requirements18Table 14. New Requirements19Table 15. Deleted Requirements19Table 16. Modified Requirements19Table 17. Modified Requirements20Table 18. Modified Requirements20Table 19. Modified Requirements21Table 20. Modified Requirements21Table 21. New Requirements22

1 Document Overview1.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 InstructionsDelete 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 means2 Executive SummaryWrite 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.

3 Business Requirement3.1 Requirement SourcesThis 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 IDSummary

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 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 ObjectivesObjective#Requirement DescriptionPriority

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.

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

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

#NameDescriptionBusiness 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

#NameDescriptionBusiness 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

#NameDescriptionBusiness ImpactEvent

BF1

BF2

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 EntityTriggering EventProcess NameDescription

E1

3.5 ProcessesThis 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.3.5.1 3.5.1.1 Process DescriptionProvide 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 DescriptionPriority

DE-UR001

3.5.1.4 Event Response DiagramCreate 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

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.Table 9. Information FlowsIDNameDescriptionData ElementsType

E1-1

E2-2

Describe the data stores, if any, used by the process.Table 10. Data Stores

IDNameDescription

3.5.1.5 Use CaseDetail 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. Use Case

Actors

Identify the Actors this generally a list of the externally entities and data stores involved in the use case

1. 2.

3.

Assumptions

Identify all assumptions associated with the process

1.

2.

3.

Pre-Conditions

Identify all Pre-conditions that must be met prior to the process beginning.

1.

2.

3.

Normal Flow of events

Step #ActionProject ImpactInfo Flow IDRequirement IDs

1.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.

Identify any impact to the step as a result of the project

Information Flow ID from the Event-Response Diagram

Functional and Non-Functional Requirement IDs from Table in following Section

2.

Alternate Flow of Events A1

Alternate Flow of Events A2

Exception Flow of Events EX1

Post-conditions

Identify the post conditions that would indicate successful completion of the process including exception handling post conditions.

1.

2.

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.

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 sub-systems 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.3. 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 non-functional 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.

4. Requirement Description:

This is the actual detailed requirement.

5. 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.

6. Region:

The region impacted by the requirement. This may be ALL or a specific region name(s).Table 12. Functional Requirements

Req IDRequirement DescriptionImplementation (S/B)Regions

Table 13. Non-Functional Requirements

Req IDRequirement DescriptionImplementation (S/B)Regions

4 Change MatrixThis 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 RequirementsTable 14. New Requirements

Additional DateRequirements #Reason for DeletionAdded By

4.2 Deleted Requirements

Table 15. Deleted Requirements

Deletion DateRequirements #Reason for DeletionAdded By

4.3 Modified Requirements

Table 16. Modified Requirements

Modified DateOld Requirements #New Requirements #Reason for ChangeModified By

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 RequirementsReq. #User RequirementsSourceImplementation (B/S)PriorityProcesses ImpactedRegions

XXX-UR-XXX

XXX-UR-XXX

5.2 Functional RequirementsTable 18. Modified RequirementsReq. #Functional RequirementsSourceImplementation (B/S)PriorityProcesses ImpactedRegions

XXX-UR-XXX

XXX-UR-XXX

5.3 Non-Functional Requirements

Table 19. Modified RequirementsReq. #Non- Functional RequirementsSourceImplementation (B/S)PriorityProcesses ImpactedRegions

XXX-NF-XXX

XXX-NF-XXX

5.4 System Requirements

Table 20. Modified RequirementsReq. #Systems RequirementsSourceImplementation (B/S)PriorityProcesses ImpactedRegions

XXX-SR-XXX

XXX-SR-XXX

6 Appendix II Traceability MatrixIndicate 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 IDRelated Business ObjectivesRelated User RequirementsRelated Functional RequirementsRelated Non-Functional RequirementsRelated Systems Requirements

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