We, the IT and business people, are usually more comfortable with concepts that can be given an exact definition than with some vaguely defined ideas which complicate our communication and reduce our productivity. The usage of Business Requirements Document (BRD) vs. Functional Requirements Document (BRD) [or] Functional Requirements Specification (FRS) is a clear example where such miscommunication creates a quite a bit of confusion.
Chiron Business Solutions made a study of over 30 samples of documents with either BRD or FRD/FRS titles maintained by reputable IT organizations (most of them being part of Fortune 500 companies) and found out that there is absolutely no agreement in the industry as to which document should contain which information and to which extent of detail. The main topics covered by the above documents were: Problem/Solution Statement, Current/Proposed Business Process, Risks, Functional Requirements, GUI, Non-Functional Requirements and Data Requirements. The confusing part is that, regardless of the name, the content of those documents was pretty much the same. Therefore, here comes a question, what is the principal difference between BRD and FRD/FRS?
Since this question falls into the subject of Business Analysis, we thought that the best resource for clarification would be the Business Analysis Body of Knowledge (BABOK), maintained by the International Institute of Business Analysis. We started by looking at their definition of the BRD. According to the BABOK, a Business Requirements Document is a requirements package that describes business requirements and stakeholder requirements. To get to the bottom of it, we also need to understand the definition of business and stakeholder requirements, so here they are:
Business Requirement – a higher level business rationale that, when addressed, will permit the organization to increase revenue, avoid costs, improve service, or meet regulatory requirements.
Do any of the topics mentioned above sound like a good fit to be included in a BRD? Not really, with the exception of Current vs. Proposed Business Process and, possibly, Risks.
Now, let’s see what a stakeholder requirement means:
Stakeholder requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and various categories of solution requirements.
“Bridge” does not mean the actual solution requirement. It means some transitional information. We still need yet another definition to understand the meaning of a solution requirement:
Solution requirement – a characteristic of a solution that meets the business and stakeholder needs. May be subdivided into functional and non-functional requirements.
Based on these definitions, here comes the moment of truth – solution requirements (i.e. functional and non-functional ones) are NOT the same thing as business/stakeholder requirements. The former should go into the FRD and the latter – into the BRD (which is a collection of high level business needs and is not meant to provide detailed requirements). Whether or not a project needs both, BRD and FRD, depends on its complexity, but it is important to understand the purpose of each one.
Going back to our study, most of the documents that were called BRD were in fact FRD because they contained such things as behavior and information that the solution would manage, i.e. functional requirements. Calling them the wrong name would not really be a big issue as long as this misconception was consistent across the industry. The bigger problem is that, unfortunately, the formatting and contents of those documents are so dramatically different from one organization to another that it makes it very challenging to discuss your understanding of this documentation once you go outside of your particular organization.
BRD/FRD questions have become pretty popular during BA interviews, and answering them becomes a guessing game because it is very hard for you to know what your potential employer considers to be a good definition of BRD or FRD.
Our advice to BA candidates would be to stick to the BABOK definitions (as this is the only industry recognized organization attempting to streamline BA knowledge) and to try to talk through your understanding of the actual concepts (i.e. business requirements and solution requirements) versus how they can be packaged inside a particular document. It is important to let your interviewer know that you are aware of various types of documentation, and your solid knowledge of the above types of requirements and their corresponding usages will help you allocate them properly to the documentation templates used by your prospective employer. Most organizations would expect a Business Analyst not to stop at the business requirements point, but to take them one step further to the solution requirements level. Therefore, you should be equally comfortable discussing both requirements groups to succeed in the interview.