Cafeteria MGMT System

HARAMAYA UNIVERSITY
Software Requirement Specification For: Team members

Dedefo Bona 1521/03
CAFETERIA MANAGEMENT SYSTEM OF MuhidinKedir 1620/03
ZeynuMisbah 1696/03
HARAMAYA UNIVERSITY
Cafeteria Management System of Haramaya University
HARAMAYA UNIVIRSITY
COLLEGE OF
COMPUTING
AND
INFORMATIC
S
Developed By:
Group Name: ID NO
DEDAFO BONA 1521\03
MUHIDIN KEDIR 1620\03
ZEYINU MISBEH 1696\03
Advisor:
DR.BANOTH RAJKUMAR
1 Software Specification Requirement For Cafeteria Management System

January 22, 2014
Haramaya University
ACKNOLEGMENT
First of all I would like to express our special thanks to Almighty Allah who helped me a
lot in all our life. Next we would like to express our deepest gratitude to our Department
SOFTWARE ENGINEERING for his all way help and kind assistance in our project.
Last but not the least we would like to give our best gratitude from bottom of my heart to
our advisor Dr. BANOTH RAJKUMAR for his valuableadvice and comments.

Figure pages
Figure: 1……………………………………………………………………….12
Figure: 2……………………………………………………………………….17
Figure: 3……………………………………………………………………….19
Figure: 4……………………………………………………………………….24
Figure: 5……………………………………………………………………….28
Figure: 6……………………………………………………………………….29
Figure: 7……………………………………………………………………….30
Figure: 8……………………………………………………………………….31
Figure: 9……………………………………………………………………….32
Figure: 10……………………………………………………………………….34
Figure: 11……………………………………………………………………….35
Figure: 12……………………………………………………………………….36
Figure: 13……………………………………………………………………….37
Figure: 14……………………………………………………………………….45
Figure: 15……………………………………………………………………….47
Figure: 16……………………………………………………………………….50

Table of contents pages

CHAPTER 1...................................................................................................................................7
1. INTRODUCTION..................................................................................................................7
1.1. Literature Survey...............................................................................................................7
1.2. Product Scope...................................................................................................................8
1.2.1. Application of the Project Output..............................................................................9
1.3. Intended Audience and Document Overview...................................................................9
1.4. Definition, Acronyms and Abbreviations.........................................................................9
1.5. Document structure.........................................................................................................10
CHAPTER 2.................................................................................................................................11
2. OVERALL DESCRIPTION...............................................................................................11
2.1. Product Perspective.........................................................................................................11
2.1.1. Description of the existing system...........................................................................11
2.1.2. Activities performed under the existing system......................................................13
2.2. Product Functionality......................................................................................................13
The main function that our system can provide includes the following....................................13
2.3. Users and Characteristics................................................................................................13
2.3.1. Cafeteria Managers..................................................................................................14
2.3.2. Tickers.....................................................................................................................14
2.3.3. Students....................................................................................................................14
2.4. Operating Environment...................................................................................................15
2.5. Design and implementation constraints..........................................................................15
2.6. User Documentation.......................................................................................................16
2.7. Assumptions and dependencies......................................................................................16

CHAPTER 3.................................................................................................................................17
3. SPECIFIC REQUIREMENTS...............................................................................................17
3.1. External Interface Requirements.........................................................................................17
3.1.1. User Interface Facilities...............................................................................................17
3.1.2. Hardware Requirements..........................................................................................19
3.1.3. Software Interfaces..................................................................................................20
3.1.4. Communication Interfaces.......................................................................................20
3.2. Functional Requirements................................................................................................20
a. Behavior Requirements......................................................................................................22
i. Use Case View................................................................................................................22
CHAPTER 4.................................................................................................................................25
4. OTHER NON-FUNCTIONAL REQUIREMENTS..........................................................25
4.1. Performance Requirements.............................................................................................25
4.2. Safety and Security Requirements..................................................................................25
4.3. Software Quality Attributes............................................................................................25
4.4. Reliability........................................................................................................................26
4.5. Availability......................................................................................................................26
4.6. Maintainability................................................................................................................26
4.7. Portability........................................................................................................................26
CHAPTER 5.................................................................................................................................27
5. ANALYSIS MODELS.........................................................................................................27
5.1. Sequence Diagrams.........................................................................................................27
5.2. Data Flow Diagrams (DFD)............................................................................................33
5.3. State Transition Diagrams (STD)...................................................................................36

CHAPTER 6.................................................................................................................................38
6. DESIGN CONSIDERATIONS...........................................................................................38
6.1. Design Goals...................................................................................................................38
6.2. Design Trade-offs...........................................................................................................39
6.3. Assumptions and Dependencies......................................................................................39
Assumptions...........................................................................................................................39
Dependencies..........................................................................................................................40
6.4. General Constraints.........................................................................................................40
CHAPTER 7.................................................................................................................................43
7. SYSTEM DECOMPOSITION............................................................................................43
7.1. Subsystem Interaction.....................................................................................................43
CHAPTER 8.................................................................................................................................46
8. USER INTERFACE DESIGN............................................................................................46
8.1. Class Design....................................................................................................................46
8.2. Detailed Design...............................................................................................................48
8.3. Entity Relationship..........................................................................................................49
9. APPENDIX...........................................................................................................................51
10. REFERENCE.......................................................................................................................52

CHAPTER 1
INTRODUCTION
1.1. Literature Survey
The present Haramaya University can be traced back to the agreement made in 1952 between
the governments of Ethiopia and the United States of America which resulted in the
establishment of the Imperial College of Agriculture and Mechanical Arts. Oklahoma State
University in the USA embarked on establishing physical plants and staff to run the college’s
academic, research and extension programs. The four-year B.Scs. in Agriculture was started at
Haramaya campus in 1954 with both limited staff and facilities available. The College became a
chartered member of Addis Ababa University following the contractual termination of Oklahoma
Stat e University in 1967. Consequently, it was re-named the Alemaya College of Agriculture in
1989. In the last few years, the University has witnessed tremendous expansion in the number of
faculties, departments, students, staff and physical infrastructure. Apart from undergraduate
programs, the university has widely been engaged in the expansion and diversification of
graduate programs at Masters and PhD level.
The cafeteria management system of Haramaya University which was the main subsystem of
the University was constructed at that time to give food services only for 300 students. The
manager of the cafeteria at that time was also American. The services that was given at that time
was very unique from today’s services because of the resource was more enough and the
numbers of users or student at that time was very limited; compared today’s services given by
the cafeteria to the students. For instance, according to the information we can get from the
workers that have many experience in the cafeteria the student can fetch the milk from the pump
where now they can fetch water from. The cafeteria hall that was constructed for giving services
for 300 students was give services for more than 1000 student; unfortunately, as the university
intended to expand its capacity to take many students in many fields of study the additional
cafeteria’s hall that can give food services for more than 6000 (senior cafeteria hall) was

constructed. Later on in 1996 E.C the fresh cafeteria hall which was give food services for more
than 5500 was constructed. Accordingly, at this time the cafeteria management system was
giving food services for more than 15,000 students which beyond its capacity at main campus.
To give food services in more sophisticated way to all these students, under the condition of
limited resource and many number of uses, for cafeteria management system of Haramaya
University (CMSHU)there must be a good and powerful computerized system, Since up to now
the this subsystem has no a well-structured add computerize system at all. This is why we can
select this project to develop the system that hopefully decreases the problem that was related to
cafeteria management system of the university.
1.2. Product Scope

The scope of our project is limited to the management of cafeteria management system of
Haramaya University. We limit our scope to only the activity that can be done by the managers
and automating ticking system of cafeteria subsystem due to the following constraints.
Among those constraints time, budget, and information accessing are the major ones. We
select the activity that can be done by the managers & automating ticking system of the
subsystem of the cafeteria management system of Haramaya University.
The activity of the manager of the cafeteria is the general managerial work done by the
managers. These activities are managing the resources that are needed for the cafeteria for giving
services to the students.The manager is responsible for giving meal card for student; control
whether services of foods and water ready on time, control whether the students are managed
properly while they are getting service, take a corrective action when the student make unethical
work and manage other worker of the cafeteria. It is also responsible for the management of
material that can play a great role to give the service to the cafeteria. Those materials are cups,
plate, that can student use directly and many other material that can used indirectly by the
student.
The atomization of the ticking system is the subsystem of the cafeteria management system
that can focus on the managing of the student while they are getting the food services from the
cafeteria.

1.2.1. Application of the Project Output

The output of this project could be applied in the real world for Haramaya University and
at the end of the completion of this project, cafeteria manager of our university will get a benefit
like:-
 Information accessing is easy and fast.

 Minimize the time that it takes to achieve a specific operation.
 Reduce the manpower required during the management activity and ticking
process.
 Reduce time and energy during the process like urgent case shift of service
schedule, applicant registration for meal card.
 Easy to handle student record after they start using the cafeteria services
1.3. Intended Audience and Document Overview

According to the information we get from the cafeteria manager they use the manual system
to give food services to the students. This document contains the description of the software
requirements specification for the project of cafeteria management system of Haramaya
University. Those descriptions are Introduction, Overall Description, Specific Requirements,
Other Non-functional Requirements, Other Requirements, Analysis Models, Design
Considerations, System Decomposition, User Interface Design, Appendix, Glossary and the
detail description of each listed components.
1.4. Definition, Acronyms and Abbreviations
CMSHU => Cafeteria Management System of Haramaya University
HU=>Haramaya University

CMS => Cafeteria Management System
DFD => Data Flow Diagram
1.5. Document structure

The document structure can explain in short the entire of document in precise and easy
manner. There are the overall description of the system, which contains the product perspective,
description of the existing system, product functionality, users and their characteristics, operating
environment, design and implementation constraints, user documentation and assumption and
dependence;the specific requirement which contain external interface requirement, functional
requirement and behavior requirements and other non-functional requirement which contains
performance, safety and security requirement, software quality attributes, reliability, availability,
maintainability and portability. Under analysis models there are the description of sequence
diagram, state transition diagram and under the design consideration there are the description of
design goals, design trade off, assumption and dependence and general constraints. In system
decomposition there is about subsystem interaction and under user interface design there are
about class diagram, detailed design and entity relationship.
In general this document describes all about process in through our project is developed.

CHAPTER 2
2. OVERALL DESCRIPTION
2.1. Product Perspective

Studying the existing system brings about an important contribution to the entire
development process. It is only after doing this phase that we can realize what is going wrong,
what to change, what activity or practice to encourage, and what alternative solution to propose.
2.1.1. Description of the existing system

The cafeteria management system of HU is a manual system. This system has some
drawback like managing workers and student while they are using the cafeteria services, which
leads to be unmanageable. Since it works manually, information accessing is very slow and to
get some task to be accomplished it goes through many processes and this is time consuming.
The cafeteria management system has four major subsystems namely workers management,
resource management, operational management and students management during they are
getting the service from cafeteria. Among these subsystems we are going to automate the worker
management and student management subsystem that can involve in the cafeteria services. Since
activities CMSs are performed in the manual system, there are many drawbacks starting from
giving the meal card to student up to managing them while they are using the services and the
managing whether the workers of the cafeteria giving the appropriate work or not. Our aim is to
make the worker management and ticking system computerized and so that the problems faced in
the manual system will be minimized. The purpose of this subsystem is to automate and manage
the worker management and ticking system.
The organizational structure of the existing system is shown below and the location of the
system we are going to automate is also presented there in the hierarchy of the organization
structure.

The structure of the cafeteria management system
Head of cafeteria
Assistant chief
Worker leader Head ticker Resource leaders Operator

leaders
Shift leader Guar Tickers

Laundry Boiler
d
(Ticking system) operators operators
Junior shift
Store men Injera house Bread

leader store
controller
Cook Dish Food
washer prepare
Dough Injera
makers prepare
Fixed asset Consumable Vegetable

store men store men store men
Figure: 1 the architectural structure of the cafeteria management system
2.1.2. Activities performed under the existing system

Activities performed in the existing system of HU cafeteria management system isdone
manually. Starting from giving the meal card to the student, which can take many times and need
many labor force up to ticking the student meal card while they are entering the cafeteria hall to
get food services.
The ticking system the CMSHU is using now is first they can print the meal card that has
its unique numbers for each student and distribute it for all students. This need much manpower
and many effort of that manpower and approximately takes up to two weeds. This meal card is
only used only for one semester and the process is continuous in the second semester. These can
take much time, much manpower effort and many losses of printed papers every semester. After
that when the student use the cafeteria service the Ticker can tick for all students for breakfast,
lunch and dinner three times a day. This is a difficult work to control those much student
properly.
2.2. Product Functionality
The main function that our system can provide includes the following.
Our system can:
 Generate the students Id’s barcode to each student.

 Checks the students Id’s barcode to get the cafeteria services.
 After checking it can welcome the student to get the cafeteria cervices.
 When the students try to enter the cafeteria twice it can reject this kind of students.
 While rejecting the student the system generate the reports of this student to the manager.
 The system produces many kind of report to the manager.
 The manager can control the subsystems that are automated using this system

2.3.
2.4. Users and Characteristics

The users of these systems are cafeteria managers, tickers,students as a whole the
organization.
2.4.1. Cafeteria Managers

The system can provide many benefits to the managers in many ways. From those benefits:
 Economically the meal card printed on paper once in semester is reduced and one student
can use one ID’s barcode during all the life of his campus.
 Work load can be reduced for the managers. We can explain these in many ways like;
the printing and distributing the meal card to the student is stopped, controlling the case
of students that related meal card can be easily handled by the system, the report of
students that done unethical behavior are generated for managers by the system and
disciple of the punishments is also given by the system.
 The management of workers and the generation of workers report are also easy for the
managers.
 The managers can thick for how to improve the services given by CMS since the
difficulties that was facing the CMS solved by implementing this system.
2.4.2. Tickers
Tickers are persons that can tick the students’ meal card in the existing system of the CMSHU at
current time. Its work is also very difficult our system can provides those benefits to them.
 They can supervise the students only by looking them whether they checking their
Id’s barcode or not.
 Since they have no difficult work they can done their work properly.
2.4.3. Students

Students are the mainly benefited users from this system in directly to use the cafeteria
services as:
 The problem of getting the meal card in each semester that takes many of their time is
solved.
 The ID’s barcode is used for their entire life their campus when they properly handle it.
 When they enter the cafeteria hall they can easily check their ID’s barcode to get the
services.
 Since the numbers of unethical practice is reduced all students get fairly get the services.
And
Indirectly the students are benefited from this system as follows:
 When the system launched and the managers start to use the system, since the workloads
of the managers are reduced, the manager works for improving their service giving.
 Because of this the services that the cafeteria give to the student is improved.
2.5. Operating Environment

The operating environment of our system must need the server that can hold the students,
workers and managers’ database, the personal computer which placed in the cafeteria halls’ door
with which the student check their ID’s barcode to enter the cafeteria to get the cafeteria food
services and the barcode reader which connected to these pc.
2.6. Design and implementation constraints

A constraint is a package-able element which represents some condition, restriction or
assertion related to some element (that owns the constraint) or several elements. Constraint is
usually specified by a Boolean expression which must evaluate to a true or false. Constraint must
be satisfied (i.e. evaluated to true) by a correct design of the system. Constraints are commonly
used for various elements on class diagrams.
In general there are many possible kinds of owners for a constraint. Owning element
must have access to the constrained elements to verify constraint. The owner of the constraint
will be determining when the constraint is evaluated. For example, operation can have pre-
condition and/or a post-condition constraint.

UML specification does not restrict languages which could be used to express
constraint.Frameworks are designed to speed up development and of course they each have their
own limitations. I personally develop sites using whatever makes sense to develop them with,
which could be anything from ASP.NET!
Web developers are essentially solution developers, so it is our job to pick the right tools
for the job. If you want to hand code sites using javascript and ignoring the abstractions that you
could use by implementing frameworks, then good luck to you, it sounds like an epic endeavor,
and I hope your client is willing to finance your voyage!
2.7. User Documentation

The user documentation is the maul that can help the user of our system after the
development of the system is over start using it. This document is developed as it can help them
before they use the system, while they use the system and after they use the system or when the
face the problem they can refer it to understand what problem they face. It can guide them easily
to use the properly.
2.8. Assumptions and dependencies
As we mentioned above the internet access is very necessary for our projects to be
successfully developed. And when there are problem with internet access it is difficult to our
project to be successful. Other constraints are shortage of time, difficulties to get information, the
problem of resource.
HTTP is the short form for Hyper Text Transfer Protocol, the underlying protocol used
by the World Wide Web. HTTP defines how messages are formatted and transmitted, and what
actions Web servers and browsers should take in response to various commands. For example,
when you enter a URL in your browser, this actually sends an HTTP command to the Web server
directing it to fetch and transmit the requested Web page.

FTP is an acronym for File Transfer Protocol. As the name suggests, FTP is used to
transfer files between computers on a network. You can use FTP to exchange files between
computer accounts, transfer files between an account and a desktop computer, or access online
software archives. Keep in mind, however, that many FTP sites are heavily used and require
several attempts before connecting.
The system can be interconnect with the database of the students that were found in the
register and also work with the website of Haramaya University to give some information to the
students about the cafeteria.
CHAPTER 3
3. SPECIFIC REQUIREMENTS
3.1. External Interface Requirements
3.1.1. User Interface Facilities

Since the knowledge of users and their acquaintance of the current information and
communication technology facility differ and therefore the system should provide an easy way to
user interface which would be able to interact in a friendly manner with the system. The major
user interfaces available are the manager login form, the ticker login form, and the error
messages box that in form the user name and password is error and the students’ Id’s barcode
scanning interface and the message box that tell whether the student is checked his Id’s barcode
before that or not.

Figure: 2 manager login form
a. Response facilities: Response time of the system is a considerable issue. Because

result of the request of the employee should be provided within a short period of
time like printing the report, searching for students and workers for any purpose,
scanning the students Id’s barcode automatically using barcode reader.
b. Documentation
This system will provide three types of systems documentations. They are Internal
Documentation, User Documentation, and External Documentation.
i. Internal documentation:
Internal documentation is the program source code when the system is

implemented. We will add some sample codes there in the implementation
phases.
ii. User Documentation :
User documentation is to help the user of the system as a reference if they

have any problem before, during and after using the system.
In our system the user documentation is for the system administratorof

cafeteria managers and tickers. And the documentation on user interface
documentation is brief and enough to understand easily and interact with the
system.
iii. External Documentation:
External documentation contains the scenarios: use-case models the class

diagram, entity relationship, sequence diagram, data flow diagram, and state
transition diagram and user interface documentation.
Figure: 3 user login form
3.1.2. Hardware Requirements

We consider the hardware requirements; we divide it in to user side requirements
and administrative (server) side requirements.
1. User Side: - minimum requirements for users to access the system

Personal computer (Intel(R) Pentium (R) 4 CPU 2.5GHz, 256 MB of RAM,

40GB of Hard Disc)
2. Barcode readers: is the user side requirement that must be needed to

implement our project.
When we say user’s side, we mean the tickers that can control the student
whether they are following the instruction or not and the students that can
check his Id’s barcode to entering the cafeteria for getting services.
3. Administrative Side: -minimum mandatory hardware for the realization of the

system
Database Server: -A server used to store the student record. (Intel(R)
Pentium (R) 4 CPU 3GHz, 512MB of RAM, 80GB Hard Disc)
Database server: located inside the cafeteria managers office and used to store the
whole data under the cafeteria manager office related to students that getting services from the
cafeteria.
Personal computer and barcode readers can be presented near the entering door of
the cafeteria hall to check the studentsId’s barcode to enter the cafeteria.
3.1.3. Software Interfaces

The mandatory operating system to run our system is window 7 and window 8 operating
system. The other software that are needed to our system need the Mozilla browser, ASP.NET,
for front end of the system for the user interface and SQL Server for back end of the system as a
server.
3.1.4. Communication Interfaces

The communication way in our system is the communication between the clients that
means the user interface of the manager, the personal computer that is used in the cafeteria hall
to check the students Id’s barcode to get the food services and the server that store the database.

Another communication way is how the system administrator allows the data accessing
permission to his co-worker. This includes the way of creating an account to that co-worker and
allowing some data permission to access it. To protect their data security the system allows the
security mechanisms to protect their data from an allowed person to access the data.
3.2. Functional Requirements

Functional requirements are mandatory requirements that must be incorporated in any
system. Among the functional requirements included in our system are:
1. Provides information about HU students
Since the existing system of cafeteria management system of HU particularly in

giving the meal card and ticking system is the major tasks that done to give service while the
student are using the cafeteria.
2. Data storage and Retrieval
The system store student record and information related to the Id’s barcode and the
process how to distribute to the student and should retrieve the information when necessary. The
Retrieval of information should be easy and data should be saved properly in a well-organized
database server so that the process of data retrieving would be simple and faster.
3. Enquiries and Reports facilities
The system must incorporate reports generalization facilities so that an administrator of

the system can easily filter out the reports of each task.
The functional requirement of the system is to reduce the degree of occurrence of the above
mentioned problems. So it is very crucial to identify the input and output requirements of the
proposed system.
The functional requirements of the giving Id’s barcode and scanning system are the inputs
and outputs necessary for this subsystem.

4. Input Requirements
When we say the input requirements of the system, we mean the process or the preconditions
that should be fulfilled to produce the desired output: that is the inputs starting from students
registered to this campus and getting the services of the cafeteria, and the inputs and output
requirements are listed below.
5. Registration of Student to the Campus
 The system must be able to handle a database of registered student.
 It should assign system generated unique number for each Id’s barcode
 It must handle detail of student information like name, photo, id number, dept.,
and year.
 It should check the Id’s barcode of the student while he/she use the cafeteria food
services.
a. Behavior Requirements
i. Use Case View

The use-case approach requires the analyst to determine all the potential actors involved in a
system. Actors are external to the system and make use of it. An actor is typically a person, but
may be a third-party organization or another computer system. We model actors, not individuals.
An actor makes use of a system in different ways. Each of these ways is known as a use-
case. Use-case is “a behaviorally related sequence of transactions (performed by a user/actor) in
a dialogue with the system”. A use-case may involve a number of actors, just as an individual
actor may make use of several use-cases. We represent use-case diagrammatically by ovals and
actors by stick men.
In our system we have three actors. Those are:
1. managers
2. tickers and
3. students

The cafeteria managers have many interactions within the systems. Among this the major one
is seeing the report of the student and the workers. By looking this report when he see unethical
student or worker which break the principles of the cafeteria management system for the first
time he can advise them. If the worker or student can do the same thing for the second time, for
the purpose of correcting them he can punish them by using the principles of the cafeteria.
Another actor of the cafeteria management system is the tickers. His/her responsibility in the
existing system is to control and tick the meal card of the student while they come to use the
food service from cafeteria. After this system is implemented the role of the ticker can be
controlling the student, ready the system to use for student and reporting the student that can
done unethical work when the system is not get student’s Id’s barcode.
Students are the most benefited and the mean actor of this system. They can get their Id’s
barcode easily.
After getting the Id’s barcode one’s they can use it while the entire life of theiruniversity.
Even if the Id’s barcode will be lost from them regaining their Id’s barcode is not difficult to
them since the system reduce this activity.
More Description of actors
Actor Name Cafeteria managers
Use case:  Reporting the servicing capacity cafeteria to the

student to the office of register
 Register the student to give id’s that have barcode
 Control the students while they getting the services
Actor Name Tickers

Use case:  Supervise the students while they are entering the
cafeteria
 reporting the unethical students

Actor Name Students
Use case:  Check their id’s barcode
 Enter the cafeteria hall
 Get the food services
An actor represents anything that needs to interact with the system to exchange
information. An actor is a user, a role, which could be an external system as well as a person. An
actor initiates the system activity, a use case, for the purpose of completing the some business
task.
Table of actors and their description

Figure: 4 use case diagram.

CHAPTER 4
4. OTHER NON-FUNCTIONAL REQUIREMENTS
4.1. Performance Requirements

Performance characteristics include:-speed constraints: this system will be accessed by
authorized CMS and it will handle huge amounts of students’ record, worker record and some
material record. Therefore it is important to consider the speed of access data from the database.
 Response time, the speed imposed on the system. The system should
responsive maximum number of tasks with minimum times.
 Throughput: number of tasks accomplished in a fixed period of times.
 Memory: memory space available for speed optimizations should use

efficiently.
4.2. Safety and Security Requirements

Consideration of the security issue has a great advantage for our system, because the database
server should be secured from the unauthorized users. Only the system administrator (the CMS
should use system for security purpose) and those who have access permission. To prevent from
the unauthorized user, the administrator should have a password and it is used privatized only for
who has access rights. The admin password should be managed properly to assure the system
security confidentially. To do this our system introduces the hash security authentication for the
manager of the cafeteria.
4.3. Software Quality Attributes

Requirements for reliability and it includes:-
1. Needs for Back up: It is a mechanism of saving files to protect it from

accidental deletion. The user of the system should use daily backup files save
the record.
2. User requirements: the system should be work as the requirements of the

users.

3. Technical issues: E.g. pseudo code, user friendly pages, layouts, conventions
etc.
4. System portability: ability to work in different platform
4.4. Reliability
That’s no system error so far from testing, therefore the system is reliable. All
information modified or uploaded by user didn’t lead to any conflict or error to the system.
4.5. Availability
In computer systems and networking, availability is a general term that is used to
describe the amount of time over a one-year period that the system resource is available in the
wake of component failures in the system. Our system can also available to give services and as
it needed it can be maintained.
4.6. Maintainability
Maintainability is characteristic of designand installation which determines the
probability that a failed equipment, machine or system can be restored to its normal operable
state within a given timeframe, using the prescribed practices and procedures. Its two main
components are serviceability (ease of conducting scheduled inspections and servicing) and
reparability (ease of restoring service after a failure).
4.7. Portability
The system is able to run on different platform as long as operating system is installed.

CHAPTER 5
5. ANALYSIS MODELS
5.1. Sequence Diagrams

Sequence diagrams are used to depict graphically how objects interact with each other via
messages in the execution of a use case or operation. Sequence diagrams highlight more the
temporal aspect, by showing invocation and responses along a (vertical) timeline and by
explicitly showing the activation time of objects. Sequence diagrams show how objects
communicate with each other in terms of a temporal sequence of messages. The time flow is the
most visible aspect in these diagrams, as messages are sequenced according to a vertical timeline
and also the lifespan of objects associated to those messages is reported. They illustrate how the
messages are sent and received between objects and in what sequence.
Our system design needs many sequence diagrams to simplify the development the system
throughout this project. Among those sequence diagrams the most needed in our project is
illustrated below.

Figure: 5 sequence diagram that show how cafeteria manager login to the system

Figure: 6 sequence diagram of how the student take Id’s barcode

Figure: 7 sequence diagram show how the manager give special food userId for student

Figure: 8 sequence diagram that show how student punished

Figure: 9 sequence diagram that show how the worker punished

5.2. Data Flow Diagrams (DFD)
A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an

information system. DFDs can also be used for the visualization of data processing (structured
design).On a DFD, data items flow from an external data source or an internal data store to an
internal data store or an external data sink, via an internal process.
A DFD provides no information about the timing or ordering of processes, or about whether
processes will operate in sequence or in parallel. It is therefore quite different from a flowchart,
which shows the flow of control through an algorithm, allowing a reader to determine what
operations will be performed, in what order, and under what circumstances, but not what kinds of
data will be input to and output from the system, nor where the data will come from and go to,
nor where the data will be stored (all of which are shown on a DFD).
When it comes to conveying how information data flows through systems (and how that data
is transformed in the process), data flow diagrams (DFDs) are the method of choice over
technical descriptions for three principal reasons.
1. DFDs are easier to understand by technical and nontechnical audiences.

2. DFDs can provide a high level system overview, complete with boundaries and
connections to other systems.
3. DFDs can provide a detailed representation of system components.
DFDs help us the system designers and others during initial analysis stages visualize a
current system or one that may be necessary to meet new requirements. Systems analysts prefer
working with DFDs, particularly when they require a clear understanding of the boundary
between existing systems and postulated systems. DFDs represent the following:
1. External devices sending and receiving data

2. Processes that change that data
3. Data flows themselves
4. Data storage locations

Among the data flow diagram we are presented here the flow of the information how the
system check for login processes during the login time. When the manager or users want login
the system ask username and password to be entered. After that the system can check from
database for username and password. This is illustrates below by data flow diagram.
Figure: 10level 0 data flow diagram

Figure: 11 level 1 data flow diagram

5.3. State Transition Diagrams (STD)

The basic idea state transition is to define a machine that has a number of states (hence the
term finite state machine). The machine receives events from the outside world, and each event
can cause the machine to move from one state to another. These diagrams therefore identify what
events can occur in a system, and what effect they can have on the object. Diagrams of this type
can provide a good sense of the events that can occur in a system and the effect they have on the
object.
Figure: 12 login state diagram

Figure: 13 scanning ID’s barcode state diagram

CHAPTER 6
6. DESIGN CONSIDERATIONS
6.1. Design Goals

System design is the process and focuses on decomposing the system into manageable
parts. During requirements gathering and analysis, we concentrated on the purpose and the
functionality of the system. During system design, we focus on the processes, data structures,
and software and hardware components necessary to implement it. The challenge of system
design is that many conflicting criteria and constraints need to be met when decomposing the
system.
The analysis model describes the system completely from the actors’ point of view and
serves as the basis of communication between the client and the developers. The analysis model,
however, does not contain information about the internal structure of the system, its hardware
configuration or more generally, how the system should be realized. System design is the first
step in this direction. System design results in the following products:
 List of design goals, describing the qualities of the system that developers should
optimize.
 Software architecture, describing the subsystem decomposition in terms of

subsystem responsibilities, dependencies among subsystems, subsystem mapping
to hardware, and major policy decisions such as control flow, access control, and
data storage.
And the purposes of object –oriented design document is to provide an overview as to

how to actually be used the proposed system and to obtain the information needed to derive the
actual implementation of CMS of Haramaya University.
In this documentation we have represented the basic design of our system through two basic
UML models sequence diagram, state diagram, class diagram, data flow diagram, user interface
design and entity relationship diagrams.

6.2. Design Trade-offs

During software development, tradeoffs are made on a daily basis by the people participating
in the development project. Different roles in the project have to handle different tradeoffs. Some
examples are that managers distribute work to developers and while doing so they have to
balance the workload between the developers and deciding how many people that should be
assigned to a particular task. If more people are assigned to a task then the task will be completed
faster, but adding more people past a certain point only serves to increase the overhead of the
group and in turn increases the time it takes to complete the task.
Developers in turn make decisions regarding design and implementation details. An example
is when software architects try to balance the quality attributes of the system. A balance of
functional as well as quality requirements has to be achieved so that the intended users of the
system will find it useful.
6.3. Assumptions and Dependencies
Assumptions
During a workshop, someone asked me what she should do if she doesn’t get all the
information that she needs to complete her requirements. I told her that assumptions were the
best way to cover these unknowns, and make the client responsible for saying if the assumptions
are correct or not. It’d be great to have the client look at these before you finalize the
requirements. However, we both know that we don’t live in a perfect world.
Assumptions are circumstances that you are assuming to be true in order for the project to
be successful. For instance, there was one project where the client would not tell us the hours of
operation (I still don’t get why). Therefore, we wrote an assumption to cover this, so that the
client couldn’t come back later saying that we should be operating 24/7. It read like this “We
assume that the hours of operation are between 7:00 a.m. and 9:00 p.m.”

Dependencies
The best way to describe dependencies is to talk about work-breakdown structures

(WBS). WBS is a way to breakdown larger tasks into smaller ones. When you are planning a
project, you use this breakdown and add resources and cost. You link tasks together that shows
that in order for one to happen, the first has to occur. It’s the same with dependencies.
Dependencies are relationships between requirements. A linkage that shows that one
requirement is dependent on another. A great example that I found online is:
Assumptions and dependencies are usually put in the same document section. The reason is
that they usually correlate because your dependencies are usually dependent on your
assumptions.
6.4. General Constraints
Project limitations may influence how you manage your project and may even determine
whether or not you (and your project’s drivers and supporters) decide to proceed with your
project. Project limitations typically fall into several categories. By recognizing these categories,
you can focus your investigations and thereby increase the chances that you’ll discover all
limitations affecting your project.
Your project’s drivers and supporters may have preset expectations or requirements in one or
more of the following categories:
 Results: The products and effect of your project

 Time frames: When you must produce certain results. For example, your project must be
done by June 30. You don’t know whether it’s possible to finish by June 30; you just
know that someone expects the product to be produced by then.
 Resources: The type, amount, and availability of resources to perform your project work.
Resources can include people, funds, equipment, raw materials, facilities, information,
and so on.

 Activity performance: The strategies for performing different tasks. For example,
you’re told that you must use your organization’s printing department to reproduce the
new users’ manuals for the system you’re developing. You don’t know what the manual
will look like, how many pages it’ll be, the number of copies you’ll need, or when you’ll
need them. Therefore, you can’t know whether your organization’s printing department is
up to the task. But at this point, you do know that someone expects you to have the
printing department do the work.
Be careful of vague limitations; they provide poor guidance for what you can or can’t do, and
they can demoralize people who have to deal with them. Here are some examples of vague
limitations and how you can improve them:
 Time frame limitation:

o Vague: “Finish this project as soon as possible.” This statement tells you nothing.
With this limitation, your audience may suddenly demand your project’s final
results — with no advance warning.
o Specific: “Finish this project by close of business June 30.”
 Resource limitation:
o Vague: “You can have Laura Webster on your project part time in May.” How
heavily can you count on her? From Laura’s point of view, how can she juggle all
her assignments in that period if she has no idea how long each one will take?
o Specific: “You can have Laura Webster on your project four hours per day for the
first two weeks in May.”
Determining limitations is a fact-finding mission, so your job is to identify and examine all
possible sources of information. You don’t want to miss anything, and you want to clarify any
conflicting information. After you know what people expect, you can determine how (or
whether) you can meet those expectations. Try the following approaches:
 Consult your audiences. Check with drivers about limitations regarding desired results;
check with supporters about limitations concerning activity performance and resources.

 Review relevant written materials. These materials may include long-range plans,
annual budgets and capital appropriations plans, benefit-cost analyses, feasibility studies,
reports of related projects, minutes of meetings, and individuals’ performance objectives.
 When you identify a limitation, be sure to note its source. Confirming a limitation
from different sources increases your confidence in its accuracy. Resolve conflicting
opinions about a limitation as soon as possible

CHAPTER 7
7. SYSTEM DECOMPOSITION
7.1. Sub system Interaction

The subsystem interaction is the description of the components of the program the can
developed in separate module or class and that can work for producing the desired output by
integrating together. The focus was on interaction between components (rather than the
conventional focus on transformation of data), and on composition, which in this domain needs
to be intrinsically concurrent (rather than the conventional thread-based applique of concurrency
on imperative models).
Composition is based on:
1. integration technologies for legacy and custom subsystems that provide an understanding
of the interaction of subsystems;
2. scalable composition mechanisms for system-of-systems architectures;
3. interface formalisms through which compatibility of subsystems can be checked and
properties of compositions can be determined from properties of the subsystems;
4. Ontology models for the organization of components together with a semantic type
system for the data on which they operate; and
5. Hybrid models for designing and analyzing the dynamics of subsystem interactions with
their physical environment. We assume that subsystems have arbitrary granularity, and
can range from simple software components to entire legacy systems appropriately
wrapped.
We focused on actor-oriented (AO) models, which complement object-oriented (OO)

component architectures with intrinsically concurrent subsystem coordination mechanisms. In
OO, components interact principally through transfer of control (method calls). At coarse
granularity, distributed objects interact through middleware that extends OO principles with
proxies that mask the distributed nature of the system. At still coarser granularity, middleware
services support a variety of strategies for managing distributed data and concurrent interactions,
including message passing, web services, transparent data replication, event marshaling,

transaction services, and distributed file systems. OO mechanisms focus instead on concurrent
semantics with disciplined, well-founded concurrency and communication mechanisms.
One major outcome of this project has been a model transformation technology that has
applications to model optimization, scalable model construction, joint management of product
families, design refactoring, and workflow automation. In the mechanisms that we have
developed, models construct models. The same modeling languages are used to specify a
scalable composition of components as are used to specify the component interactions.
Potential applications include large complex software systems, distributed systems, and
scalable parallel programming.

Figure: 14 system decomposition

CHAPTER 8
8. USER INTERFACE DESIGN
8.1. Class Design

Class diagram depicts the system’s object structure. They show object classes that the system
is composed of as well as the relationships between those object classes. UML class diagram
show the classes of the system, their inter-relationships, and the operations and attributes of the
classes. Class diagrams are typically used, although not all at once, to:
 Explore domain concepts in the form of a domain model
 Analyze requirements in the form of a conceptual/analysis model
 Depict the detailed design of object-oriented or object-based software
A class model is comprised of one or more class diagrams and the supporting
specifications that describe model elements including classes, relationships between classes, and
interfaces. Classes are shown as boxes with three sections – the top for the name of the class,
the middle for the attributes, and the bottom for the operations. Associations between classes are
depicted as lines between classes. Associations should include multiplicity indicators at each
end.

Figure: 15 class diagram

8.2. Detailed Design

Detailed design is a second level of design process. During detailed design we specify how
the module in the system interacts with each other and internal logic of each of modules
specified during system design is decided, hence it is also called as logic design. Detailed design
essentially expands the system design and database design. To contain a more detailed
description of the processing logic and data structures so that the design is sufficiently complete
for the coding.
The detailed design refines the system document. Hence first applicable document here is
system design. Also we are referring the data structure. Hence second applicable document is
database design.
The manager of the cafeteria management system has the overall data access permission and
the authority to give permission to the coworkers managed below its authority. The manager can
add or register new student to the database as it is needed, delete the students from the database
when the student finish getting service from the cafeteria service and update as necessary.
The ticker of the cafeteria has the responsibility to prepare the system for use when the time
of the service will on and control the student while they have getting the food service from the
cafeteria. The ticker can also help the students that have lost their ID’s barcode by entering their
ID No number to the system from the paper which have the signature of cafeteria managers and
allow them to get the food service until they get the ID’s barcode.
The students have the user of this product directly by checking their ID’s barcode to get the
food service from the cafeteria.

8.3. Entity Relationship
An entity-relationship diagram is a data modeling technique that creates a graphical

representation of the entities, and the relationships between entities, within an information
system. The three main components of an ERD are:
 Theentity is a person, object, place or event for which data is collected. For example, if
we consider the information system for a cafeteria management system, entities would
include not only student, but the student's ID’s barcode,name other information as well.
The entity is represented by a rectangle and labeled with a singular noun.
 The relationship is the interaction between the entities. A relationship may be
represented by a diamond shape, or more simply, by the line connecting the entities. In
either case, verbs are used to label the relationships.
 The cardinalitydefines the relationship between the entities in terms of numbers. An
entity may be optional:
The overall description of our entity relationship diagram is described below which contain
their relationship and their attributes.

Mname
Fname Lname
Status
Access permission
Position
ID No
Name
Fname
Mname
Lname
MANAGER
Name
ID No
MANAGES
MANAGES
TICKER
Position
Status
CONTROLSLS
ID No
STUDENT Year
Lname
Name
Mname
Branch
Cafeteria use door Department Fname
Figure 16 the entity relationship diagram

9. APPENDIX
A: actor
assistance
B: boiler operator
C: cafeteria management system
D: Dough makers, Dish washer
E: entity
G: guard
H: head of cafeteria
I: Injera
J: javascript
M: manager
R: Resource leader
S: Student,store men
T: ticker
W: work break down structure

10. REFERENCE
www.haramaya.edu.et
www.freestudentprojects.com
ASP.NET 4 in C# and VB Book

Cafeteria MGMT System

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cafeteria MGMT System

Uploaded by

Copyright:

Available Formats

HARAMAYA UNIVERSITY

Software Requirement Specification For: Team members

DEDAFO BONA 1521\03

MUHIDIN KEDIR 1620\03

ZEYINU MISBEH 1696\03

1 Software Specification Requirement For Cafeteria Management System

January 22, 2014

2 Software Specification Requirement For Cafeteria Management System

3 Software Specification Requirement For Cafeteria Management System

Table of contents pages

1.1. Literature Survey...............................................................................................................7

1.2. Product Scope...................................................................................................................8

1.2.1. Application of the Project Output..............................................................................9

1.3. Intended Audience and Document Overview...................................................................9

1.4. Definition, Acronyms and Abbreviations.........................................................................9

1.5. Document structure.........................................................................................................10

2.1. Product Perspective.........................................................................................................11

2.1.1. Description of the existing system...........................................................................11

2.1.2. Activities performed under the existing system......................................................13

2.2. Product Functionality......................................................................................................13

2.3. Users and Characteristics................................................................................................13

2.3.1. Cafeteria Managers..................................................................................................14

2.4. Operating Environment...................................................................................................15

2.5. Design and implementation constraints..........................................................................15

2.6. User Documentation.......................................................................................................16

2.7. Assumptions and dependencies......................................................................................16

4 Software Specification Requirement For Cafeteria Management System

3.1. External Interface Requirements.........................................................................................17

3.1.1. User Interface Facilities...............................................................................................17

3.1.2. Hardware Requirements..........................................................................................19

3.1.3. Software Interfaces..................................................................................................20

3.1.4. Communication Interfaces.......................................................................................20

3.2. Functional Requirements................................................................................................20

i. Use Case View................................................................................................................22

4. OTHER NON-FUNCTIONAL REQUIREMENTS..........................................................25

4.1. Performance Requirements.............................................................................................25

4.2. Safety and Security Requirements..................................................................................25

4.3. Software Quality Attributes............................................................................................25

5.1. Sequence Diagrams.........................................................................................................27

5.2. Data Flow Diagrams (DFD)............................................................................................33

5.3. State Transition Diagrams (STD)...................................................................................36

5 Software Specification Requirement For Cafeteria Management System

6.1. Design Goals...................................................................................................................38

6.2. Design Trade-offs...........................................................................................................39

6.3. Assumptions and Dependencies......................................................................................39

6.4. General Constraints.........................................................................................................40

7.1. Subsystem Interaction.....................................................................................................43

8. USER INTERFACE DESIGN............................................................................................46

8.1. Class Design....................................................................................................................46

8.2. Detailed Design...............................................................................................................48

8.3. Entity Relationship..........................................................................................................49

6 Software Specification Requirement For Cafeteria Management System

1.1. Literature Survey

7 Software Specification Requirement For Cafeteria Management System

1.2. Product Scope

8 Software Specification Requirement For Cafeteria Management System

1.2.1. Application of the Project Output

 Information accessing is easy and fast.

1.3. Intended Audience and Document Overview

1.4. Definition, Acronyms and Abbreviations

CMSHU => Cafeteria Management System of Haramaya University

9 Software Specification Requirement For Cafeteria Management System