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.

Live from RESFQ: The Requirements Object Model (ROM), part 3

Today we have an example to illustrate what I’ve said in the past two posts from Tuesday's setup for the ROM and Wednesday's definition of the ROM.

Let’s say in this scenario we have an online gaming company that historically has only built complex role-playing games. Now let’s say the head of product management wants to build a Yahtzee game. Here’s the process to go back and figure out what the problem is that someone thinks Yahtzee will solve, working our way to the top until we get to a Business Objective.

Note the problem at the top of this diagram finally becomes one that relates to money: The competition is still growing and we aren’t. And the business Objective can now be written to quantify the desire: 25% growth in markets other than 15-30 year olds.

Now that we have a business objective, we can define strategies. There may be 5 or even 100 business strategies and someone must select the ones to be implemented. In this case, 2 possible strategies include building a game for 7-13 year olds and advertising to the retirement community. Out of that, we can believe that Yahtzee is a valid product concept, as long as they develop it to target that 7-13 year old user group.

Finally, we can complete the rest of the ROM by crisply defining our product concept (Online Yahtzee), success metrics (7-13 year olds rate the game fun), and guiding principle (create a social environment). Then we can take on the fun task of defining features that fit within this definition.

If you follow this approach, you will have a constant guide in your Business Objectives to ensure that you are creating features that you need, but only features that you need, to achieve the business value of the project.

Live from REFSQ: The Requirements Object Model (ROM), part 2

What follows is our ROM defined. For context, you can see yesterday's post on why we have a ROM now at Seilevel.





Definitions for the items in the ROM hierarchy:

• Business Problem: Describes a problem to be solved.
• Business Objectives: Desired metrics the business seeks to meet in order to solve the problem.
• Business Strategy: Approach to meet the business objectives. It is not specific to any one product or project solution.
• Product Concept: Proposed solution to follow the business strategy to accomplish one or more business objectives. This becomes a project.
• Success Metrics: Statements about the specific desired outcomes to meet the business objectives.
• Guiding Principles: The approach to meet the success metrics for the product. Common themes to be considered in creating a product. These will drive the feature set and specific requirements.
• Product Features: A collection of functionality that provides a set of services to the users.
• Product Qualities: A collection of desired qualities about the product.

Features and Qualities are derived from business objectives.

The important thing is that your features should trace from your Business Objectives. And in the end, if you cannot make this leap directly, then you use the product concept, success metrics and guiding principles to help define them.

To that point, most projects actually start with a product concept. The team might define success metrics (i.e. a launch date). But they quickly jump in to defining features and qualities and then requirements and design. There are no agreed upon Business Objectives and development strays from the intent of the project. If we lived in a perfect world, we could start with the business level problem and objectives, then define the product level, and out of that define the product requirements. But having worked with many customers, nothing is ever this clean.


So instead, we suggest you do start with a product concept if you have one, and put any pre-defined features aside. Then work back up from the product concept to understand what problem it is supposed to solve. Continuously ask “why is that a problem?” until you find a problem that relates to money and write your Business Objectives at that level. We make it this simple so that you clearly know if you have gone high enough to say you have defined Business Objectives. The reality is that most (if not all) businesses exist to make money so all of their objectives relate to that goal – either in the form of increasing revenue or decreasing costs. Before I go on, I will say that every time I speak about this topic, someone gasps in the audience when I make this claim. That said, we have yet to see a project that doesn’t relate to money (and that’s not to say they aren’t doing other good things too!).

Once you have good Business Objectives, you can determine appropriate strategies to meet them. These strategies may or may not include building software products. But if they do, then you write a clear product concept that may or may not look like your original one. Then you continue through the ROM, developing success metrics and guiding principles for the product. Again, realize that the features may have changed from the original suggestions, in order to map back to actual objectives.

A quick example for today, but tomorrow I’ll give a more complete example:

• Proposed feature: Online training
• Problem question: Why do we need online training?
• Problem answer that relates to money: Online training leads to more trained users. More trained users leads to more sales. Now we can relate this to revenue!

Live from REFSQ’09: The ROM, Experiences with a Requirements Object Model

What follows is a summary of the paper I wrote with James Hulgan (also from Seilevel) and presented at REFSQ’09 last week. The paper is titled “Experiences with a Requirements Object Model”. You can get the actual paper here.


Most software projects we’ve seen develop features that don’t add value or they don’t build what they actually do need in order to achieve the intended business value. This leads to project that are over budget, late, and often canceled because they don’t really satisfy the needs. Fundamental to this, most project teams don’t know the Business Objectives that tell them why they are doing the project in the first place, so it’s not surprising they have a hard time picking the right features to develop.


Business Objectives are hard to elicit. When teams get an answer like “increase profitability” they are complacent to stop there because they don’t want to or know how to push people to give the hard answers.


Our paper discussed the basic terminology as described by many industry experts to describe this “thing”. They use business objectives, goals, needs, business requirements, user requirements, etc. And there are subtle differences behind each of these from person-to-person. But for our work, we are using “Business Objective” to mean: the desired metrics the business seeks to meet in order to solve the business problems.


Terminology is just a small part of the problem, but the bigger issue is this: If you ask a project team why they are doing this project, they often have no concrete idea. They may have a vague phrase associated with it such as “We are reducing operating costs”. Sometimes we hear them say that they are sure the executives know because there was a business case developed – but the project team has not seen it. It’s as if you can develop the business case, start the project, and never need to look at it again. And this is where the problem lies. The Business Objectives, probably in that very business case, should be driving the feature set developed.


We were looking for a model to use to identify and represent these, as well as to train our people on to elicit them. Out of that came the ROM – Requirements Object Model.


Tune in tomorrow for a description of the ROM!