Requirement Specifications Document For Kids and Babies Day Care Center

Muhammad Salman Habib Page 1 1/15/2009
Index
1. Introduction
a. Goals and Objectives
b. Statement of Scope
c. Software Context
d. Major Constraints
2. User Scenarios
a. User Profiles
b. Use-cases
c. Use-case Diagrams
d. Use-case Descriptions
3. Data Model
a. Data Objects
b. Relationships
c. Complete Data Model
4. Functional Model and Description

a. Class Diagrams
b. Software Interface Description
5. Behavioral Model
a. Events and States
b. State-chart Diagram
6. Limitation and Constraints
7. Test Cases
a. Classes of Test
b. Expected Software Response
c. Performance Bounds
Introduction
The goal of designing software for a “Day care center” is to provide a complete Day Care
Management system, keeping the day care provider and clients in mind. It is essentially
an electronic filing cabinet that maintains a complete record of clients and employee
information. The clients are the customers that is, parents and children. The system
maintains information such as parents and child address and their personal data in a
database. The software system is modeled and designed such that it has the seamless
integration between all feature based elements that makes it very user friendly. Users of
the software have the ability to add/update/delete all information based on their access
levels. Secure entry into the system is envisaged through all employees being identified
by a unique login ID and given password. Family & child data collection is a
fundamental requirement for all Child Care businesses. Our collection capabilities are
robust and simple with an ease of use that makes the task of data entry quick and
efficient.
a. Goals and Objectives:
The objective of the software is to build a tool for the use for a day care management
With the following features:
1. Create data base for family and child information with features: Parent names,
addresses, phone numbers, email addresses, emergency contacts, authorized
pickups, Child Name, Birth Date, and Class.
2. Immunization tracking information: recording immunization types, physicals and

dates. Classroom Tracking & Scheduling Classrooms, programs, activities
schedules.
3. Waiting List & Potential Customer Tracking, Daily Reminders, upcoming

appointments, contract renewals.
4. Customer Log Notes, Maintain records of correspondence with parents, children

special need, incident reports, and more.
5. Login is required for all users.
6. Users be divided into groups and access is granted on a per group basis.
7. We aim to provide continuity throughout each phase of a project.
8. Account activity reports and receipt printing. Track each family’s balance
including their child care billing history of registration fees, tuition charges,
family discounts and payments received. Billing History, history of registration
fees, tuition charges, family discounts and payments
9. Generate a report of all the expenses.
10.We also aim to design the software to be much user friendly, all the interfaces to
be self descriptive and interactive.
b. Statement of Scope:
As per the requirements of the client, different functionality has been designed keeping in
view the constraints of time and manpower. The major software inputs are the parents and
child information and major outputs are billing forms, receipts etc. The software very
closely matches the requirements laid down by the end users, viz. Employees,
Administrators. It maintains a data repository containing the information related to each
child. It has the required features of parent and child information, tracking each child for
information related to his/her done through interface which manages efficiently and
thoroughly all issues related to child. There are requirements, which are desirable and
would increase the scope of the final product if incorporated in the project. One such
feature is incorporating additional features such making appointments and contract
renewals through web based service, which would be added in near future, due to time
constraints. All major functionality, which falls in the category of essential and desirable
prioritization of the day care centre software, will be implemented with an attempt to
model the future priority needs as well if time permits.
REQUIREMENT PRIORITIES
Requirement Requirement Description reference Priority

number
R0 Secure login Login, unique ID Specification Essential

documentation
template
R1 Secure login Password, 6-8 Specification Essential
alphanumeric only documentation
template
R2 Store child Child full-name, SSN, Specification Essential
information Birthday, documentation
template
R3 Store parent Parent full name, SSN, Specification Essential
information address, emergency document
contacts template
R4 Child Child ID, child name Specification Essential
immunization Immunization tracking, document
immunization type, date template
of immunization, due
date, doctors name.
R5 Class class activities, Specification Essential

class schedules, class document
room tracking, instructor Template
R6 Expenses building maintenance Specification Essential

electricity document
template
R7 Profile employee ability to Specification Desirable

management change password document
template
R8 Child status Active, inactive Specification Essential

document
template
R9 Report Customer log notes, Group Decision Desirable
correspondence records,
child special notes, child
immunization history,
R10 Scheduling Appointment, contract Web Future
Information Renewal
R11 Employee SSN, name , address ,
information phone number, gender,
email address, birth date.
R12 Billing Tuition charges, Late fee, Specification Essential

Information family discount & document
payments, print balance template
R13 Billing Charging late fee for Specification Future
information overdue payment document
template
R14 Security Using electronic ID System Access Future
c. Software Context:
As per the requirements of the client, different functionality has been designed keeping
in view the constraints time and manpower. The major software inputs are the parents and
child information and major outputs are billing forms, receipts etc. The software very
closely matches the requirements laid down by the end users, viz. Employees,
Administrators. It maintains a data repository containing the information related to each
child, parent. It has the required features of tracking each child for information related to
each individual done through interface which manages efficiently and thoroughly all
issues related to child development and needs. There are requirements, which are
desirable and would increase the scope of the final product if incorporated in the project.
One such feature is incorporating additional features such making appointments and
contract renewals through web based service, which would be added in near future, due
to time constraints. All major functionality, which falls in the category of essential and
desirable prioritization of the day care centre software, will be implemented with an
attempt to model the future priority needs as well if time permits.
d. Major Constraints:
There are few points that we have not covered like loss of unsaved data, any sort of
security feature. No restoring facility has been provided. Our software system is not
redundant that is there is no backup facility. The system also depends on the network that
is its speed. If the speed of the network is not sufficient there is a likelihood of slow
response. DOTNET framework has to be installed on the web server since the software
runs of DOTNET environment. And moreover we need a high performance web server
for good performance.
Usage Scenario
a. User Profiles:
The user profiles are divided into three types in this system.
1. Parent:
A parent will have the accessibility to view their child’s information and schedule.
They are restricted to very low profile when compared to others.
2. Employee:
An employee can view the billing information of all children along with viewing
and updating the privileges given to parent.
3. Administrator:
He can access, view, delete and update all the information available in the
website. He is given all the privileges.
b. Use-Cases:
A Use-Case Diagram is used to depict the main aspects of the system and the
ways a user can interact with the system. Separate use cases and their description follows
the Use-case diagram below.
c. Use Case Diagrams:

Please refer the next page for the figure.
Manage Children
Manage Classes
«uses»
«uses»
Manage Activities
«uses»
«uses»
«uses»
«uses»
Manage Child
«uses» Immunization
«uses» «uses»
«uses»
«uses» Manage child «uses»
Employee
«uses» Schedule
«uses» «uses»
«uses» «uses»
Login
«uses»
Parent
«uses» Manage Parent Info
Admin
«uses»
Manage Payments on
«uses» Child A/C
Manage Billing on
Child A/C
Manage Expenses
 This is the system use-case diagram that displays all the different tasks that are
accomplished by the system. Following this, we will have brief description of each of
these use-cases.
d. Use-Case Descriptions:
1. Manage Children:
«uses»
Employee Manage Children

«uses»
Admin
Objective: Admin and Employee will be able to add, delete and update child
information.
Pre-condition: User has logged in successfully as Admin or Employee.
Post-condition: NA
Main Flow:
1. System displays a form with editable fields for child's information. For Add, it
would be empty fields and for Edit child info, there will be child information for
selected child
2. Admin/Employee fills out new child information or edits the existing child info
[A1]
3. Admin/Employee hits submit button on the page
4. System saves the child information in database
5. System notifies the user
Alternative flow: A1
1. Admin/Employee presses delete button on edit child info page

2. System asks for confirmation on child delete
3. On confirm, system checks whether the child's account has any bills due
4. If payment is due on child A/C, System notifies the employee of due bill
5. On confirm system adds the amount in Day care Expenses table
6. System deletes the child from database
7. User is notified
2. Manage Class:
«uses»
Employee Manage Classes
«uses»
Admin
Objective: Employee/Admin can add, delete or update a class information.
Pre-condition: User has successfully logged in as Employee/Admin
Main Flow:
1. Employee/Admin can either select a class from dropdown list and modify the
fields and edit it, or they can add a new class and finally click submit.
2. On submit, the system performs validation and adds the class to database or
updates the class.
Alternative Flow:
1. Employee/Admin can select one class from drop down list, and can click delete
button.
2. System asks for confirmation and on confirm, system deletes the class from
database.
3. Manage Activities:
«uses»
Employee Manage Activities

«uses»
Admin
Objective: Employee/Admin can add, delete or update a activity.
Pre-condition: User has successfully logged in as Employee/Admin
Main Flow:
1. Employee/Admin can either select an activity from dropdown list and modify the
fields and edit it, or they can add a new activity and finally click submit
2. On submit, the system performs validation and adds the class to database or
updates the activity
Alternative Flow:
1. Employee/Admin can select one activity from drop down list, and can click delete
button.
2. System asks for confirmation and on confirm, system deletes the activity from
database.
4. Manage Child Immunization:
«uses»
«uses»
Employee Manage Child
Immunization
«uses»
Parent
Admin
Objective:
Employee/Admin can add child immunization information, Admin can also update or
delete an immunization record
Pre-condition: User must have successfully logged in as an employee or admin
Post-condition: Employee/Admin updates child's immunization information
Main Flow:
1. System shows the user the child's immunization information.
2. When applying immunizations to the child, the Employee/Admin can add

information about child's immunization info @ date, type of immunization,
physicals... etc. and press submit.
3. System stores this information in database
Alternative flow:
1. Admin can also edit or delete an immunization entry
2. Select an immunization entry from the list, to edit, or click delete
3. System deletes or updates the information from database
5. Manage child Schedule:

«uses»
«uses»
Employee Manage Child
Immunization
«uses»
Parent
Admin
Objective:
Add or delete a class or activity in a child's schedule, A parent can only view child
schedule, cant update it
Pre-condition: User has logged into the system as Employee or Admin, to view Parent
have to be logged in as parent
Post-condition: Employee/Admin can update child's schedule
Main Flow:
1. Employee/Admin selects a class or an activity to the student's schedule

2. System checks if there is already another class existing at the same time
3. If there is no class at the same time then the class is added, activities have more
priority than class
4. Information is stored in the database and user is notified of that
Alternative flow:
1. Parent can view the student schedule online

2. Parent logs in and chooses to view the child's schedule

3. system fetches the schedule information of that child from database and displays
in proper format
6. Login:
«uses»
«uses»
Login
Employee «uses»
Parent
Admin
Objective: Log the user into the system and direct him to the proper interface(webpage)
Pre-condition: NA
Post-condition: User is logged into a system and sees an Admin/Employee/Parent

interface
Main Flow:
1. System shows the user a login screen with editable boxes for Username, Password
and a dropdown menu for category: Employee, Admin or Parent
2. User puts username and password and then selects a category from the dropdown
list
3. User hits submit
4. System authenticates the username and password
5. System shows the proper interface as per selection, if the authentication is

successful
Alternative Flow:
1. If the username and password don’t match, the system shows login screen again
7. Manage Parent Info:
«uses»
«uses»
Employee Manage Parent Info
«uses»
Parent
Admin
Objective: Admin and Employee will be able to add, delete and update Parent
information.
Pre-condition: User has logged in successfully as Admin or Employee.
Post-condition: NA
Main Flow:
1. System displays a form with editable fields for parent's information. For Add, it
would be empty fields and for Edit child info, there will be Parent information for
selected parent
2. Admin/Employee fills out new child information or edits the existing parent info
and selects the child(/children) the parent is associated with [A1]
3. Admin/Employee hits submit button on the page
4. System saves the parent information in database
5. System notifies the user
Alternative flow: A1
1. Admin/Employee presses delete button on edit Parent info page

2. System asks for confirmation on Parent delete
3. On confirm, system checks whether the Parent is the only parent for any children
4. If parent is the only parent for any child, System notifies the employee of it, no
changes made to database
5. If that is not the case, System deletes the child from database
6. User is notified
8. Manage Payments on Child A/C:
«uses»
Manage Payments on
Child A/C
Admin
Objective: Admin should be able to add update or delete a payment to a child's account
Pre-condition: User must be logged in as an admin
Post-condition: Admin user can add update or delete records for payment to a child
account
Main Flow:
1. Admin selects a child

2. System displays a button saying Add payment on top, and displays all the
Payment entries below it, with edit and delete buttons [A1]
3. User goes to edit billing page with blank editable fields for add entry or editable
fields with data for the selected record
4. User makes changes to the fields and hits submit button
5. System does the validation and adds an entry in the database
6. User is notified
Alternative Flow A1:
1. User selects delete button next to one of the payment records

2. The payment record is deleted from database
3. User is notified
9. Manage Billing on Child A/C:
«uses»
Manage Billing on
Child A/C
Admin
Objective: Admin should be able to add update or delete a bill to a child's account
Post-condition: Admin user can add update or delete records for billing from a child
account
Main Flow:
1. User selects a child

2. System displays a button saying Add billing on top, and displays all the billing
entries below it, with edit and delete buttons [A1]
3. User goes to edit billing page with blank editable fields for add entry or editable
fields with data for the selected record
6. User is notified
1. User selects delete button next to one of the billing records

2. The billing record is deleted from database
3. User is notified
10. Manage Expenses:
«uses»
Manage Expenses
Admin
Objective: Admin should be able to add update or delete expenses

Post-condition: Admin user can add update or delete records for day care expenses into
the system
Main Flow:
1. System displays a button saying Add Expense on top, and displays all the
expenses records below it, with edit and delete buttons [A1]
2. User goes to edit expenses page with blank editable fields for add entry or
editable fields with data for the selected record
5. User is notified
1. User selects delete button next to one of the expenses record

2. The expense record is deleted from database
3. User is notified
Data Model
a. Data objects:
The major data objects that we are using in the system are basically the main entities that
are described in the requirements.
• Child
• Parent
• Classes
• Activities
• Schedule
• Billing
• Payment
• Expense
We will describe them as classes in the next section and identify their essential attributes
and essential operation that are performed on these objects.
b. Relationships:
We identify the relationships between two or more Data objects and describe them below:
c. Complete data model
class -Manages
* -Has
1 schedule -has Child
* -Has
*
* * *
* * *
activity * *
*
billing
* -Views
*
Parent *
*
-Views
Parent *
-Views payment
* *
*
-Manages
-Manages *
* * -Manages
*
-Manages -Manages
Employee -Manages Expenses
-Manages -Manages
* *
*
* * *
Admin Employee
The next section will take each of these data object and describe them as a class,
mentioning the important attributes and operations.
Functional Model and Description
a. Class Diagrams:
Here we have all the classes that we will consider for designing the system. We take care
that all the Use-cases that we want to accomplish and all the operations can be performed
by the use of following classes.
1.
child
-SSN
-Name
-BirthDate
-Gender
-FirstContactParent
+AddChild()
+UpdateChild()
+DeleteChild()
2. This is one of the actor classes

Parent
-SSN
-Name
-BirthDate
-Gender
-LoginID
-Password
-Address
-EmailAddress
-PhoneNumber
+AddParent()
+UpdateParent( )
+DeleteParent()
+ViewChildrenSchedule()
+ViewChildrenImmunization()
+ViewBilling()
3. This is the other actor class

Employee
-SSN
-Name
-BirthDate
-Gender
-LoginID
-Password
-Admin
-Address
-EmailAddress
-PhoneNumber
+AddEmployee()
+UpdateEmployee()
+DeleteEmployee()
+ManageChildren()
+ManageParent()
+ManageClasses()
+ManageActivities()
+ManageSchedules()
+ManageBilling()
+ManagePayment()
+ManageExpenses()
+ManageImmunization()
4.
Class
-ClassID
-ClassName
-Instructor
-Description
-Timing1
-Timing2
+AddClass()
+UpdateClass()
+DeleteClass()
5.
Activity
-ActID
-ActName
-Instructor
-Description
-Timing
+AddActivity()
+UpdateActivity()
+DeleteActivity()
6.
ChildSchedule
-SchID
-ChildID
-ClassAct
-ClassID
-ActID
+AddSchedule()
+UpdateSchedule()
+DeleteSchedule()
7.
BillingInfo
-BillingID
-BillingDescription
-BillingAmount
+AddBill()
+UpdateBill()
+DeleteBill()
8.
PaymentInfo
-PaymentID
-PaymentDescription
-PaymentAmt
+AddPayment()
+UpdatePayment()
+DeletePayment()
9.
ExpenseInfo
-ExpenseID
-ExpenseDesc
-ExpenseAmt
+AddExpense()
+UpdateExpense()
+DeleteExpense()
b. Software Interface Description:
Our software system is a simple, user friendly web based solution. It has no external
system interfaces and no external machine interfaces. It has only a human interface that
is a GUI(Graphical User Interface). GUI is basically the interface description of the
software system contained in the requirement documentation. There are three types of
human interfaces in our system namely employee, parent, administrator which will be
interacting with the software system. Although we can have an external system interface
by maintaining database in a different server but the depends on the size of the database
Behavioral Model and Description
The behavioral model indicates how software will respond to external events or stimuli. It
depicts the dynamic behavior of the system as a function of specific events and time.
These specific events are triggered by the actors who use the system.
There are three types of actors in this system depending on their access levels.
1. Parent:
A parent can login and only view class schedule, billing information and immunization
information of his/her child. He cannot make any type of modifications to the information
displayed.
2. Employee (Staff):
An employee’s accessibility is also limited. An Employee can view and make changes to
class schedules, activities, and child and parent information and also to immunization
information.
3. Administrator:
Administrator has no restrictions in accessing any type of information or updating it. He

can manage the
a. Description for software behavior

To better understand the behavioral model of this system, the events which result in
different states are listed below. The actors who trigger the particular event are also listed.
Events:
Event: Login User
Actor: Parent/Employee/Administrator
Event: View class schedule

Actor: Parent
Event: View Billing Information

Actor: Parent
Event: View Immunization Information

Actor: Parent
Event: View/Delete/Update Classes

Actor: Employee/Administrator
Event: View/Delete/Update Activities

Event: View/Delete/Update Immunization Information

Event: View/Delete/Update Child Information

Event: View/Delete/Update Parent Information

Event: View/Delete/Update Billing Information

Actor: Administrator
Event: View/Delete/Update Payment Information

Event: View/Delete/Update Expenses Information

Event: Logout User

Actor: Parent/Employee/Administrator
States:
A state is any observable mode of behavior and a state diagram depicts the actions taken
as a consequence of a particular event. The whole system is divided into 3 states namely
depending on the access levels. Two other states are also defined to enter and exit the
system.
The states are as follows:
1. Login user:
By entering a valid user id, password and the type of user, he will gain access to
the system.
2. Administrator:
By entering valid login information, the user can enter this state and will be able
to perform all the operations he can access and make changes to the database.
Generally he has the control of the whole system. He can exit the system by
logging out.
3. Employee:
After logging into the system, an employee can manage the system depending on
his access level. He has certain limitations in accessibility. Logging out of the
system will take him to logout user state.
4. Parent:
A parent can enter the system by entering valid user id and password. After
entering the system, user can view his own child’s information. He cannot make
any kind of changes to the database. Exits the system by logging out.
5. Logout user:
User will be taken to this state once he logs out of the system. Here he can go
back to login user state through re-login information.
b. Statechart Diagram:
Initial State
LogIn User
Enter ID
Enter Password
Select user type
Administrator Home
Employee Home View, delete and Update Class Schedule
Parent Home View, delete and Update Immunization
View, delete and Update Class Schedule Information
View Class Schedule View, delete and Update Immunization Information View, delete and Update Activities
View Billing Information View, delete and Update Activities View, delete and Update Child Information
View Immunization Information View, delete and Update Child Information View, delete and Update Parent Information
View, delete and Update Parent Information View, delete and Update Billing Information
View, delete and Update Payment Information
View, delete and Update Expenses Information
LogOut User
LogIn again
Final State
Restrictions, Limitations & Constraints
• The size of the database is restricted to few hundreds.

• The software doesn’t have any security features, network features or doesn’t have
any compatibility for it. So software has to be further developed to deploy it
network.
• It is developed in such a way that the employee can work only on one user
interface and therefore employee cannot open multiple interfaces and perform
task simultaneously.
• Some applications can only be used by administrator e.g. change the fees structure
of children, add or remove the employees etc.
• The Graphical User Interface (GUI) is planned to be developed in Java 1.5 or
above and the minimum hardware requirements are:
1. Intel® Pentium® III processor (or higher preferred)
2. 256 MB memory
3. 20MB free disk space
4. Windows 2000/Xp/Vista
Validation Criteria
The validation criteria for the software system is such that the information provided in the
fields is checked for the correct format and if any information of child or parent is found
to be wrong or missing then it will not be able to enter the database.
Business rules are validated that is: only the administrator can change certain things such
as billing information, add and remove employee’s names etc.
Each user has a unique ID and password provided by the administrator.
a. Classes of Tests:
The inputs are going to be entered erroneously to check the system performance.
Basically test cases are going to be developed by using brainstorm sessions. This will
help us to figure out behavior of system and performance of the system.
Method of testing:
• The system’s internal structure will be tested (white box testing)
• The overall system will be tested (black box testing)
• Specimen test cases:
1. Click add button to add the parent without his or her social security number.
2. Click staff information to add or remove the name of employee from the staff
Login.
3. Click add button to add the child without his or her parent information.
b. Expected Software Response

This software will perform certain operations like Add, Remove or Update the detail
Information of child, parent, employee, administrator etc. It will keep track of billing,
Immunization and class activities. When searching for a particular child a unique id will
be specified and all the information about the child will be displayed.
c. Performance Bounds
The major performance bound in our software system is the size of the database although
this could be improved by using another external system interface. The performance of
the software in terms of response time is at best immediately or at worst 20 seconds. A
major factor pertaining to response time is the network speed.
END OF
Requirement Specifications Document

Requirement Specifications Document For Kids and Babies Day Care Center

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Requirement Specifications Document For Kids and Babies Day Care Center

Загружено:

Авторское право:

Доступные форматы

Muhammad Salman Habib Page 1 1/15/2009

Muhammad Salman Habib Page 2 1/15/2009

4. Functional Model and Description

6. Limitation and Constraints

a. Goals and Objectives:

2. Immunization tracking information: recording immunization types, physicals and

3. Waiting List & Potential Customer Tracking, Daily Reminders, upcoming

4. Customer Log Notes, Maintain records of correspondence with parents, children

5. Login is required for all users.

7. We aim to provide continuity throughout each phase of a project.

9. Generate a report of all the expenses.

Requirement Requirement Description reference Priority

R0 Secure login Login, unique ID Specification Essential

R5 Class class activities, Specification Essential

R6 Expenses building maintenance Specification Essential

R7 Profile employee ability to Specification Desirable

R8 Child status Active, inactive Specification Essential

R12 Billing Tuition charges, Late fee, Specification Essential

c. Use Case Diagrams:

«uses» Manage Parent Info

Employee Manage Children

Pre-condition: User has logged in successfully as Admin or Employee.

1. Admin/Employee presses delete button on edit child info page

Employee Manage Classes

Objective: Employee/Admin can add, delete or update a class information.

Pre-condition: User has successfully logged in as Employee/Admin

Employee Manage Activities

Objective: Employee/Admin can add, delete or update a activity.

Pre-condition: User has successfully logged in as Employee/Admin

4. Manage Child Immunization:

Pre-condition: User must have successfully logged in as an employee or admin

Post-condition: Employee/Admin updates child's immunization information

1. System shows the user the child's immunization information.

2. When applying immunizations to the child, the Employee/Admin can add

3. System stores this information in database

1. Admin can also edit or delete an immunization entry

2. Select an immunization entry from the list, to edit, or click delete

3. System deletes or updates the information from database

5. Manage child Schedule:

Post-condition: Employee/Admin can update child's schedule

1. Employee/Admin selects a class or an activity to the student's schedule

1. Parent can view the student schedule online

2. Parent logs in and chooses to view the child's schedule

Post-condition: User is logged into a system and sees an Admin/Employee/Parent

5. System shows the proper interface as per selection, if the authentication is

7. Manage Parent Info:

Pre-condition: User has logged in successfully as Admin or Employee.

1. Admin/Employee presses delete button on edit Parent info page

8. Manage Payments on Child A/C:

Pre-condition: User must be logged in as an admin

1. Admin selects a child

Alternative Flow A1:

1. User selects delete button next to one of the payment records

9. Manage Billing on Child A/C:

Pre-condition: User must be logged in as an admin

1. User selects a child

Alternative Flow A1:

1. User selects delete button next to one of the billing records

10. Manage Expenses:

Objective: Admin should be able to add update or delete expenses

Pre-condition: User must be logged in as an admin

Alternative Flow A1:

1. User selects delete button next to one of the expenses record