Customers want what they pay for. Businesses want satisfied customers. This simple mantra fits into all elements...
of the business world.
From an IT perspective, organizations expect software they purchase to work in the way it's promised from the company they bought it from. And the business expects that its product will result in a satisfied customer.
An IT organization must have clear and comprehensive documentation that sums up -- in business terms -- what it should deliver to a customer. The team can fulfill that demand with a business requirements document.
Let's evaluate the role of a business requirements document (BRD), how Agile and non-Agile teams convert requirements into working code and how to determine if the team fulfilled business requirements.
How a BRD sets expectations
A BRD describes the business purpose for a project. It defines how to produce the product, including its objective, how it works and the client's intended use. With a BRD, a business can assess potential cost factors and constraints, and a timeline or schedule for the software project. A BRD represents a basic contract between the customer and the vendor; it outlines the expectations and deliverables for the project. Additionally, it sets the standards for project success.
Before any IT organization builds an application for customers or business stakeholders, it should understand how to create a detailed BRD, particularly for Agile teams to use.
A BRD template for Agile teams
Business requirements documents can take on various structures. However, a successful Agile BRD should contain these key 10 components:
- project overview;
- success factors;
- project scope;
- stakeholder identification;
- business requirements;
- scope of the solution;
- functional requirements (optional);
- project constraints (such as schedule and budget);
- quality control measures; and
- schedule, timeline and deadlines.
How functional and business requirements differ
Although the terms are often used interchangeably, business requirements are not the same as the functional requirements for a project. The business requirements describe the deliverables customers need, but not how to accomplish them.
The functional requirements cover how to meet customer expectations with a software product. There can be separate software requirements documentation for development projects or a functional requirements section in the BRD. These functional requirements detail how a system should operate to fulfill the business requirements.
How to use BRDs in Agile development
In Agile, the product owner or customer representative typically defines product features. The features are considered an epic in Agile, and these epics encompass everything defined in the BRD. The Agile project manager works with the product owner to translate the BRD into a series of epics that define the product. These two then translate features to user stories. Here, developers meet the functional requirements to fulfill the business requirements.
A user story briefly describes something of value to a target user -- or customer. Here's an example of the user story format:
"As a <type of user/role>, I <want/desire to>, so that <some reason/benefit>."
The user story also includes acceptance criteria, which describe what the function must achieve, and how developers can determine if the user story succeeded or failed.
Many development groups further break down user stories into tasks and/or sub-tasks that focus on different components of the system. For example, tasks cover work on the UI, the back end or database that the development team needs to finish to complete the story.
How to manage BRD changes
Many non-Agile teams use a well-defined configuration management process to track a project's requirements. This process uses automated requirements management tools to cross-reference each requirement developers use to create a traceability matrix. This matrix helps confirm that the development team addressed each requirement and that development only creates artifacts tied to requirements. Management of the documents and requirements is the responsibility of a configuration control board.
In Agile, the team maintains the relationship between the top-level product feature and the lower-level development tasks via a parent/child relationship. The Agile project manager and product owner tie all user stories to their parent epic, and all tasks and sub-tasks connect to their parent user story. This inherent relationship and flow allow the Agile project manager to easily track its progress. The setup also allows the product owner to manage or reorder work based on initial and changing priorities.
How to react to business requirement changes
Customers can make requests for changes (RFCs) and vendors can accordingly write and approve revised business requirements. However, RFCs can mean additional costs and longer timelines for development teams. Also, managing these changes is different in Agile and non-Agile development.
Teams in Waterfall and other development styles often actively control prospective changes to business requirements documents via the change control board. This body preapproves requested changes and sometimes also confirms that approved changes were made based on customers' specifications.
Changes in Agile take form as either additional epics or additional user stories based on the scope of the RFC. A control board doesn't exist in Agile teams, and the product owner -- who works in conjunction with the development team -- fulfills that role. As the client or development stakeholders agree on feature changes, the Agile team writes new user stories that the product owner must prioritize in the backlog for developers. Afterwards, the development team should review those stories in backlog grooming sessions and create any necessary tasks. The BRD traceability matrix is inherent in the parent/child relationship between epics and stories.
How to measure completion of business requirements
Agile teams measure success at each level in the development process.
At the release level, the product owner continuously makes tradeoffs in scope, date, budget and quality as a stream of economically important information arrives during product development. Ultimately, Agile teams can measure success at this level by the on-time delivery of product features that the product owner committed to deliver.
To get to that delivery, the Agile team must accomplish the tasks, complete the user stories and acceptance test each feature. At the task level, unit tests on code verify that it meets the threshold necessary to commit. At the user story level, team members use acceptance criteria to determine if they satisfied the specific aspect of the feature. When developers complete all the user stories successfully, the team can then perform user acceptance testing on the epic or feature.