USA: +1(669)289-8683 
Sign in
Use Case Template, Drexel University, IST, INFO 355, Song
| USE CASE # |
<< An arbitrary use case number for reference purpose>> |
|
| USE CASE Name |
<< “Use Verb + Noun” form as the use case name>> |
|
| Scenario |
< |
|
| Trigger |
<< Which event starts the use case?>> |
|
| ACTOR |
<< The actor who will be using this use case. You may list more than one actor here>> |
|
| Goal (1 phrase) |
<< Write a phrase for the goal of the use case in the form of “To + verb + ….”>> |
|
| Overview and scope |
<< Write 2-4 sentences for the overview and main scope >> |
|
| Level |
<< Primary or included or extended >> |
|
| Stakeholders |
< |
|
| Preconditions |
<< Non-trivial pre-conditions to execute this use case>> |
|
| Postconditions in words (write in passive and past tense) |
<< Successful end conditions in business terms. Write them in passive and past tense. Write 3 ideas: (1) What objects were created and deleted in this use case? (2) What attributes changed their values? (3) Which objects were connected/disconnected with which objects? >> |
|
|
Included Use Cases |
<< List of included use case names >> |
|
|
Extending Use Cases |
<< List of extending use case names >> |
|
|
MAIN SUCCESSFUL SCENARIO in numbered sequence Reference “included use cases” in this section using INCLUDE ius_name Italicized terms are defined in Glossary |
Actor Action |
System Action |
|
1. Actor does this |
2. System does that |
|
|
3. Actor does another |
4. System does next thing |
|
|
5 INCLUDE < |
||
|
6. Actor does |
7. System replies |
|
|
8. Customer pays by credit card |
9. Process the credit card |
|
|
10. |
11. |
|
|
<< Add more rows if you need>> |
||
|
OTHER SUCCESSFUL SCENARIOS EXTEND eus_name) |
Step |
Branching Action |
|
2a |
< |
|
|
2b |
<< Another branching action of step 2 above >> |
|
|
8a Customer pays by cash |
9a. System indicates cash and enter amount |
|
|
8b Customer pays by check |
9b. System indicates check and enter amount |
|
|
<< Add more rows if you need>> |
||
|
UNSUCCESSFUL SCENARIOS (erroneous situations) |
Conditions |
Actions |
|
*a |
Abort the transaction . <,Here * means this can be executed at any step>> |
|
|
8c. Customer is short of money; |
Abort the transaction | |
|
9c. Credit card validation fails |
Ask to pay by another means or abort |
|
|
Priority in scheduling |
< |
|
|
Frequency |
< |
|
|
Business rules and data logic |
<< Any integrity constraints on data and business rules related to this use case>> |
|
|
Other non-functional requirements |
<< Optional, non-functional requirements such as performance, reliability, usability, and other design considerations etc.>> |
|
|
Superordinates |
< |
|
|
Developer |
< |
|
|
Creation date and last modified date |
<< The version dates as stated >> |
|
|
Glossary |
< |
|
|
Other Comments |
< |
NOTE 1: ius_name means an included_use_case_name and eus_name means an extended use case name.
NOTE 2: The text inside << >> are comments. Remove them when you use the template for your assignment and project.
NOTE 3: *a means the operation can be performed at any step
Milestone 1
, INFO355
1
Milestone 1, INFO355
2
INFO355: Systems Analysis II
Winter 2018
Project Category: Analysis and Design
Title:
Drexel On-Demand Food Delivery (DOFOOD)
Milestone 1
01/25/2018
Drexel On-Demand Food Delivery (DOFOOD)
1. The problem statement
1.1
Goals of the system
Drexel On-Demand Food Delivery (DOFOOD) is a system designed to help residents of Drexel University order their food and access on-the-door-step delivery to any location within the university. This is a user friendly and a convenient system which targets on solving the buzzing encounters during the meal hours within the school as people seek to buy their foods. The system will help people who are preoccupied either inside a class or carrying out other important activities, making it hard for them to buy food from the surrounding restaurants. It is the most convenient mode of accessing any food from the restaurants during extreme weather conditions as well.
1.2
Context and importance of the system
DOFOOD system incorporates known restaurants around the campus which offer diverse meals selection to suit the different consumer taste. The communication channel between the consumer and the services providers will be through internet enabled devices where by a consumer will be able to place an order to the restaurant which will then confirm the order, prepare the requested food, and make the delivery within a specified time limit. Each restaurant will have an iPad which will be the center of all transactions/operations. This will ease and fasten the transactions and speed of accessing food.
1.3
Scope of the system
The system will be operational 24/7 and will cater for all the persons included within the school’s record systems. This includes; students, staff members, and subordinate staffs. It will also include the restaurants around the campus who will be the providers of delivery services.
1.3.1
In-scope
The in-scope will be built in three important versions. Namely; Customer version, courier version and Restaurant version. Among the components in this section will include available restaurants, special offers, cuisine list and prices, payment, list of orders, and orders status update.
1.3.2
Out-scope
Delivery cost.
2. Requirements
2.1
Functional Requirements of the system
i. Registration of users and restaurants together with their profile updates.
ii. Search for available restaurants.
iii. Search for available cuisines.
iv. Placement of orders and making payment.
v. Sharing location and pickup status.
vi. Updating the user on order status.
vii. Managing orders and receiving payments.
viii. Delivery and pickup of order.
ix. Generating transaction reports.
x. Refreshing the system after every minute.
2.2
Data Requirements of the system
i. A list of restaurants around Drexel University.
ii. User name and profiles according to the Drexel University records.
iii. Payment details.
iv. Invoice details.
v. Available courier services.
vi. Order placement time and delivery time.
2.3
Business Rules and Logic
i. User ID should reflect the registration ID in the university records. This will include their contact information.
ii. The couriers will be interested in the database of available orders, and drop locations (NoAuthorFound, 2017).
iii. Delivery services will be tracked to facilitate follow up of ordered foods.
iv. All transactions will be controlled from one iPad which is under the restaurants management.
v. Restaurant managers will be responsible for orders list and transaction status in order to effectively organize for the delivery of ready meals to the customers.
vi. Users will receive notifications updates on the status of their orders to be aware when the order is to be delivered.
vii. Users have the option to cancel orders. Whereby the respective restaurants will make compensation arrangements.
viii. A cancelled order will not be deleted.
ix. All payment will be made electronically.
x. Only the managers will have access to monthly updates on transaction and payment reports.
xi. Transaction and payment data will be backed up automatically on a daily basis to an external drive.
2.4
Non-Functional Requirements
i.
Usability
The system will be fast and easy to use. It will contain guiding texts and illustrations of how to conduct the entire transaction. Available cuisines will be organized according to customer preferences. There should be a variety of Chinese food, American food, Japanese Food, and any other cuisines served by each restaurant. The system will have a search option which will enable the user to key-in their preferred cuisine name. Each food will have its own picture illustration.
ii.
Reliability
Upon placement and payment of order, the user shall receive a direct notification on the contact information shared which will be the center of all communications with the restaurant.
iii.
Performance
System refreshing will take place in every passing minute.
iv.
Security
Each user will have unique access codes and passwords which will be used in every transaction.
There will be a user help guide for password recovery or change.
Collection of any delivery will require the user to show an ID confirmation from the restaurant.
Transaction details will never be deleted.
2.5
Other important assumptions
i. Registration of each user is same as creating a system account.
ii. Each user is entitled to post their preview of the services and experience they have encountered while using DOFOOD system.
iii. The restaurants are entitled to editing their menu options. This includes adding and deleting items, changing prices, and descriptions attached to each product.
iv. Users will receive daily updates on special offers made by specific restaurants.
3. Examples of system input/output scenarios.
Managing orders
The courier service provider registers via phone or any other social account. He then inputs his logs in to access the list of available orders. These orders are arranged in the order of time in which each transaction was initiated. Order information available include order type, size/number, and delivery location. He then confirms the orders which he can make and then books it by confirming with the respective restaurant. Upon confirmation he notifies the user/customer of an incoming delivery. He then picks the product and delivers it. At this time, he will use a tracking system to indicate his location.
4. Knowledge Acquisition
·
How you will learn about the problem?
A problem in the system will be first noted in the admin version of the system as he is responsible for the running of the whole system. A challenge include computation errors which will be visible at the end of a day’s transaction even without the manager necessarily investigating it.
·
Is this a real problem, or one you have conjured up?
Computation errors might be a challenge due to flooding of orders.
5. Software and/or hardware involved in developing specifications or implementation (if you are working on Life Cycle projects)
List of hardware include iPad for each restaurant and multiple courier vehicles. The software on the other hand include;
i. Stripe SDK software will be used to manage the payment system (NoAuthorFound, 2017).
ii. Firebase SDK software will be used to send push notifications.
iii. Routific API software will be used to optimize routes for the courier.
6. Proposed Deliverables and the work plan
Deliverables for this system include;
i. A profitable restaurant business (Careers, 2013).
ii. A dependable delivery service for meals across Drexel University.
The work plan will begin with introduction of the DOFOOD system to different restaurants around Drexel University. We will then undertake a system test which will include the participation of some members from the university, delivery service provides, and the restaurants as well. Upon completion and satisfaction of the quality of service provided by the system we will embark on launching and marketing of the DOFOOD system.
References
Careers, C. (2013). Make Money With Your iPhone: 100+ Money-Making Apps and Ideas. Cork: BookBaby.
NoAuthorFound, (2017). How Much Does It Cost to Create an On-Demand Delivery App? Retrieved on 24th January, 2018, from:
https://yalantis.com/blog/how-much-does-it-cost-to-create-an-on-demand-delivery-app/
NoAuthorFound, (2017). How to make an On-Demand Food Delivery app. Retrieved on 24th January, 2018, from:
https://stormotion.io/blog/how-to-make-a-food-delivery-app/
Use Case Description Example, INFO 355, Il-Yeol Song
1
Use case template example for VRS: Process Rent
USE CASE # 1
USE CASE Name Process Rent
Scenario Actor checks out at a store
Trigger The use case starts when a staff begins to process rentals of
movie
items
ACTOR Staff
Goal (1 phrase) Capture rental items along with payment.
Overview and scope A store employee checks out items for a customer by calculating
due dates and correct charges. The use case also checks for any
overdue items. The store employee accepts payments for the
items and any late payments. A rental slip is issued and kept by
the store employee.
Level Primary
Stakeholders Customers
Preconditions The staff is logged into the system.
Each rental item has a correct identifier.
Post conditions
(write in passive and
past tense)
(1) Object creation
and deletion
(2) Attribute value
changes
(3) Object linking
The Rental transaction object was created.
The Due dates and Charges were correctly calculated and stored.
The Movie items were marked as rented.
For the Movie Title, Number of available copies was reduced by
the Number of items rented in that transaction.
Payment object was created
Payment amount and date were recorded.
Rented items were associated with the customer.
Payment was associated with the customer. [E1]
Included Use Cases Validate Customer
Pay fee
Check overdue
THE MAIN
SUCCESSFUL
SCENARIO in
numbered sequence
Reference “included
use cases” in this
section using
INCLUDE iuc_name
Actor Action System Action
1. The staff begins to
process rentals of movie
items
2. If current customer, the
staff verifies customer status
by ID card.
3. System finds Customer
information [E2]using the ID
number.
4. System displays Customer
information[E3].
5. INCLUDE Check_overdue[E4]
Use Case Description Example, INFO 355, Il-Yeol Song
2
6. If there is any overdue item,
system displays Overdue
information.[E5]
7. The staff identifies each
rental item to be checked
out.
8. System stores rental information
and transaction.
System determines the Total rental
charges and the Due date.
9. System displays Title, Due date,
and the Rental charge for each
rental item.
10. Once all the rental data
are entered, the staff
indicates to the system that
the transaction order is
completed.
11. System records transaction
Date, Return due date, calculates
taxes, and displays the Total rental
fee. Any Overdue charges are
applied to the customer’s Current
outstanding balance.
12. Customer pays the
charges. Staff initiates the
payment processing.
13. INCLUDE Pay fee
14. If successful, inventory is
reduced for each Rental item.
Also, a receipt is printed.
15. System connects Rental
transaction with Customer.
System connects Rental with
Payment.
All transaction data is saved into
the database.
15. Staff gives rented items
and receipt to the customer
and files the rental slip.
OTHER
SUCCESSFUL
SCENARIOS (Specify
other successful
variations of the
normal execution
path.)
Step Branching Action
2a. If a new customer, the
staff creates an account for
the customer.
INCLUDE Validate_Customer.
3a. ID card fails. Enter ID number manually
3b. Entering ID number
fails
Search using last name and phone
number.
UNSUCCESSFUL
SCENARIOS
(erroneous scenarios)
Conditions Actions
3c Searching process failed
when using the last name or
phone number.
Abort the transaction
Use Case Description Example, INFO 355, Il-Yeol Song
3
6a Customer challenges
overdue charges.
Waive overdue charges, or reduce
overdue charges by 50% or call
management.
13a Payment fails Abort the transaction
*a cancel
Priority Primary
Frequency 500 during week days and 1000 during weekends and holidays
Other non-functional
requirements
1. All staff belong to a security group.
2. Barcode reader must be available
3. Credit card authorization must be completed in 2 seconds
Business rules and
data logic
1. Signature required for credit card transaction.
2. Credit card refunds must be applied to the credit card.
3. Rules for management override.
4. Movie item is identified by a barcode
Superordinates None
Developer Il – Yeol Song
Creation date and
last modified date
Created on: June 10, 2001
Modified on: Jan 25, 2016
Glossary Customer information ( customer ID, name, address, phone
number, and email address).
Overdue information ( transaction number, title, check out
date, due date, and late payment charge).
Other Comments
