Software

Design
(ITS60603)
ASSIGNMENT
HAND OUT DATE: March 31st 2016
HAND IN DATE: 27th May 2016
WEIGHTAGE: 20%

Instructions to student:
This is a group assignment.

Student declaration:
I declare that:
I understand what is meant by plagiarism
The implication of plagiarism have been explained to me by our
lecturer This assignment is my own work.
Name

Student ID

Sandip Singh Krir A/L Suwaran Singh

Darryl Goh Jen Fai
Tan De Ren
Chee Zhong Wai

0320038
0319614
0319137
0323658

Page 1 of 26

Functional Requirements Document

SDDC
Version 3.0

Page 2 of 26

Version

Description of Change

Author

Date

1.0

Initial Draft

Sandip Singh, Darryl

Goh, Chee Zhong Wai,
Tan De Ren

23/4/2016

2.0

First Revision

Sandip Singh, Darryl

Goh, Chee Zhong Wai,
Tan De Ren

3/5/2016

3.0

Second Revision

Sandip Singh, Darryl

Goh, Tan De Ren

26/5/2016

Page 3 of 26

CONTENTS
1

INTRODUCTION ...................................................................................................... 5
1.1 Purpose.................................................................................................................... 5
1.2 Scope ....................................................................................................................... 5
1.3 Background ............................................................................................................. 6
1.4 References ............................................................................................................... 6
1.5 Assumptions and Constraints .................................................................................. 6
1.6 Document Overview ............................................................................................... 7

METHODOLOGY ..................................................................................................... 8

FUNCTIONAL REQUIREMENTS ........................................................................... 9

3.1 Context .................................................................................................................... 9
3.2 User Requirements .................................................................................................. 9
3.3 Data Flow Diagrams ............................................................................................. 10
3.4 Logical Data Model/Data Dictionary.................................................................... 13
3.4.1

Tables, Fields and Relationships ...................................................................... 14

3.5 Functional Requirements ...................................................................................... 15

4

OTHER REQUIREMENTS ..................................................................................... 17

4.1 Interface Requirements ......................................................................................... 17
4.2 Data Conversion Requirements ............................................................................ 18
4.3 Hardware/Software Requirements ........................................................................ 18
4.4 Operational Requirements .................................................................................... 19

APPENDIX A - GLOSSARY .......................................................................................... 25

CRITICAL PATH ANALYSIS ........................................................................................ 26

Page 4 of 26

1 INTRODUCTION
The name given to this proposed project for a web application is Calories Calculator.
This web applications purpose is to provide a single platform where all food and drinks
can be listed out in one place, benefiting both the user (ease of finding out about foods
calories) and the foods themselves (easy of exposure). Following in this section will
explain more about the purpose of this document as well as more detailed information
about our product, Calories Calculator.

1.1

Purpose
The purpose of this document is to give a detailed overview of the project, Calories

Calculator (scope, functionalities, constraints etc.), as well as to list out any requirements
necessary for the development of this project. As this proposed application is a new, selfcontained product on its own and with no parent subsystem nor is it a member of an already
existing product family, this document will not be talking about any other products and
will only focus on Calories Calculator.
1.2

Scope
The boundary of the web application covers everyone that have intention to check

out the calories of their product. The web app is a one stop platform that provides a location
for everyone to gain exposure. Its objective is to gather all foods for visibility to the public
as well as to provide extra features to user who use the application for exercise and the
food they have ate such as low calories and high calories foods. The main benefit this
would have to general users is that it makes searching for food calories easier, since they
can all be found in one place. For calories calculator however, the single largest benefit to
be gained is the extra exposure. Having all the foods calories listed in one place makes it
easier for even the most unknown food to gain exposure and recognition. Aside from
exposure, this application also provides many features that make it easy for a calories
calculator to interact with its user such as by checking the needed of calories per day.

Page 5 of 26

1.3

Background
Our organization which consists of the four main members including Sandip Singh,

Tan De Ren, Chee Zhong Wai and Darryl aim to try and help those people who lead a
healthy lifestyle to be able to focus on their goals and be ahead of themselves in a much
easier way. Since half of our organization consists of people whom have a healthy lifestyle,
we figured that it would be practical to develop such an application whereby others around
the world can do the same with their lifestyles as well. This document if being produced
by all the members of the organization as each one of the members have a different part
that they are responsible for.
1.4

References

CalorieKing, (2016), How many calories should you eat, Retrieved 10th April from
http://www.calorieking.com/interactive-tools/how-many-calories-should-youeat/?ref=nav
MyNetDiary, (2016), The Best Commercial Food Database and API, Retrieved 10th April
from
http://www.mynetdiary.com/food-database.html
Stack Exchange, (2014), Open API for nutritional information and/or food barcodes,
Retrieved 10th April from http://opendata.stackexchange.com/questions/269/open-api-fornutritional-information-and-or-food-barcodes
The fatsecretPlatform API, (2016), The FatSecret Platform API, Retrieved 10th April from
https://platform.fatsecret.com/api/
1.5

Assumptions and Constraints

While doing this entire project, we managed to come up with quite a few assumptions

and constrains. These assumptions and constrains were detected by the members of our
organization and also were logically thought up of while doing this project.

Page 6 of 26

1.5.2 Assumptions
One of the assumptions we as a group have come up with is that everyone who is
using this web based application has a reliable internet connection. This is important
because since our application is web based, we need our users to be able to connect to the
internet without any issue in order to use our application. Next assumption that we need to
make is that the user is inputting their bodyweight in pounds accurately. This is because
the calorie intake for each user is solely dependent of their bodyweight in pounds. Failing
to do so can allow the user to get a false calorie intake amount and thus this may cause
problems to their lifestyle.
1.5.3 Constrains
Some of the constrains that we have identified is that our application will not be able
to run without the internet. This is because our application is of a web based application.
Another constrain is that our application will only be able to calculate the calorie intake of
each user from their bodyweight in pounds. We will not be able to do so if the user inputs
their bodyweight in another format. This can sometimes be a hassle as we want our user to
first find out what their bodyweight is in pounds and then use our application to help them.
1.6

Document Overview
This document is focused on the functional aspects of our project. In the first part,

there is the introduction whereby we talk about the main idea of our project altogether.
Next, there is the Methodology part whereby we focus on the kind of design methodology
we are using for our assignment. This is then followed by the functional requirements and
lastly any other requirements from this document.

Page 7 of 26

2 METHODOLOGY
When coming to the designing we thought about something simple whereby the users
on Windows would find it easy to use therefore the interface on the Windows will be
updated to the feedbacks there are taken. We have taken the Agile method which is
SCRUM (Sprint) because when dealing with agile the steps taken is tedious but yet it
outputs a satisfying outcome in which 42% will be confirmed a success. This is because
when using this SCRUM its simpler compared to the other methods which are longer and
have a lower percentage of success due to the implementation of easy software
development based projects. Agile has five main roles that make it come together The
product owner, SCRUM Master, Team Members, Stake-holders and the Users. In an effort
to enable companies to focus on the business value using short development cycles in their
application development projects, Genius Project supports Agile and SCRUM
methodologies by providing a variety of Agile and SCRUM specific tools and views that
tie into an organizations project management processes. At regular intervals, the team
reflects on how to become more effective, then tunes and adjusts its behavior accordingly
and therefore due to the continuous attention to the app there will be technical excellence
and a good design to improve the quality. From here this is the most efficient way and
effective way to convey the information within the development team. When we create this
app we want it to be flexible whereby there is more freedom of time and not rush the project
fast and consume errors this will allow options gives them the ability to leave important
decisions until more or better data or even entire hosting programs are available.

Page 8 of 26

FUNCTIONAL REQUIREMENTS
This section explains about all the functional requirements that are required from the
system.

3.1 Context
Exhibit 2 - Generic Context Diagram

3.2 User Requirements

For guest users, they will be able to view the home page and the registration page. On
the home page, the guest users will be able to view information about the system and access
the registration page. They will then be able to provide their information as well as choose
to link their account with their social media accounts. Registered users will be able to
access the calculation page, where they can enter their information and specify their goal
(to lose or gain weight), then receive results of the calculation based on their information
and goal. They will also be able to save their information and view them again when they
return. Advertisers are able to advertise their product on the system. They will be able to
make payments based on their advertising status and number of advertisements. They will
also receive a report on their advertisement from the system.

Page 9 of 26

3.3 Data Flow Diagrams

Figure Level 0 Diagram

Figure Level 1 Diagram Registration

Page 10 of 26

Figure Level 1 Diagram - Login

Figure Level 1 Diagram - Calculation

Page 11 of 26

Figure Level 1 Diagram Advertisement

Figure Sequence Diagram

Page 12 of 26

3.4 Logical Data Model/Data Dictionary

Data
Data Member
Name
Body Weight

Calories to lose
weight

Calories to gain
weight

Calories to
maintain weight

Protein
Breakdown

Carbohydrate
Breakdown

Fat Breakdown

Username

Password

The calories and macro nutrition breakdown that will be displayed by the System.
Additional Type
Information
0.00 to 99999.9999
always 8 digits
including leading
zeroes

Default
Value
0

Mandatory?
Yes

Unique?
Yes

Float

0.00 to 99999.9999
always 8 digits
including leading
zeroes

Yes

Yes

Float

0.00 to 99999.9999
always 8 digits
including leading
zeroes

Yes

Yes

Float

0.00 to 99999.9999
always 8 digits
including leading
zeroes

Yes

Yes

Float

0.00 to 99999.9999
always 8 digits
including leading
zeroes

Yes

Yes

Float

0.00 to 99999.9999
always 8 digits
including leading
zeroes

Yes

Yes

Float

0.00 to 99999.9999
always 8 digits
including leading
zeroes

Yes

Yes

String

String value 16 digit

Yes

Yes

Passw
ord

Password value 16
digit

Yes

Yes

Description
The unique
identifier of the
bodyweight
inputted by the
user
The unique
identifier of the
calories needed to
be consumed by
the user
The unique
identifier of the
calories needed to
be consumed by
the user
The unique
identifier of the
calories needed to
be consumed by
the user
The protein
breakdown of the
user based on
their calories
inputted
The carbohydrate
breakdown of the
user based on
their calories
inputted
The fat
breakdown of the
user based on
their calories
inputted
The username of
the user inputted

Type
Float

The password of
the user inputted

Page 13 of 26

Numbers of
advertisement

Payment Total

The number of
products
advertised by
advertiser
The payment
charged to the
advertisers

Float

0.00 to 99999.9999
always 8 digits
including leading
zeroes
0.00 to 99999.9999
always 8 digits
including leading
zeroes

Float

Yes

Yes

Yes

Yes

3.4.1 Tables, Fields and Relationships

User
Column Name

USER_NAME
USER_PASS

System
Column Name

BODY_WEIGHT
CAL_LOSE
CAL_GAIN
CAL_MANTAIN
PROTEIN
CARB
FAT
NUM_AD
PAYMENT_AD

Data
Type

Null

Text
Text

No
No

Data
Type

Float
Float
Float
Float
Float
Float
Float
Int
Float

Null

Description

Username
Password

Description

No
No
No
No
No
No
No
No
No

Bodyweight of User
Calories to lose weight
Calories to gain weight
Calories to maintain weight
Protein Breakdown
Carbohydrate Breakdown
Fat Breakdown
Number of Advertisements on website
Amount for advertisement

Page 14 of 26

3.5 Functional Requirements

This section lists the functional requirements of a system
3.5.1 Functional Requirements (Registration)
Section/
Requirement ID Requirement Definition
FR1.0.

The system registers new users.

FR1.1

The system gathers user information.

FR1.1.1

The system requests information from guest users.

FR1.1.2

The system receives information from guest users.

FR1.1.3

The system receives social media information from guest users.

FR1.1.4

The system requests guest users account information from social media.

FR1.1.5

The system receives guest users account information from social media.

FR1.2

The system checks for duplicate accounts before registering new users.

FR1.2.1

The system checks if information received from guest users already exist in
database.

FR1.3

The system registers information received from guest users into database.

FR1.4

The system notifies guest users of registration status.

FR1.4.1

The system sends guest users a notification email of their registration.

3.5.2 Functional Requirements (Login System)

Section/
Requirement ID
FR 2.0.

Requirement Definition
The system requests login information

FR 2.0.1

The system requests username from registered users

FR 2.0.2

The system requests password from registered users

FR 2.0.3

The registered user provides username to the system

FR 2.0.4

The registered user provides password to the system

FR 2.1

The system validates the login information

FR 2.1.1

The system validates the information of the registered user

FR 2.2

The system confirms the login of the registered user

Page 15 of 26

3.5.3 Functional Requirements (Calculation System)

Section/
Requirement ID
FR 3.0

Requirement Definition
The system request user details

FR 3.0.1

The system request user body weight

FR 3.0.2

The system request user activity level

FR 3.0.3

The system reads entered details

FR 3.1

The system calculates the calories

FR 3.1.1

The system retrieves formulas from database

FR 3.1.2

The system stores user information into database

FR 3.1.3

The system stores calculated results into database

FR 3.2

The system displays results to the user

3.5.4 Functional Requirements (Advertising System)

Section/
Requirement ID
FR 3.0

Requirement Definition
The system gathers advertisement information

FR 3.0.1

The system requests advertisement information from advertisers

FR 3.0.2

The system reads entered advertisement information

FR 3.0.3

The system stores advertisement information into database

FR 3.1

The system displays advertisement to users

FR 3.1.1

The system records user feedback into database

FR 3.2

The system generates advertisement report to advertisers

FR 3.3

The system generates payment information

FR 3.3.1

The system sends invoice to advertisers

FR 3.3.2

The system receives payment from advertisers

Page 16 of 26

4 OTHER REQUIREMENTS
This section describes the other requirements that are present within our document.
4.1 Interface Requirements
The interface that the app will display is basic in the sense that the user can use any
computer either it can be high end or low end the interface will be the same, but when the
user is using the interface is easy to be accessed and the user will get more into the app
interface. We have created the interface that is a simple toggle when the user wants to go
to a certain topic there will be a dropdown feature and it will be displayed in the simplest
and effective way that the user doesnt have to understand to use this.
4.1.1 Hardware Interfaces
When it comes to the hardware part the system is simple it just collects the users data each
time they enter the site and from there the system will recall the toggled topics was last
accessed. The logical structure of this app is understand or trying to read the users using
the cookies. The physical address needed is just the users login IP address and from there
the system will send the signal data to the logical structure to read. We expected the
behaviors of this app are to interact with the user and understand what the user wants and
intercept the users move.

4.1.2 Software Interfaces

When dealing with the software interfaces we made the system simple as possible in the
sense that when the system is receiving or sending the data signal the subsystems come in
and send each related data that can be found and send it to the system. An ICD should only
describe the interface itself, and not the characteristics of the systems which use it to
connect. The function and logic of those systems should be described in their own design
documents if required. In this way, independent teams can develop the connecting systems
which use the interface specified, without regard to how other systems will react to data
and signals which are sent over the interface.

Page 17 of 26

4.1.3 Communications Interfaces

When the system for the data is implemented we had to create a local area network (LAN)
so that it will only be sent around in the system. The subsystems will send signals to each
other and will be allocating the data to be complied and sent to the system to the website.
Each of the subsystems handle a different category in the app therefore all the data will be
more arranged and easily accessed because the system will send the users IP address and
from there all the related data will be sent.

4.2 Data Conversion Requirements

Updating applications with current technology means IT must make sure that data makes
the move smoothly and efficiently as well. We have to work closely with the specific
department and determine what their requirement is. In some cases, limping along is a
legitimate option. As you rebuild a strategy to implement a state-of-the-art system, its
important to not repeat past decisions because when having a data migration that system
shouldnt have the extra of past data and all new data categorized. One element everyone
is getting much more savvy about is open architecture, which means using standards such
as SQL
4.3 Hardware/Software Requirements
Hardware:

1 gigahertz (GHz) or faster 32-bit (x86) or 64-bit (x64) processor

1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit)

1 GB available hard disk space (32-bit) or 2 GB (64-bit)

Internet access (fees may apply)

Software:

Windows XP, 7, 8 or higher.

Google Chrome, Internet Explorer 9 or higher

Internet speed 512kbps, 1mbps or higher.

Page 18 of 26

4.4 Operational Requirements

Requires the user accurate information key-in into system.
4.4.1 Security and Privacy
A. State the consequences of the following breaches of security in the subject application:
1. Loss or corruption of data

System will be unavailable until the data has been recovered.

Users Login information will be lost as our database would be corrupted.

Users will also be unable to track their calories as it has been removed from our
database.

2. Disclosure of secrets or sensitive information

It will be a breach of security

Our users will lose their trust in our data confidentiality and integrity.

We would make a loss in revenue as our advertisers would not want to advertise
on our website any longer.

3. Disclosure of privileged/privacy information about individuals

Security of our application will be jeopardized.

Loss of trust in our application

Loss of revenue generated.

4. Corruption of software or introduction of malware, such as viruses

The system will be in downtime and will fail

System might generate incorrect outputs

Loss of revenue as advertisers will not be able to pay us for advertisements.

Page 19 of 26

B. State the type(s) of security required. Include the need for the following as appropriate:
1. Physical security.
Firewall. This is because a firewall will help prevent hackers and any un-authorized
access from accessing into our website and modifying the codes to damage it.
2. Access by user role or types.
User Login. This user login will help us identify if the user currently accessing the
application is authorized or not. This will help improve the security of our
application.
3. State access control requirements by data attribute. For example, one group of users
has permission to view an attribute but not update it while another group of users
has permissions to update or view it.
Administrator Level Control. This will allow only the administrator to gain access
of our application framework layer and make necessary changes to it if needed.
4. State access requirements based on system function. For example, if there is a need
to grant access to certain system functions to one group of users, but not to another.
For example, "The system shall make Function X available to the System
Administrator only".
Registered users. Registered users will be able to share their progress of the caloric
intake onto social media while non-registered ones will not be allowed to do so.
Registered users will also be allowed to store their caloric intakes into our database
while non-users will not be allowed to do so.
5. State if there is a need for certification and accreditation of the security measures
adopted for this application.
Not Needed. Our web based application has a simple user interface that does not
need to have a high level of security to function.

4.4.2 Audit Trail

Not Available

Page 20 of 26

4.4.3 Reliability
A. State the following in this section:
1. State the damage can result from failure of this systemindicate the criticality of
the software, such as:
Loss of revenue and loss of users trust and records within our database.
2. What is the minimum acceptable level of reliability?
Reliable enough to be able to perform the software required function under specific
conditions
B. State required reliability:
1. Mean-Time-Between-Failure is the number of time units the system is operable
before the first failure occurs.
Approximately 3 Hours
2. Mean-Time-To-Failure is the number of time units before the system is operable
divided by the number of failures during the time period.
Approximately 4 Hours
3. Mean-Time-To-Repair is the number of time units required to perform system
repair divided by the number of repairs during the time period.
Approximately 3 Hours
4.4.4 Recoverability
A. In the event the application is unavailable to users (down) because of a system failure,
how soon after the failure is detected must function be restored?
The system will be restored within 3 hours as the administrator needs to check and
understand the why the system has failed and find a proper way to fix it so such an
error can be addressed more easily in the future

Page 21 of 26

B. In the event the database is corrupted, to what level of currency must it be restored?
For example, The database must be capable of being restored to its condition of no
more than 1 hour before the corruption occurred.
The data will be sync every 30 minutes to ensure that if data corruption occurs, the
backup system can restore back the current system within 10 minutes. At the same time,
the backup system will run when restore process running at the background.

C. If the processing site (hardware, data, and onsite backup) is destroyed, how soon must
the application be able to be restored?
The application able to restore within 2 hours as the backup databases are constantly
storing the records from the main database itself.

4.4.5 System Availability

The administrator will constantly be monitoring the system to prevent downtime. If there
is downtime, it would be fixed within approximately 3 hours.
4.4.6 General Performance
Performance requirements define acceptable response times for system functionality
A. Response time for queries and updates
- Queries shall return results within five seconds
- The load time for user interface screens shall take no longer than five seconds.
B. Throughput
The log in information shall be verified within five seconds.

Page 22 of 26

C. Expected rate of user activity (for example, number of transactions per hour, day, or
month, or cyclical periods)
The system shall consume very little of primary memory as not much information needs to
be stored into the database
4.4.7 Capacity
As the amount of data transferred from the server to each user is very low, the capacity
required and volume of data will be extremely low. As the system is used by more users
and advertisers, volumes of data will increase accordingly, with the majority of data being
held from advertisement reports.
4.4.8 Data Retention
The system shall retain application information until it is requested to be removed by the
user. Different forms of data include: user login information, user calculation information,
and advertisement information.
4.4.9 Error Handling
The system will catch all errors to ensure the stability of the system. User input errors will
prompt the user to reenter the details, while server side errors will be logged and bugs in
the system will be fixed.

Page 23 of 26

4.4.10 Validation Rules

Validation Rule VR1
Validation Rule Type

User account validation

Rule Name

If_incorrect_password

Error Message

Error. Incorrect password.

Description

Password entered is incorrect for the

account entered

Error Location

Above login details field

Created and Modified by

Darryl Goh

Validation Rule VR2

Validation Rule Type

Calculation details type format validation

Rule Name

If_incorrect_format

Error Message

Error. Incorrect password.

Description

Details entered in incorrect format for the

fields required

Error Location

Above enter button

Created and Modified by

Darryl Goh

4.4.11 Conventions/Standards
This document follows the Microsoft standards for windows. IEEE standards are followed
for the document and program. This document uses the Times New Roman font with a font
size of 12.

Page 24 of 26

APPENDIX A - GLOSSARY

Figure Gantt Chart

Page 25 of 26

CRITICAL PATH ANALYSIS

Page 26 of 26