Project :Industry: Security, Manufacturing, Human Resources, Research and Development Services Provided: Project Management, Organizational Change Management Company: The client is a global leader in

<Sponsor>

..........

<Project name>

Requirements Planning Document

Author: <Author>

Version: <Version>

Date: <Date>

Document History

Supporting Document Links:

<File link> (Sharepoint Location/link)

Related Documents

(Examples) Project Concept Document, Project Charter, PDD, Application Development Master Plan, Customer request

Template Notes

• The document template contains some other basic templates.

• Graphic templates are Visio drawings that include the set of symbols and eventually a prototype diagram. They are not true Visio templates.

• When a UML diagram is required, the template is not included. A UML modelling tool (such as Rational Rose) may be used. Same can apply to Mercury & other tools

• The template may be converted to landscape format for better spacing of tables and graphs. The text in italics and blue are comments about the template and should be removed.

• PROPOSED METHDOLOGY RULE (PROJECT CATEGORIZATION):

The flag << SML >> indicates if the section or chapter is required for a Small, Medium, or Large project. Everything is required for a large project. S and M are indicated where applicable.

Requirements Analysis Team:

Authorization page

CONTENTS

1. Overview

<< SML >>

<<< A brief summary conveying the essentials of the project.

It is aimed at business line & management level and should not contain technical terms. Explanation of terms that are unavoidable should be provided in an appendix.>>>

1. 1. Introduction

<< SML >>

<<< A brief introduction providing essential background to the project.

Other topics could include:

• Business background

• Origins of the project

• Existing systems overview

• Major issues

• Major limitations for the existing business or systems

• Existing relevant documentation – full references are given here or in an Appendix.

A note is helpful clarifying the nature and structure of the requirement analysis, such as:

The document presents the requirements independent of any potential implementation. The document structure follows the business functions analysed and presented in the functional structure section of the report.>>>

1. 1. Approach<< SML >>

<<<A short statement of how the investigation and analysis was carried out.>>>

<<<Any formal techniques should be described at a high-level (Agile, SCRUM,Etc) l. The approach to presenting the report should be described in outline and reference to any special matters given, e.g.:

Sources and any limits to the techniques should be clearly stated.>>>

1. 1. Scope

<< SML >>

<<<A clear statement of the scope of the requirements analysis, showing areas analyzed and boundaries.

Possible ambiguities should be clarified by stating what is NOT included. Limitations should be described.

Diagrams can be helpful to improve clarity – put these in this section or refer to them in an appendix. Refer to the methodology if appropriate, such as :>>>

1. 1. 1. High-level Functional Structure

<< SML >>

<<<This section includes a diagram that represents the functionality of the application to be developed. It may be described as one of the following:

• A high-level use case model. A UML Use Case Diagram or a hierarchy diagram (e.g. Story Points) may be used.

• A high-level functional decomposition. A hierarchy diagram may be used.

The diagram should show the structure of business processes, not the place in the organization where the process occurs. Each node in the diagram will need a unique identifier that will link it to more detailed views of the functional structure. (Req Breakdown Structure)>>>

1. 1. 1. High-level Process Definition

<< SML >>

<<<A “swim lane” diagram may be used to describe the high-level process. The actual level of detail may depend on the application.>>>

1. 1. 1. High-level Information View

<< SML >>

<<<The high-level information view shows the relationship between

• Interaction devices

• Data stores

• Business functionality>>>

1. 1. 1. High-level Integration View

<< SML >>

<<<The high-level integration view shows the high-level components used to integrate the business functionality components. It may be seen as a high-level view of the middleware required to support the application.>>>

1. 1. 1. High-level Technology View

<< SML >>

<<<This high-level view shows the physical infrastructure where the application will execute.>>>

1. 1. Business Impact

<< SML >>

<<<Include a short statement describing the potential impact of this document’s requirements and recommendations upon the business as a whole. >>>

<<<Topics could include:

• Strategic issues – how this project implements or supports the business strategy

• Life expectancy of current systems

• Business expansion or contraction

• Broad business benefits – such as direction, major issues resolved, and competitive edge.>>>

1. 1. Current Systems

<< SML >>

<<<Include the main characteristics of the current systems and immediate plans within the scope of the project.>>>

<<<Use bullet points to highlight the most significant matters. It is not appropriate to describe current systems in detail.>>>

<<<Points to consider include:

• Nature of the systems, such as manual procedures, legacy systems, or end-user computing solutions

• Relevant recent history, such as application development and investment

• Life expectancy of current systems

• How well current systems match the target technical environment and technical strategy

• Limitations of current systems

• Impact on the current business and its opportunities

• Advantages and disadvantages of the current facilities

Relationship to the business organization and any limitations>>>

1. 1. Constraints

<< SML >>

<<<Include a short list of the main business constraints to be considered when identifying requirements and possible solutions.>>>

<<<Possible categories include:

• Regulatory (Basel 2, Sarbox, Needed for MU Attestation, etc)

• Business Policy

• Other systems development projects

• Infrastructure

• Technical architecture

• Business strategy

• IT strategy

• Product availability and reliability

• Marketplace Timeliness to market>>>

1. 1. Assumptions

<< SML >>

<<<A list of the assumptions on which the requirements are stated. This may well be in addition to those identified earlier in the project.>>>

<<<Points to consider include:

Business circumstances, such as the business environment

Business strategy

IT strategy

Organizational plans or constraints

Other development activity outside the scope of this project

Other business activity outside the scope of this project

External factors

Timing

Availability of critical Lahey resources

Integration to other Lahey projects

Continuity

Priorities as outlined by PPM Governance>>>

1. BUSINESS MODEL

<<<Include a high-level definition of the business processes within the scope of the project.

This is in three parts:

Diagram(s) of the high-level business view

Description of the main processes

Process volumes>>>

1. 1. Process Diagram

<< SML >>

<<<Include a high-level flow/activity diagram of the main business processes covered by the scope of the project. An outline of related processes (or functions) can be shown if relevant or helpful.>>>

1. 1. Process Descriptions

<< ML >>

<<<Include short descriptions of the main business processes and events.

Other items to be considered for a process are:

Objective of the process

Specifications/Directives

A brief description of each event is sufficient.>>>

1. 1. Process Volumes

<< SML >>

<<<Estimate the volumes of the main business processes.

Volumes for the significant processes at any level should be Rough Order of Magnitude (ROM) estimated. This is particularly necessary if the process volume is likely to affect the sizing of the project infrastructure requirements.>>>

1. 1. Business Entity Model Diagram

<< SML >>

<<<Include a diagram of the relationships of the significant business entities within the scope of the project. The diagram uses UML notation for Class Model but may include any attribute or operation for the business entities.>>>

1. 1. Business Entity Descriptions

<< SML >>

<<<Brief description of each business entity in the model (often called Personas).

A short description of the entity is required. Optionally, a bullet list of the entity attributes can be added (usually included in the diagram). The descriptions should be short and logically exact. Some background explanation can be added, if it is necessary to clarify.>>>

1. 1. Data Volumes

<< SML >>

<<<Include an initial estimate of the volumes of data for each of the business entities contained in the entity model.>>>

1. REQUIREMENTs definition

<<<The requirements should be clearly and simply described, without ambiguity.

It is a distinct advantage, where possible, for requirements to be quantifiable and relate to the business purpose stated earlier.

It is valid to describe the requirement at an outline level where a package solution is to be considered, rather than try to define the exact business mechanism.

Requirements may be:

• High Level Business Objectives

• Functional requirements

• Non functional requirements.

The templates are described below.>>>

.

1. 1. Functional Requirements

<< SML >>

<<<This section includes a diagram that represents the functionality required for the application to be developed. It may be described as of the following four options (Note: This is the detail that feeds the overview section):

• A high-level use case model. A UML Use Case Diagram or a hierarchy diagram may be used.

• A high-level functional decomposition. A hierarchy diagram may be used.

• a Table describing the functionality hierarchy

• A description for every node in the diagram. The description will include:

Code - Name of Requirement

Where adequate, code may represent the hierarchy of requirements (#.#.#).

Description

General description of the requirement.

Priority

Mandatory, Desirable, or Optional.

Performance Parameters

The dynamic business performance requirements of throughput, frequency of use and growth expected, such as stock turn, planning lead-time, number of business transactions, peak load, commercial windows, and response times required. All must be in terms of business performance requirements, and not in any way second-guess the design of the solution.

Issues/Constraints

Issues and constraints relating to Design, Location or Organization that may not be addressed within this specification, but that need to be documented here so that they do not get overlooked.>>>

1. 1. Non-functional Requirements

<< SML >>

<<<Non-functional Requirements are those requirements not representing business functionality. They are represented as lists of requirements, grouped as appropriate.

Non-functional requirements may be applicable to:

• The complete application (required)

• A specific functional requirement (optional)

The following non-functional requirements represent the minimum set to be specified :Also refer to Non-Functional Requirements (NFR guidelines)>>>

Performance

Security

Availability (e.g. HA)

Regulatory

Recoverability (e.g. DR / Business Continuity)

Reliability (e.g SLA, Required Uptime Objectives)

Scalability

Portability

Reusability

Testability

Management

User Interface

<<<Any other non-functional requirement will be included here. A requirement code will be attached to every requirement. These other non-functional requirements may include:

• Internationalization

• Accessibility (support for the handicapped)

• Interoperability

• Special technologies (such as support for Kiosk multimedia)>>>

Other Requirements

1. 1. Requirement Dependencies

<< ML >>

<<<This section describes the dependencies between requirements. This may be represented by one of the following options:

• A dependencies diagram (where every requirement is a node, and an arrow indicates a dependency)

• A matrix (requirements vs. requirements) indicating the type of dependency.

The text inside the box linking two requirements may indicate or describe the type of dependency.>>>

<<<Appendices should be included when any further detail is required.

Examples that could occur include:

• References to related documents

• More detailed information on the business modelling

• Related business volume or background for estimates

• Additional matrices that may help define the current or required system(s)

(Samples given below)>>>