iDine System: Analysis of Requirements, Use Cases, and System Design

This report provides a detailed analysis of the iDine system, designed for restaurant management. It begins by outlining both functional and non-functional requirements, detailing how the system manages ordering, waiter interactions, order processing, and data storage, while ensuring real-time data flow and usability. The report then presents a use case diagram illustrating the interactions of various actors, including customers, waiters, cooks, and management. A domain model class diagram visualizes the system's structure, showing classes like Customer, Order, and Food, and their relationships. Furthermore, event partitioned system models are included to show the flow of events and activities in the system. Finally, the report concludes by discussing the SDLC model activities, including environment setup, application component design, and user interface design, to demonstrate the development lifecycle of the iDine system.

Running head: ELABORATION PHASE
Assignment 2
Name of the Student
Name of the University
Author’s Note:

2ELABORATION PHASE
Table of Contents
1. Functional and Non-Functional Requirements:...........................................................................3
2. Use Case:.....................................................................................................................................7
3. Domain Model Class Diagram:...................................................................................................9
4. Event Partitioned System Models:.............................................................................................10
5. SDLC Model Activities:............................................................................................................11
Bibliography:.................................................................................................................................12

3ELABORATION PHASE
1. Functional and Non-Functional Requirements:
The functional requirement will state the behavior of iDine system. Each of the
functional requirement would associated with one behavior of system. The system functional
requirements starts user recognition and ends after generating reports. Operation of a system is a
loop and functional requirements denotes the features of the loop.
Ordering: Each of the tables will have an individual tablet. This tablet will be called as
tabletop tablet. Each of these tablets will have a digital menu installed within it through which
orders can be made. All these tablets will be connected to the main system through a wireless
connection. Each electronic device has a MAC address and this address will be the unique
identification number of the tablet. Each device will be assigned to a fix table. However, the
table number can be changed if the management wants. The customers will select foods that they
want to order through this tabletop tablet digital menu. They can also customize the order if they
want. Some customers are not able to understand how to use the digital menu so they prefer old
fashioned way of giving order. The customer will click on call waiter button and the head waiter
will send a waiter to take the order. The waiters will have a handheld device that will also have a
digital menu. No matter how the order is placed, the processes like preparing food, delivering
food and other processes is done same way.
Involve Waiter: The waiters are inalterable part of Vallée de Goût. No matter how much
technological advancement is introduced to the organization, the waiters will be needed to take
order and deliver food to tables. The waiter head will manage all the waiter related activities. The
waiter will make orders for the customers if they request. After the food is ready, the waiter will
serve the food to the customer tables. The head of the waiter will see the notifications of

4ELABORATION PHASE
customer requesting a waiter and order is being marked as ready. The head waiter will assign an
available waiter to take orders or service food.
Order Processing: The system will forward the order after it is confirmed by the
customer. These orders will have different food items. The system will categorize each of the
ordered food based on predefined conditions. The system will have information on which area of
the kitchen is dedicated to prepare which food. Taken as an example, different areas of kitchen
will prepare salad, sauce, soup and many more category of food differently. The system will be
connected to the printers in each are so that orders can be printed. This will allow the
organization to prevent any order related issue that used to occur due to bad handwriting of the
waiters. The cook will have a UI through which they can mark an order as ready. It is not
mentioned whether the cook can mark the status of preparing or not.
Login: The login is an essential security related aspect of any system. The login function
allows the system to verify a user’s access to the system. The login is the authentication feature
of the proposed iDine system. To login, every user must have a unique identification number and
a password. The system will employ a security measure for maintaining quality of the password
so that guessing the password cannot be possible for third person. The users will have login
credentials are waiter, waiter head, cook and management. The tabletop tablets will be logged in
to the system using the hardware MAC address. This way the system will have complete control
over who will access the system.
Access to Function and Data: The system will protect the data and operations by
implementing different authorization levels. Each of the user authorization level will determined
based on the user’s unique identification number. The system will allow a user to access
requested data or function based on the authorization level. This illustrates that the system will

5ELABORATION PHASE
distinguish if the user has permission to access the requested data or not. Taken as an example,
the management and a waiter cannot have same authority over the system. The same is for other
users of the system. The authority is determined based on the interaction of the user with the
system.
Ingredient Stock Management: The system will be equipped with the information of the
ingredients required to prepare a food. After each food is prepared, the system will reduce the
amount of ingredient from the inventory based on the amount of food prepared. The system
inform the management if an ingredient stock becomes low in quantity. The management can
also check the actual physical stock and update the stock amount if it differs from system data.
See Reports: Reports are most vital part for getting an overall idea of the business
activities. The system will produce reports based on the data stored in the database of the system.
Each of the reports will be based on different aspect of the business.
Data Storage: The data storage is integral part of any digital system. The system will
store the login credentials, order, food, ingredient and payment related information in the
database. The database will be connected to the core of the iDine system. The organization can
choose to implement a cloud based database or an in-house database. The in-house database will
be using storage disks or magnetic tapes for storing the data in physical format
The non-functional requirements of iDine will determine the behavior of the system.
System Availability: The primary requirement from the system is that it will be available
while the restaurant is open. The system is proposed for implementing an alternative approach
toward the operation management and customer relationship handling. If the system becomes
unavailable during working period, the whole business operation of Vallée de Goût.

6ELABORATION PHASE
Real-time Data Flow: The business operates on many dynamic aspects like availability
of ingredients, available waiters and many more. The system must flow the data among various
users and system units in real time. This means that the data will be visible to the users before it
is even stored in the database. This will increase the management of waiters significantly.
Usability: The users of the system will not be technical experts. None of the internal staff
of Vallée de Goût such as waiter, waiter head and cook has ever used any information system to
operate their job. To attain customer loyalty, the system must provide them an easy to understand
user interface from which giving orders can be extremely easy. The quality of user interface will
have a tremendous impact on the business as the users will not need bother about how to use the
system. Instead, those users concentrate on their jobs.
Supportability: Vallée de Goût is not a huge organization that can afford huge amount of
maintenance cost. The cost-effective maintenance of the system is expected from the proposed
iDine information system.

7ELABORATION PHASE
2. Use Case:
Figure 1: Use Case Diagram of iDine
(Source: Created by Author)
The actors of the iDine system are as following.
Customer: The customer is the external user of the system. This customer do not have
any personal account in the system. Instead, their activities will be measured through the tabletop
tablet they use.
Waiter Head: The waiters of Vallée de Goût will work under a supervisor and the
supervisor is the waiter head. The waiter head will acknowledge and send a waiter when
customer will request a waiter’s assistance or order is marked as ready.

8ELABORATION PHASE
Cook: The cook is responsible for preparing the food and marking the order as ready
when the food if prepared.
Waiter: The waiter will work as an intermediate service person who will make order for
the customer and serve food from kitchen to customer table.
Vallée de Goût: The organization will be monitoring and controlling the system along
with all the activities done within it. They can also see reports based on the business activities.
The use case of the iDine System are as following.
Give Order: The customer will be responsible for giving an order directly or indirectly.
The customer will use the tabletop tablets for placing an order. The waiter can also place an
order for the customer. The order will be placed for a table number. All the orders will calculated
through the table from which it is placed.
Request Waiter: Not all the customers will be able to use the tabletop tablet for placing
an order. In such cases, the customer will click on the button ‘call waiter’ for requesting a waiter
to collect order.
Send Waiter to Take Order: The waiter will be sent by the head waiter when a customer
will request for a waiter to place order.
Mark Order Ready: The cooks will be responsible for this use case. The system will
acknowledge the food as prepared when the cook will mark the order as ready.
Appoint Waiter to Deliver Food: The head waiter will send an available waiter to serve
the food to the tables

9ELABORATION PHASE
See Reports: The system will generate reports for each of the business activities, profits
and system audits.
Update Inventory Details: The owner of the organization will check inventory and
manually update stock if something is wrong.
Pay for Order: The system will check which table has ordered which food and calculate
the total amount of food ordered. Based on the order details, the payment will be calculated.
3. Domain Model Class Diagram:
Figure 2: Domain Model Class Diagram of iDine
(Source: Created by Author)

10ELABORATION PHASE
The domain model class diagram shows the attributes and the operations of each classes
of Vallée de Goût’s iDine system. The diagram shows that the class has total seven classes. Each
class is for supporting the use cases identified in the previous task. The customer class stores the
information of the customer. The customer details are required to generate bills. The customer
can place order through two different ways such as using tablet and waiter. For this reason, the
tablet and waiter are shown as generalization relationship with the Order class. The Payment
class will be used for representing the payment related structural patterns for the system. The
food class will be created based on the ingredients class therefore, the class will have
composition relationship among them. The orders are created based on the Foods ordered. That
is why they will have composition relationship among them.
4. Event Partitioned System Models:
Figure 3: Event Partitioned System Model of iDine
(Source: Created by Author)

11ELABORATION PHASE
5. SDLC Model Activities:
Environment: The system will be developed in an in-house system. The hardware of the
system will be implemented in the premise of Vallée de Goût. The organization will purchase the
system application that will be installed in every system. The environment of the system will be
decided in the planning phase. It is the first phase of the SDLC model.
Designing Application Components: The application will have different components that
can be implemented for different aspect of the system. Each of the units will be supporting
different business processes and activities of the system. The business analyst will collect the
information of the business requirements. The system analyst will convert those business
requirements into system requirements. Requirements are further evaluated for defining the
components. This is done in the analysis phase of the SDLC based project.
User Interface: The user interface is designed by the system interface designers. These
designs are mainly done through the interface designing applications like Balsamiq or Adobe CC
or Sketch. The user interface provide a detailed graphical representation of the system.
The Database: The system database will be developed using the relational database
applications. This is done in the development phase of the application. The user interface will
provide the base for identifying the inputs for the database.
The Software: The software will be developed and tested through the development and
testing phase.

12ELABORATION PHASE
Bibliography:
Ahmad, M., Belloir, N., & Bruel, J. M. (2015). Modeling and verification of functional and non-
functional requirements of ambient self-adaptive systems. Journal of Systems and
Software, 107, 50-70.
de Vasconcelos, J. B., Kimble, C., Carreteiro, P., & Rocha, Á. (2017). The application of
knowledge management to software evolution. International Journal of Information
Management, 37(1), 1499-1506.
Eckhardt, J., Fernández, D. M., & Vogelsang, A. (2015, October). How to specify non-functional
requirements to support seamless modeling? A study design and preliminary results.
In Empirical Software Engineering and Measurement (ESEM), 2015 ACM/IEEE
International Symposium on (pp. 1-4). IEEE.
Eckhardt, J., Vogelsang, A., & Fernández, D. M. (2016). Are" Non-functional" Requirements
really Non-functional? An Investigation of Non-functional Requirements in Practice.
In Software Engineering (ICSE), 2016 IEEE/ACM 38th International Conference on (pp.
832-842). IEEE.
Eckhardt, J., Vogelsang, A., & Fernández, D. M. (2016). Are" Non-functional" Requirements
really Non-functional? An Investigation of Non-functional Requirements in Practice.
In Software Engineering (ICSE), 2016 IEEE/ACM 38th International Conference on (pp.
832-842). IEEE.
Idani, A., & Ledru, Y. (2015). B for modeling secure information systems. In International
Conference on Formal Engineering Methods (pp. 312-318). Springer, Cham.

13ELABORATION PHASE
Ilieva-Obretenovaa, M. (2016). Information System Functions for SmartGrid
Management. Sociology, 6(2), 96-103.
Khan, F., Jan, S. R., Tahir, M., Khan, S., & Ullah, F. (2016). Survey: Dealing Non-Functional
Requirements at Architecture Level. VFAST Transactions on Software Engineering, 9(2),
7-13.
Marrella, A., Mecella, M., Russo, A., Steinau, S., Andrews, K., & Reichert, M. (2015). Data in
Business Process Models, A Preliminary Empirical Study (Short Paper). In Service-
Oriented Computing and Applications (SOCA), 2015 IEEE 8th International Conference
on (pp. 116-122). IEEE.
Plataniotis, G., Ma, Q., Proper, E., & de Kinderen, S. (2015). Traceability and modeling of
requirements in enterprise architecture from a design rationale perspective. In Research
Challenges in Information Science (RCIS), 2015 IEEE 9th International Conference
on (pp. 518-519). IEEE.
Schlieter, H., Burwitz, M., Schönherr, O., & Benedict, M. (2015). Towards Model Driven
Architecture in Health Care Information System Development.
In Wirtschaftsinformatik (pp. 497-511).
Shiang, C. W., Halin, A. A., Lu, M., & CheeWhye, G. (2016). Long Lamai Community ICT4D
E‐Commerce System Modelling: An Agent Oriented Role‐Based Approach. The
Electronic Journal of Information Systems in Developing Countries, 75(1), 1-22.
Tran, H. T., & Feuerlicht, G. (2016). Service development life cycle for hybrid cloud
environments. Journal of Software.

14ELABORATION PHASE
Vashisht, V., Lal, M., Sureshchandar, G. S., & Kamya, S. (2015). A framework for software
defect prediction using neural networks. Journal of Software Engineering and
Applications, 8(8), 384.
Vashisht, V., Lal, M., Sureshchandar, G. S., & Kamya, S. (2015). A framework for software
defect prediction using neural networks. Journal of Software Engineering and
Applications, 8(8), 384.
Wichmann, A., Jäger, S., Jungebloud, T., Maschotta, R., & Zimmermann, A. (2016, April).
Specification and execution of system optimization processes with UML activity
diagrams. In Systems Conference (SysCon), 2016 Annual IEEE (pp. 1-7). IEEE.