BRD vs. Functional Software Requirements

Business requirements vs Functional requirements

We often get the question asking “what is the difference between business requirements and functional requirements?” In prior posts I have discussed that these distinctions are actually artificial and are artifacts of an organization structure that requires people in “the business” to produce a “business requirements document (BRD)” vs. some other group that will produce a “system requirements specification (SRS)”. The difference ultimately is just the level of detail. But given that we do have to live with BRD’s and SRS’s, how do we decide what goes into each document?

As you may know, at Seilevel we use a model called the Requirements Object Model (ROM) which describes a hierarchy of business needs and features. At the top of the hierarchy we expect a statement of Problems, Objectives and Strategies that tie directly in to corporate strategies. At the bottom of the business level, we expect specific Problems, Objectives and Strategies that drive a particular program.

To determine what goes into the BRD and what goes into an SRS, the best place to start is by thinking in terms of who uses the BRD vs. the SRS and what decisions do they need to make from it. If you think of a typical process model, executives must be presented with information following each phase to determine if the project should continue. Based on the information gathered in each phase, the team presents a summary to the executive who decides whether to proceed. This model can easily be incorporated into an agile or iterative approach which I will cover in another blog post.

Select – Executives are presented with a number of possible projects with conceptual business cases. Based on the corporate strategy and the value of the businesses cases, they select which projects get tentative funding based on a very high level view of the product concept.

Envision – The team gathers more detail around the problems the business is experiencing, the features to solve them and the final business case. The development team uses this information to construct a high level estimate of the total cost. Based on the cost and the return specified in the business case, executives decide to go ahead to the next phase.

Plan – The team creates a detailed set of specifications and design along with a release plan for what will be released when. Based on this, the executives determine, based on the timing of achieving the value, whether the project should proceed.

Build – The team begins building. Exit criteria are based on the level of quality and the value of the features actually implemented. Executives review the business case in the context of the features actually implemented and decide to proceed based on this information.

Deploy – The project can only be declared a success once metrics have been collected to determine if the business value was actually achieved and the business case met.

In this model, the purpose of the BRD is to provide executive stakeholders with enough information to determine if the project has a sound business case. This means that finance needs to understand the features well enough to assign a dollar value on the return and IT needs to understand the features to create a design concept that allows initial sizing of the project.

The purpose of the SRS is for IT to perform an accurate sizing and create a delivery schedule. Based on the delivery schedule, the business case can be reevaluated to determine if the project should go forward.

The BRD should focus on linking features to the business case to enable executives to determine whether the business value warrants more study and to set overarching priorities of features. The SRS should focus on linking features to the design to so that executives can determine if the value can be achieved in a timely fashion and at an acceptable cost.