Write a BRD for a Grocery Delivery App

Create a professional Business Requirements Document for a grocery delivery app.

Introduction

30 Second Summary

Every app you use started with someone figuring out exactly what it needed to do. That person is a Business Analyst, and their most important deliverable is a Business Requirements Document.

In this project, you will step into the role of a Business Analyst hired by a fictional grocery delivery startup called FreshCart. You will gather requirements, document them professionally, and produce a visual model of the system.

What You'll Build

You will create a complete set of BA deliverables for a grocery delivery platform, including a stakeholder register, interview questions, a full BRD, and a UML use case diagram.

By the end of this project, you'll have:

A Stakeholder Register identifying key project participants with their roles, interests, and influence levels.
A set of Stakeholder Interview Questions tailored to each stakeholder group, demonstrating requirements elicitation skills.
A complete Business Requirements Document (BRD) containing business objectives, project scope, functional requirements, business rules, and assumptions.
A UML Use Case Diagram created in draw.io showing actors and their interactions with the system.
Secret Mission: Add non-functional requirements and build a Requirements Traceability Matrix linking each requirement back to a business objective.

Are there any prerequisites?

No prior Business Analysis experience is needed. You only need a Google account (for Google Docs and Google Drive) and a web browser (for draw.io, which is completely free and requires no account).

Set Up Your Workspace

Every Business Analyst project starts with organized documentation. Without a clear folder structure from day one, deliverables get scattered across your drive and you lose track of what you've written.

In this step, you will create a dedicated workspace in Google Drive and confirm that your diagramming tool is ready. This gives you a clean home for every document you produce in this project.

In this step, get ready to:

Create a project folder and two Google Docs in Google Drive.
Confirm draw.io works in your browser.
Add section headings to your BRD document.

Create your project folder in Google Drive

You need a single folder to keep all your BA deliverables together. You will create the folder first, then add two documents inside it.

Open your browser and navigate to drive.google.com.
Sign in with your Google account if prompted.
Click + New in the top left corner.
Select New folder.
Name the folder FreshCart BA Project and click Create.
Double-click the FreshCart BA Project folder to open it.
Click + New again, then select Google Docs, then Blank document.
A new tab opens with an untitled document. Click Untitled document at the top left and rename it to FreshCart - Stakeholder Register.
Close this document tab and return to your Google Drive folder.
Click + New once more, select Google Docs, then Blank document.
Rename this document to FreshCart - Business Requirements Document.
Close this tab and return to Google Drive.

Your folder should now show two documents listed inside it.

Don't see both documents in your folder?

If a document ended up in your main Drive instead of the folder, right-click it, select Organise, and move it into FreshCart BA Project. Make sure you are inside the folder (its name shows in the breadcrumb at the top) before clicking + New.

Help me move my documents into the correct folder

Open draw.io

Later in this project you will create a UML use case diagram. For now, you just need to confirm that draw.io loads in your browser.

Open a new browser tab and navigate to app.diagrams.net.
A dialog may appear asking where you want to save diagrams. Select Device. This stores diagram files on your computer instead of in the cloud.
You should see a blank canvas with a shape library panel on the left side.
Close this tab for now. You will return to draw.io in Step 5.

What is draw.io?

draw.io is a free, browser-based diagramming tool. It supports UML diagrams, flowcharts, network diagrams, and more. No account or credit card is needed.

You will use it to create a use case diagram showing how different users interact with the FreshCart system.

Didn't see the storage prompt?

If draw.io opened directly to a blank canvas without asking where to save, that is fine. It means your browser remembered a previous setting or defaulted to browser storage. You can always choose File then Save As later to pick a save location.

Set up the BRD document structure

A Business Requirements Document (BRD) follows a standard structure that hiring managers recognize. Adding the section headings now gives you a skeleton to fill in during Steps 3 and 4.

Return to your Google Drive tab and open the FreshCart - Business Requirements Document by double-clicking it.
At the top of the document, type the first heading: Document Overview.
Highlight the text, then open the Styles dropdown (it shows "Normal text" by default) and select Heading 1.
Press Enter to move to a new line, then type the next heading: Business Objective.
Apply Heading 1 to this line as well.
Repeat this process for each of the remaining headings listed below.

Your full list of section headings (each formatted as Heading 1):

Document Overview
Business Objective
Project Scope
Stakeholders
Functional Requirements
Business Rules
Assumptions and Constraints
Approval

Leave all sections empty beneath their headings. You will fill them in during later steps.

Your document should now show eight bold headings stacked one after another, each on its own line.

Why these eight sections?

These are the standard sections a professional BRD contains. They cover who is involved (Stakeholders), what the system must do (Functional Requirements), the rules it must follow (Business Rules), and what limits exist (Assumptions and Constraints).

Having this structure in place before writing keeps your document focused and makes it easy for reviewers to find what they need.

Headings look like normal text?

Make sure you select each line of text before applying the Heading 1 style. If the Styles dropdown still shows "Normal text" after clicking Heading 1, try highlighting the text again and reapplying.

Help me fix my heading styles in Google Docs

Your workspace is ready. Next up, you will start filling these documents with real content by identifying stakeholders and writing interview questions.

Create Your Stakeholder Register

Your workspace is ready. Now it's time to identify the people who have a stake in the FreshCart project and document how you plan to gather their requirements.

A stakeholder register is the first deliverable a Business Analyst creates on a new project. It maps out who cares about the project, how much power they have, and what they need from the system. Without this map, you risk building features nobody asked for or missing a key decision-maker entirely.

In this step, get ready to:

Build a stakeholder table identifying 6 key project participants.
Write targeted interview questions for 3 stakeholder groups.
Document your requirements elicitation approach.

Identify the stakeholders for FreshCart

Every software project has people who influence its direction or depend on its outcome. For FreshCart, you need to identify everyone from the CEO who sets the budget to the end customer who uses the app.

Switch back to your FreshCart - Stakeholder Register Google Doc.
Click into the document body and type the heading Stakeholder Register at the top.
Below the heading, click Insert in the top menu bar.
Select Table, then choose a 5x7 grid (5 columns, 7 rows including the header row).

Fill in the header row with these column names:

Name/Role
Department
Interest in Project
Influence Level (High/Medium/Low)
Communication Preference

Now fill in the 6 data rows using the stakeholder information below. For the Communication Preference column, choose what makes sense for each role (e.g., weekly status emails, sprint demos, monthly reports).

CEO / Founder - Executive - Wants the product to launch on time and within budget - High influence.
Head of Operations - Operations - Needs efficient delivery routing and order management - High influence.
Marketing Manager - Marketing - Wants features that attract and retain customers - Medium influence.
Customer Support Lead - Support - Needs tools to handle complaints and order issues - Medium influence.
End Customer (represented persona) - External - Wants easy ordering, fast delivery, fresh groceries - Low influence (but high importance).
Delivery Driver (represented persona) - External - Needs clear delivery instructions and fair scheduling - Low influence.

What is influence level?

Influence level describes how much power a stakeholder has to change the project's direction. A CEO can cancel the project entirely (high influence), while an end customer provides feedback but cannot make decisions about scope or budget (low influence).

Notice that "low influence" does not mean "unimportant." The end customer is the person the entire product is built for. Capturing their needs is critical even though they do not sit in the boardroom.

Communication Preference ideas

Think about what each stakeholder cares about and how often they need updates. Executives often prefer brief weekly summaries. Operations leaders want detailed sprint demos. External personas are typically reached through surveys or usability testing sessions.

Write stakeholder interview questions

A requirements elicitation interview is how a Business Analyst uncovers what stakeholders actually need. Good questions are open-ended, role-specific, and designed to surface hidden requirements rather than confirm assumptions.

Below your stakeholder table, type the heading Interview Questions by Stakeholder Group.

Write 3-4 targeted questions for each of the following three groups. Focus on uncovering needs, pain points, and success criteria.

Add a subheading Executive (CEO) and write 3-4 questions about business goals, timeline, budget constraints, and how they define project success.
Add a subheading Operations (Head of Operations) and write 3-4 questions about current delivery processes, bottlenecks, desired system capabilities, and integration needs.
Add a subheading Customer-facing (Marketing + Support) and write 3-4 questions about customer complaints, desired features, competitor advantages, and how they measure customer satisfaction.

What makes a good interview question?

Good interview questions are open-ended (not yes/no), specific to the stakeholder's role, and focused on uncovering requirements rather than confirming assumptions.

For example, asking the CEO "Do you want fast delivery?" is weak because the answer is obviously yes. Asking "What does a successful launch look like to you in the first 6 months?" uncovers measurable success criteria you can turn into requirements.

✔️ I'll give it a go!

Write your own questions based on the guidance above. Think about what each stakeholder group would care about most.

ⓧ Maybe a little help...

Here are example questions for each group to get you started. Feel free to use these as-is or modify them.

Executive (CEO):

What does a successful launch look like in the first 6 months?
What is the maximum budget for this project, and are there phases where spending could be deferred?
Which competitor capabilities concern you most?
Are there any hard deadlines tied to external events (e.g., a marketing campaign or seasonal demand)?

Operations (Head of Operations):

Walk me through the current process from when a customer places an order to when it arrives at their door.
Where do orders get delayed or lost in the current system?
What existing tools or systems would the new platform need to integrate with?
How do you currently handle out-of-stock items after an order is placed?

Customer-facing (Marketing + Support):

What are the top 3 complaints customers have about the current ordering process?
What features do competitors offer that our customers ask for?
How do you currently measure customer satisfaction, and what metrics would you like the new system to track?
What information does the support team need most urgently when a customer calls with a problem?

Document your elicitation approach

Professional BAs always explain their methodology. This tells readers why you chose a particular technique and what complementary methods you would use alongside it.

Scroll to the very top of your Stakeholder Register document, above the table.
Add a heading called Requirements Elicitation Approach.
Below it, write a paragraph of 2-3 sentences explaining your approach.

Your paragraph should address three things:

Why you chose stakeholder interviews as your primary elicitation technique.
What complementary techniques you would use (e.g., document analysis of competitor apps, observation of the current manual ordering process).
How you plan to validate your findings (e.g., follow-up workshops, prototype walkthroughs).

Why interviews as the primary technique?

Stakeholder interviews are ideal for early-stage projects because they let you uncover unstated needs and hidden concerns through follow-up questions. Techniques like document analysis and observation work best as complements. They fill gaps that interviews miss, such as undocumented workflows or competitor features nobody mentioned.

Your completed Stakeholder Register should now have three sections from top to bottom: the methodology paragraph, the stakeholder table with 6 rows of data, and the interview questions grouped by stakeholder category.

Document looking disorganized?

Make sure you are using Google Docs heading styles (select text, then choose a heading level from the Styles dropdown in the toolbar) rather than just bolding text. Heading styles create a clear document structure and make the doc easier to navigate.

If your table columns are too narrow, hover between column borders until you see a resize cursor, then drag to widen.

Need more help structuring your document?

You now have a complete picture of who matters on the FreshCart project and how to reach them. Next up, you will turn these stakeholder insights into the core of your Business Requirements Document by writing the business objective and defining the project scope.

Write the Business Objective and Scope

Your stakeholder register is complete. You know who cares about FreshCart and what questions to ask them.

Now it's time to fill in the heart of your Business Requirements Document. The Business Objective and Scope sections answer two critical questions: "Why are we doing this?" and "What exactly are we building?"

In this step, get ready to:

Fill in the Document Overview and Business Objective.
Define the project scope with explicit in-scope and out-of-scope lists.
Add a stakeholder summary to the BRD for quick reference.

Write the Document Overview and Business Objective

Every BRD starts with metadata so readers know the document's status at a glance. After that comes the Business Objective, which explains why the project exists in the first place.

Return to your FreshCart - Business Requirements Document in Google Drive.
Click into the Document Overview section heading.
Below the heading, fill in the following project metadata:

Project Name: FreshCart Online Grocery Platform
Document Version: 1.0
Author: Your name.
Date: Today's date.
Status: Draft

Now scroll down to the Business Objective section. Here you will explain why this project needs to exist.

Write 2-3 sentences that describe the business problem and the desired outcome.

Use this scenario context for your objective:

FreshCart currently takes grocery orders via phone calls and a paper-based system.
They are losing customers to competitors with online ordering.
The project aims to launch a digital platform that allows customers to browse products, place orders, and schedule deliveries online.
The measurable target is increasing order volume by 40% within 6 months of launch.

What makes a good Business Objective?

A strong Business Objective ties the project to a measurable business outcome. It explains the current pain point, the proposed solution, and how success will be measured.

Notice the 40% order volume increase within 6 months. That specific number gives stakeholders something concrete to evaluate and the development team a clear target to design for.

Define the project scope

The scope definition draws a clear boundary around what the team will and will not build. Without it, stakeholders add requests endlessly and the project never ships.

Scroll to the Project Scope section in your BRD.
Create a subheading called In Scope.
Add the following items as a bulleted list:

Customer-facing web application for browsing and ordering groceries.
Customer account creation and login.
Product catalog with categories, search, and pricing.
Shopping cart and checkout with payment processing.
Delivery scheduling (same-day and next-day options).
Order tracking for customers.
Admin dashboard for FreshCart staff to manage orders and inventory.

Below the In Scope list, create a subheading called Out of Scope.
Add these items as a bulleted list:

Mobile native app (future phase).
Loyalty rewards program (future phase).
Integration with third-party delivery services.
In-store kiosk ordering.
Supplier/vendor management system.

Why is Out of Scope just as important?

Listing what you will NOT build prevents scope creep. When a stakeholder later asks "Can we add a loyalty program?", you can point to this section and say it was explicitly excluded for this phase.

Notice the "future phase" notes. They acknowledge the idea has value without committing to it now. This keeps stakeholders feeling heard while protecting the team's timeline.

Add a stakeholder summary to the BRD

BRD readers need a quick reference for who is involved without digging through a separate document. You will add a brief version of your stakeholder register here.

Scroll to the Stakeholders section in your BRD.
List each stakeholder role from your register with one sentence describing their primary interest.

For example:

CEO/Founder: Wants the product to launch on time and within budget.
Head of Operations: Needs efficient delivery routing and order management.
Marketing Manager: Wants features that attract and retain customers.
Customer Support Lead: Needs tools to handle complaints and order issues.
End Customer (persona): Wants easy ordering, fast delivery, fresh groceries.
Delivery Driver (persona): Needs clear delivery instructions and fair scheduling.

Add a note at the bottom of this section: "For full details, see the FreshCart Stakeholder Register."

Keep summaries lean

This section is a quick-reference snapshot, not a duplicate of your full register. One sentence per stakeholder is enough. Readers who need more detail can open the separate Stakeholder Register document.

Your BRD now has four sections filled in: Document Overview, Business Objective, Project Scope, and Stakeholders. The remaining sections (Functional Requirements, Business Rules, Assumptions and Constraints, Approval) are still empty.

✔️ Awesome, I've got everything!

Great. Double check you have both the In Scope and Out of Scope lists, and that your Business Objective includes the 40% measurable target.

ⓧ I'd like to double check the full document

Here is what your BRD should contain at this point:

Document Overview:

Project Name: FreshCart Online Grocery Platform.
Document Version: 1.0.
Author: Your name.
Date: Today's date.
Status: Draft.

Business Objective: 2-3 sentences describing FreshCart's move from phone/paper orders to a digital platform, targeting a 40% order volume increase within 6 months of launch.

Project Scope - In Scope:

Customer-facing web application for browsing and ordering groceries.
Customer account creation and login.
Product catalog with categories, search, and pricing.
Shopping cart and checkout with payment processing.
Delivery scheduling (same-day and next-day options).
Order tracking for customers.
Admin dashboard for FreshCart staff to manage orders and inventory.

Project Scope - Out of Scope:

Mobile native app (future phase).
Loyalty rewards program (future phase).
Integration with third-party delivery services.
In-store kiosk ordering.
Supplier/vendor management system.

Stakeholders: One-sentence summary per role (6 stakeholders) with a reference to the full Stakeholder Register.

Sections still empty: Functional Requirements, Business Rules, Assumptions and Constraints, Approval.

Your BRD now has a solid foundation. Next up, you will write the functional requirements and business rules that tell developers exactly what the system needs to do.

Write Functional Requirements and Business Rules

Your BRD now has a solid foundation. The business objective, scope, and stakeholders give readers the full context of what FreshCart is building and why.

Now it is time to fill in the core of the document. Functional requirements describe exactly what the system must do, while business rules define the policies and restrictions that constrain how it operates. Together, they give the development team a precise blueprint to build from.

In this step, get ready to:

Write 8-10 functional requirements with acceptance criteria.
Define business rules that constrain FreshCart's operations.
Document assumptions and constraints for the project.

Write functional requirements

Functional requirements describe specific behaviors the system must perform. Each one answers the question: "What does the system need to do for its users?"

Switch back to your FreshCart - Business Requirements Document in Google Docs.
Scroll down to the Functional Requirements heading.
Write 8-10 requirements, each following this format:

Requirement ID (e.g., REQ-FUNC-001).
Description: "The system shall [action] so that [business reason]."
Actor: Who performs or benefits from this action.
Acceptance Criteria: 2-3 testable conditions that prove this requirement is met.

Cover these areas across your 8-10 requirements:

User registration and login (1-2 requirements).
Product browsing and search (2 requirements).
Shopping cart and checkout (2-3 requirements).
Delivery scheduling (1-2 requirements).
Order tracking (1 requirement).

What makes a good requirement?

Every requirement you write must pass five quality checks. It should be Clear (unambiguous), Testable (you can verify it works), Necessary (ties to a business objective), Feasible (technically possible), and Traceable (links back to the business objective).

If you can not write a test for a requirement, it is too vague. Rewrite it until someone could build a checklist to verify it.

Example requirement to guide you

Here is one example to model your own requirements on:

REQ-FUNC-001 | Description: "The system shall allow customers to create an account using their email address and a password so that they can save delivery addresses and view order history." | Actor: Customer | Acceptance Criteria: (1) User can register with a valid email and password. (2) System rejects duplicate email addresses. (3) User receives a confirmation email after registration.

✔️ I'll give it a go!

Write all 8-10 requirements on your own. Use the example above as a model and make sure each one covers a different feature area.

ⓧ Maybe a little help...

Here are a few more examples to get you started. Write at least 4-5 of your own in addition to these.

REQ-FUNC-002: "The system shall allow customers to search for products by name or category so that they can quickly find items." Actor: Customer. Acceptance Criteria: (1) Search returns results within 3 seconds. (2) Results match the search term in product name or category. (3) A "no results found" message displays when no matches exist.
REQ-FUNC-005: "The system shall allow customers to add items to a shopping cart and adjust quantities so that they can review their order before checkout." Actor: Customer. Acceptance Criteria: (1) Customer can increase or decrease item quantity. (2) Cart total updates in real time. (3) Items persist in the cart across browser sessions for logged-in users.
REQ-FUNC-008: "The system shall allow customers to select same-day or next-day delivery and choose a 2-hour delivery window so that they can receive groceries at a convenient time." Actor: Customer. Acceptance Criteria: (1) Same-day option only displays if the order is placed before the cut-off time. (2) Available delivery windows reflect driver capacity. (3) Confirmation email includes the selected delivery window.

Now write the remaining requirements yourself, covering product browsing, checkout/payment, and order tracking.

Define business rules

Business rules are different from functional requirements. They are restrictions or policies that govern how the business operates, not features the system provides.

Scroll down to the Business Rules heading in your BRD.
Write 4-5 business rules using the format: BR-001: [Rule statement]. Rationale: [Why this rule exists].

Write one rule for each of these areas:

Minimum order value for free delivery.
Maximum delivery radius from the store location.
Cut-off time for same-day delivery orders.
Payment processing rules (accepted methods, refund policy window).
Product availability rules (what happens when an item goes out of stock after ordering).

What is the difference between a requirement and a business rule?

A functional requirement says what the system must do ("The system shall allow customers to place orders"). A business rule says what the system must enforce ("Orders under $30 incur a $5 delivery fee").

Business rules come from company policy, regulations, or operational realities. They constrain the system rather than define new capabilities.

✔️ I'll give it a go!

Write all 4-5 business rules on your own. Pick realistic values and explain why each rule exists in the rationale.

ⓧ Maybe a little help...

Here are two examples. Write the remaining 2-3 yourself.

BR-001: Orders below $30 will incur a $5.99 delivery fee. Orders of $30 or above receive free delivery. Rationale: Encourages larger order sizes while covering delivery costs for small orders.
BR-003: Same-day delivery orders must be placed before 2:00 PM local time. Orders placed after 2:00 PM will default to next-day delivery. Rationale: Allows sufficient time for order picking, packing, and route optimization before end-of-day delivery runs.

Now write rules for maximum delivery radius, payment processing, and out-of-stock handling.

Document assumptions and constraints

Every project operates under conditions that have not been formally verified (assumptions) and hard limits that cannot be changed (constraints). Documenting these up front prevents surprises later.

Scroll down to the Assumptions and Constraints heading in your BRD.
Add a subheading called Assumptions.
Write 3-4 assumptions. These are things you believe to be true but have not confirmed.

Example assumptions for FreshCart:

Customers have reliable internet access and a modern web browser.
FreshCart has an existing product database that can be imported into the new system.
Delivery drivers have smartphones capable of running the driver status update interface.
A third-party payment processor will be integrated rather than building payment handling from scratch.

Below your assumptions, add a subheading called Constraints.
Write 3-4 constraints. These are hard limits on the project that cannot be negotiated.

Example constraints for FreshCart:

The project must launch within 6 months of approval.
The development budget is capped at $150,000.
The system must comply with payment card industry (PCI) data security standards for handling credit card information.
The platform must support at least 500 concurrent users at launch.

Why document assumptions separately from constraints?

Assumptions are things that could turn out to be wrong. If FreshCart does not actually have an existing product database, someone needs to build one, and that changes the timeline and budget.

Constraints are fixed boundaries set by leadership, regulations, or technical reality. Listing them prevents scope creep by making limits visible to everyone.

Your BRD now contains the technical backbone that a development team would use to build FreshCart. Next up, you will bring these requirements to life by creating a visual use case diagram that shows exactly how each actor interacts with the system.

Create a Use Case Diagram

Your BRD now has a solid written foundation with functional requirements, business rules, and documented assumptions. Words are powerful, but a visual model can communicate system interactions at a glance.

In this step, you will create a UML use case diagram that shows exactly how each actor interacts with the FreshCart platform. This gives stakeholders and developers an instant overview of who does what in the system.

In this step, get ready to:

Open draw.io and create a new diagram file.
Add actors, use cases, and connections to model the FreshCart system.
Export the diagram and embed it in your BRD.

Open draw.io and set up the diagram

draw.io is a free browser-based diagramming tool that supports UML shapes out of the box. You do not need an account to use it.

Open a new browser tab and navigate to app.diagrams.net.
When prompted where to save your diagram, select Device.
A dialog will appear asking you to create a new diagram or open an existing one. Click Create New Diagram.
Select Blank Diagram.
In the filename field, type FreshCart Use Case Diagram and click Create.

You should see a blank white canvas with a shapes panel on the left side and a format panel on the right.

What shapes will you use?

For a use case diagram, you need three types of shapes from the General shape library (visible by default in the left panel):

Stick figures represent actors (people or external systems that interact with your platform).
Ovals represent use cases (actions or goals an actor performs).
Rectangles represent the system boundary (a box around all use cases to show what is inside your system).

Don't see the shapes panel?

If the left panel is missing, click View in the top menu and ensure the shapes panel is enabled. You can also try refreshing the page.

help me find the shapes panel in draw.io

Add actors and use cases

Now you will build the diagram piece by piece. Start with the system boundary, then add actors outside it and use cases inside it.

First, create the system boundary:

From the General section in the shapes panel, drag a rectangle onto the center of the canvas.
Resize it to take up most of the canvas (you need room for 11 ovals inside it).
Double-click the rectangle to edit its label and type FreshCart Platform.
To make the boundary a hollow box (no fill colour), select the rectangle, then in the format panel on the right, uncheck Fill under the Style tab.

Next, add the actors:

In the shapes panel search field, type actor or scroll down in the General library to find the stick figure shape.
Drag four stick figures onto the canvas, placing them outside the system boundary rectangle.
Place two actors on the left side of the rectangle and two on the right side.
Double-click each stick figure to add its label:
Top left: Customer.
Bottom left: Delivery Driver.
Top right: Admin/Staff.
Bottom right: Payment Gateway.

Why is Payment Gateway an actor?

In UML, an actor does not have to be a person. Any external system that interacts with your platform counts as an actor. The Payment Gateway is a third-party service that processes transactions, so it sits outside your system boundary.

Now, add the use cases inside the system boundary:

From the General library, drag an oval (ellipse) shape inside the system boundary rectangle.
Double-click the oval to label it.
Repeat this process to create 11 ovals total with these labels:

Browse Products.
Search Products.
Register/Login.
Add to Cart.
Place Order.
Make Payment.
Schedule Delivery.
Track Order.
Manage Inventory.
Process Order.
Update Delivery Status.

Finally, draw the association lines:

Association lines are solid lines connecting each actor to the use cases they interact with. To draw a line, hover over an actor shape until you see blue connection points appear, then click and drag from the actor to a use case oval.

Connect Customer to: Browse Products, Search Products, Register/Login, Add to Cart, Place Order, Make Payment, Schedule Delivery, Track Order.
Connect Delivery Driver to: Update Delivery Status.
Connect Admin/Staff to: Manage Inventory, Process Order.
Connect Payment Gateway to: Make Payment.

Keep your lines straight

If a connector has unwanted bends, right-click the line and select Straight from the connection style options. You can also rearrange your ovals so that lines do not cross over each other.

Your canvas should now show four actors outside the rectangle, 11 labelled ovals inside it, and solid lines mapping each actor to their relevant use cases.

Shapes overlapping or hard to read?

Select all shapes with Cmd+A (macOS) or Ctrl+A (Windows), then try Arrange in the top menu and select a layout option to auto-arrange. You can also drag individual shapes to reposition them manually.

help me arrange my use case diagram so it is readable

Export and link your diagram

The diagram is complete. Now you will export it as an image and embed it into your BRD so stakeholders can see the visual model alongside the written requirements.

In draw.io, click File in the top menu.
Select Export as, then click PNG.
In the export dialog, leave the default settings and click Export.
Choose a location on your computer to save the PNG file and click Save.

Now embed the diagram in your BRD:

Switch back to your FreshCart - Business Requirements Document in Google Docs.
Place your cursor after the Stakeholders section (before Functional Requirements).
Add a new heading: Visual Models.
Click Insert in the Google Docs menu bar.
Select Image, then Upload from computer.
Choose the PNG file you just exported and insert it.
Below the image, type the caption: Figure 1: FreshCart Platform Use Case Diagram.

Your BRD now has a professional visual model embedded directly in the document.

Why embed the diagram in the BRD?

A standalone diagram file can get lost or separated from the document. Embedding it means anyone reading the BRD sees the visual context immediately without needing to open a separate file.

In a real project, you would also keep the editable draw.io file so you can update the diagram as requirements change.

Image not appearing in Google Docs?

Make sure you exported the diagram as PNG (not as an XML or SVG file). Google Docs supports PNG and JPEG image uploads. If the file is very large, try reducing the zoom level in the draw.io export dialog before exporting again.

help me insert an image into Google Docs

Your BRD is now a complete, professional document with both written requirements and a visual model. Ready to take it further? The Secret Mission adds non-functional requirements and a traceability matrix to round out your BA portfolio.

Secret mission

Add Non-Functional Requirements and a Traceability Matrix

Your BRD covers what the system does, but hiring managers also want to see that you can define how well it performs. In this secret mission, you will add non-functional requirements and build a Requirements Traceability Matrix that links every requirement back to a business objective.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on Google Drive and local files, so there are no ongoing costs.

Resources you used:

Google Drive folder: FreshCart BA Project (contains 3 Google Docs).
FreshCart Use Case Diagram file (.drawio file saved on your device).
FreshCart Use Case Diagram PNG (exported image saved on your device).

Keep everything running

No action needed. Choose this if you want to revisit your BRD, refine your requirements, or use these documents as portfolio pieces for job applications.

Your Google Docs remain in your FreshCart BA Project folder on Google Drive.
Your draw.io file and exported PNG remain on your device wherever you saved them.
None of these resources cost anything to keep.

Pause - I'll come back to this later

Since all resources are free Google Docs and local files, there is nothing to pause. Your documents stay exactly as you left them.

Your Google Docs are automatically saved and accessible anytime you return to Google Drive.
Your local draw.io file can be reopened at app.diagrams.net whenever you are ready to continue.

Delete - I don't want to use this again

Remove all project files from Google Drive and your device.

Open Google Drive at drive.google.com.
Right-click the FreshCart BA Project folder and select Move to trash. This deletes the folder and all three Google Docs inside it.
Open Trash in the left sidebar, then click Empty trash to permanently remove the files.
On your device, locate the draw.io diagram file and the exported PNG wherever you saved them. Delete both files.

Nice Work!

You just produced a full set of Business Analyst deliverables for the FreshCart grocery delivery platform. These are the same documents a BA creates at the start of any real software project.

You've learned how to:

Build a Stakeholder Register identifying key project participants and write targeted interview questions that demonstrate requirements elicitation technique.
Create a professional Business Requirements Document with business objectives, in/out scope, functional requirements with acceptance criteria, business rules, and assumptions and constraints.
Draw a UML Use Case Diagram in draw.io with 4 actors, 11 use cases inside a system boundary, and clear association lines.
Secret Mission: Added non-functional requirements and built a Requirements Traceability Matrix with MoSCoW prioritization, completing an interview-ready BA portfolio piece.

Ready to quiz yourself?