How To Write a Business Requirements Document (Template Included)

By Kat Boogaard, March 18, 2021

https://www.wrike.com/blog/how-write-business-requirements-document/#Business-requirements-document-example-and-template

Research shows that 11.4% of organizational investments go to waste due to poor project performance. So, how can you avoid being part of that frightening statistic?

The key to a successful project is a thoughtful and well-written business requirements document (often abbreviated as a BRD).

What is a business requirements document (BRD)?

So, what is a business requirements document? It clearly defines everything that a project entails. It considers all facets of the project, including the expected outcomes and the key stakeholders.

This document outlines what’s needed to reach the intended project objectives. When it’s done well, it should be so self-explanatory that it removes any ambiguity associated with the project work. Nobody is left guessing — everything they need is listed in the business requirements document.

In a paper for the Project Management Institute (PMI), Paul Burek emphasized that business requirements are the “what” — what an organization wants to do upon completing a project. The requirements define the changes that will come as a result of the project work.

While it might sound overly-formal, a business requirements document is a critical element to ensure alignment among all parties involved.

What information do you put in a business requirements document?

Now that we have a loose overview of what this document is, let’s dig into the nitty-gritty of what goes into it.

Business requirements documents are similar to other formal documents such as requests for proposals (RFPs) and client contracts. With that in mind, they often include:

• An executive summary: Write this summary after completing the rest of the document. This high-level section should outline the project requirements and should summarize the following contents of the document.

• Project objectives: Describe the project’s goals and objectives and mention what the work will achieve. What are the outcomes? How does the project align with the goals of the business? To simplify this product management roadmap and ensure it’s succinct, use the SMART system for project objectives.

• A needs statement: This is where you make your case as to why the project is needed. Providing rationale and garnering support from stakeholders and employees is a great way to build rapport with your peers before diving into the rest of the project.

• Project scope: Why is scope management important? Successful projects communicate the work scope from the beginning and stay within the defined boundaries unless otherwise instructed. Clear project scope will help you avoid dreaded scope creep. Find a scoping document template that works for you to clearly lay out your project scope.

• Requirements: After requirements gathering with key stakeholders, you’ll need to summarize all of the project’s requirements in this section. Be mindful of high-level requirements like the “what,” as well as technical requirements like the “how.”

• Key stakeholders: Identify the stakeholders involved in the project and lay out their roles and responsibilities. Who will do the work? What are the expectations of each stakeholder? Will the business need to hire any additional resources?

• Schedule, timeline, and milestone deadlines: Detail the project phases in this section, carefully outlining what is required and when. Create timelines and account for dependencies, as well as unforeseen challenges that could arise.

• Cost-benefit analysis: Your cost-benefit analysis is where you’ll capture the associated costs involved in the project along with the expected benefits to help you build a case for return on investment (ROI) of the project.

How to write a business requirements document

There’s no denying that there’s a lot that goes into this document. But, writing business requirements and adding them to a business requirements document doesn’t have to be an overwhelming challenge. Follow these tips for writing your own.

1. Start by learning from previous successful projects

If starting this document feels daunting, spend some time reviewing successful past projects completed within the organization.

Look at the documentation associated with these projects and use your insights to outline your new business requirements document. Some elements to consider as you review previous documentation include:

• What worked well

• What didn’t work

• Hurdles the project team had to overcome

• Dependencies that might affect your current project

• Elicitation methods used during the requirements gathering phase

2. Capture your requirements

Here are the meat and potatoes of this process: gathering requirements. This may consist of many different types of requirements ranging from high-level to technical.

Ultimately, your business requirements document won’t be effective without gathering and capturing all stakeholders’ requirements accordingly.

"A Guide to the Business Analysis Body of Knowledge" (BABOK® Guide) identifies commonly used requirements elicitation methods, including:

• Brainstorming: Bring your stakeholders together and elicit ideas and themes for the project. This particular method may be beneficial if there are multiple solutions identified.

• Document analysis: Review all existing documentation pertinent to the project, including previous documentation for successful projects.

• Focus groups: Identify stakeholders to gather input from them on a smaller scale. You can dig into the proposed solutions further with pre-determined stakeholders than you would in a brainstorming session.

• Interface analysis: This elicitation method is particularly beneficial for software solutions and involves user interactions with an application.

• Interviews: One-on-one interviews are a popular way to gather input for requirements. Hone in on the stakeholder’s thoughts and perspectives related to the project and potential solutions.

• Observation: This method of elicitation is beneficial when revamping a process or workflow. When observing a worker’s process or workflow, be mindful not to interrupt them. Instead, ask them to review your documentation post-observation.

• Prototyping: Using a prototype is a great way to ensure that the current requirements meet all stakeholders’ needs. Prototypes can illustrate how a solution might work and help determine if requirements should be altered.

• Requirements workshops: Conduct collaborative workshops with your stakeholders to outline requirements together. Workshops generally have more direction than brainstorming sessions with pre-determined asks of each stakeholder specified at the beginning.

• Surveys/questionnaires: Surveys and questionnaires can help if you’re looking to obtain feedback from a larger group of stakeholders. Question design is important, so be sure to determine how best to pose questions to gather the information you need.

Don’t worry — it’s certainly not essential to use all of the techniques mentioned above. Instead, identify which ones will work best for you and your current product specifics. Throughout the project lifecycle, ensure you listen for impacts to the requirements defined at the beginning of the project and address them as needed.

3. Add visual elements to make content more digestible

Visuals and surrounding context can increase your plan’s effectiveness and break up text-heavy chunks of information.

Research indicates that 65% of the population are visual learners, which means incorporating visuals in your document can help you convey your message and plan in a more compelling way.

For example, a business process diagram is a typical visual seen in a business requirements document. Mapping out business processes in their current state versus the proposed future state can help communicate requirements with ease.

4. Ask team members to review your document

Once you’ve finished your business requirements document, ask stakeholders to review it and validate it. This provides the opportunity for you to confirm you’ve captured all of the requirements accordingly and offers a chance for stakeholders to provide feedback and make changes before the project begins.

As an added bonus, completing a review process also contributes to overall alignment, setting your team up for success from the get-go.

Business requirements document example and template

We’ll admit that all of this can feel a little complex and academic, so let’s walk through a basic requirements document example.

Imagine that your organization wants to find a way to better track employee performance and key performance indicators (KPIs).

For the sake of this example, let’s say there’s currently no system that allows employees to track their performance, so one will have to be selected and implemented. Here’s what a very simple document might look like for this type of project (along with some helpful tips):

1. Executive summary

Our organization is seeking a performance management system to track our overall employee performance, boost retention and morale, and increase transparency between managers and employees.

We aim to have this system launched within the second quarter and will evaluate systems, implement the system, and provide adequate training to managers and employees by June 1, 2021.

There are a number of requirements we’re looking to satisfy, including career path mapping, reporting and analytics, and goal management. A number of stakeholders will be involved in the selection and implementation of this system, including a project manager, human resources, department heads, executives, managers, and employees.

This document details the selection of this system, the objectives, needs, scope, requirements, stakeholders, schedule, and cost-benefit analysis.

2. Project objectives

Use the SMART system for your project objectives:

• We will have all 500 employees trained using our new performance management system by June 1, 2021.

3. Needs statement

Back your statement with data and research, if possible, to strengthen your position:

• A performance management system is needed to increase our employee retention rates, maintain consistency across employee development paths, boost our financial position by up-leveling our talent, and motivate and reward employees. Turnover costs our organization on average $35,000, and implementing this system will allow us to save money by retaining our employees.

4. Project scope

Clearly define what work falls within the scope:

• In scope:

  • Evaluating and selecting a performance management system
    Implementing the performance management system

  • Providing system training to managers

  • Providing system training to employees

5. Requirements

Work with key stakeholders to outline all of the requirements:

• Goal management for tracking progress

• Performance evaluation for mid-year and end of year performance reviews

• Career path mapping and succession planning

• Reporting

• Performance analytics

• Coaching and mentoring opportunities

6. Key stakeholders

Identify key stakeholders and outline their roles and responsibilities:

• Project Manager: responsible for holding all parties accountable to the project timeline

• Human Resources: will research performance management systems, gather requirements, provide a recommendation to the Executives for signoff, conduct manager and employee training sessions

• Department Heads: share desired needs with HR for a comprehensive list of requirements

• Executives: responsible for signing off on the selected performance management system

• Managers: will be trained on the system

• Employees: will be trained on the system

7. Schedule

Outline all various phases of the project along with the deadline for each phase:

• Phase I: Complete requirements gathering with all stakeholders by March 31, 2021

• Phase II: Select a performance management system to recommend to Executives by April 7, 2021

• Phase III: Onboard HR team to the new performance management system by April 26, 2021

• Phase IV: Complete training materials for managers and employees by May 3, 2021

• Phase V: Conduct manager training on May 10, 2021

• Phase VI: Conduct employee training on May 17, 2021

8. Cost-Benefit Analysis

Complete a cost-benefit analysis:

• Costs of employee turnover per team YoY

• Costs of resources needed on the project team to implement the system

• Benefits of having employees aligned to company objectives

• Benefits of legal protection for terminations

How to plan a business requirements document with Wrike

While a template and example will help make the process of creating your own business requirements document feel a little more manageable, there’s no denying that there’s a lot involved in the process.

The good news is that a collaborative work management platform like Wrike can take plenty of stress and headaches out of the process by:

• Streamlining and centralizing communication

• Easily collecting requirements from stakeholders

• Providing visibility into the process

• Breaking the document creation process into smaller tasks

Ready to create your own business requirements document? Need more product management resources? Start your free trial of Wrike today.

https://www.wrike.com/blog/how-write-business-requirements-document/#Business-requirements-document-example-and-template

Product requirements template

BY ATLASSIAN

Your pre-launch prep and post-launch progress check

Use template

As excited as you are to roll out a new product or feature, you don’t want your enthusiasm to sabotage your ability to make strategic decisions. You need to ensure that whatever you’re launching is well thought out and has a real use case. Use this template to flesh out your product requirements with your development team and product designers. The sections of this template will walk you through the assumptions you're making, user stories, UX design, scoping, and more.

How to use the product requirements template

Step 1. Cover the basics

Set the scene by using the top table of the template to lay out the details of your new product or feature. What’s your target release date? What’s the current status? Who is on the core team? You can type /date to quickly add your target release date, "/jira" to link directly to Jira epics or issues, and @ mention team members to keep everybody in the loop.

Step 2. Outline your objective and success metrics

You aren’t launching this new product or feature for the sake of doing so (at least, you shouldn’t be). In the Objective section of the template, provide a brief explanation for how this project supports your organization’s larger goals. Basically, why should this new feature or product exist in the first place? Then, in the Success metrics table, list your product or feature-specific goals as well as the metrics you’ll use to monitor your success. For example, maybe you want to simplify the user experience and you’ll know you’ve done so when your customer satisfaction scores increase by at least 15%.

Step 3. List your assumptions and options to address them

This product or feature is entirely new, which means you don’t have a ton of existing information to work off of. However, you do have assumptions – and those can be surprisingly powerful for informing your next steps. In the Assumptions section of the template, jot down any assumptions you have about your users, technical constraints, and business goals. Do you think most users will access this feature from a tablet? Note that here.

With those assumptions in mind, you’ll use the Options table to map out all of the product requirements you’ve considered. If most users will utilize this feature on a tablet, then one requirement is that you need it to be mobile responsive. In addition to stating the requirement itself, this table also has spots for you to come up with a user story (i.e., John is a PM who wants to check his team’s progress from the train station), assign a level of importance, note any Jira issues, and record any other notes you need to keep handy.

Step 4. Add supporting documentation

There’s a lot that goes into pulling together a new feature or product, and it’s smart to keep that information consolidated so everybody has a single source of truth and can find what they need. Use this section of the template to add mockups, diagrams, or visual designs related to the product requirements you’ve outlined. Having all of those in one place immediately gives everybody the context they need.

Step 5. Anticipate open questions and scope creep

Sometimes the process of launching a feature or product seems like a never-ending series of questions. As soon as you address one, five more seem to crop up. This table gives you a spot to jot down those questions as they come to you (for example, how will you make your users aware of this new feature?) so you don’t lose track of them. When you eventually come up with a suitable answer, there’s a space to record that information as well as the date that you answered it so you can track your progress and the evolution of your product.

Finally, we know that the words “scope creep” alone are enough to send a shiver down your spine, and one of the best ways to prevent it is to be proactive. Use this final section of the template to list what’s out of scope for this feature or release. Be as specific as possible (and continue adding to this section as you move forward) so that everybody knows where the line is.

https://www.atlassian.com/software/confluence/templates/product-requirements

Behaviour-Driven Development (BDD) is the software development process that Cucumber was built to support.

There’s much more to BDD than just using Cucumber.

What is BDD?

BDD is a way for software teams to work that closes the gap between business people and technical people by:

• Encouraging collaboration across roles to build shared understanding of the problem to be solved

• Working in rapid, small iterations to increase feedback and the flow of value

• Producing system documentation that is automatically checked against the system’s behaviour

We do this by focusing collaborative work around concrete, real-world examples that illustrate how we want the system to behave. We use those examples to guide us from concept through to implementation, in a process of continuous collaboration.

BDD and agile

We assume that your team are using some kind of agile methodology already, planning work in small increments of value like User Stories. BDD does not replace your existing agile process, it enhances it.

Think of BDD as a set of plugins for your existing process that will make your team more able to deliver on the promises of agile: timely, reliable releases of working software that meets your organisation’s evolving needs, requiring some maintenance effort and discipline.

Rapid iterations

We assume you would like to be able to respond quickly to feedback from your users, and do only the minimal work necessary to meet those needs.

BDD encourages working in rapid iterations, continuously breaking down your user’s problems into small pieces that can flow through your development process as quickly as possible.

Three practices

Essentially, day-to-day BDD activity is a three-step, iterative process:

1. First, take a small upcoming change to the system – a User Story – and talk about concrete examples of the new functionality to explore, discover and agree on the details of what’s expected to be done.

2. Next, document those examples in a way that can be automated, and check for agreement.

3. Finally, implement the behaviour described by each documented example, starting with an automated test to guide the development of the code.

The idea is to make each change small and iterate rapidly, moving back up a level each time you need more information. Each time you automate and implement a new example, you’ve added something valuable to your system, and you’re ready to respond to feedback.

We call these practices Discovery, Formulation, and Automation.

Discovery, Formulation and Automation

Over time, the documented examples become an asset that enables your team to continue confidently and rapidly making changes to the system. The code reflects the documentation, and the documentation reflects the team’s shared understanding of the problem domain. This shared understanding is constantly evolving.

There’s lots to learn about each of these practices. We’ll summarise each of them below.

Discovery: What it could do

The hardest single part of building a software system is deciding precisely what to build.

– Fred Brooks, The mythical man-month

Although documentation and automated tests are produced by a BDD team, you can think of them as nice side-effects. The real goal is valuable, working software, and the fastest way to get there is through conversations between the people who are involved in imagining and delivering that software.

BDD helps teams to have the right conversations at the right time so you minimise the amount of time spent in meetings and maximising the amount of valuable code you produce.

We use structured conversations, called discovery workshops, that focus around real-world examples of the system from the users’ perspective. These conversations grow our team’s shared understanding of the needs of our users, of the rules that govern how the system should function, and of the scope of what needs to be done.

It may also reveal gaps in our understanding, where we need more information before we know what to do.

The scrutiny of a discovery session often reveals low-priority functionality that can be deferred from the scope of a user story, helping the team to work in smaller increments, improving their flow.

If you’re new to BDD, discovery is the right place to start. You won’t get much joy from the other two practices until you’ve mastered discovery.

Formulation: What it should do

As soon as we have identified at least one valuable example from our discovery sessions, we can now formulate each example as structured documentation. This gives us a quick way to confirm that we really do have a shared understanding of what to build.

In contrast to traditional documentation, we use a medium that can be read by both humans and computers, so that:

• We can get feedback from the whole team about our shared vision of what we’re building.

• We’ll be able to automate these examples to guide our development of the implementation.

By writing this executable specification collaboratively, we establish a shared language for talking about the system. This helps us to use problem-domain terminology all the way down into the code.

Automation: What it actually does

Now that we have our executable specification, we can use it to guide our development of the implementation.

Taking one example at a time, we automate it by connecting it to the system as a test. The test fails because we have not implemented the behaviour it describes yet. Now we develop the implementation code, using lower-level examples of the behaviour of internal system components to guide us as required.

The automated examples work like guide-rails, helping us to keep our development work on track.

When we need to come back and maintain the system later, the automated examples will help us to understand what the system is currently doing, and to make changes safely without unintentionally breaking anything.

This rapid, repeatable feedback reduces the burden of manual regression testing, freeing people up to do more interesting work, like exploratory testing.

Learn more

Read the topics below to dig deeper and learn more about BDD.

CONFIDENTIALITY / COPYRIGHT NOTICE: This site and my information and any attachments contains the PRIVILEGED AND CONFIDENTIAL INFORMATION of Fred Finkelstein & Irondesigner DBA / LLC mutually, Inc., its affiliated corporations or legal entities, and is intended only for the use of the individual(s) named above. If you are not the intended recipient of this e-mail or invited to this site, or the employee or agent responsible for delivering this to the intended recipient, you are hereby notified that any unlawful interception, dissemination, disclosure, printing or copying of this e-mail or site or any attachments is strictly prohibited under the Electronics Communication Privacy Act (ECPA), 18 USCA 2510, 18 USCA 2511, and any applicable laws. If you have received this e-mail or viewing this site in error, please delete or destroy it & close down, including all attachments or copies, and immediately notify us by e-mail at mechanicalengrg@gmail.com