Requirements Documents are used to accurately and unambiguously convey the needs of a business. A Business Requirements Document is a well-known ‘requirements’ document however there are other types of requirements documents that are also important in progressing a project through to completion. The template of a Requirement Document to be used depends upon the type of requirements that it is meant to capture. Organizations develop and adapt their own templates to suit their needs.
Business Requirements Document (BRD)
It defines the high level business goals and core functions of a product. It is prepared by a business analyst or a project manager. It contains sections to describe the project scope, functional, non-functional, data and interface requirements. It provides a good understanding of the types of users and their expectations. It presents an idea of the proposed system from the point of view of the business organization that commissions the system.
Functional Requirements Document
It describes in detail, the services provided by the system. It specifies the sequence of events, inputs, outputs, data stored and computational processes for every function. It captures the behavior of the system for every event and user action. Text descriptions are supported by wire diagrams for better understanding.
Quality Requirements Document
This document describes the acceptance criteria for the end product. It states what the end users expects from the system in terms of throughput, response time, reliability, disaster recovery, fail safe mechanisms, maintainability, accessibility, load handling capability, portability and robustness. These are also termed as non-functional requirements.
Technical Requirements Document
Software, Hardware and Platform requirements of the final product are described in this document. Software requirements state what programming language the system should be developed on, what software will be used to access the system and the type of database. Hardware requirements state the processor speed, memory size, disk space, network configuration and capacity of the application and database servers to be deployed when the system goes live (production environment). Platform requirements state the constraints on the system’s environment and the limitations on the technology to be employed while building the system. If the system is to be deployed in multiple locations, the hardware and software environment of each location is described. The document lists the limitations to be considered while designing the system architecture.
User Interface Requirements Document
It describes the look and feel of the Graphical User Interface (GUI) of the system. It defines the positioning of user input fields, messages, menus, header and footer on the application screen. It explains how the screens will be accessed by the user and the sequence of user actions for each process. It contains mock-up screen shots to give the project team an idea of what the end product will look like. It shows:
• How the content is presented to the user
• Color codes to be used
• User navigation
• Hints / tips / suggestions to be displayed to the user on the screen
• “Save data and continue operation later” options when the user has to enter a large amount of data into the system
Shortcut-keys for frequently used functions
Market Requirements Document (MRD)
It defines the needs of the end user of the system (i.e. customers of the company for which the system is to be deployed). This document is prepared by marketing managers, product managers or business analysts. It defines the system’s functions in accordance with the current market trend and expectations of the targeted customer base. It lists features that give the company a competitive advantage in the market.
