4 Primal Reasons For The Business Requirements Document

4 Primal Reasons For The Business Requirements Document Cover
Noelene Noone

May 3, 2017 in Uncategorized

Fast-forward, and the business requirements document continues to facilitate stakeholder needs, organisational decisions, project risk and business analysis.

The Business Requirements Document (BRD), in one form or another, has been around for since the business analyst role emerged, serving as a binder for all the artefacts used in the analysis of a business problem. 

In a changing world where many development workshops subscribe to the agile manifesto statement of “Working software over comprehensive documentation”, but corporate management expectations still centre around comprehensive well-documented analysis, I’ve been left with the question:

How relevant is the business requirements document in enabling business solutions today?

The fact still stands: the more things change the more they stay the same.

Whatever the business analyst speciality, and whether in a development environment set-up for Agile, Waterfall or a hybrid of the two, I’ve encountered profound rationale why the findings of a business analyst need to be captured have not changed.

Here are 4 primal reasons why we cannot shelve the business requirements document:

#1 If you don’t ask, you don’t get

Stakeholders need to know that their voices are heard. They want to see in no uncertain terms that I, the business analyst, have understood them. The business requirements document gives me the opportunity to demonstrate how I plan to meet their needs, avoiding any unwanted surprises later when we are well down the delivery path.

Defining clearly what I know my stakeholders business needs are, gives me the foundation from which to build a strong business solution, …

and brings my stakeholders into a world where they feel part of the delivery, increasing my chances of their continual support and buy-in when tough decisions need to be made.

#2 The road not travelled

You might argue whatever eventual solution your analysis reaches — whether a new process, business model or software product — the options agreed upon should be evident in the solution and don’t need to be documented in any detail. However, from my experience I’ve learned that in the longer term

… of more importance than the option taken, are the options that were discarded, the decisions taken not to pursue opportunities and the reasons given why the business did not sign-off.

Documenting requirements clearly allows the business to revisit past thinking in the future. In a fast changing business landscape, the business must be able to revisit prior options without having to redo the initial analysis.

#3 The proverbial bus

The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, from the phrase “in case they get hit by a bus”. I, as the business analyst on a strategic initiative of my employer or client, come with a risk. Life happens and I might not be around from tomorrow to continue with the analysis.

Recording the analysis journey as the solution unfolds gives the owners of the project assurance that the time and effort spent is not at risk.

It also frees me up should I want to move on to another opportunity and can motivate to my client why they can easily slot another business analyst into my spot, making my leaving a bridge-building rather than bridge-burning event.

#4 Analysis paralysis

An assignment will originate from a pressing business need and with documents to read, users to consult, processes to map out and design, systems to consider and a looming deadline it can be overwhelming to know where and how to start. When I was a business analyst young in analysis experience,

… having a business requirements document template to work from, gave me a direction with a clear deliverable, a check point from where I could operate.

Now that I have a few years’ experience behind me and I am comfortable with what is expected of me, the business requirements document serves as a guideline that helps me steer from the whirlpool of analysis paralysis.

Once a problem is solved the best solution often seems obvious and simple. By reaching the best solution, you as a business analyst would have put in the work – collecting the right information from the right sources, sifting through and collating your findings, and building your conclusion.

No matter your business analyst specialisation or the solution delivery methodology you use, the business requirements document will continue to be a trusted tool that demonstrates the process you’ve traversed to reach your findings.