Document Location: < Insert File Path Here >

[Insert Company Title]
[Insert Title]
Requirements
Version 1.0
[Insert Date]

Document Revision History

Every change to this document (subsequent to initial sign-off) must be recorded in the revision history chart below. Modifications to this document will be documented in the following chart. There are no exceptions. Note that the Project Sponsor and the Project Manager must sign off any changes to the requirements document.

Document Location:< Insert file path here >

Version / Date / Author/Editor / Comments
1.0 / January 1, 2007 / Full name and title / Initial version of this document.

1Introduction

This document provides the requirements for the proposed product.

Provide a brief overview of this project. You can copy text from the project proposal/charter, paste it here, and shorten it.

Provide a short description of the product being specified and its purpose, including relevant benefits, objectives, and goals. Relate the product to corporate goals or business strategies. If a separate vision and scope document is available, refer to it rather than duplicating its contents here.

The purpose of this document is to record the functional, quality and usability requirements into formats that are easily consumable for future analysis, architectural, and design activities and most importantly in a format that is understandable by all business partners.

This document is laid out to take the reader from a high-level understanding of the business processes down to the detailed automation requirements.

1.1Intended Audience

This is a brief description of who should be reading this document and what they should get out of it.

There are < Insert number here > main audiences for this document:

Audience / How This Document Will Be Used
Project Sponsor /

To understand and approve the requirements which define the overall scope of the project

Business Analyst /

To review process descriptions and automation requirements to ensure nothing is missed from their perspective
To provide input on requirements priorities

IT Manager /

To provide input into whatever other requirements or design artifacts needed to develop the approved requirements
To provide input into test plans/sets/cases based on prioritized requirements

2Scope

In a paragraph describe the scope of the product that is covered by this document.

2.1Business Process Model

Use this section to graphically depict the current state of the process. The practice of business practice modelling is used to bring to light a need to change a process or to identify some issue(s) that need to be corrected.

Use the following information from Sparx Systems to guide in developing a business process model.

A business process is a collection of activities designed to produce a specific output for a particular customer or market. It implies a strong emphasis on how the work is done within and organization, in contrast to a product's focus on what. A process is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs: a structure for action. (Source: Sparx Systems).

[For Example]:

You may choose to include a brief description of other process to give a better picture and understanding to the reader that are part of a larger process but not within the scope of this project.

Other processes include:

(list here with brief description):

Use the table below to describe each process (depicted above) very briefly to help establish the needs of this project.You may want to state up front, that with any business process, some aspects are manual and some are – or need to be – automated.

Note that the descriptions below are not the defined requirements. For the example shown above:

Process / Description and Needs
Develop Strategy /

Create & maintain team taxonomy to guide all content work
Set overall team goals and priorities on an annual and quarterly basis

Process #2…. /

….

(Add more rows as necessary).

2.2Assumptions and Constraints

Few projects begin with absolute certainty. Each assumption is an "educated guess", a likely condition, circumstance or event, presumed known and true in the absence of absolute certainty.

Each constraint is a limiting condition, circumstance or event, setting boundaries for the project process and expected results. Once identified, these assumptions and constraints shape a project in specific, but diverging ways - assumptions bring possibilities, and constraints bring limits. (Source: ITtoolkit.com).

The following assumptions and/or constraints have guided the scope and context for this requirements document:

List here.

2.3Automation Features Required for Release

Develop Silo Strategy Process
Feature Description – the solution must… / Priority (L/M/H) / Comments
Provide the ability to make additions, changes and deletions to the silo taxonomy / L / Stable requirement
Keep an audit trail of taxonomy changes / L / But high priority if above feature is implemented.
Stable requirement
Provide the ability to record priorities for the taxonomy – at a topic or sub-topic level - on a quarterly, annual or periodic basis / M / Evolving requirement – still outstanding questions on any automated validation rules for priorities (see Use Case)
Keep a history of goals and priorities / L
Process # 2….
Feature Description – the solution must… / Priority / Comments
….. / ….. / …..

2.4Out of Scope and Deferred Requirements

The following items are deemed to be out of scope for this project:

List here.

3Requirements

This section (and the requirement sub-sections that follow) captures the heart of this document. All business requirements must be captured here. You want to capture all the true business requirements of the proposed solution, succinctly and in an organized manner. To do that, use goal-oriented Use Cases. Remember that the purpose of requirements gathering through Use Cases is to describe the problems that need to be solved, not the manner in which they will be solved. In other words, avoid describing the proposed system or how it will solve the problems.

Consider gathering requirements from the following perspectives:

Needs and Features are the initial unstructured requirements gathered and lead to:

The Functional (Client and/or End-User) perspective
The Quality perspective
The Usability perspective
The Project Managementor Constraint perspective

Organizing the requirements in this manner ensures that all valid requirements are captured: the requirements of the end users of the system are clearly understood; the quality requirements are considered; and that project constraints and management expectations are documented.

For more information on gathering good requirements, see InfoTech Advisor’s “Characteristics of Requirements Checklist.”

3.1Functional Requirements

NOTE: The following section uses Use Cases to define product requirements. Use Cases are not the only way to define functional requirements but are the basis for this template.

Functional requirements define specific behaviours of a system and show how Use Cases are to be satisfied. A typical functional requirement will contain a unique name and number, a brief summary, and a rationale. This information is used to help the reader understand why the requirement is needed, and to track the requirement through the development of the system.

The core of each requirement is a clear and legible description of the required behavior.

3.1.1Functional Requirements Model

This project is being written for end-users. In order to capture their requirements, you need to identify who the end-users are. (Note that an individual can play one or more roles in this system).

List of Actors

Actors are used when writing Use Cases. They represent a role of an entity external to the system, and can be humans, machines, or devices. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action.

List actors below and provide a brief description.

[For example]:

Document Maintainer –Research Lead or Research Manager
General Research User – any staff in the Research area

Use Case Model

A Use Case Model describes the proposed functionality of a new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. This interaction is a single unit of meaningful work, such as Create Account or View Account Details.

Each Use Case describes the functionality to be built in the proposed system, which can include another Use Case's functionality or extend another Use Case with its own behaviour.

These can be created in Visio or a similar product and “cut and pasted” into this document.

[For Example}

The following diagram shows the relationships between the users of the product and the requirements of insert actor’s name.

3.1.2Functional Requirements Detail

Use Casesprovide the detailed view of the requirements. They do not specify ‘how’ the solution will be developed. They provide a high-level flow that will need to be considered in product design but do not attempt to design the actual product. See Info-Tech’s “Use Case Template” template and Info-Tech’s “Leading Principles in Use Case Design” In-Depth Reportfor more information.

Insert Use Case detail tables here as required. Note that if there are more than 5-10 Use Cases you may want to create a separate document and provide a link to that document in this section.

3.1.3Conversion Requirements

List all activities that must be done prior to or to address functional requirements.

List here.

3.1.4Data Retention and Purge Requirements

Data Retention and Purge Requirements –reference any functional requirements(Use Cases) that deal specifically with Purge. Ensure that the need to retain and/or purge information for business reasonsis clearly stated. E.g. Privacy Legislation may require that personal information about customers is deleted when no longer required to administer their business. Be sure to note the retention periods for audit, tax and legal requirements.

Records Retention Schedules apply to all storage media for information. Data retention rules should be updated in accordance with the Records Retention Best Practices at your site.

List here.

3.2Quality Requirements

There are a number of quality considerations that will need to be addressed within the scope of this project.

See Info-Tech’s “Quality of Service Requirements Template.”

After filling in the template cut and paste it into here.

3.3Usability Requirements

There are a number of usability requirements that will need to be addressed within the scope of this project.

See InfoTech Advisor’s “Usability Goals and Requirements” template for more instructions and additional information.

After filling in the template cut and paste it into here.

3.4Constraint Requirements

In order to predict the success of the project, Project Management requires clarification around the following parameters, at a minimum. These requirements are discussed in more detail in the Project Charter.

Time:

[Example: The timing of this project is not flexible – it must be implemented by January 1, 2007 in order to adhere to legislative changes.]

Resources:

[Example: This project requires significant testing resources]

Scope:

[Example: The scope of this project is flexible. OR the scope of this project is not flexible – only legislative specific changes can be made]

4Sign-off – Version X.X

The undersigned have read and reviewed the contents of the attached Requirements and Use Case documents and agree they meet the business needs. We approve of what has been stated and authorize the project team to proceed.

Business SponsorDate

IT LeaderDate

Privacy Compliance OfficerDate

Name

Appendix A: Communication and Meeting History

The purpose of this detail is to summarize meetings held during the requirements gathering process. Keeping this detail is designed to help avoid circular arguments. Fill in all communication and meeting history in the following table.

Version / Meeting Date / Attendees / Details
1.0 / January 1, 2007 / Full names and titles / Focus, key decisions, etc.
….. / ….. / ….. / …..

(Add more rows as necessary).

______

Info-Tech Research Group tools and template documents are provided for the free and unrestricted use of subscribers to Info-Tech Research Group services. Use this document either in whole or in part as a basis and guide for document creation. To customize this document with corporate marks and titles, simply replace the Info-Tech Information in the Header and Footer fields of this document.

Page 1 of 15

Document Location: &lt; Insert File Path Here &gt;

1Introduction

1.1Intended Audience

2Scope

2.1Business Process Model

2.2Assumptions and Constraints

2.3Automation Features Required for Release

2.4Out of Scope and Deferred Requirements

3Requirements

3.1Functional Requirements

3.1.1Functional Requirements Model

3.1.2Functional Requirements Detail

3.1.3Conversion Requirements

3.1.4Data Retention and Purge Requirements

3.2Quality Requirements

3.3Usability Requirements

3.4Constraint Requirements

4Sign-off – Version X.X

Appendix A: Communication and Meeting History

Document Location: < Insert File Path Here >