Introduction

This chapter provides an overview of the structure of the Functional Requirements document itself, the contents of the rest of the document, how it is organized and its intended audience.

Ownership: Product Manager, Client, Market Specialist, Business Analyst

Background
This section defines the environmental conditions that have shaped the product. These may include:

• History


• Market Forces


• Business Case


• Legacy Issues


• Competition


• Perceived customer motivation

Purpose and Scope
This section provides a general description of the product. This may include:

• Name of the product to be produced (version )


• Perquisites and dependencies on previous products


• Target audience


• Anticipated impact

References
This section provides references to all other publications (books, technical manuals, standard documents) that are applicable to the Functional Requirements Document, including the sources from which the references may be obtained.

Overview

This chapter is absolutely critical to the product development process, as it provides all Project Team members with a common ground description and context for the product, the environment, the business case, the critical issues and the major players.

Ownership: Product Manager, Market Specialist, Business Analyst

Product Functions
This section provides an overview of the tasks that the product is to perform. This may include:

• Use Case descriptions
• Graphic representation of the processing functions (e.g.,data flow diagrams or other charts)
• Table of functions

Product Perspective
This section describes the relationship of the system being developed to other related system products or components, including a general description of the interfaces. This may include:

• General hardware interface requirements (i.e. compliance with existing hardware)


• General user interface requirements (i.e. compliance with existing software)


• Marketing or client-specific information which helps to put the product capabilities into perspective

User Characteristics
This section describes the target audience (users) for whom the product is being developed, and how they will use it (i.e. End User, Manager, System Administrator, Installation personnel, Operations personnel, Support Desk personnel).
Describe:

• Perceived needs


• The tasks they wish to accomplish


• The way in which they work.

User Interface
This section provides a general description of the type of user interface that is appropriate for the product.

• Screen: Windows


• menus


• forms


• HELP facilities (Online, context-sensitive, tooltips, wizards)


• Operational: batch vs. interactive

General Constraints and Guidelines
This section describes the factors limiting the design of the product, such as:

• Regulatory constraints


• User constraints


• Product structure constraints


• Performance constraints

This section may also define the criteria by which the product is to be rolled out in phased stages.

Assumptions, Dependencies and Risks
This section describes factors that affect the requirements stated in the Functional Requirements Document. These are not design constraints, but factors that would affect the requirements themselves (i.e. The dependency on a specific operating system or major software library).

This section shall also identify any technical risks associated with the development of new capabilities.

Terminology

This chapter defines the terms most commonly used in this document. The section is arranged in alphabetical order.

Ownership: Product Manager, Market Specialist, Client, Business Analyst

The Terminology chapter is not only a helpful reference; it also provides a more detailed definition of the topics described in the Overview chapter.

Term	Definition
Term	Each term and its definition is arranged in this table. The terminology glossary may at some point be maintained in a central database. The terminology glossary is both a reference and a guide.
Chapter	This document is divided into numbered chapters that identify major informational areas.
Section	Each chapter may be divided into sub-levels or sections, which identify areas of greater informational specificity.

Functional Requirements

This chapter contains a description of the detailed requirements that will directly affect the design of the software being developed. These include:

• Processing requirements


• Performance requirements


• Design constraints


• Technical interface requirements


• Human interface requirements


• System attributes, s.a. Security, Development and Product Support & Maintenance

Depending on the type and complexity of the system being developed:

• These requirements may remain as separate sections that apply to the Product as a whole.


• The Product may be broken down into major function sections, with each function described in terms of the requirements.

  Processing Requirements
  This section contains detailed descriptions of product processing requirements, as grouped within INPUT, OUTPUT and PROCESSING descriptions. The Functional Requirements author has the freedom to use a combination of text descriptions, graphical representations (such as diagrams) and/or actual computer screen images (from a system prototype) to describe input, output and processing requirements.

  Ownership: Development Manager, Technical Architect, Client
  

Inputs

• Type and Sources of Data (File, Database, Online Feed, User Input)


• Units of Measure and Valid Ranges (Accuracies, Tolerances)

Processing

• Major Processing Functions (diagram)


• Methods (Mathematical Algorithms, Logical Operations)


• Input Checking/Validation, Parameters Affected, Responses to Abnormal Situations


• Sequence and Timing of Operations

Outputs

• Destinations of Data (Audit Log)


• Type of Output - File, Report, Graphics


• Quantities, Units of Measure and Valid Ranges (Accuracies, Tolerances)


• Error Messages

Performance Requirements
This section contains a detailed description of product software and hardware performance requirements.

Ownership: Technical Architect

Static Requirements (Capacity)

• Number of Terminals, Workstations and Users Supported Simultaneously


• Number of Files, Records and Pages Handled


• Sizes of Tables and Files

Dynamic Requirements

• Normal Conditions / Peak Workload


• Numbers of Transactions, Tasks, Data Per Unit Time


• User Response Time

Design Constraints & Benchmarks
This section contains all product hardware, software and standards requirements that constrain the design of the software being developed.

Standards Compliance
This section describes compatibility and conformance to established standards in terms of technical, operational and business-related issues.

Ownership: Interface Architect, Technical Architect, Business Analyst

• Report Formats


• Naming Conventions


• Accounting Procedures and Audit Tracing


• IEEE and Communications standards


• ANSI portability


• Financial segment, data quality standards and Project Specific Design Standards

Hardware And Software Limitations

Ownership: Technical Architect

• Configuration Characteristics


• Memory and Disk Usage


• Languages


• Peripherals

Technical Interface Requirements
This section contains a detailed definition of product hardware, and software interfaces.

Ownership: Technical Architect

• All machine platforms and peripherals


• 3rd Party Vendor Software and other related software products


• Terminal and Modem interfaces


• Local and Wide area networks, including Internet interfaces

Human Interface Requirements
The human interfaces described here are generic to all functions described in the Functional Requirements section. Each specific function description in the Functional Requirements section may specify additional human interface requirements. Reference to a product prototype may be included here in addition to the textual description of the user interface.

Ownership: Interface Architect, Business Analyst

• Hierarchy of Input Data


• Layout of Input and Output Items


• Relative Input, Output Timings


• Batch/Interactive Interface, Defaults

GUI Design

• Programmable Function Keys, Mouse, Accelerator Key


• Menus and Forms


• Windows, windows screen components


• On-Line Help, hypertext and User Manual

Security

Ownership: Technical Architect

• System Password Access and System Data Security


• Capability Access Security

Development

Ownership: Interface Architect, Technical Architect

• Structured Design


• Defined design documentation


• Modularity


• Reusability


• Methodologies


• Standards


• Tools

Product Support & Maintenance

Operations

• Interactive versus Unattended


• Backup and Recovery


• System Administration

Installation

• Hardware Tuning


• Software Tuning


• Environmental Constraints

Support Desk

Appendix: Document Checklist

Does the document conform with the Guidelines?

• Are the necessary sections present and does each section contain the required information?


• Is the Functional Requirements Document in the recommended format and does it conform to documentation guidelines?


• Is the Functional Requirements Document limited to defining requirements, and not how will it be done?

Is there an understanding of the problem to be solved?

• Have the system functions been described in a manner consistent with the environment and perceived user needs?


• Will the system, as described, solve the problem/needs?


• Are the numerical techniques appropriate, scientifically correct and consistent with the requirements?


• Is the full scope of software development understood, and are problem areas explicitly noted?

Is the operational environment correctly understood?

Are the requirements complete?

• Are user needs identified and addressed?


• Are the ultimate software products completely defined?


• Are the documentation standards established for all software?


• Is all software to be used, identified?


• Are system startup, restart, and batch or interactive program execution procedures identified?


• Are human factors requirements and problem areas identified?


• Are goals for the software identified?


• Have the expected level of change in the system and the time required to implement changes been considered?

Are all functional requirements completely defined?
Explicitly, quantitatively, and testably defined in terms of inputs, processing, outputs, data requirements, interfaces, accuracy, timing, exception handling, constraints, and performance

Input/Output

• Are display contents and layouts described?


• Are program inputs identified and described to the extent needed to design the program?


• Are required program outputs identified and described to the extent needed to design the program?


• Does the Functional Requirements Document include required behavior in the face of improper inputs and other anomalous conditions?

Data

• Are procedures identified for purging and updating data bases?


• Are data security and protection against data loss provided for?


• Are the logic data base and its access mechanism defined?


• Is each entity or relationship that is mentioned in the


• requirements also defined in the data dictionary, and vice versa?

Interfaces

• Are the person-machine interfaces and operational procedures clearly defined?


• Is adequate attention given to both the hardware-to-software and software-to-hardware interfaces?


• Is conformance with system accuracy control and interface control specifications (i.e., other equipments, operators, other software and data/data bases) stated?


• Are external system interface definitions accurate and complete?


• Are operational interfaces with the computer program, including both hardware and software, identified, or are there references to the specifications that define those interfaces?


• Are applicable nonoperational interfaces that are related to computer program support and code generation identified, such as specific programming languages, compilers, data based management systems, loaders, other utility programs, or unique support hardware? Are references to appropriate documentation of these interfaces identified?


• Do the requirements identify external interfaces and fully specify required program behavior with respect to each?

Performance

• Are the performance requirements for each function described in separate paragraphs? Do these paragraphs include source and type of inputs, and destination and type of outputs?
• Are requirements for system resource margins adequately specified?

Error Processing

• Are provisions made for transition to degraded or manual modes if the system or subsystem fails?


• Are adequate provisions made for system backup and redundancy?


• Are the software and hardware diagnostic capability requirements adequate?


• Is error processing logic described; i.e., do the requirements indicate improper, incorrect, or out-of-range inputs.

Environment

• Are the software tools required for development, testing, and maintenance of the software described, and are they deliverables?


• Does the Functional Requirements Document describe the operational environment into which the program must fit?


• Do the specifications tell what the computer program must do, how well, and under what conditions, and do they describe the environment in which it is to operate?


• Have software support and modification requirements been initially identified?


• Have support tools, facilities, and recruitment and training of support personnel been addressed?

Constraints

• Are explicit limits for the system (i.e., what it should and should not do) defined, and are constraints identified?


• Are the volume and throughput expectations for the system identified?


• Are the system protection and security requirements identified?


• Does the Functional Requirements Document include applicable timing and sizing constraints?

Are the requirements correct?

• Are the requirements consistent with documented descriptions and known properties of the operational environment into which the program must fit?


• Do interface requirements agree with document descriptions and known properties of the external interfacing elements?


• Do input and output requirements correctly describe inputs whose format, content, data rate, etc. are not at the discretion of the designer?


• Do requirements concerning models, algorithms, and numerical techniques agree with standard references, where applicable?


• Do the project manager and user management have any differences or other interpretation of the requirements?

Are the requirements consistent?

• Are the models, algorithms, and numerical techniques that are specified mathematically compatible?


• Are input and output formats consistent and is each entity related to a source?


• Are the requirements for similar or related functions consistent?


• Are the accuracies required of inputs, computations, output, etc. compatible?


• Are the style of presentation and the level of detail consistent throughout the document?


• Is the mapping of software requirements from the system specifications consistent?


• Are software system limits and capacities compatible with the system specification?

Are all requirements clear and unambiguous?

• Can all requirements be adequately interpreted and sufficiently detailed?


• Can all requirements be interpreted in only one way?


• Are the requirements organized and presented in a way that promotes clarity?


• Are the requirements for software structure, data base, data requirements and system/subsystem limitations clearly stated?


• Are the performance requirements stated in a manner that will support unambiguous design and test?

Are the requirements feasible?

• Are the specified models, algorithms, and numerical techniques state of the art?


• Can the models, algorithms, and numerical techniques be implemented within the constraints imposed on the system and on the development effort?


• Are the required functions attainable within the available resources?


• Are the quality attributes specified for the program achievable?


• Are adequate development and test facilities available?

Are there adequate verification and acceptance criteria?

• Are requirements stated in testable terms?


• Are acceptance criteria specified for each requirement in quantitative terms (i.e., ranges accuracies, tolerances, rates, boundary values, and limits)?


• Are the acceptance criteria consistent with use of any of the following:


• results obtained from similar computer programs


• classical solutions


• accepted experimental results


• analytical results published in the technical literature


• benchmark problems


• Is the source of each requirement or derivation shown, and are all requirements traceable to or derived from a higher level specification?

Are there sufficient quality requirements?

• Does the Functional Requirements Document include the desired quality requirements (i.e., performance, reliability, accuracy, portability, maintainability, user friendliness)?


• Are the factors that lead to quality and reliable software sufficiently well defined (i.e., modularity, structure, descriptiveness, consistency, simplicity, expandability, testability, device independence, robustness, integrity, and accessibility)?