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