Functional Requirements Document
The Functional Requirements Document (FRD) is a formal statement of an application’s functional requirements. It serves the same purpose as a contract. Here, 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.
Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. The document should be tailored to fit a particular project’s need. They define things such as system calculations, data manipulation and processing, user interface and interaction with the application.
The Functional Requirements Document (FRD) has the following characteristics −
It demonstrates that the application provides value in terms of the business objectives and business processes in the next few years.
It contains a complete set of requirements for the application. It leaves no room for anyone to assume anything which is 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.
The functional requirement should include the following −
Descriptions of data to be entered into the system
Descriptions of operations performed by each screen
Descriptions of work-flows performed by the system
Descriptions of system reports or other outputs
Who can enter the data into the system?
How the system meets applicable regulatory requirements?
The functional specification is designed to be read by a general audience. Readers should understand the system, but no technical knowledge should be required to understand this document.
Functional Requirements Deliverables
A Business Requirements Document (BRD) consists of −
Functional Requirements − A document containing detailed requirements for the system being developed. These requirements define the functional features and capabilities that a system must possess. Be sure that any assumptions and constraints identified during the Business Case are still accurate and up to date.
Business Process Model − A model of the current state of the process ("as is" model) or a concept of what the process should become ("to be" model)
System Context Diagram − A Context Diagram shows the system boundaries, external and internal entities that interact with the system, and the relevant data flows between these external and internal entities.
Flow Diagrams (as-is or to-be) − Diagrams graphically depict the sequence of operations or the movement of data for a business process. One or more flow diagrams are included depending on the complexity of the model.
Business Rules and Data Requirements − Business rules define or constrain some aspects of the business and are used to define data constraints, default values, value ranges, cardinality, data types, calculations, exceptions, required elements and the relational integrity of the data.
Data Models − Entity Relationship Diagrams, Entity Descriptions, Class Diagrams
Conceptual Model − High level display of different entities for a business function and how they relate to one another.
Logical Model − Illustrates the specific entities, attributes and relationships involved in a business function and represents all the definitions, characteristics, and relationships of data in a business, technical, or conceptual environment.
Data Dictionary and Glossary − A collection of detailed information on the data elements, fields, tables and other entities that comprise the data model underlying a database or similar data management system.
Stakeholder Map − Identifies all stakeholders who are affected by the proposed change and their influence/authority level for requirements. This document is developed in the origination phase of the Project Management Methodology (PMM) and is owned by the Project Manager but needs to be updated by the project team as new/changed Stakeholders are identified throughout the process.
Requirements Traceability Matrix − A table that illustrates logical links between individual functional requirements and other types of system artifacts, including other Functional Requirements, Use-cases/User Stories, Architecture and Design Elements, Code Modules, Test Cases, and Business Rules.
