Real World Business Requirements Gathering Examples

Real World Business Requirements Gathering Examples
Page content

Business Requirements Gathering

The process of business requirements gathering will ensure your project has clearly defined requirements that need to be met in order to call a project successful. Basically, a business requirements document (BRD) ensures the stage is set—for every element of the project before you begin to deal with client changes, user disappointments, team conflicts and just about anything else that could (and might) go wrong. Via the BRD, project leaders can be assured that no unexpected changes will occur, nor will they have to change game plans halfway through the project. This article will give you a few real world business requirements gathering examples. [caption id=“attachment_132825” align=“aligncenter” width=“640”]Use these business requirements gathering examples to help you better plan projects Communicating is key to proper project management[/caption] A BRD is written prior to the project scope and while they can be lengthy, once you get past your first effort, you can use the basic outline again and again. Mind Tools says all BRDs should include five key elements:

  • Stakeholders
  • Stakeholder Requirements
  • Categorizing Requirements
  • Interpret and Record Requirements
  • Signing Off on the Requirements

The Chrysler PT Cruiser

[caption id="" align=“aligncenter” width=“600”]Learn about the PT Cruiser with this business requirements gathering example Chrysler PT Cruiser[/caption]

If the Chrysler Group would have thought ahead and used a more in depth BRD before production of their PT Cruiser, they may have saved all the headaches that followed. Using the above elements, let’s look at how their BRD failed.

Stakeholders – Chrysler pretty much had most of the stakeholders identified including teams, vendors and the production of the PT Cruiser. Stakeholders that weren’t identified included the dealerships that would be selling the Cruiser and the end customer purchasing the vehicle—these two stakeholders were simply left out of the BRD entirely. An oversight indeed as perhaps these two stakeholders were the most important.

Stakeholder Requirements – Again, Chrysler did a pretty good job when it came to everyone at top levels supplying and overseeing the build. What they didn’t do was question the timeline for production (manufacturer to market), end users (customers) or dealers (sellers) on things such as price, model availability, demand and optional equipment. Had they taken the time to gather these requirements, perhaps those unforeseen delays in product delivery could have been swayed. Many consumers awaited the PT Cruiser to hit the showroom floor in models and colors presented in brochures only to find not only were the color choices slim at the get go, the vehicles didn’t arrive often until months after they were promised.

Categorizing Requirements – If Chrysler’s BRD included the requirements of all stakeholders, they surely would have discovered not only the end user needs and wants but also realized why vehicle production was delayed—in advance of production.

Interpret and Record Requirements – Here Chrysler failed miserably. If they had taken the time to actually document and analyze what stakeholders wanted, (such as vehicle availability) the many failures associated with the Cruiser may have been averted.

Signing Off – Every BRD requires signatures from project sponsors, lead stakeholders and stakeholder representatives to ensure the project will be delivered as required and requested—and on time. Chrysler also failed to do this meaning the actual money maker for the Cruiser (the customer) was left out of the picture and another important stakeholder (the dealers) were left returning deposits to unhappy customers.

If Chrysler would have utilized a well thought out BRD, this example of a process business requirements document may not have failed but succeeded on every level. In fact, Chrysler stopped production on the PT Cruiser in 2009—that alone speaks of failure.

The Apple iPad

[caption id="" align=“aligncenter” width=“600”]Business requirements gathering examples - the iPad Apple iPad 2[/caption]

Apple, on the other hand knew what stakeholders wanted and expected and succeeded in their BRD with both the iPad and iPad 2. Let’s look at the same process:

Stakeholders – Apple did a good job of keeping everyone involved including the end user and retailer—that included focus groups.

Stakeholder Requirements – The eyes of Apple developers, retailers and end users all got to participate in things like options, design, and pricing. Apple’s in-depth research was to hit the market with a product that delivered what was promised—and they did just that.

Categorizing Requirements – Apple looked at most desired features, the ability to customize, and Internet access among other elements. Stakeholders from top to bottom were pleased with the results and the iPad would become a hot ticket item.

Interpret and Record Requirements – From focus groups and developer ideas, Apple was able to find what was most important for the iPad to succeed and what could be left in the background, or as a customization option. They knew what was wanted and delivered on that promise.

Sign Off – Both developers and real end users got to test the iPad before Apple’s BRD was given the go ahead and signed off by all involved. This ensured a product that had quality, desirability, and a price that would make a profit for Apple, happy retailers and end users.

Final Thoughts on BRDs

The two business requirements gathering examples we looked at here offered two very different results. The Chrysler failure due to an incomplete stakeholder analysis left out two of the most important stakeholders causing project requirement delays and customer dissatisfaction. Apple on the other hand, took the time to involve stakeholders and their expectations and the end product resulted in a hot seller for Apple and a happy consumer. The key to successful BRDs is understanding why it’s important to get every detail, desire and requirement from all stakeholder before the game, not allowing the game to change once it’s started. Do take time to learn how to write a business requirements document and once the first one has been tackled, you can utilize your outline as a template for all future projects.


Mind Tools, Business Requirements Analysis - Meeting Image by Free-Photos from Pixabay Chrysler PT Cruiser - Wikimedia Commons/Alex Chupryna Apple iPad 2 courtesy of Amazon