Software Requirements

Specification
for

FoodAlloc – A Food & Diet

Management Software

Version 1.0 approved

Prepared by
Rahul Sankar (16CO137)
Ashwin Nair (16CO103)

National Institute of Technology Karnataka, Surathkal

20th February, 2018

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for FoodAlloc  Page ii

Table of Contents
Table of Contents...........................................................................................................................ii
Revision History.............................................................................................................................ii
1. Introduction..............................................................................................................................1
1.1 Purpose...........................................................................................................................................1
1.2 Document Conventions..................................................................................................................1
1.3 Intended Audience and Reading Suggestions.................................................................................1
1.4 Product Scope.................................................................................................................................1
1.5 References......................................................................................................................................1
2. Overall Description..................................................................................................................2
2.1 Product Perspective........................................................................................................................2
2.2 Product Functions...........................................................................................................................3
2.3 User Classes and Characteristics....................................................................................................3
2.4 Operating Environment..................................................................................................................3
2.5 Design and Implementation Constraints.........................................................................................3
2.6 User Documentation.......................................................................................................................4
2.7 Assumptions and Dependencies.....................................................................................................4
3. External Interface Requirements...........................................................................................4
3.1 User Interfaces................................................................................................................................4
3.2 Hardware Interfaces........................................................................................................................6
3.3 Software Interfaces.........................................................................................................................6
3.4 Communications Interfaces............................................................................................................6
4. System Features.......................................................................................................................7
4.1 System Feature 1............................................................................................................................7
4.2 System Feature 2............................................................................................................................7
    4.3 System Feature 3..................................................................................................................8
5. Other Nonfunctional Requirements.......................................................................................9
5.1 Performance Requirements.............................................................................................................9
5.2 Safety Requirements.......................................................................................................................9
5.3 Security Requirements....................................................................................................................9
5.4 Software Quality Attributes............................................................................................................9
6. Other Requirements................................................................................................................9
Appendix A: Glossary..................................................................................................................10
Appendix B: Analysis Models.....................................................................................................11

Revision History
Name Date Reason For Changes Version
Food­Alloc 15/2/18 Inital SRS document 1.0
Software Requirements Specification for FoodAlloc Page 1

1. Introduction

1.1 Purpose 
The purpose of this document is to give a detailed description of the requirements
for the FoodAlloc software, including functional, non-functional and domain
requirements. It will also explain system constraints, interface and interactions with
other external applications and users. This document is primarily intended to be
proposed to a customer for its approval and a reference for developing the first
version of the system for the development team.

1.2 Document Conventions
The document follows the IEEE SRS template. In section 4, under subsection
dependencies, italics indicate that the output may depend on certain other
requirements, howeve these are not necessary for the function itself to run
smoothly. For technical terms and abbreviations, see appendix A. The priorities of
each individual requirement has been stated explicitly in section 4; there is no
inheritance of priorities.

1.3 Intended Audience and Reading Suggestions
This document is meant mainly meant for developers, and testers as a reference
guide for the first implementation of the software. Sections 1, 2, 4 and 5, as well as
appendices A and B are to be read by both developers and testers, while
developers also need to refer to section 3 for development purposes.

1.4 Product Scope
The goal of this software is to help a user plan his/her diet or food management.
The user simply needs to login and choose an option as to how they want to
plan/modify their diet, and the software must fetch data from a database and
present the relevant information to the user. The goal is to make the product fast,
efficient, accurate and intuitive, so that the software is adopted by lots of users in a
short span of time.

1.5 References
1.IEEE SRS template:
https://capstone.cs.ucsb.edu/team_docs_13/SRS/SRS_NullTerminators.pdf
Software Requirements Specification for FoodAlloc Page 2

2. Overall Description

2.1 Product Perspective
Our software will consist of a user interface where the user will be presented with
four options, namely, Food Allocation, Food Lookup, Add Preferences, Set
Alternative. These four options will be presented in the form of buttons. The user
can interact with these buttons by pressing them.
The food allocation module will allocate food to the user as per his/her input, which
can either be his height, weight and age, or his/her calorie requirement. The food
lookup module allows the user to lookup information about the food. The add
preferences module allows the user to set certain food items as preferences, The
set alternatives module allows the user to set certain food items as hi/her
dislikes/allergies.
All the food items will be stored in a database and specific food items will be fetched
according to the user’s queries. All the modules will have access to this food
database. The database can only be used to read data. No data may be written into
the database.

SOFTWARE

Food Allocation Food Lookup Set Preferences Set Alternatives

Food Database

Figure 1 – Block Diagram

Software Requirements Specification for FoodAlloc Page 3

2.2 Product Functions
The user can interact with the software mainly using the four built-in modules. The
software can allocate food to the user based on his/her inputs, which may be either
his/her height, weight and age, or the calorie requirement that they need. The
software will then select the appropriate food items to the user and then output the
result in the form of a list.
The user can also lookup information about certain food items. The user can enter
the name of the food or a specific calorie range and the software will fetch the
appropriate food items from the database and output the result to the user.
The user can also set preferences and alternatives. By setting the preferences, the
software will try to recommend the user food items of his/her choice and by setting
alternatives, the software will try to avoid certain food items that the user dislikes or
is allergic to.

2.3 User Classes and Characteristics
There is only 1 type of user who will find this software useful: one who wants help in
manging his/her diet and allocation of food. Such users will find this software very
useful. The food allocation module, in particular will be very useful for such users as
they can use the software to maintain a diet plan. Thus they will main demographic
for this software.

2.4 Operating Environment
The software is designed as a website, so one constraint is that the system
containing the software should have a web browser to fetch and display HTML
pages. The software is operating system independent, i.e. it can work on any
operating system as long as it contains a web browser and the operating system
supports Python, as the back-end of the software will be built using Python.

2.5 Design and Implementation Constraints
Since the software is going to be deployed as a website, the speed at which the
software operates depends on the web browser being used to run the software. The
speed of the software also depends on how fast the software is able to manipulate
the database as most operations of the software involve reading from the database.
The system should also support MySQL as that is the language used for the
manipulation of the database.
The system running the software should also support Python as the back-end of the
website uses Python to operate.
Software Requirements Specification for FoodAlloc Page 4

2.6 User Documentation
A thorough user manual will be provided along with the software that will explain
each feature of the software in detail. The manual will contain instructions as to how
to interact with the software and how to use each feature effectively in simple
natural language.

2.7 Assumptions and Dependencies
It is assumed that the software will always be used on a desktop/laptop. The
software is not built for mobile operating systems. Another assumption is that the
system that will run the software will have enough resources available for the
software to run smoothly.
One more assumption is that the user knows how to operate a basic web browser.

3. External Interface Requirements

3.1 User Interfaces
The first screen that comes up when the user opens the software is as shown as
Figure 2. The user is presented with four options which he/she can select.

Figure 2 – Main page Figure 3 – Allocate Food

Software Requirements Specification for FoodAlloc Page 5

If the user selects the “Allocate Food” option, he/she will be redirected to the
“Allocate Food” page, see Figure 3. Here, the user can either enter his/her physical
attributes, i.e. height, weight and age, or he/she can enter the calorie range they
need and click on submit.
Once submitted, the user will be given the output, see Figure 4. The user can then
select the back button and be redirected to the main page, see Figure 2. Here, if the
user selects the “Food Lookup” option, the user will be taken to the “Food Lookup”
page, see Figure 5. Here, the user can either enter the name of the food he/she
wants to look up, or the calorie range, and then hit submit. For the output, see
Figure 4.

Figure 4 – Output Figure 5 – Food Lookup

If the user selects the “Set Preferences” option, he/she will be taken to the “Set
Preferences” page, see Figure 6. Here, the user can enter food items that he/she
prefers so that the software would be more likely to recommend those items to the
user.
If the user selects the “Set Alternatives” option, he/she will be taken to the “Set
Alternatives” page, see Figure 7. Here, the user can enter food items that he/she
dislikes or has allergies to, so that the software would be more likely to not
recommend those items to the user.
Software Requirements Specification for FoodAlloc Page 6

Figure 6 – Setting Preferences Figure 7 – Setting Alternatives

3.2 Hardware Interfaces
The software doesn’t have any designated hardware, so no direct hardware
interface is required. All the data flow and data manipulation is managed by the
underlying operating system and the logic of the software.

3.3 Software Interfaces
The software has many modules which interact with the underlying food database.
MySQL language is used as a query language which fetches items from the food
database according to the queries of the user. Thus, MySQL acts as an interface
between the food database and the software.
The Django web-framework acts as an interface between the user interface and the
functions of the software. The user enters the input through the user interface,
which is then interpreted by the framework and the appropriate actions are taken.

3.4 Communications Interfaces

The communication between each part of the system is important since they depend
on each other. However in what way the communication is achieved is not important
for the system and is
therefore handled by the underlaying operating system.
Software Requirements Specification for FoodAlloc Page 7

4. System Features
This section covers all the functionalities provided by the software, along with some
use case examples.

4.1 System Feature 1
Logging in
4.1.1 Description and Priority
Upon accessing the website, the user must have the option for either
logging in or registering a new account. This requirement has the
highest priority and forms the base for other requirements.

4.2 System Feature 2
Planning of user’s diet
4.1.1 Description and Priority
The software should either give the user a list of food items that can
function as his/her diet, or allow the user to look up food items along
with their nutritional values so that he/she may plan a diet for
themselves. This feature has high priority

4.1.2 Stimulus/Response Sequences

Upon logging in, the web page must display the options for allocating
food or looking up items from the database. Choosing either options
must display another page prompting users to input necessary
information.
4.1.3 Functional Requirements
REQ-2.1:
Title: Allocation of food
Description: The algorithm must select appropriate food items
from the database and allot it to the user.
Dependency: REQ-1.1, REQ-1.2, REQ-3.1, REQ-3.2
REQ-2.2:
Title: Lookup of food
Description: The user must be able to lookup up food items by
entering their name or calorie range.
• In case the name of the food item is
Software Requirements Specification for FoodAlloc Page 8

provided, a single entry must be displayed if

the name matches, else the user must be told
that no such item is available
• In case a calorie range is provided, all entries
fitting into the range must be displayed. The
value of the upper bound of the calorie range
must default to the lower bound in case the
value of the upper bound entered is lesser
than the value of the lower bound.
Dependency: REQ-1.1, REQ-1.2

4.3 System Feature 3

User making changes to his/her diet
4.3.1 Description and Priority
The user should be able to enter his/her food preferences and/or
alternatives required if any, and these should be taken into account
while allocation.

4.3.2 Stimulus/Response Sequences

Upon logging in, the web page must display the options for setting
preferences and alternatives. Choosing either options must display
another page prompting users to input necessary information.

4.3.3 Functional Requirements

REQ-3.1:
Title: Setting preferences
Description: The user should be able to set preferences of
his/her food items. These food items must be chosen first
during allocation. In case the name of the entered food
item does not match with any entry in the database, user
must be asked to re-enter the name.
Dependency: REQ-1.1, REQ-1.2
REQ-2.2:
Title: Setting alternatives
Description: The user must be able to select a food item
he/she does not want, and replace it with another food item
of their choice. If the unwanted food item is selected during
allocation, the the software must instead display the
alternative item, taking into account that the quantity of the
items required may differ. In case the name of the entered
food item does not match with any entry in the database,
user must be asked to re-enter the name.
Software Requirements Specification for FoodAlloc Page 9

Dependency: REQ-1.1, REQ-1.2

5. Other Nonfunctional Requirements

5.1 Performance Requirements
• The allocating feature must take at most 3 seconds to complete by the server
• The lookup feature should be done in under 1 second by the server.
• The setting alternatives and setting preferences features must be
instantaneous.

5.2 Safety Requirements
In the case of incorrect allocation of food items, a patient may have health
problems, which can cause a lot of problems for the organization. Thorough testing
of the software must be done to ensure that the allocation is always done right,
following certain standards such as the US dietary guidelines.

5.3 Security Requirements
Breach of security will not cause widespread loss to the organization. However, user
details must be kept as safe as possible and hence encryption algorithms like DES-
64 must be used.

5.4 Software Quality Attributes
The highest priority of the software is correctness. At least 90% accuracy of the
software must be demonstrated. Therefore Correctness and Testability must have
the highest preference. Flexibility and reusability are also important as further
features may be added or corrected. The sotware must also be easy to use and
learn with a user able to efficiently operate the software within 15 minutes of first
use. This requires a simple and intuitive interface. Other features such as reliability
and robustness are important, and have a medium priority, while other features like
interoperability with other food or diet related software is desirable, but may be held
off for later and has a low priority.

6. Other Requirements
Legal requirements: The terms of use must explicitly specify that the software is
meant only as a reference and helpful guide to a user in picking certain food items
for their diet. The user must use his/her own discretion and no responsibility related
to a user’s health lies with the organization.
Software Requirements Specification for FoodAlloc Page 10

Appendix A: Glossary
CPU: Central Processing Unit. It is a hardware device in a computer that is
responsible for most (if not all) of the mathematical calculations required by the
computer. All programs execution is performed by the CPU. The CPU includes all
the derived components including the ALU (arithmetic logic unit), cache and register.
GUI: Graphical User Interface. An interface that receives and reacts to the user
input with a graphical display.
IDE: Integrated Development Environment is a tool to aid programmers in writing
code, usually used for graphical application.
Python: Python is an interpreted high-level programming language for general-
purpose programming.
OS: Operating System, the low-level software that supports a computer's basic
functions, such as scheduling tasks and controlling peripherals.
Web Browser: A web browser (commonly referred to as a browser) is a software
application for retrieving, presenting and traversing information resources on the
World Wide Web.
URL: Uniform Resource Locator is a reference to a web resource that specifies its
location on a computer network and a mechanism for retrieving it
SRS: Software Requirements Specification, is a description of a software system to
be developed
HTTP: The Hypertext Transfer Protocol (HTTP) is an application protocol for
distributed, collaborative, and hypermedia information systems. HTTP is the
foundation of data communication for the World Wide Web.
Client-Server Model: The client–server model is a distributed application structure
that partitions tasks or workloads between the providers of a resource or service,
called servers, and service requesters, called clients.
MySQL: MySQL is an open-source relational database management system.
Django: Django is a free and open-source web framework, written in Python, which
follows the model-view-template architectural pattern.
Software Requirements Specification for FoodAlloc Page 11

Appendix B: Analysis Models

Dataflow Diagram -
Software Requirements Specification for FoodAlloc Page 12

Entity Relationship Diagram -