SRS DOCUMENT OF
RECIPE FINDER APPLICATION
By
ADIL NABHAN C.V
SAFA MUSTHAFA
VYSHNAV P
MUHAMMED PP
Supervisor:
ANUSREE DEPARTMENT COMPUTER SCINCE
STATEMENT OF NONPLAGIARISM
We hereby declare that all information in this report has been obtained and presented in
accordance with academic rules and ethical conduct. We also declare that, as required by
these rules and conduct, we have fully cited and referenced all materials and results that are
not original to this work.
Date: 21.04.2024
Name, Surname Signature
i
TABLE OF CONTENTS
STATEMENT OF NONPLAGIARISM..............................................................................................i
TABLE OF CONTENTS..............................................................................................................................ii
LIST OF FIGURES....................................................................................................................................iii
1. INTRODUCTION..................................................................................................................................1
1.1. Purpose.......................................................................................................................................1
1.2. Scope of Project...........................................................................................................................1
1.3. Glossary.......................................................................................................................................2
1.4. Overview of Document................................................................................................................2
2.0. OVERALL DESCRIPTION....................................................................................................................3
2.1. System Environment...................................................................................................................3
2.2. Functional Requirements Specification.......................................................................................4
2.2.1. User Use Case.......................................................................................................................4
2.2.2. Admin Use Case....................................................................................................................7
2.2.3. System Use Case...................................................................................................................8
2.3. Actor Characteristics....................................................................................................................9
2.4. Non-Functional Requirements...................................................................................................10
3. REQUIREMENT SPECIFICATION.........................................................................................................10
3.1. Interface Requirements.............................................................................................................10
3.2. Functional Requirements...........................................................................................................11
3.2.1. User Use Case.....................................................................................................................11
3.2.2. Admin Use Case..................................................................................................................16
3.2.3. System Use Case.................................................................................................................19
3.3. Non-Functional Requirements...................................................................................................20
3.4. Flow Description........................................................................................................................20
CONCLUSION........................................................................................................................................20
ii
LIST OF FIGURES
Figure 2: USER USE CASE...................................................................................................................5
Figure 3: ADMIN USE CASE...............................................................................................................7
iii
1. INTRODUCTION
1.1. Purpose
The purpose of this document is to explain the Recipe finder app for Food recipe in detail.
This document describes the system's software requirements, system intent, and features.
This document is prepared for both java c++. The purpose of this system is to present the
recipes that the user is looking for and recipes similar to the user's preferred recipes.
In the General Description section, your system's use case diagram is shown. Initial Step-
By-Step Description for each actor is explained.
1.2. Scope of Project
This system will be a website. This system aims to finding and presenting recipes that the
user is searching and providing correct similar to what the user prefers. The system
contains a database which is providing lists of users, recipes, category of recipes, recipes’
ingredients. This database enables to keep the information of recipes and users.
In addition, this system also receives personal information such as age, height, weight
from the user. Users can update this information and keep this information under control.
Also some of ingredients’ calories will be found in the system. Users can choose recipe.
In addition, this system will save user’s time to find preferred recipes.
1.3. Glossary
TERM DEFINITION
User People who search recipes and recommended it.
Admin Person who can manage the system and can add recipes.
1
System Recommends recipes based on what they prefer to the user
Database Location of all recipes, ingredients, user’s information, rates
on this system.
Website A website where the user searches for recipes and receives
recipe.
1.4. Overview of Document
The document contains the Recipe finder app details. We will explain that in overall
description. Using use case we showed all available functions in the second part. The use case
of two actors have been identified. The relationship of the actors to use case has been
explained in detail. Summarized at the end., the system's functional. Database ER diagram
has been showed and explained. The entities of each table have been shown. Types and
explanations have been added to the document in tabular form.
2.0. OVERALL DESCRIPTION
2.1. System Environment
2
2.
FIGURE 1: RECIPE FINDER SYSTEM,
SYSTEM OF FOOD RECIPE AIMED AT FACILITATING THE SELECTION OF FOOD WHICH WE
ARE HARD TO DECIDE. THIS SYSTEM HAS TWO ACTOR AND ONE SYSTEM
(RECOMMENDATION ENGINE). AS CAN BE UNDERSTOOD FROM THE ABOVE, IT IS A SYSTEM
IN WHICH USERS PLAY AN ACTIVE ROLE. ADMIN AND SYSTEM HAVE LIMITED TASKS.
2.2. Functional Requirements Specification
Recipe Recommendation System for food recipe has 2 actors namely user, admin .
3
2.2.1. User Use Case
Use Case:
Register User
Login Account
Search Recipe
View Recipe
View Profile
Add Recipe
4
FIGURE 2: USER USE CASE
Brief Description
In general, user shall be able to register system, login to system, view his/her profile search
recipes, add recipes and view recipes . All recipes have user can search it.
Initial Step-by-Step Description
1. If User do not have account, user chooses Register button.
2. The user register
3. The user enters recipe name into search box, system lists recipes
and recipes.
4. The user selects recipe.
5. .
5
2.2.2. Admin Use Case
Use Case:
Search Recipe
View Recipe
Add recipe to system
Update Recipe
View users’ profiles
Diagram:
FIGURE 3: ADMIN USE CASE
Brief Description:
6
Admin shall be able to search, view recipes. In addition, admin shall be able to add, delete or
update recipes and add recipes’ nutritional values. Also, admin can view all users’ profiles.
Initial Step-by-Step Description
1. Admin writes recipe name into search box, system lists
recipes.
2. Admin views recipe.
3. Admin presses ‘Add Recipe’ button and system shows
textboxes for getting information of new recipe from admin.
4. If admin wants to delete a recipe from system, presses ‘Delete
Recipe’ button, recipe is removes from system.
5. If admin wants to update a recipe, presses ‘Update Recipe’
button, system list recipe’s information.
6. If admin wants to view user’s profile, presses ‘Users’ Profiles’
button and system lists users.
7. Admin writes or selects user’s name and view his/her profile.
2.3. Actor Characteristics
All types of people can use this system. There is no any specification for them.
All they need is the Internet connection to use this app
2.4. Non-Functional Requirements
In this part, how this system works is shown. Some crucial non-functional requirements are
accessibility, performance and security. First of all, accessibility is very important, so web
page design should be done simply for users. In addition to that user should be able to find
7
what she/he is looking for. The other important thing is performance, searching for recipes
should be done quickly, so speed is important. Finally, security is essential for users as
important as in many systems, because users share their personal information.
3. REQUIREMENT SPECIFICATION
In this section, interface requirements, functional and non-functional requirements subtitles
were described.
3.1. Interface Requirements
User interface phases are divided to two phases:
User
In this interface, users’ perspective is shown. Firstly, users can register and then login to the
system. After that, they can search, view recipes and rate them. They can add recipe to
favorites and to system, organize their favorite list and do some changes on their profile.
Admin
Admins are this system designers, at this point we are admins. We can search and view
recipes, add new recipe to system or delete from the system, update them and lastly they can
view users’ profile.
3.2. Functional Requirements
In this section, main functions of recipe finder are clarified.
3.2.1. User Use Case
The main sequential functions of user-side of the system is shown below.
3.2.1.1. Register User
Use Case Name: Register User
Xref: Section 2.1.1, User Use Case
Trigger: Click on the Register button
8
Pre-Condition: Access to Recipe Recommendation Web
Site
Basic Path: 1. User opens the Web Site
Alternative Path: None
Post-Condition: Registered user can login to system
Exception Paths: None
Other: None
3.2.1.2. Login to the System
Use Case Name: Login to the System
Xref: Section 2.1.1, User Use Case
Trigger: Click on the Login button
Pre-Condition: Registration to the Web Site
Basic Path: 1. User opens the Login Page
Alternative Path: None
Post-Condition: User can view recommended recipes, view
or search recipes, update profile, add new
recipe
Exception Paths: None
Other: None
33.2.1.6. Search Recipe
Use Case Name: Search Recipe
Xref: Section 2.1.1, User Use Case
Trigger: Click on the Search button
Pre-Condition: Login to the system
Basic Path: 1. User is directed to main page
2. User can write recipe name on search box
Alternative Path: None
Post-Condition: User can select searched recipe and rate it
Exception Paths: User can give up searching at any time
Other: The recipe list is updated according to new
recipes to be added
3.2.1.8. View Recipe
Use Case Name: View Recipe
Xref: Section 2.1.1, User Use Case
9
Trigger: Click on the Recipe List button
Pre-Condition: Login to the system
Basic Path: 1. User can see recipe list
Alternative Path: None
Post-Condition: User can select from recipe list and rate it
Exception Paths: User can give up viewing at any time
Other: The recipe list is updated according to new
recipes to be added
3.2.1.9. View and Update Profile
Use Case Name: View and Update Profile
Xref: Section 2.1.1, User Use Case
Trigger: Click on the Profile button
Pre-Condition: Login to the system
Basic Path: 1. User can view and make any changes on
his/her profile
Alternative Path: None
Post-Condition: User can search or view recommended
recipes
Exception Paths: None
Other: None
3.2.1.10. Add New Recipe
Use Case Name: Add New Recipe
Xref: Section 2.1.1, User Use Case
Trigger: Click on the Add New Recipe button
Pre-Condition: Login to the system
Basic Path: 1. User write ingredients’ list, calorie and recipe
information to add a new recipe to the system
2. Added new recipe is controlled by admin
3. If it is approved, it is added
Alternative Path: None
Post-Condition: User can search or view recommended recipes
Exception Paths: If added new recipe is not appropriate, the new
recipe is not added to the system.
Other: The recipe list is updated.
10
3.2.2. Admin Use Case
The main sequential functions of admin-side of the system is shown below.
3.2.2.1. Search Recipe
Use Case Name: Search Recipe
Xref: Section 2.1.2, Admin Use Case
Trigger: Click on Search button
Pre-Condition: Using one of admin computers to login
Basic Path: 1. Admin can write recipe name on search
box
Alternative Path: None
Post-Condition: Admin can update, delete or view the recipe
Exception Paths: None
Other: None
3.2.2.2. View Recipe
Use Case Name: View Recipe
Xref: Section 2.1.2, Admin Use Case
Trigger: Click on the Recipe List button
Pre-Condition: Using one of admin computers to login
Basic Path: 1. Admin can see recipe list
Alternative Path: None
Post-Condition: Admin can add, delete or update the recipe
Exception Paths: None
Other: None
3.2.2.3. View Users’ Profiles
Use Case Name: View Users’ Profiles
Xref: Section 2.1.2, Admin Use Case
Trigger: Click on the Users’ Profiles button
Pre-Condition: Any complaints from the user
Basic Path: 1. Admin can list users’ profiles
Alternative Path: 1. Admin can write users’ name and search
them
Post-Condition: Admin can send messages to users about their
complaints
Exception Paths: None
Other: None
3.2.2.4. Add Recipe to System
Use Case Name: Add Recipe to System
Xref: Section 2.1.2, Admin Use Case
11
Trigger: Click on the Add Recipe button
Pre-Condition: Expansion recipe list
Basic Path: 1. Admin write ingredients’ list, calorie and
recipe information to add a new recipe to the
system
Alternative Path: None
Post-Condition: Recipes can be recommended to users
Exception Paths: None
Other: The recipe list is updated
3.2.2.6. Delete Recipe from System
Use Case Name: Delete Recipe from System
Xref: Section 2.1.2, Admin Use Case
Trigger: Click on the Delete Recipe button
Pre-Condition: The presence of unpopular and low grade recipes
Basic Path: 1. Admin observes unpopular, low grade recipes
2. Admin can delete them from system
Alternative Path: None
Post-Condition: Users can select from the rest of recipes
Exception Paths: None
Other: The recipe list is updated
3.2.2.7. Update Recipe
Use Case Name: Update Recipe
Xref: Section 2.1.2, Admin Use Case
Trigger: Click on the Update Recipe button
Pre-Condition: Some ingredients’ list or recipe changes occurring
Basic Path: 1. Admin makes necessary changes on recipe and update
it
Alternative Path: None
Post-Condition: Updated recipe can be recommended to users
Exception Paths: None
Other: The updated recipe is added to recipe lists
12
3.3. Non-Functional Requirements
Some important non-functional requirements for the system are listed below.
Accessibility
Users should be reach easily what they are looking for in the website. Web design should
be done simply. Generally, website should be reachable for users.
Usability
All functions but especially complex functions should be tested.
Performance
System’s response time to user and also some small time measurements are very
important such as refresh time etc.
Security
Users’ personal information should be kept secret in the system.
3.4. Flow Description
First of all system needs about 20 recipe to show user. Admin should add recipes to
system.
Finally, the user can evaluate the recipe used.
CONCLUSION
Software requirements document is an important document of project. We explained how we
will do the project in this document. This software requirements document describes in detail
the functional and non-functional requirements and the interface requirements of the system.
The e-r diagram of the system's database is shown. The Use Case Diagram of the system was
drawn and explained what actors could do step by step.
13
