– Business Requirements –

  • Business Requirements (BRD) creation must begin by talking and listening to people.
  • Competent BA’s should be able to understand what is meant rather than stated.
  • Once understood, it falls to the BA to craft the necessary documents, stating it clearly.
  • BRDs both confirm the Client’s expectations and  provides DEV a clear path forward

Provided are numerous Business Requirement Definitions (BRDs) samples from my career, covering both Waterfall and Agile methodologies.  This includes varied projects types, including…

  • Enterprise Resource Planning (ERP)
  • Enterprise Asset Management (EAM)
  • Transportation Management Software (TMS)
  • Government Projects (DOT)

PORTFOLIO DIRECTIONS

ov

PORTFOLIO CONTENTS

agg2
(REDACTED ORIGINAL) Complete Agile Initiative Document, including Epics and User Stories, used to define an updated Sales and Order Processing platform for an automobile manufacturer.  
nona1
(REDACTED ORIGINAL) A detailed waterfall-based Business Requirements Document for an updated and expanded Alloy Specification Management platform. The chemistry required for this project made for a unique set of requirements. 

brd2

(PUBLICLY AVAILABLE)  This 300+  page BRD (available via FOIA) detailed a crucial Bridge Inspection Management System for the State of Georgia that was responsible for securing $12M in Federal funding per year. Government agencies demand far greater detail than private concerns. 

brd44

(CLIENT BANKRUPT) This is an instance of an out-of-date system, in this case an Enterprise Asset Management platform that was created during the early days of the DOT.com boom, being replaced with an upgraded version while still keeping all legacy functionality.

brd7
(REDACTED ORIGINAL)  Many industries have “choke points” in their processes that can grind the entire site to a halt if not properly managed. In this case, a company must ensure that a minimum number of “hopper cars” are on site at all times. This BRD was created to address this concern. 

REDACTION POLICY

  • REDACTED ORIGINAL:  Document edited for online display to protect sensitive data from Public view while still retaining it’s structure and form.
  • PUBLICLY AVAILABLE:  Any documents authored at GDOT are available to the general public on request and therefore are not redacted in any way.
  • CLIENT BANKRUPT: In circumstances where both sides of the dev agreement are no longer in business the documents are treated the same as OBSOLETE ORIGINAL.