BRD vs FRD

Business Requirement Document :
These documents are written to define the Requests of a business process or a system that needs to support a business process. These are high level documents that diectors or managements would understand, these documents can be a statement, user story or one liner.
BA needs to identify the key people who will be affected by the project. Identify project’s sponsor. They would be internal or external client. Identify the user who use the service, product and solution. Make sure that your list is complete. end-users for a product or service might be a division or department, or might be spread across different departments.

Capture Stakeholder Requirements: Find with each key stakeholders, or groups of stakeholders, for their requirements, find out the expectation the project?. Each person has a different view of the project. BA needs to understand these different perspectives and gather those different requirements to build a complete picture of what the project should be.
When interviewing stakeholders, be sepcific about what the basic scope of the project is, and keep your discussions within. We can get these information from interviewing the stakeholder or end user. another option is to use combined interviews in groups. with this BA can understand the flow between diff divisons and departments.
We can also use “use cases” : this would be scenario-based technique which will walk through the whole system or process, It helps in understanding how the system or service would work. This is a good technique for gathering functional requirements.
Building prototypes : Build a model of the system or product to give users an idea of what would be the the final product look like. Using this, stakehoder can address the issues and can identify any inconsistencies and problems.
Categorize Requirements: To make analysis easy, group the requirements:
Functional Requirements – These define how a product or service or solution should work from end-users perspective.
Operational Requirements – These define operations which must be carried in the background to keep the product or process functioning.
Technical Requirements – These define the technical issues which must be considered to successfully implement the process.
Interpret and Record Requirements: Once all requirements are gathered, determine which is achievable.
Funtional Requirement Document :
The Functional Requirements Specification

Functional Requirements should include:
operations to be performed by each screen, work-flows performed by the system, system reports or other outputs. Who would enter the data. How the system meets applicable requirements. detailed descriptions of data to be entered into the system,
The Functional Requirements Specification is designed to be read by a normal readers, who understand the system, Reader need not be an technical savy to understand the document. This document include functions of each and specific screens, work flow outlines performed by the system, business or compliance requirements. This document describes how sys should work and what the system must do. All the user requirement specification needs to be address in FRD. This document should be signed by system owner and quality assurance.

The following key fields, should be part of the this document.
Purpose of the Document
Scope
Business Processes
Functional Requirements
Data and Integration
Security Requirements
Performance
Data Migration & Conversion