[See the last page for template assistance.]

Functional Requirements Document

<Project/Sub-project Title>

<Office/Group>

Prepared for

University Information Technology Services

Babbidge Library, Storrs CT

369 Fairfield Rd, Unit 2209

Storrs, CT 06269-2209

File Name: Functional Requirements Document.doc

Overview

The functional requirements document (FRD) is a formal statement of an application’s functional requirements. It serves the same purpose as a contract. The developers agree to provide the capabilities specified. The client agrees to find the product satisfactory if it provides the capabilities specified in the FRD.

Quality is meeting requirements. For that reason, the FRD is the central document in system development. It is used for the following:

Designing and developing the application system.

Evaluating the product in all subsequent phases of the life cycle.

Determining the success of the project.

The FRD has the following characteristics:

It demonstrates that the application provides value to the University in terms of the business objectives and business processes in the 5-year plan.

It contains a complete set of requirements for the application. It leaves no room for anyone to assume anything not stated in the FRD.

It is solution independent. The ERD is a statement of what the application is to do—not of how it works. The FRD does not commit the developers to a design. For that reason, any reference to the use of a specific technology is entirely inappropriate in an FRD.

A requirement is a condition that the application must meet for the customer to find the application satisfactory. A requirement has the following characteristics:

It provides a benefit to the organization.

It describes the capabilities the application must provide in business terms.

It does not describe how the application provides that capability.

It does not describe such design considerations as computer hardware, operating system, and database design.

It is stated in unambiguous words. Its meaning is clear and understandable.

It is verifiable.

TABLE OF CONTENTS

1	General	4

1.1	Project Description	4

1.1.1	Background	4

1.1.2	Purpose	4

1.1.3	Assumptions and Constraints	4

1.1.4	Interfaces to External Systems	4

1.2	Points of Contact	5

1.3	Document References	5

2	FUNCTIONAL REQUIREMENTS	5

2.1	Data Requirements	5

2.2	Functional Process Requirements	5

3	OPERATIONAL REQUIREMENTS	5

3.1	Security	6

3.2	Audit Trail	6

3.3	Data Currency	6

3.4	Reliability	6

3.5	Recoverability	7

3.6	System Availability	7

3.7	Performance	8

3.8	Capacity	8

3.9	Data Retention	8

4	REQUIREMENTS TRACEABILITY MATRIX	8

5	Glossary	8

General

Project Description

[Provide a brief overview of the project.]

Background

[Summarize the conditions that created the need for the application.]

Purpose

[Describe the business objectives and business processes from the project charter document and the CBA that this application supports.]

Assumptions and Constraints

Assumptions are future situations, beyond the control of the project, whose outcomes influence the success of a project. The following are examples of assumptions:

Availability of a hardware/software platform

Pending legislation

Court decisions that have not been rendered

Developments in technology

Constraints are conditions outside the control of the project that limit the design alternatives. The following are examples of constraints:

Government regulations (both federal and state)

University of Connecticut policies and procedures

Standards imposed on the solution

Strategic decisions

Be careful to distinguish constraints from preferences. Constraints exist because of real business conditions. Preferences are arbitrary. For example, a delivery date is a constraint only if there are real business consequences that can happen as a result of not meeting the date. For example, if failing to have the subject application operational by the specified date places the University in legal default, the date is a constraint. A date chosen arbitrarily is a preference. Preferences, if included in the FRD, should be noted as such.

Interfaces to External Systems

[Name the applications with which the subject application must interface, State the following for each such application:

Owner of application (if external to the University)

Details of interface (only if determined by the other application)]

Points of Contact

[List the names, titles, and roles of the major participants in the project. At a minimum, list the following:

Project Manager

Development project leader

User contacts

Agency employee whose signature constitutes acceptance of the FRD]

Document References

[Name the documents that were sources of this version of the FRD. Include meeting summaries, white paper analyses, and other System Development Life Cycle deliverables, as well as any other documents that contributed to the FRD. Include the Configuration Management identifier and date published for each document listed.]

FUNCTIONAL REQUIREMENTS

The functional requirements describe the core functionality of the application.

[Include the data and functional process requirements.]

Data Requirements

[Describe the data requirements by producing a logical data model, which consists of entity relationship diagrams, entity definitions, and attribute definitions. This is called the application data model. The data requirements describe the business data needed by the application system. Data requirements do not describe the physical database.]

Functional Process Requirements

Process requirements describe what the application must do. Process requirements relate the entities and attributes from the data requirements to the users’ needs.

[State the functional process requirements in a manner that enables the reader to see broad concepts decomposed into layers of increasing detail.]

Process requirements may be expressed using data flow diagrams, text, or any technique that provides the following information about the processes performed by the application:

Context

Detailed view of the processes

Data (attributes) input to and output from processes

Logic used inside the processes to manipulate data

Accesses to stored data

Processes decomposed into finer levels of detail

OPERATIONAL REQUIREMENTS

Operational requirements describe the non-business characteristics of an application.

[State the requirements in this section. Do not state how these requirements will be satisfied. For example, in the Reliability section, answer the question, “How reliable must the system be?” Do not state what steps will be taken to provide reliability.

Distinguish preferences from requirements. Requirements are based on business needs. Preferences are not. If, for example, the user expresses a desire for sub-second response but does not have a business-related reason for needing it, that desire is a preference.]

Security

[Security Steward Name:]

The security Section describes the need to control access to the data. This includes controlling who may view and alter application data.

[State the consequences of the following breaches of security in the subject application:

Erasure or contamination of application data

Disclosure of Government secrets

Disclosure of privileged information about individuals

State the type(s) of security required. Include the need for the following as appropriate:

State if there is a need to control access to the facility housing the application.

State the need to control access by class of users. For example, “No user may access any part of this application who does not have at least a (specified) clearance.”

State the need to control access by data attribute. State, for example, if one group of users may view an attribute but may not update it while another type of user may update or view it.

State the need to control access based on system function. State for example, if there is a need to grant one type of user access to certain system functions but not to others. For example, “This function is available only to the system administrator.”

State if there is a need for accreditation of the security measures adopted for this application. For example, C2 protection must be certified by an independent authorized organization.]

Audit Trail

[List the activities that will be recorded in the application’s audit trail. For each activity, list the data to be recorded.]

Data Currency

Data currency is a measure of how recent data are. This section answers the question, “When the application responds to a request for data how current must those data be?” [Answer that question for each type of data request.]

Reliability

Reliability is the probability that the system will be able to process work correctly and completely without being aborted.

[State the following in this section:

What damage can result from this system’s failure?

Loss of human life

Complete or partial loss of the ability to perform a mission-critical function

Loss of revenue

Loss of employee productivity

What is the minimum acceptable level of reliability?

State required reliability in any of the following ways:

Mean Time Between Failure is the number of time units the system is operable before the first failure occurs.

Mean Time To Failure is computed as the number of time units before the system is operable divided by the number of failures during the time period.

Mean Time To Repair is computed as the number of time units required to perform system repair divided by the number of repairs during the time period.]

Recoverability

Recoverability is the ability to restore function and data in the event of a failure.

[Answer the following questions in this section:

In the event the application is unavailable to users (down) because of a system failure, how soon after the failure is detected must function be restored?

In the event the database is corrupted, to what level of currency must it be restored? For example “The database must be capable of being restored to its condition on no more than one hour before the corruption occurred.”

If the process site (hardware, data, and onsite backup) is destroyed how soon must the application be able to be restored?

In the event of s system failure, describe any partial recovery scenarios that are required in order to provide smaller window of downtime.]

System Availability

System availability is the time when the application must be available for use. Required system availability is used in determining when maintenance may be performed.

[In this section state the hours (including time zone) during which the application is to be available to users. For example, “The application must be available to users Monday through Friday between the hours of 6:30 a.m. and 5:30 p.m. EST.” If the application must be available to users in more than one time zone state the earliest start time and the latest stop time.

Include the times when usage is expected to be at its peak. These are times when system unavailability is least acceptable.

For most applications, there are no fault tolerance requirements. When a portion of the application is unavailable there is no need to be able to use the remainder for the application.]

Performance

[Describe the requirements for the following:

Response time for queries and updates

Throughput

Expected volume of data

Expected volume of user activity (for example, number of transactions per hour, day, or month)]

Capacity

[List the required capacities and expected volumes of data in business terms. For example, state the number of cases about which the application will have to store data. For example, “The project volume is 600 applications for travel per month.” State capacities in terms of the business. Do not state capacities in terms of system memory requirements or disk space.]

Data Retention

[Describe the length of time the data must be retained. For example, “information about an application for travel must be retained and immediately accessible from for three years after receipt of the application.”]

REQUIREMENTS TRAcEABILITY MATRIX

The requirements traceability matrix (RTM) provides a method for tracking the functional requirements and their implementation through the development process. Each requirement is included in the matrix along with its associated section number. As the project progresses, the RIM is updated to reflect each requirement’s status. When the product is ready for system testing, the matrix lists each requirement, what product component addresses it, and what test verify that it is correctly implemented.

[Include columns for each of the following in the RTM:

Requirement description

Requirement reference in FRD

Verification Method

Requirement reference in Test Plan]

Glossary

[Include business terms peculiar to the application. Do not include any technology-related terms.]

Functional Requirements Document Sign Off

To:

From:_

Preparer/Contact: _________________________	Phone: _______________________

Project Name: __________________

The functional requirements for the project named above have been captured and documented within these pages as complete per the business client’s team and the technical team. All sections of the document have been completed to the best of the teams ability and knowledge to solve the domain problem described in this document beginning on page 4.

Any further requirements uncovered for this project will be evaluated for importance to the successful delivery of this project. If it is deemed the project will not be successful without the inclusion of the new requirements, the requirements will be added to this document and management will be notified at once. Other requirements will follow the change control process.

SIGNATURES	___________________	_____________________

Project Manager	Functional Lead

___________________	_____________________

Date	Date

RevisioN History

Version	Date	Summary of Changes	Author	Revision Marks (Yes/No)
0.1	Initial revision.

[Note: This template is provided to assist authors with the UITS SDLC.

Blue or black text within arrow brackets (< >) should be customized before publishing this document. Be sure to change the color of the text to black before publishing this document.

Blue text within square brackets ([ ]) provides instructions and guidance and should be deleted before publishing this document.

This document uses automatic fields:

Viewing Automatic Fields
If you cannot see the automatic fields in this document, select Tools>Options, and then choose the View tab; in the Field Shading drop-down list, choose Always.

Customizing Automatic Fields
To customize the automatic fields in this document, select File>Properties and then replace the information in brackets (< >) with the appropriate information for this document; be sure to also customize the Custom properties by choosing the Custom tab, selecting a property, changing its value, and then clicking Modify. Repeat this for each custom field. Click OK to close the dialog.

Updating Automatic Fields
You can update the automatic fields with new, customized information by selecting Edit>Select All (or Ctrl+A) and then pressing F9, or by simply clicking on a field and pressing F9. This must be done separately for Headers and Footers (View>Header and Footer, Ctrl+A, F9). See MS Word help for more information on working with fields.]