1. Michael Afolabi Petr Novotny Wei Luo Xin Zhang Yuan Li
System Requirements Engineering Group Coursework
SRS for Automated Catering System
Michael Afolabi
Petr Novotny
Wei Luo
Xin Zhang
Yuan Li

2. The Purpose of the Project
The User Business or Background of the Project Effort
Inaccurate stock inventory is a serious problem
Change in the availability of menus to clients due to lack of ingredients
Problems with suppliers delivery.
Customers at time do not know how a menu would look like until they have ordered it
Customers unable to seek assistance during the course of their meals because the waiter wasn’t around
Goals of the Project
Purpose: To accurately maintain the stock level of products and meet customer satisfaction.

3. The Client, the Customer, and Other Stakeholders
The Client and Customer
The clients and customer for the product are Joel Ali, Philip Anderson, James Beattie, Benoit Cousin, Pirouz Vosoughi and Anthony Ward, the chief directors of Group 1 restaurant
Stakeholder
Description
Priority
(1-highest priority)
Customers
Customers of the restaurant, customers come to the restaurant to order menu of their choice provided its available 1
Suppliers
The supplier delivers goods to the restaurant everyday. The supplier will be checking the inventory of the client to ensure they are only supplying what is need by the client. 2
Payment Company
This is the company that receives all card payment from the restaurant’s system, the decision whether to authorize or reject a card transaction comes from the bank. 3
Inland Revenue
There would be a time where reports would be generated by the restaurant to disclose their earnings to the inland revenue when requested for, this is where the inland revenue comes in. 4
Residents
This is the local residents that live in the neighbour hood. They have some impact in the system as they can make protest against the time of delivery of goods for the restaurant since the delivery is made everyday. 5

4. Users of the Product Customers
The customers are anyone from individuals to business customers, literally anyone who comes to the restaurant to order a meal. They will be selecting the menu from the terminal as they know what they want to order.
The customer will be ranging from kids, students, adults to elderly people.
Chef
The chef will be working in the restaurant, as he will be preparing the menu the customer has requested for, the chef will be highly skilled in cooking, and he would be trained on how to use the system as the chef would be updating the system.
The chef will be PC Literate.
The chef will also be giving advice to the stock manager on stocks, may be an introduction of new products or recipe.
Stock Manager
The stock manager also works for the restaurant and would be interacting with the system as he will be in charge of the accuracy of the inventory of the system. The stock manager is moderately literate in the use of PC and would have no problem using the system.
The stock manager would be adding, deleting and adjusting the number of stocks in the inventory and would be seeking advise from the chef.
Bartender
The bar tender currently works at the restaurant assists customers and works as a intermediary between the chef and the customer, he takes the customer’s order and passes it on the chef, and he helps the chef in serving the customer what they’ve ordered.
He would also be assisting the customers in need.
Supplier
The supplier would be interacting directly with the automated catering system, as they would be querying the inventory of the system to know what the restaurant wants, and they supply stocks (ranging from wine, beef, raw ingredients to drinks) to the restaurant.

5. Naming Conventions and Definitions
Definitions of All Terms, Including Acronyms, Used in the Project
Menu
Inventory
Product delivery
Terminal Panel
Handsets scanner
Bank authorization

6. Product Boundary

7. Functional requirements I
Techniques
Goal graphs
Analysis of scenarios – Volere
However as a major technique was used Goal graphs with refinement techniques and consequent writing requirements with advices from Volere.

8. Goal graph – Customer received food

9. Goal graph – Achieve [Sufficient Stock In Inventory]

10. Requirements for goal – Provide Menu
First 4 requirements:
The product shall present menu on the restaurant table screen.
The product shall present customer with default menu screen upon customer’s arrival.
The product shall switch to default menu screen when ever customer doesn’t interact with screen for 5 minutes.
The product shall present customer with ability to switch into default menu page from any page of menu or from any entertainment plug-in.

11. requirement example
Requirement #: 20 Requirement Type: 9 Goal: Pay Order
Description: The product shall presents user with selection of type of payment.
Rationale: Customer has several options to choose from to carry out payment for order.
Originator: Group #1
Fit Criterion: The customer should have at least two options to select from to carry out payment for order.
Customer satisfaction: 1
Customer dissatisfaction: 5
Priority: High

12. Functional requirements – lessons learned
Goal graphs provides robust technique for finding requirements in form of leaf goals.
However, its necessary to use other techniques to determine granular functional requirements from leaf goals.
Combination of goal graphs and Volere techniques proved to be of great value and feasibility.

13. Functional requirements II
Techniques:
context diagram
class diagram
elicitation from goal graph

14. Context diagram for the Automated Catering System

15. Goal graph for Automated Catering System

16. Class diagram for the Automated Catering System

17. Lessons learned
Class diagram is an ideal technique to identify agents in the real world, and it is also a good supplement to the functional requirements in terms of specifying functional goals.
Class diagram is the most robust when it is elicited from context diagram as well as goal graphs.

18. Non-functional Requirements
Techniques
User Interface Prototype
Analysis of different considerations from Volere
We include some simple screens to show the basic layout for different users. It is only for the purpose of easy understanding, please don’t restrict yourself to these screens. Also the requirements are written with advices from Volere Template.

19. Most Important Non-functional Requirements
Look and Feel Requirements & Usability and Humanity Requirements are most important to users in this product as they can directly feel these things when using.

20. Look and Feel Requirements Example
10a. Appearance requirements …
Examples
The product shall comply with the restaurant standards, e.g. the furnishing style, the style of cuisine, and the client’s other products.
Fit Criterion
The office of standards shall certify the product complies with the current standards.

21. Usability and Humanity Requirements Example 1
11a. Ease of use requirements …
Examples
The product shall be easy for 11-year-old children and 60 year-old people to use.
The product shall provide call to waiter for service / help when something can’t be done automatically happens.
Fit Criterion
80% of a test panel of 11-year-old children and 60 year-old people shall be able to successfully complete order of dishes within 5 minutes.
The user interface of customers should provide a ‘call waiter’ button.

22. Usability and Humanity Requirements Example 2
11b. Personalization and internalization requirements …
Examples
The product shall retain the customers paying preferences.
The product shall allow the user to select a chosen language.
Fit Criterion
The customer is able to pay in cash / card according to his wish.
The customer is able to choose from the following main languages in the world: English, French, German, Spanish, Italian, Portuguese, Chinese, Japanese, and Russian.

23. Customer General Order Window

24. Customer Detailed Order Window

25. Customer Order Confirmation Window

26. Non-Functional Requirements Lessons Learned
Non-functional requirements are important, but you should express them clearly with proper fit criterions, so it can be tested in a reasonable way.
User interface prototype is good to help people to understand, but it shouldn’t put any restrictions to your ideas.

27. Card Payment component
open issues
the supplier’s supply system is not determined.
Off-the-shelf solution
Ready-made component
reusability
Card Payment component
complete reuse
Reporting component
very high
Game component
high
TV component
Logistics component
New Problems
changing of the culture of the restaurant
the decrease of the customer throughput
lack of inter-personal communication for waiters

28. Effort in different phases
Inception
Elaboration
Construction
Transition
Initial
Elab1
Elab2
Requirement
Analysis & Design
Implementation
Testing
Life-Cycle Support

29. Project plan: Gantt Chart

30. User Documentation and Training
Cost
Schedule: 8 months
Numbers of staff: 4
Money: 480,000
Equipment: 100,000
Prototypes: 100,000
Development Staff: 280,000
Waiting Room
entertainment component
User Documentation and Training
1. Requirement Document
2. Design Document
3. System Instructions / Manuals
4. Training for staff including waiter, chef, stock manager

31. Risks

32. Thanks you !!!