Unctional Equirements Ocument: Project or System Name
Unctional Equirements Ocument: Project or System Name
Unctional Equirements Ocument: Project or System Name
REQUIREMENTS
DOCUMENT
Month, Year
Revision Sheet
Revision Sheet
Release No. Date Revision Description
Rev. 0 5/30/00 Functional Requirements Document Template and Checklist
Rev. 1 6/6/00 Additions to Section 7
Rev. 2 4/10/02 Conversion to WORD 2000 format
I have carefully assessed the Functional Requirements Document for the (System Name). This document
has been completed in accordance with the requirements of the HUD System Development Methodology.
We fully accept the changes as needed improvements and authorize initiation of work to proceed. Based
on our authority and judgment, the continued operation of this system is authorized.
_______________________________ _____________________
NAME DATE
Project Leader
_______________________________ _____________________
NAME DATE
Operations Division Director
_______________________________ _____________________
NAME DATE
Program Area/Sponsor Representative
_______________________________ _____________________
NAME DATE
Program Area/Sponsor Director
TABLE OF CONTENTS
Page #
NOTE TO AUTHOR: Highlighted, italicized text throughout this template is provided solely as
background information to assist you in creating this document. Please delete all such text, as well as
the instructions in each section, prior to submitting this document. ONLY YOUR PROJECT-
SPECIFIC INFORMATION SHOULD APPEAR IN THE FINAL VERSION OF THIS
DOCUMENT.
The Functional Requirements Document provides the user a clear statement of the functions required of
the system in order to solve the user's information problem as outlined in the Needs Statement.
1.1 Purpose
1.2 Scope
Describe the scope of the Functional Requirements Document as it relates to the project.
Provide a list of the references that were used in preparation of this document. Examples of references
are:
Provide a list of the acronyms and abbreviations used in this document and the meaning of each.
1.5.1 Information
Provide a list of the points of organizational contact (POCs) that may be needed by the document user for
informational and troubleshooting purposes. Include type of contact, contact name, department,
telephone number, and e-mail address (if applicable). Points of contact may include, but are not limited
to, helpdesk POC, development/maintenance POC, and operations POC.
1.5.2 Coordination
Provide a list of organizations that require coordination between the project and its specific support
function (e.g., installation coordination, security, etc.). Include a schedule for coordination activities.
This chapter describes (in non-computer-oriented language) the existing system functions to establish a
context for the proposed system. If the existing system is a manual process, describe that.
2.1 Background
Provide background information concerning the uses and purposes of the current system. Refer to
interfacing systems when needed to enhance the general description.
State the major requirements and goals of the current system. These statements should be concise,
quantified if possible, and may include examples. When applicable, related events may be discussed.
Provide an explanation of how the current system interacts with the functional processing supported.
Identify products from other systems used with the current system.
Briefly describe the current methods and procedures being employed to satisfy the existing information
requirements. Provide a graphic representation that depicts the existing data flow through the functional
system from data acquisition through its processing and eventual output. The graphic may be
complimented by a narrative explanation of the sequence in which the user performs the operational
functions. Include in your explanation the information requested in the following subsections.
Discuss provisions in the existing system design, including operation in degraded modes or at alternate
sites in the event of emergency, disaster, or accident.
2.3.4 Deficiencies
Describe proposed methods and procedures. If functions from an existing system are to be incorporated,
describe these functions. Explain (in non-computer-oriented language) how the proposed system will
interact with the functional processes that the automated system will support. Identify products from
other systems that will be used with, or become part of, the proposed system. Describe the relationship
between the project and other capabilities being developed concurrently.
If the proposed system eliminates or degrades any capabilities in an existing system, identify these
capabilities, and state the reasons for their elimination or degradation. In the following subsections, you
may also include a graphic representation depicting the major functional processing steps and the
interacting organizations.
3.1.3 Timeliness
Summarize the anticipated impacts and associated costs (detailed in the following subsections) of the
proposed system on the existing organizational and operational environments of the user, as well as to the
user during the development of the system.
Organizational impacts may include the modification of responsibilities and the addition or elimination
of responsibilities that will be necessary to use the proposed system.
Identify any personnel positions expected to be eliminated, as well as requirements for the number and
skills of additional personnel. Include changes in staffing levels, location, and position, if known. If
functions of the proposed system may need to be restored (at one or more alternate sites following an
emergency, disaster, or accident) identify the number and skills of personnel needed for contingency
operation at each alternate site, if known.
Identify the operational impacts to the organization during the use of the proposed system. Include the
proposed interface between the user and the primary or alternate computer operating centers; the impacts
on the user to change from the current operational procedures; new data sources; quantity, type, and
timeliness of data to be submitted for use in the system; data retention requirements; modes of user
operation based on emergency, disaster, and accident; and proposed methods for providing input data if
these data are not already available.
Identify all user effort that will be required prior to implementation of the system, such as development
and modification of the database, or required training. Include any user requirement for the parallel
operation of the new and existing system, along with the potential impact on the user during the testing
phase of the proposed system. Discuss any additional activities to be provided by the user to aid
development.
Describe any assumptions and constraints that will affect development and operation of the system.
Identify any limitations affecting the desired capability, any desired capabilities that will not be provided
by the proposed system, as well as any anticipated operational changes that will affect the proposed
operation of the system.
This chapter provides a detailed description (in non-computer-oriented language) of the functions to be
performed and the performance requirements of the proposed system.
Describe the specific performance requirements for the system as a whole and for major functions or
subsystems within it. Delineate the requirements on which the system design will be based. Include a
quantitative presentation of requirements, such as the number of events that must be processed,
maximum allowable time from query to receipt of requested information, and flexibility required to
accommodate changing user requirements.
4.1.2 Timing
Describe the online and/or batch timing requirements to be imposed on the system. Consider the
following requirements:
Specify the maximum numbers of transactions, storage requirements, concurrent users, or any other
quantifiable information about capacity requirements placed on the system. Identify changes to capacity
limits resulting from varying modes of operation. Include peak load limits and issues.
Describe by individual function the major functional processing steps. This may be done using graphic
representation (e.g., flowchart) or descriptive use cases. Provide enough detail to support development of
design specifications.
Provide a general description of each of the batch and online inputs and outputs. Include information
regarding the following:
Discuss alternative courses of action that are to be taken to satisfy the information requirements if the
proposed system fails. Include as appropriate:
Backup: Identify backup requirements for ensuring the continued achievement of system
functions.
Fallback: Identify fallback techniques for ensuring the continued satisfaction of the specific
requirements of the system. Fallback indicates the use of another system to satisfy the system
requirements. For example, the fallback techniques for an automated system might be manual
manipulation and recording of data.
Degraded Modes of Operation: State priorities for restoring the essential functional processing
steps in the event that full processing capability is not available.
This chapter describes the way in which the proposed system will satisfy the requirements. It restates
the user requirements, previously stated in non-technical language, using any terminology required for
the design methods to be used for development. This chapter may also be used to document additional
technical requirements when they do not directly relate to the functions and performance that is obvious
to the user, and therefore have not been described previously.
Provide a general description of the design of the proposed system. Refer to related and interfacing
systems and their documentation (as required) to enhance this general description. Include a graphic
representation showing the relationship of the user organizations to the major components of the
proposed system.
Discuss the functions of the proposed system. Elaborate on the performance requirements and the
functions in enough detail, relating them to the system environment.
5.3 Flexibility
Describe the capability for modification to the system to be incorporated in the design. Discuss the
capability that will allow modification as a result of changing requirements, operational changes,
interaction with new or improved systems, or periodic modifications.
6.0 ENVIRONMENT
6.0 ENVIRONMENT
Provide an overview of the equipment capabilities required for the proposed system, as well as the
equipment presently available, and the characteristics of any new equipment. Equipment description
should include:
Processors (including personal computers), the number of each, and size of internal storage
Storage media, including disk units, size, and number
Output devices, including number of each online/offline
Input devices, including number of each online/offline
Provide an overview of the software with which the application software is to interact. Include support
software, CASE/automated tools, input and equipment simulators, and test software, if needed. Provide
the correct name, level (version), and documentation references of each software system, subsystem, and
software unit.
Identify the language, the operating system, and any Database Management System (DBMS).
If any of the software components is not an approved HUD standard, indicate when the item was
submitted to the Configuration Change Management Board (CCMB) for approval.
State the general communication requirements of the system being developed if it is not the HUD
standard network. Desired remote response times may be specified.
Provide a graphic representation or diagram that shows the known communication requirements of the
system. Include notations of type and peak volume of data.
List the known communication hardware required to support the system being developed. Include such
hardware items as number and type of storage devices required, specialized input devices, and number
and type of printers required.
List the known communication software requirements of the system being developed. Include such
software as languages, compilers, the operating system, report and code generators, database management
systems, and text editors. When determining what programming language will be used, consider the
following:
6.4 Interfaces
Describe all interfaces with other application systems and subsystems. For each interface, the following
information should be specified:
Describe the anticipated organizational, operational, and developmental impacts of the proposed system
on the information systems (IS) organization.
Include any modifications of positional responsibilities that will be required by the proposed system, as
well as any personnel interactions to be eliminated. Discuss IS personnel responsibilities. Identify
requirements for the number and skills of additional personnel. Include changes in staffing levels,
location, and position identification.
Discuss impacts on the operational procedures of the information processing centers to implement the
system. Include operational impacts caused by a change in equipment configuration, if known.
Assess the personnel and resources necessary for the development and testing of the automated system.
Address any additional requirements for software and data conversion, if known, along with any
additional impacts resulting from the requirements in Section 3, Proposed Methods and Procedures.
Discuss possible failures of the hardware or software system, the consequences (in terms of system
performance) of such failures, and the alternative courses of action that may be taken to satisfy the
information requirements.
6.6.1 Restart/Recovery
Describe capabilities for ensuring effective and efficient recovery from a problem within the hardware or
software systems.
Positioning of data, program (software units), and documentation at alternate sites or other
locations that are not subject to the same threats as the primary site
Production of special output upon warning or alert to support fallback or backup operation
Additional addressing or re-addressing of transactions to permit alternate site operations, both
after loss of primary site capability and upon warning or alert
Requirements for re-homing of communication circuits to permit alternate site operations
Identify any constraints that will affect operation of the system. Define any limitations affecting desired
capability (e.g., availability of main memory and storage devices). Include any desired capabilities that
will not be provided by the proposed system and the reason(s) why each will not be provided. Also
include any anticipated and operational changes that will affect the proposed operation of the system.
7.0 SECURITY
7.0 SECURITY
To control dissemination of sensitive information, all or portions of this chapter may be maintained and
distributed separately from the remainder of the document. A more detailed description of security
requirements is to be provided in the System/Subsystem Specifications.
The following provides an overview of each control point, the vulnerabilities at the control point, and
the safeguard requirements to reduce the risk at each point to an acceptable level. Include consideration
of alternate modes of operation based on emergency, disaster, or accident, if appropriate.
Describe the points in the system at which there is a known vulnerability that requires specific
safeguards. (A control point can be located at any interface at which there is a movement of data within
or between sites.) The following control points should be considered:
Origin: Identify the point at which input data will be collected, prepared, and entered into the
system.
Data Entry: Identify remote devices intended to be used to perform data entry, update, and
corrective actions.
Disposition: Describe the disposition of source data after it is entered into the system. Refer to
Handbook 2229.2 Records Disposition Schedule for Automated Systems.
Error Correction: Identify the points at which data input errors will be detected, reported, and
corrected.
Accuracy and Completeness: Identify the points in the processing cycle at which the system will
provide notification of success or failure of the requested processing.
System Interface: Identify the points in the processing cycle at which the systems will pass data
to or receive data from other systems.
Distribution: Identify the steps involved in the distribution and disposition of output products.
7.2.2 Vulnerabilities
A design implementation, or operational condition inherent in the application or system that lends itself
to error, loss, or compromise of information or denial of service is a system vulnerability.
Describe the vulnerabilities at each control point identified in Section 7.2.1, Control Points.
7.2.3 Safeguards
Describe the safeguard requirements at each control point to reduce the vulnerabilities. At a minimum,
the following areas should be considered:
Personnel: Identify positions requiring security clearances or access authorization and functions
that are authorized.
Collection and Preparation: Describe any requirements for the proper control of the collection,
preparation, and backup of data.
Environmental Constraints: Describe any requirements to limit operation of the system to certain
devices or periods of the day.
Distribution: Describe any requirements for a variance from standard distribution procedures.
Access/Permission: Describe procedural requirements to develop, maintain, and control
access/permissions to system data or functions.
A physical safeguard is any physical means that limits access to data (locked doors, vaults, card/key
access).
A technical safeguard is defined as any automated process that assures appropriate processing
(passwords, read/write keys).
User Access: Describe all requirements for controlling user access and detecting abnormal
patterns of use.
Process Safeguards: Identify the need for any unique data validation procedures or data
encryption that may provide added integrity.
Security Identification Requirements: Describe any unique requirements to be imposed on the
system for automated labeling or display of security identification.
Describe all user requirements for the production of an audit trail including automated reports or journals
necessary to monitor the system. Monitoring may be provided by this system or by another system.
7.3.1 Journalizing
Journalizing is the recording of selected events as they occur within the system, and provides the basis
for monitoring the processing and use of data and the use of computer resources.
Describe the conditions (functions, events, dates, times, unusual circumstances) that will cause the
creation of an entry in a journal.
Describe the identification information, such as date, time, system or function identification, user name,
terminal identification, and location, to be recorded in each type of journal entry.
Identify the application systems data to be recorded for each type of journal entry.
Identify the procedural and management requirements for review of the journal and follow-up action.
Describe all user requirements for an audit trail, such as total transactions processed by location, time,
type and retention periods.
Describe all record disposition schedules covering the electronic files of finance and accounting systems
or their feeder systems. Forward these schedules for clearance with OIG to allow them an opportunity to
review and provide input on the proposed retention periods.