requirement specifications document for kids and babies day care center

Muhammad Salman Habib 4/8/2023


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

number

Requirement Description reference Priority

R0 Secure login Login, unique ID Specification

documentation

template

Essential

R1 Secure login Password, 6-8

alphanumeric only

Specification

documentation

template

Essential

R2 Store child

information

Child full-name, SSN,

Birthday,

Specification

documentation

template

Essential

R3 Store parent

information

Parent full name, SSN,

address, emergency

contacts

Specification

document

template

Essential

R4 Child

immunization

Child ID, child name

Immunization tracking,

immunization type, date

of immunization, due

date, doctors name.

Specification

document

template

Essential


R5 Class class activities,

class schedules, class

room tracking, instructor

Specification

document

Template

Essential

R6 Expenses building maintenance

electricity

Specification

document

template

Essential

R7 Profile

management

employee ability to

change password

Specification

document

template

Desirable

R8 Child status Active, inactive Specification

document

template

Essential

R9 Report Customer log notes,

correspondence records,

child special notes, child

immunization history,

Group Decision Desirable

R10 Scheduling

Information

Appointment, contract

Renewal

Web Future

R11 Employee

information

SSN, name , address ,

phone number, gender,

email address, birth date.

R12 Billing

Information

Tuition charges, Late

fee, family discount &

payments, print balance

Specification

document

template

Essential

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.


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:


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:

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:

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:

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:


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:

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:

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:

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:

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:

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


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.

2. This is one of the actor classes


3. This is the other actor class

4.

5.


6.

7.

8.

9.


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

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

Documents