APPENDIX
Example Business Requirements Document
Every organization has its own rules, so the rules defined in the example business requirements document (BRD) shown here might not necessarily apply to your project. This BRD template can be adapted for your project’s needs.
The business events defined in the example document might not be the only ones in the scope of your project. The template is intended to show you what your BRD might look like based on what has been discussed in this book.
I have provided definitions to explain the purpose of each section, but when you populate the template, you may delete these explanations.
PIZZAS R’ US
ORDER PROCESSING TRANSFORMATION
Business Requirements Document
Prepared by: Joe Major
Documentation Specialist
Ext 999
Date: 2008-08-30
Document Control
a. Document History
b. Document Reviewers/Approvers
Contents
The Business Goals, Risks, and Benefits
Assumptions, Dependencies, and Restrictions
Business Requirements Overview
Specific Business Requirements
Contingency and Disaster Recovery
Regulatory, Audit, and Data Retention Requirements
Immediate Opportunities for Efficiency
Executive Summary
(The executive summary should highlight the business drivers for the project, the expected benefits, and the current status of the project. The goal is to provide user management with concise paragraphs that simply state the objectives and scope of the project.)
Pizzas R’ Us is a chain of restaurants across the nation. It is famous for its slogan “Your order is ready in 15 minutes or it’s free!”
The chain of Pizzas R’ Us restaurants wishes to (1) improve the current level of service provided to its customer base by shortening the waiting time for the fulfillment of customer order; and (2) reduce each outlet’s financial loss by minimizing the number of pizzas given away because of the untimely delivery of orders.
The head office has decided that to get the market share of the young adults, the chain needs to be technology savvy, which means that it needs to provide a way of allowing customers to enter their order directly and make payment through the Internet without having to talk to restaurant personnel.
The company would also like to explore the effectiveness of a loyalty program that will see the restaurants giving away a large pizza of the customer’s choice after 10 orders of pizza within 3 months. This program is also affiliated with the Company’s marketing program, which allows a customer to earn 1 point for every $10 order. These points can be redeemed as a credit toward service charges. The orders are to be received at a call centre, and processed at the chain location nearest to where the pizza is to be delivered.
Payments may be made using cash, credit card, debit card, points, and/or coupons.
The company would like to encourage customers to send feedback, complaints or otherwise. An employee who excels in customer service may receive a cash bonus. Customer complaints are to be analyzed periodically to determine areas that need customer service improvement.
Project Overview
The Business Problem/Need
[Define the current constraints/business needs that this project is being initiated to address. What can you create, fix, or improve? What are the drivers for the project (e.g., improved process/risk reduction/external mandate)?]
Marketing has determined that the company has been giving away too many pizzas due to untimely delivery of the order. Through the analysis of the current processes, we need to identify where we might be able to introduce some improvement to make order delivery better match the company’s slogan.
The Business Goals, Risks, and Benefits
[Define what the project should achieve and what rewards will be realized with this achievement. The benefits should include any cost reduction, revenue generation opportunities, productivity increases, customer experience improvement, etc. The risks should include items that could be jeopardized if the process(s) is not implemented. This should flow directly from the problem/need that was addressed in the previous section. The level of detail will be dependent upon the individual project.]
The vision for the Pizzas R’ Us Automation project is twofold: to develop a pizza delivery service that makes the ordering process as quick as possible while meeting the needs of the customer and to develop a pizza delivery service that will create flexibility that may be moved to the Internet.
The goals for the Pizzas R’ Us Automation project are to create an order entry system that:
Will be easy for the customer service representative to use, to ensure that order-taking time is reduced- Will present the most up-to-date product availability
- Can be easily updated with promotions and products.
The mission for the Pizzas R’ Us Automation project is to determine and deliver an automated ordering system that will reduce the elapsed time spent on the phone taking orders from a customer and will increase responsiveness to customer requests.
Reduction of the number of give-away pizzas from 2000/month to 500/month will generate a potential increase in profits of approximately 65 percent. This will also lead to a better company image among customers and thus a potential increase in sales of $1000/month.
Critical Success Factors
[Define how success will be measured and realized. How will you know whether the project is successful? What do you consider the criteria for which to measure success?]
Marketing and Finance and Operations believe that there are two major criteria for measuring success:
Reduction of give-away pizzas (minimum reduction of 50 percent)
Increase in sales (minimum increase of 35 percent)
The analyses of the above factors will be conducted throughout a 1-year period from the date of implementation.
Out of Scope
[Define the events and business functions that are out of the scope for this project, including information, scenarios, subject areas, etc.]
The processes at the Head Office are not in the scope of this project. The analysis and definition of process changes will be limited to the operations within the call center, delivery depots, and kitchens.
Assumptions, Dependencies, and Restrictions
[Based on current knowledge, list the circumstances and events that are highly likely to occur that are outside the total control of the project team. This could also include decisions made about scope, project functionality, system interfaces, etc., that must be confirmed. Dependencies should document other projects or initiatives whose completion this project is contingent upon. For example, assume that project X will be completed prior to implementation of project Y. Restrictions are those circumstances and events that could constrain the project and affect the delivery of the solution (e.g., the project must be implemented within a strict and specified dollar amount).]
Business Requirements Overview
Context Diagram
Context Description
[Describe the interfaces between the target project and external business groups, users, or systems.]
The Order Processing Transformation System (OPTS) will be used by the Customer Service Reps at the Call Center to take orders from the Customers. If the Customer’s order is paid with a credit card, the order is considered ready to be prepared by the Kitchen when the credit card is approved by the appropriate Credit Card Bureau. OPTS will send notification to the appropriate Kitchen of the customer order that needs to be prepared. The Kitchen will use OPTS to advise of the supplies required to be ordered from the Vendors and advise when the customer order is ready for delivery. OPTS will advise the appropriate Driver when a customer order needs to be picked up from the Kitchen to be delivered to the Customer. The Driver will use OPTS to send notification of the successful or unsuccessful delivery of the customer order.
Downstream Impacts
[Identify business groups or users that are indirectly affected by this project and not reflected in the context diagram.]
The back-end office will be able to access statistical information for analysis, directly from OPTS.
Logical Data Model
Specific Business Requirements
[This itemizes the business events in the scope of this project.]
Business events include:
- Customer Orders a Pizza
- Customer Cancels an Order
- Customer Makes a Payment
- Customer Earns Points
- Customer Provides Feedback
- Order Supplies
- Cancel an Order for Supplies.
Customer Orders a Pizza
Event Entity Relationship Diagram
Process Description
For each request for a pizza or a product made by a CUSTOMER, determine whether the Customer exists.
If the customer does not exist,
request customer information from CUSTOMER.
Create Customer, including name, address, telephone number, and postal code.
If customer exists,
determine the last Order received from the customer.
Determine whether the Product on the last order is available.
If the requested product is available, determine from the CUSTOMER if the same order is to be repeated.
If the CUSTOMER wants the order repeated, record the accepted Order with the current date, time, and order value, including applicable taxes.
If the CUSTOMER does not want the order repeated or the CUSTOMER is new, request the product details from the CUSTOMER.
If the requested product is not available, request that the CUSTOMER make another product selection.
If the CUSTOMER does not select another product, reject the request. Record the date and time of order and the reason why the order was not completed/accepted.
Confirm the accepted order with the CUSTOMER.
Send the accepted order to the KITCHEN of the location nearest to the delivery address.
Design Considerations
Smart fill postal code based on address provided by customer (use 411 database).
Customer Cancels an Order
Event Entity Relationship Diagram
Process Description
Occasionally, a CUSTOMER might decide to cancel an order.
For each order cancellation request received from a CUSTOMER, retrieve the information about the Customer Order being cancelled.
Determine the status of the Customer Order.
If the Customer Order is enroute (i.e., dispatched for delivery), cancellation is not allowed because it is deemed delivered.
If the Customer Order is yet to be prepared by the Kitchen, cancel it. Record the reason for cancellation of the order, and who at the store location cancelled it.
Determine whether the order is paid for. If it is, retrieve the Customer Payment information, such as type and amount of payment.
If payment is by cash or debit, refund the amount to the CUSTOMER.
If payment is by credit card, apply a credit of the charge on the card and provide proof of credit to the CUSTOMER.
If payment is by points, reclaim the Customer’s loyalty points.
If payment is by coupon, the value of the coupon is forfeited.
Confirm cancellation of the Customer Order.
Notify KITCHEN of order cancellation.
Outstanding Questions
Should a cancellation be allowed for an order that is ready? What are the business rules?
Design Considerations
When recording the reason for the cancellation of the order, provide valid choices for the Customer Service Rep to select from to minimize data entry strokes.
Customer Makes a Payment
Entity Relationship Diagram
Process Description
For each payment received from a CUSTOMER, retrieve the information about the Customer Order being paid for.
If order has already been paid, do not accept payment.
If not, receive Customer Payment and record the following information:
- Date of payment
- Amount of payment
- Form of payment (e.g. cash, credit card, debit, points, coupon)
If payment is by credit card, request authorization from the CREDIT CARD BUREAU.
If transaction is authorized, record the following information:
- Which credit card (Visa, Master Card, etc.)
- Credit card number
- Name of cardholder
- Amount to be charged to the credit card
- Authorization number
If payment is by points, retrieve the Customer’s loyalty information, and determine the number of points that the Customer has accumulated. Update the Customer’s points balance, and record the following Customer Payment information:
- Points used
- Loyalty number
- Equivalent value (in $) of points
If payment is by Coupon, record the following information:
- Face value of the coupon
- Expiration date of the coupon
Acknowledge receipt of payment. Provide proof of payment to the CUSTOMER.
Design Considerations
If the order is placed through the Internet, payment is required at the time the order is placed. A reference number and an option to print a receipt are to be provided to the Customer as proof of payment. Only authorized employees should be able to take orders and accept payments from customers. Future enhancement: link to the Coupon Generation System (CGS) for coupon information like face value and expiration date.
Customer Earns Points
Event Entity Relationship Diagram
Process Description
A Customer may earn 1 point for each $10 order.
For each Customer order, determine the value of the order. If the order is more than $10, calculate the number of points that the customer may earn (i.e. Value of Customer Order divided by 10).
Record the Customer’s loyalty points
Advise CUSTOMER of points earned.
Design Considerations
Points earned by a Customer may be printed on the receipt or acknowledgement of the order.
Customer Provides Feedback
Event Entity Relationship Diagram
Process Description
Occasionally, a CUSTOMER may be inspired to complete a survey form or provide feedback to the restaurant personnel.
For each comment received from a CUSTOMER, retrieve the information about the Customer who is providing the feedback.
If information is not available, obtain and record the following information from the CUSTOMER:
- Name
- Telephone number
- Email address, if applicable
If information is available, determine from CUSTOMER whether information is valid. If not, update Customer information.
Record the following Customer Feedback information:
- Date of feedback
- Restaurant location subject of feedback, if applicable
- Type of feedback (e.g., complaint or compliment)
- Date of occurrence of incident, if applicable
- Feedback
- Restaurant personnel who received the feedback
- Restaurant personnel who may be involved in the incident
- Resolution of the complaint, if applicable
- Who resolved the complaint.
Acknowledge receipt of feedback to the CUSTOMER.
Design Considerations
Design a standard form to be populated when acknowledging receipt of feedback.
Order Supplies
Event Entity Relationship Diagram
Process Description
For each request from the KITCHEN to order necessary supplies from a Vendor, retrieve the information about the Supply that needs to be ordered.
Retrieve the information about the Vendor who is contracted to provide the Supply to the restaurants.
Determine if Supply is still in a “sufficient-stock” level. (“Sufficient-stock” level is defined as greater than or equal to the minimum inventory level.) If it is, reject the supply request.
If Supply is not available, or it is below the minimum inventory level, approve the request as a valid Purchase Order and record the following:
- Vendor to order from
- Supply being ordered
- Quantity or amount of each supply
- Total value of the Purchase Order
- Date when supply is required
- Location where supply is to be delivered
- Contact person (at the location) for the order
Issue Purchase Order to the VENDOR.
Assumption: Vendor indicated in the supply information has undergone certification or approval process. The approval process itself is out of scope of this project.
Cancel an Order for Supplies
Event Entity Relationship Diagram
Process Description
PROCUREMENT or OPERATIONS may decide to override a previously-approved purchase order for a supply.
Retrieve the information about the Purchase Order that needs to be cancelled. Only those Purchase Orders that have not been filled may be cancelled
Retrieve the information about the Vendor who received the Purchase Order.
Change the status of the Purchase Order to “cancelled” and record the following:
- Date/time when order is cancelled
- Who authorized the cancellation
- Reason for cancellation.
Advise the VENDOR of the cancellation of the Purchase Order.
Design Considerations
Provide a list of reasons allowed for cancellation from which the Customer Service Rep can make a selection. This will help minimize the data entry strokes required to complete the process.
Data Dictionary
A list of business objects referenced in this Business Requirements Document. Each business object has a definition and a list of data attributes.
Customer Order
Request made by a Customer for any product provided by the Company.
Data Attributes:
- Date and time order received
- Customer who made the order
- Pizza ingredient (MV)
- $ value of the order
- Date and time order dispatched for delivery
- Date and time order delivered
- Date and time order cancelled
- Reason for cancellation
- Employee who received cancellation
Customer
An individual who has ordered a pizza at least once. A Customer is also someone who has made an inquiry about product offering but may have never purchased anything from the Company.
Data Attributes:
- Customer name
- Customer telephone number
- Customer address
- nearest intersection
- loyalty points—total points accumulated by a Customer for every $10 worth of customer order.
Supply
A pizza ingredient or a product that is ordered from a specific Vendor. This may include kitchen utensils, restaurant props, etc.
Data Attributes:
- Supply code
- Supply name
- Supply category
e.g., pizza ingredient, kitchen supply, restaurant supply, office supply
- Vendor who can supply (MV)
- Vendor rank (MV)
e.g., 1st preference, 2nd preference
- Supply price agreed with Vendor (MV)
- Minimum quantity
- Maximum quantity
Customer Payment
Payment made by a customer for the pizza ordered.
Data Attributes:
- Date of payment
- Who received payment
- Type of payment
e.g. cash, credit card, debit card, points, coupon
- Amount of payment
- Amount refunded
Customer Feedback
Complaint or compliment provided by a Customer about personnel, service or product received at a Pizzas R’ Us location.
Data Attributes:
- Date of receipt of feedback
- Subject location
- Type of feedback
e.g., complaint or compliment
- Feedback
- Who received the feedback
- Date of occurrence of incident, if applicable
- Restaurant personnel involved in the feedback (MV)
- Resolution, if applicable
- Who resolved
- Date of resolution
Vendor
A certified provider of a supplies.
Data Attributes:
- Vendor number
- Vendor name
- Vendor address
- Vendor telephone number
- Main contact at Vendor
- Contact’s telephone number
- Contact’s email address
- Contact’s fax number
Purchase Order
An order for a supply or ingredient.
Data Attributes:
- Purchase order number
- Vendor
- Supply ordered (MV)
- Quantity of supply (MV)
- Date when supply is required (MV)
- Location where supply is to be delivered (MV)
- Cost of the supply ordered (MV)
Global Requirements
[The subsections refer to those that are applicable to the whole project. The following topics are some examples of nonfunctional requirements that you may need for your specific project.]
Volumes
[Explain what data volumes should be expected, i.e., number of accounts, inquiries, sales, etc. Where volumes are anticipated to vary significantly over the day or time of the month, specify the expected deviation, the size of the peaks, and also the average volume. For example, expect 1,000 new records to be uploaded daily, 300 records updated daily; month-end processing (last Friday of each month) should have a 25 percent increase in record updates.]
Potential Growth
[Estimate the potential increase in both number of users and transaction volumes that could realistically be expected in the next 12–18 months; e.g., “The number of users should increase from 10 to 100 within a year of this process implementation. The number of accounts is expected to be approximately 200,000 a year.”]
Performance
[What is an acceptable response time when accessing the new or changed system, screen, report, etc.? For example, “The system must be able to generate reports and perform calculations within one day of data being received from the equity system.” Are there any time constraints on when updates/processes should run? For example, “Equity data must be received and processed before Asian markets open for business each day.”]
Data Migration/Conversion
[Describe any migration or conversion requirements for the proposed system.]
Usability
[Detail any usability requirements that the overall solution must fulfill including screen requirements, flow requirements, etc.; e.g., “All screens must have the same menu items available. The system must meet the latest branding requirements. The system must work using Netscape and Internet Explorer.”]
System Availability
[Do these requirements change the current Service Level Agreement for the application? The Service Level Agreement is the hours in the day the system must be available for use, considering the locations detailed previously. If a Service Level Agreement does not exist, do you require one with this release? For example, “The system must be available from 7:00 a.m. to 10:00 p.m., Monday through Friday.”
What is the maximum time the system could be unavailable during the business day due to component failure, and what could be the impact on business operations during an outage?]
Customer orders are received at the call center 24/7. It is imperative that the system be available and operational during that time period to allow CSRs to receive customer orders and prepare them within the promised 15-minute period. While the system is down for any reason, such as maintenance work, customer orders may be received and communicated to the appropriate kitchen by phone.
Contingency and Disaster Recovery
[Explain what contingency requirements the system must meet in the event of an extended outage. What needs to happen if there is an extended outage? If applicable, what are the timing requirements to make the system available in an alternative location? Will there be a manual process that goes into effect in the event of a system outage?]
In case of a power outage at the kitchen locations, the call center should not take any customer orders because this will only increase the possibility of giving away pizzas.
Information Security
[For each group of users, explain the user capability profiles in terms of function authorization (at what level(s) is password authentication required?) Outline user entitlements.]
All personnel accepting customer orders and customer payments must have the proper level of authorization.
Help and Training
The introduction of any new user interface screen for accepting customer orders, customer payment, and customer feedback and for cancelling customer orders will necessitate training of the resources currently performing the processes. The training and preparation of any training materials and standard operating procedure (SOP) manuals should be addressed by the Change Management Team.
Regulatory, Audit, and Data Retention Requirements
For the first year of implementation, all customer order data must be retained for an indefinite period until further notice for success analyses, and key performance indicators.
Reporting Requirements
All reports will be generated upon request. No canned reports need to be generated.
Some reports that may be requested:
List of all customer orders that have been cancelled, itemizing cancellations by a specific reason, along with the value of the order
List of all negative/positive feedback
List of customers who have ordered more than 10 pizzas over a specified period of time.
Project Timing Considerations
[Is there a critical date by which this solution must be in place? What considerations are driving this date? A date cannot be given without specific consequences behind the given date (e.g., audit review of business process is due on a specific date).]
The new processes are expected to be in place no later than Q1/09. The company’s financial position will be in jeopardy if the profitability does not improve by Q2/09.
Glossary of Terms
[Define all acronyms/business terms that are used within this document where the definition would not be widely known/used by the general population or technology organization. For example, “CDB - Central Database that is the main repository for a specific department.”]
OPTS Order Processing Transformation System
CSR Customer Service Rep
SOP Standard Operating Procedures
Appendix
Immediate Opportunities for Efficiency
Provide a “caller display” feature to all the call center telephones. This will minimize (not necessarily eliminate) the need for the Customer Service Representative to ask for the Customer’s telephone number.
Assumptions
Vendor indicated in the supply information has undergone certification or approval process. The approval or vendor certification process itself is out of scope of this project.
Questions
Should a cancellation be allowed for an order that has been cooked and ready for delivery? What are the business rules for cancelling a customer order (from event “Customer cancels an order”)?
Issues
No outstanding issues.