0% found this document useful (0 votes)
15 views10 pages

Software Engineering File

Uploaded by

2022582150.jatin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views10 pages

Software Engineering File

Uploaded by

2022582150.jatin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

Software Engineering

And Testing
Methodologies Lab
(CSP357)
B. TECH 3nd YEAR
SEMESTER: 5th
SESSION: 2024-2025

Submitted By: HARSHIT CHAUDHARY


(2022006162)
SECTION: F

Submitted To: Ms. Ashu Goyal


Assistant Professor

DEPARTMENT OF COMPUTER SCIENCE &


ENGINEERING SHARDA SCHOOL OF ENGINEERING &
TECHNOLOGY SHARDA UNIVERSITY, GREATER NOIDA
Experiment 1
Aim: - Design requirement analysis and develop Software Requirement
Specification Sheet (SRS) for suggested systems in IEEE standard.

SRS Report on Online food ordering System –


Introduction-
Purpose:-
This document provides a detailed Software Requirements Specification (SRS) for the
Online Food Ordering System (OFOS). The purpose of this system is to provide users with
the ability to order food from nearby restaurants using a web-based or mobile application.
The document outlines the functionalities, interfaces, system requirements, and
constraints necessary to develop and maintain the system.

Scope:-
The Online Food Ordering System allows users to browse a list of available restaurants, view
their menus, add items to their cart, and place orders. Users can pay online, track their
orders, and review their past transactions. Restaurants have access to an admin interface
where they can manage orders, update menus, and track delivery.

Definitions, Acronyms, and Abbreviations:-


 OFOS: Online Food Ordering System
 UI: User Interface
 UX: User Experience
 DB: Database
 HTTP: Hypertext Transfer Protocol
 API: Application Programming Interface

Overall Description-
Product Perspective:-
The Online Food Ordering System will be a web-based and mobile application accessible to
users, restaurant owners, and administrators. It integrates with a payment gateway,
supports real-time notifications, and provides a seamless user experience for both ordering
food and managing restaurant menus.
Product Features:-
 User registration and profile management
 Real-time restaurant browsing and menu exploration
 Customizable food orders and special instructions
 Online payment gateway integration (credit/debit card, digital wallets)
 Order tracking with real-time status updates
 Review and rating system for orders and restaurants
 Admin panel for restaurant management (menu updates, order management) 

User Classes and Characteristics:-


 Customers: End-users of the system who place food orders.
 Employee: Manage their restaurant profile, menu, and orders.
 Admin: Responsible for managing users, orders, and system settings.

Operating Environment:-
 Mobile: Android and iOS devices, supporting modern web browsers.
 Web: Compatible with modern browsers like Google Chrome, Mozilla Firefox,
Safari.

Design and Implementation Constraints:-


 The system must comply with PCI DSS standards for handling online payments.
 The system should be accessible to users with varying levels of technological
expertise.
 The user interface must be responsive and mobile-friendly. 

Assumptions and Dependencies:-


 Reliable internet connection for all users.
 Integration with third-party services (payment gateways, SMS/Email APIs) will be
available. 

External Interface Requirements-


User Interface:-
There would be two separate apps for food brands and customers.
However, the app would maintain consistency and follow some standards:
• There shall be a fixed menu bar at the top with following buttons (All, Budget,
Deals/discounts/Rating)
• There should be fixed drop down menu pointer at top left with following options (Profile,
Help, Settings, Logout)
• On clicking the logo, the system shall return to Home Page
• There should be a “Contact us” and “Logout” buttons at bottom

Hardware and Software Interface:-


We would require following technology for development of the app:
Camera: for QR scanning.
GPS receiver: indicates user location.
Moreover, following technology stack can be used: MySql database, Javascript and React
for front end, PHP for backend, any framework such as Angular and server such as Apachee.
A cache such as Memcached would be required to store data.
Cloud can be used for backup and retrieval of data.

Communication Interface:-
The system will use following communication interfaces:
Emails, Social media, Text communication etc.
Protocols would be required for secure communication and message encryption.

Other non-functional Requirements-


Performance Requirements:-
The app should provide greater performance with no delay. For food brands, who would
be using web app on their desktop computers, the performance should be good and
queries with minimum “join” statements are preferred for better and fast results. Too many
tables in database can result in slower execution of queries, hence effecting the entire
system 92% of the queries shall be completed in approximately 3.5-4 seconds. There should
be no more than 0.5 – 0.8 second of delay in communication between customers and food
brands.

Safety Requirements:-
RPO and RTO should be clearly defined to avoid loss of data that could affect the business.
The system can not afford loss of data of its customers because it provides analysis on basis
of it.
Security Requirements:-
• Every user must change his initial password after first successful login
• If any user uses his credit card for payment, OTP is sent via text or call for confirmation
• The user shall receive a text message by bank on successful transaction

Software Quality Attributes:-


The mobile app should have a responsive layout and should be portable. The web app
should be scalable and manages the data load accordingly. The mobile app should follow
recognition rather than recall i.e. it is simple and easy to use and learn.
Experiment 02
Aim: -. Draw the user ‘s view analysis for the suggested system: Use case diagram,
Activity Diagram and State chart Diagram.

Use case Diagram for Online food ordering System-

A use case diagram for an online food ordering system visually represents the
interactions between the users (actors) and the system itself, outlining the key
functionalities and how users engage with them.
Actors (Users): Represented by stick figures (Customer, Restaurant Staff, Delivery
Person, Administrator).
System Boundary: The rectangle encapsulating all the use cases, indicating what the
system does.
Use Cases: Represented as ovals inside the system boundary, showing the
functionalities (e.g., "Navigate Menu", "Review Order").
Activity Diagram-

An activity diagram for an online food ordering system visually represents the
workflow of the system, showing how users and the system interact during the
food ordering process.
 Customer Logs In/Registers.
 Browse Menu and Select Food Items.
 Customize Order, View Cart, and Confirm Order.
 Make Payment and Order Confirmation.
 Restaurant Prepares Food.
 Track Order and Deliver Food.
 Order Completion
State Chart Diagram-

A State Case Diagram (or State Machine Diagram) for an online food ordering
system shows the various states the system can be in at different times, along
with the transitions between these states.
States in Online Food Ordering System:
1. Inspection: Either Accepted/Rejected by Restaurant.
2. Order Status: If Status = Ready then order is dispatched and if Status =
Not Ready then order is prepared.
3. Delivered: Customer either receives the order or the order returns back
to the restaurant.
Key Transitions:
1. Order Inspects -> Available : Order is being prepared.
2. Payment Pending → Order Confirmed: Payment successful.
3. Order Status -> Ready : Order is dispatched and out for delivery.
Experiment 3
Aim: -. Draw the structural view diagram for the system: Class diagram,
object diagram and Sequence diagram.

Class Diagram-

A class diagram is used to represent the static structure of a system, showcasing the classes, their
attributes, methods, and their relationships.
Classes: Rectangles represent classes. Each class includes the class name, attributes, and methods.
Attributes: These are represented as name: type pairs within the class rectangle.
Methods: These are listed beneath the class name within the class rectangle.
Associations: Lines connecting classes represent associations or relationships between classes. You
can label associations to indicate their nature (e.g., one-to-many).
Inheritance: An open arrowhead line indicates inheritance or a parent-child relationship between
classes.
Sequence Diagram:-
A sequence diagram illustrates the interactions and messages exchanged between objects or
components in a particular scenario or use case.
Lifelines: Vertical lines represent the lifelines of objects or actors involved in the scenario.

Messages: Horizontal arrows show the flow of messages between objects. Labels on the arrows
describe the type of message or method call.
Activation Bars: Activation bars show the period during which an object is active and processing a
message. Return Messages: Dashed arrows represent return messages when an object responds to a
message.

You might also like