BRD Vs FRD, Difference between BRD and FRD Documents

BRD Document Vs FRD Document

Let us discuss BRD Vs FRD  herre and how to to  prepare the BRD and FRD.

BRD Vs FRD
BRD Vs FRD

Documentation is the most important aspect for any Business Analyst.

The documentation is useful to understand the requirements and the detailed discussion about new features and change request if any. Business Analyst will prepare many different types of documents. Some of the important ones are listed below –

  • Business Requirement Document (BRD)
  • User Stories
  • Use Case Specification Document (USD)
  • Functional Requirement Document (FRD)
  • Requirements Traceability Matrix (RTM)
  • Product Requirements Document (PRD)

Documentation helps in understanding the business process and business events throughout the project. A Diagrammatically the documents can be pictured as a simple sheets of papers which contains some useful matter.

Let’s take a look at the similarities and differences between BRD and FRD.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Business Requirement Document

  • BRD highlights “Business Requirements” – i.e., high-level business goals of the organization developing the product or solution with the help of IT.
  • A formal document illustrating the requirement provided by the client
  • In other words it describes at very high level the functional specifications of the software
  • The requirements could be collected either by verbal or written or both
  • Created by a Business Analyst who interacts with the client
  • Entire work is executed under the supervision of the Project Manager
  • It is derived from the client interaction and requirements

The BRD is important since it is the foundation for all subsequent project deliverable, describing what inputs and outputs are associated with each process function. It describes what the system would look like from a business perspective. Following are the most common objectives of BRD –

  • To arrive at a consensus with stakeholders
  • To provide input into the next phase of the project
  • To explain how customer/business needs will be met with the solution
  • Holistic approach to business needs with the help of strategy that will provide some value to the customer

Basically, stakeholder’s requirements can be small or big. Thus it needs to be break wherever it requires and should be taken as multiple requirements.

Format Of BRD –

There are many formats or templates that the organization follows. However, it depends upon the practices that is carried in the organization. For a product based company the BRD format is different as compared to service based firms. Standard format which is followed in most organizations are shown below. It is important to note that for clear understanding of the document we should include list of acronyms used.

The BRD template contains –

  • document revision
  • approvals
  • introduction
  • business goals
  • business objectives
  • business rules
  • background
  • project objective
  • project scope
  • in-scope functionality
  • out-scope functionality
  • assumptions
  • constraints
  • risks
  • business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
  • legacy systems
  • proposed recommendations
  • business requirements
  • list of acronyms
  • glossary of terms
  • related documents

Now let us look into FRD…

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Functional Requirement Document

  • FRD highlights “Functional Requirements” i.e., functionality of the software in detail
  • Depending on the product.
  • It will describes at a high level the functional and technical specification of the software
  • Usually created by Business Analyst under the supervision of technical expert, for instance System Architect
  • In a small and medium sized organizations a BA take care of this
  • Few companies did not create FRD, instead they used BRD as it is detailed enough to be used as FRD as well
  • FRD is derived from the BRD
  • Will get sign off from the client once we prepare FRD

Actually, the process to reach the expectancy of the BRD is an FRD itself. Business Analyst will prepare the FRD after discussing with the stake holders and Project Manager. He is the person analyze the requirements, to get clarity on requirements he will conduct multiple meeting session with internal and external stake holders. And he will concentrate on below questions mostly.

  • How we develop the expected requirement(s)?
  • What are the tools and/or systems used and their dependencies?
  • What are the features and functionalities?
  • How will the customer reacts when they start using the solution?
  • Any assumptions or constraints?

Most common objectives of FRD –

  • Draw flow charts for each process flows for each activity interlinking dependencies
  • Holistic view for each and every requirements, steps to built
  • Estimating detailed risks for each new change request
  • Highlight the consequences if the project health is weak to avoid scope creep

The FRD should document the operations and activities that a system must be able to perform.

Format Of FRD –

Likewise BRD, FRD has a somewhat different format focusing more on risks and interfaces. Although there is no such standard format that a Business Analyst should opt for. Companies belonging to different domains use their own template. For instance, you would find many points would be repeating as in BRD.

But there should be no confusion for BA to prepare this document.

The FRD template contains –

  • Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, document overview
  • Methodology
  • Functional Requirements
  • Modeling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
  • Other Requirements – Interface Requirements, Hardware/Software Requirements,
  • Glossary

Now the use of BRD or FRD in organizations depends on the organization policies, practices followed by the project team and stakeholders. In my company client will share the BRD, based on the BRD we prepare FSD.

I hope now you understand the BRD vs FRD

BRD Vs FRD – Business Analyst Articles, Webinars

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

What is the difference between a BRD and FRD?

The Business Requirement Document (BRD) describes the high-level business needs whereas the Functional Requirement Document (FRD) outlines the functions required to fulfill the business need. BRD answers the question what the business wants to do whereas the FRD gives an answer to how should it be done

What is an FRD?

The functional requirements document (FRD) is a formal statement of an application’s functional requirements. It serves the same purpose as a contract. 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

What is difference between BRD and SRS?

It is obvious that BRS is the specification of the business processes and operations. Use Cases: SRS describes the interaction between the created product and the end users. It is the reason why this specification type includes use cases. … Specification sphere: SRS describes the peculiarities of the developed system

What is included in a requirements document?

Requirements documents should include these kinds of requirements: Business Requirements: Business requirements generally come from the customer of the project. They represent the product features, or what the end outputs of the project need to provide

What are two types of functional requirements?

Requirements generally fall into two typesfunctional and non-functional. The difference between them is fairly straightforward, nevertheless, in the this article we’ll define the two types of requirements and provide examples of each to point out more concretely the fundamental difference between them

What is Waterfall Methodology or Model in SDLC

What is Waterfall Methodology or Model

 

What is waterfall methodology or model
What is waterfall methodology or model

Here we will discuss about traditional software methodology Waterfall and who will involve in each phase.

Waterfall or Sequential methodology: Here next task will start once previous task completed only. We will see here in detail, what are the advantages and disadvantages of this methodology. First we will observe what are phases involved here and how it works.

Software Development Life Cycle is a framework having defined set of activities performed in phases for developing a software application or a software product.
There are different SDLC methodologies like Waterfall, Agile, Spiral, RAD, iterative Development etc..

For now we will try to understand 2 popular SDLC methodologies Waterfall & Agile. Still so many companies are using water fall methodology. And now a day’s most of the companies are looking for Agile methodology, because in Agile less documentation will be there and easy to understand. First we will observe Waterfall methodology.

The below are called as phases in waterfall methodology.  Let us discuss in details what is waterfall methodology or model and what are the phases in waterfall model.

Requirements Gathering: 

This is the first phase in Software Development Life cycle.

Generally Project manager and Senior Business analyst will participate in this phase.
In this Phase, we will identify;

  • Stakeholders of the project i.,e Technical teams, testing teams, customer team and other dependant teams
  • Technology – that will be used in the project like programming language, front end, backend (which technology to use like Java or dot Net, Database)
  • Hardware requirements, software requirements
  • High level requirements
  • High level test approach
  • High level effort and cost required for the project
  •  High level schedule
  • Project approvers
  • High level assumptions
  • Identify possible risks

We will discuss these things and document it. The phase deliverable artifact  is called Project Charter or BRD (Business Requirements document).

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Requirement Analysis:

In this Phase, we will start discussing in-detail on the high level requirements which we gathered in previous phase.

Business Analyst,Project Manager, Technical Team , Architect , Network Engineer and Data base team will participate in this phase.

  • We will conduct multiple meetings to understand the requirements like interview, Jad sessions and Brainstorming.
  • We will use the Activity diagrams, UML diagrams and flow charts to make the document clear.
  • Usually requirements’ gathering is done though meetings, phone calls, emails, virtual meetings.
  • Once document is prepared, it will be reviewed with project stakeholders.
  • We will freeze the requirements and take sign-off from the customer.
  • The Analyze phase deliverable artifact is called (FS/FRS,SRS,RTM)

Design:

First, based on the requirements we will identify and device the flow of data in the application.

Tech leads Architect, DB architect, Network Architect and UI designer will participate in Design phase.

  • Design phase will have HDD , LDD and ADD (High level design document , Low Level design document and Application design document).
  • We will determine how many tables are needed? How tables are connected? what is the expected load on the database? And all.
  • Followed by we will go to table level mappings, defining each field, like length of field, restriction for the field, unique ID’s and validations etc.
  • We will do requirement mapping to design. i.e to ensure all the requirements are covered in design or not.
  • We will document the design of application and review with Architects and we will take signoff on the design document.

Development and Coding

In this phase, developers will start coding the functionalities.
Developers will create Unit test cases and perform unit testing.
Tech Leads will do code review
Once build is complete, build will submitted to QA team for testing.

Testing :

Testing team will prepare  their test strategy after Requirements Analysis Phase. Based on Test Strategy and Requirements document, testing team will create Test cases.
Test cases will be prepared before test phase so that after Development and Coding phase Testing team can start executing test cases.
If there are any defects or bugs found, testing team will assign it to development team to resolve.
Developers will fix the defects and again give it to testers.
This cycle will go on till all the defects are resolved and application is bug free.
Testing team will publish Test report at the end of testing phase and they provide sign-off. Once we receive internal sign off from the QA team then we will release to client for testing.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

UAT:

User Acceptance Testing is called UAT. In this phase, customer or the business user will test the application functionality.


Customer will write UAT test cases and execute the cases.


If there are any defects found, they will communicate to the Business Analyst or Project manager. They will verify whether it is genuine bug or functionality gap.If it is genuine bug then they will ask the testing team and they will assign this defect to development team to fix the bug.

Once all the UAT cases are executed, customer will provide sign-off on the UAT.

Deployment/Go Live/ Implementation :

In this phase the test application will be deployed in production environment for live usage.
After implementation, project team will do a round of high level testing to ensure everything is working perfect.
Customer will do validation in production environment and give sign-off if everything is working.

Support and Maintenance:

After implementation, warranty period starts. There will be agreement with customer and project team on the warranty period. Like 3 years, 5 years from the day of implementation.
During this period, if there are any issues, project team will take care of the issues. Usually production support team will take care of production issues, if they are unable to look into the issues then they will raise ticket and assign to Business Analyst then he will verify and assign to Development team to fix the issue.
After warranty period, maintenance will start. It means, any changes or issues found after warranty, it will taken care at additional cost and time.
 
This is how software application is built and maintained in waterfall methodology. !!

Advantages of Waterfall Methodology:

  • Simple and easy to use
  • Easy to manage – each phase has specific deliverables and a review process
  • Phases are processed and completed within scheduled time
  • Works well if requirements are very clear

Disadvantages:

  • Handling change request is difficult.
  • Feedback from the client is not there.
  • There may be chance to no coordination between the teams.
  • Team work and coordination is not there
  • Continuous improvement process

Any questions are clarifications please ask me in comments section, will respond as soon as possible.

Currently most of the organizations are looking for Agile methodology but still as a Business Analyst we should know what is waterfall methodology or model.

I hope it helped you to provide overview of what is waterfall methodology or model.

To know more about what is waterfall methodology or model you can browse on google to get more idea and information.

If any other clarifications related what is waterfall methodology, feel free to post here.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

SDLC Waterfall : FAQs

What is waterfall SDLC?

Waterfall Model is a sequential model that divides software development into different phases. Each phase is designed for performing specific activity during SDLC phase. It was introduced in 1970 by Winston Royce.

Is SDLC waterfall or agile?

In Agile process, requirements can change frequently. However, in a waterfall model, it is defined only once by the business analyst. In Agile Description of project, details can be altered anytime during the SDLC process which is not possible in Waterfall method

What is difference between SDLC and waterfall model?

Different phases of the SDLC model are Requirement, Design, Implementation and Testing. Waterfall model is one of the most popular SDLC models. … This model has different deliverables from each phase.In a waterfall model, each step follows in a sequential manner without overlapping or iterative steps.

Why waterfall model is best?

Advantages of waterfall model
This model is simple and easy to understand and use. It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. In this model phases are processed and completed one at a time.

Is waterfall iterative?

In traditional, full waterfall development, a team does all of the analysis for the entire project first. … This is an iterative waterfall process, not an agile process. Ideally, in an agile process, all types of work would finish at exactly the same time

Why should I use waterfall methodology?

The advantages of waterfall development are that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

What are the disadvantages of waterfall model?

Disadvantages of waterfall model:
Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. No working software is produced until late during the life cycle. High amounts of risk and uncertainty.

Bug Life Cycle / What is Defect Life Cycle ?

Defect/Bug Life Cycle

Defect/ Bug Life Cycle

Defect life cycle also known as bug life cycle. Defect life cycle/ Bug life cycle is the journey of bug from initiation to closure during its life time. It may different from organization to organization and may project to project.

Business Analyst/ Scrum Master will monitor till closure of the defect, it may different from organization to organization.

New : During testing of the application if tester find/observed any issue then tester will raise the issue(Bug/Defect)

Assigned : Once tested raised the defect it will be assigned to the development team to fix/resolve  the defect.

Open : Development team will open the defect.

Review : Development team will review the defect, whether it is genuine issue or not.

Rejected : If development team feels it is not a genuine defect then they can reject the ticket with mention their comments.

Deferred – When a defect cannot be addressed in this cycle then it is deferred to future release.

Duplicate: Development team will mark as a duplicate if it is duplicate defect means which is already raised previously.

Fixed : If development team identifies as it is genuine bug then team will fix the issue. In some organizations once, developer fixed the code development manager/team lead will review the code, whether it is impacting any other functionality or not. And they fixed the issue again they will assign to testing team for testing.

Retest : Testing team will test the defect which is assigned by development team.

Close : If testing team feels defect is resolved then they will close the defect ticket.

Reopen : If testing team feels still issue/defect not resolved then again they will reopen the ticket and assign back to development team to resolve the issue, again same cycle will follow.

I hope it helped you to understand  Defect Management Life Cycle 

Defect/Bug Life Cycle in Software Testing

 

error

Enjoy this blog? Please spread the word :)