Significance of BRD (Business Requirement Document) & FSD (Functional Specification Document): StraQuappians are professionals withextensive expe...

Significance of BRD (Business Requirement Document) & FSD (Functional Specification Document): StraQuappians are professionals withextensive expe...: StraQuappians are professionals with extensive expertise in planning and implementing Information Technology, System Development & M...

StraQuappians are professionals with extensive expertise in planning and implementing Information Technology, System Development & Maintenance's, Project handlings, Networking Solutions & Client/Server Applications. StraQuapp follows professional behaviour to assist project management and project implementation. To step into a new project, StraQuapp analysis the requirement of the customer & provide an approach by considering many factors, that’s on required functions, volume of transactions, Integrations etc. Based on customer business specifications and requirements, StraQuapp steps forward to create BRD (Business Development Document).  

StraQuapp Inc., Our company name explains the meaning that we provide. STRATEGICALLY QUALIFIED APPLICATIONS! That's "THE STRAQUAPP TECHNOLOGIES”.

Initial step we build is BRD, for our customer requirement. To finalise the business process between the StraQuapp and the customer, BRD assist the whole project implementation. Our BRD gives us opportunity to improve involvement in making reasonable estimates of how big a project is and how much it is going to cost.

StraQuapp business requirements are the activities which must be performed to meet the organisational objective while remaining solution independent. In Straquapp there are many different names for tools used with this process: business needs specification, requirements specification, business requirements etc..

Importance of StraQuapp’s BRD (Business Requirement Document):
StraQuapp’s BRD is a document which explains the business requirement in detail for a project that consist of both functional and nonfunctional requirements which lead to creation of software product. 

StraQuapp’s BRD is a document which explains the business requirement in detail for a project that consist of both functional and non-functional requirements which lead to creation of software product.

There are many variants of BRD known to people like SRS (System Requirement Specification) or SRD (System Requirement Document) & In StraQuapp, BRD describes the requirements by business in comprehensive way of explanations with flow charts  & It has to be approved by business owners to proceed further for development of system.

Main aim of BRD are as follows:

1. BRD should be very simple and the document covers all the customer viewpoints & should be agreed by the customer.
2. It contains more business requirements rather than technical requirements as the main motto of straQuapp BRD is to deal by describing the customer requirement about the project and BRD will not speak about how they accomplish.
3. StraQuapp describe the business needs in clear and brief manner.
4. StraQuapp will have a logical flow and can be used as an input for next phase of the project.

The BRD is most often used in development of software application. It describes business needs and goals, the processes required to meet them and the key operational and environmental factors that influence what the software is built upon. It is generally accepted by the customer.

• BRD is used to provide an appropriate solution to meet the customer or business needs.
• To provide input between the phases of the projects.

What StraQuapp BRD (Business Development Document) Covers:   

StraQuapp’s BRD gives a detailed view of how the business processes should be mapped into business Document. BRD includes scope of the project, business operations, work-flow and requirements for the Business implementation.

StraQuapp Business Requirement Document includes the following key sections:

1. Version Approval
2. Project background.
3. Business goals and objectives 
4. Requirement Scope  
5. Functional Requirements
6. Data Requirements 
7. Non-functional Requirements
8. Interface Requirements 
9. Business Glossary or Definitions
10. Dependencies of existing systems and Assumptions

Version & Approval

StraQuapp specifies and maintains the version. In all the StraQuapp BRD documents, certain process are followed. BRD Document should be approved and accurately reflects the current understanding of business requirements. Requirement changes will be managed by the project’s change management process including analysis, appropriate reviews and approvals.

Project Background

Before developing the project background, StraQuapp will undertake tremendous research. We carry out field research, communicate to the customer and refer to relevant topic about the project area(R&D). When we have collected enough data or research material, we develop and write up about the general situation of the project area and its collectivity.

The software requirements will be agreed as request and addressed in the requirements document. This document does not include screen layouts, database schemes, descriptions of communication layers.
Business goals and Objectives:
This document defines the high-level requirements. It is used as basis for the following activities:

1. Creating solution designs
2. Developing test plans, test scripts and test cases.
3. Determining project completion.
4. Assessing project success.

Requirement Scope:

In BRD the requirement scope has well defined requirements. The document can serve as a basis for an agreement between the StraQuapp and the customer and it can be used by the developers and testers to implement the application and it should be verified frequently to meet the original agreement.

Functional & Data Requirements:  

Functional requirements describe the intended behaviour of a system including Operations, Input & Outputs and the properties of the systems. 

Non-Functional Requirements:

Non-Functional requirements covers overall requirements which are not covered by the functional requirements. They specify criteria that judge the operation of a system rather than specific behaviours.

Ex: Modified data in a database should be updated for all users accessing it within 2 seconds. Some typical non-functional requirements are: Functional requirements covers overall requirements which are not covered by the functional requirements. They specify criteria that judge the operation of a system rather than specific behaviours.

Ex: Modified data in a database should be updated for all users accessing it within 2 seconds. Some typical non-functional requirements are:

• Performance – for example Response Time, Throughput, Utilization, Static Volumetric
• Scalability
• Capacity
• Availability
• Reliability
• Recoverability
• Maintainability
• Serviceability
• Security
• Regulatory
• Manageability
• Environmental
• Data Integrity
• Usability
• Interoperability

Interface Requirements:

In the interface, we describe what can pass between the system and the environment.  The implementation can be defined as the system minus the interface.   The types of interfaces used can affect the amount of technical debt that is created and programmer productivity.

For Ex: In the software solution capture data regarding customer transactions; this information is required for accounting and sales systems. The methods of interfacing with back-end systems may vary depending on the desired level to control. This is the interface requirements which mostly will be shown in the diagrammatic forms.

Business Glossary or Definitions:

Business Glossary increases the return on data by providing a common business vocabulary across the organisation. This vocabulary removes ambiguity from conversations, reduces errors, speeds up project delivery cycles and enables the delivery of trusted data in support of informed business decisions and processes.

FSD (Functional Specification Document):

Before start working with the specified project, there should a clear idea of what the project is to accomplish and what the system we are going to implement.  We should get some “high-level” goals and objectives and some “requirements” from the users of the system.

FSD goals, objectives and requirements specifies what the project to be accomplished, but generally users may not give the sound basis for planning and executing the project. Initial set of information should be translated into functional requirements which are statements of the things, the system we’re implementing must do, with enough detail to guide while designing a system that meets those requirements.

Functional Specification Document serve as the basis for the system to be built.  They help to:

• Determine whether to build a system component.
• Interface subsystems or components.
• Conduct performance testing of subsystems and systems.
• Conduct acceptance testing of the final system.

StraQuapp “Functional Specification Document” used to define enhancements to existing systems and to develop statements of work for customers.  When comparing the functional requirements for an enhanced version of a system to its existing capability, FSD helps to develop a migration plan or route to follow while implementing the desired enhancements.  FSD has three key types of system requirements usually developed in addition to functional requirements. They are:

• Performance requirements.
• Interface requirements.
• Human-Machine interface requirements.

Difference Between BRD and FSD:

BRD (Business Requirement Document).	FSD (Functional Specification Document).
BRD define the requirements of a business process.	FSD Defines "how" the system will accomplish the requirements by outlining the functionality and features that will be supported by the system.
The BRD contains the business requirements that are to be met and fulfilled by the system under development.	FSD system will be described in logical terms so that the FSD is technology and platform independent.
The BRD is often important later if analysts or developers have questions regarding the purpose or validity of the requirement.	FSD gives the architects and developers more freedom in making development and design decisions about the physical design of the system.
The Logical basis can be used to support the need for the business requirement or clarify ambiguous language by providing a context for the requirement.	FSD’s include screen mock ups or wire-frames for communicating the layout and design of the system screens.

Conclusion:

StraQuapp hope this paper gives you some ideas about structuring the next requirements document you will work on. But this is just a very brief introduction to the subject of requirements engineering. Below I am providing of my favourite books to start off your reading. In addition, we strongly recommend books by Gerald Weinberg who does a lot of work in the area of systems analysis.

Prepared by JoyBaby

Senior Software Test Engineer

StraQuapp Technologies.