Software Requirements Specification
 Data Model and Description
Functional Model Description
Behavioral Model Description
Restrictions, Limitations, Constraints

Introduction
Usage scenario

3. Data Model Description

3.1 Data objects
3.2 Relationships
3.3 Complete data model

4. Functional Model Description

4.1 Class diagrams
4.2 Software Interface Description

4.2.1 External machine interfaces
4.2.2 External system interfaces
4.2.3 Human interface

5. Behavioral Model Description

5.1 Description for software behavior

5.1.1 Events
5.1.2 States

5.2 Statechart Diagram

6. Restrictions, Limitations, and Constraints

7. Validation Criteria

7.1 Classes of tests
7.2 Expected software response
7.3 Performance Bounds

Appendix A: Glossary
Appendix B: Issues List
 

3. Data Model and Description

3.1 Data objects

Child Data Object
ChildID A unique identifier assigned to the child.
ParentID The parent's identification number.
Name The child’s name.
BirthDate The child's birth date.
Gender The child’s gender.
ClassroomID The classroom that the child has been assigned to.
SpecialNeeds Any special needs such as allergies or physical handicaps.
Photo A photo of the child.
Status Indicates if the child is enrolled or on a waiting list.
Comments A teacher's comments about the child's behavior.


Parent Data Object
ParentID A unique number assigned to the parent.
Name The parent’s name.
Address The address of the parents.
HomePhone The home phone number for the parents.
WorkPhone A work phone number for a parent.
Email An email address for the parents.
EmgName A name to contact in an emergency if the parents cannot be reached.
EmgPhone The phone number to call in an emergency if the parents cannot be reached.
AuthPickUp The name of someone the parent has authorized to pick up their child.


Employee Data Object
UserID A unique number assigned to the employee.
Password The employee's password used to log on to the computer system.
FirstName The employee's first name.
LastName The employee's last name.
Classification The job classification of the employee. Limited to administrator, teacher, or assistant.


Classroom Data Object
ClassroomID A unique number for the classroom.
Name The name of the classroom.
RoomNo The classroom number.
PhoneNumber The phone number for the classroom.
Teacher The name of the teacher assigned to the classroom.
Assistant The name of the teacher assistant assigned to the classroom.


Bill Data Object
InvoiceID A unique number for an invoice. Invoices are issued each month to every parent.
ParentID The identifier number of a parent.
AmountDue The amount owed for a particular invoice.
AmountPaid The amount that has been paid for a particular invoice.
DatePaid The date the invoice was paid.


Call Sheet Data Object
ChildID The identifier number of a child.
Date The date that the information was entered.
SignIn The time the child arrived at the Day Care Center.
SignOut The time the child left the Day Care Center.


Change Data Object
UserID The number of the employee changing the record.
Time The time of the change.
Description A description of the change being made.


Immunization Data Object
ImmuneID A unique number assigned to the immunization record.
ChildID The identifier number of the child that received the immunization.
Type A description of the immunization.
Date The date that the immunization was received.


Registration Data Object
ChildID The identifier number of the child.
RegisterDate The date that the child registered.
EnrollDate The date that the child actually enrolled.
WithdrawDate The date that the child withdrew.


Reminder Data Object
ReminderID A unique identifier for the reminder.
EmployeeID The ID number of the employee entering the reminder.
Date The date of the reminder.
Message The reminder message to be displayed.
^ TOP

3.2 Relationships

In order for a parent to have an account with the Child Care Center they must have at least one child. Since a parent can have multiple children a one-to-many relationship exists. It is also true that a parent and child cannot exist alone in the NCCM system. In general all children must have parents and a parent without a child has no need to register for the Day Care Center.

A parent will receive a new bill each month so a one-to-many relationship exists. Before the first month of enrollment a parent may exist without a bill, however after the first month the two data objects cannot exist alone.

Each classroom can hold up to twenty children so the twenty-first child will be added to a waiting list. With fewer than 21 children there is no need for a waiting list; however a waiting list must always be associated with a classroom. A one-to-one relationship exists because a classroom will have at most one waiting list and each list can only be used for a single classroom.

An immunization data object is created for every immunization a child receives. Therefore each child will have many immunizations and a one-to-many relationship exists. A child will not be admitted without an immunization, therefore an immunization and child cannot exist alone.

An employee may add multiple events to their daily reminder list so a one-to-many relationship exists. Since the employee may not need to be reminded of anything it is possible for an employee to exist without a daily reminder, but a daily reminder must be assigned to a specific employee.

Each time an employee edits a record it will be recorded in the change data object. Most employees will make multiple changes so there is a one-to-many relationship between employees and change data objects. An employee may not make any changes and can therefore exist alone. However, a change object must be associated with an employee and therefore cannot exist alone.

An immunization object will be created for a child each time they receive a new immunization, therefore a one-to-many relationship will exist. A new call sheet object will be created every day so it will also be in a one-to-many relationship with the child. The registration data object could also be in a one-to-many relationship because a child could withdraw and then reenroll. Typically there will only be a one-to-one relationship between the child and registration objects, but this is not by design. Neither the immunization, call sheet or registration objects can exist without a child object.

Each classroom can have up to twenty children so a one-to-many relationship exists between classrooms and children. It is also true that a classroom and child should not exist alone.
^ TOP

3.3 Complete data model

The relationships between the data objects describe in section 3.2 are shown in Figure 11.

Figure 11 - Relationship diagram for the NCCM system

^ TOP
4. Functional Model and Description

4.1 Class diagrams

The associations between the different classes are shown in Figure 12. The access functions to get and set private data attributes have been removed for clarity.

Figure 12 - Neñios Child Care system class diagram

4.2 Software Interface Description

4.2.1 External machine interfaces

The software will be capable of printing invoices and reports on a local or network printer.

4.2.2 External system interfaces

The NCCM system will communicate with a Web server on the internet through a high speed network connection such as DSL, cable, or a T1 line.

4.2.3 Human interface

The Web pages shall permit complete navigation using the keyboard alone, in addition to using mouse and keyboard combinations.

^ TOP
5. Behavioral Model and Description

5.1 Description for software behavior

5.1.1 Events

Child Class Events

Parent registers child
Child’s birthday
Child is dropped off
Child is picked up
Child is withdrawn from day care

Parent Class Events

Parent registers child
Parent receives bill
Parent sends payment
Parent enrolls another child

Employee Class Events

Employee is hired
Employee logs onto the system
Employee logs off of the system
Employee gets promoted
Employee is no longer employed

Classroom Class Events

Child added to class
Child removed from class

Waiting List Class Events

Child added to waiting list
Child removed from waiting list

Immunization Class Events

Immunization due
Immunization received
New child enrolled
Start of day

Bill Class Events

End of month
Payment received
Payment not received
Print invoices

Daily Reminder Class Events

Start of day
User acknowledgement
New reminder
New reminder

^ TOP
5.1.2 States

 

^ TOP
5.2 Statechart Diagram

A statechart diagram for the entire system is shown in Figure 13. After a user logs on the system will check for reminders and update account records as needed. The user will then select a hyperlink to load a page the appropriate page.

Figure 14 contains statecharts for the child, parent, and employee classes. After a child reaches the age of 6 they will no longer be allowed to enroll in child care. A parent may decide to enroll another child in which case they will need to enter the registering state again so that the new child’s information can be recorded. If an employee is promoted their access privileges will change so they will need to log out then log on to the system for the new changes to take effect.

The various states for ae classroom, waiting list and immunization objects are shown in Figure 15. The statechart for the classroom is identical to that for the waiting list except for the guard conditions. Either object can be at capacity or below. It is expected that a classroom will close if its enrollment drops too low. Likewise a waiting list is eliminated if there are fewer than 20 children in a classroom

Figure 13 - Overall system statechart diagram

Figure 14 - Statechart diagrams

Figure 15 - Statechart diagrams

^ TOP

6. Restrictions, Limitations, and Constraints

• The system shall integrate within the existing LAN structure and with the existing systems, such as the database management systems.
•  All HTML code shall conform to the HTML 4.0 standard.
• All server side code shall be written in ASP.NET.
• Netscape 7.0x or Microsoft Internet Explorer 5.x (or more recent versions of either)

7. Validation Criteria

Software validation will ensure that the system responds according to the users expectations; therefore it is important that the end users be involved in some phases of the test procedure. All tests will be traced back to the requirements in section 1.2.

7.1 Classes of tests

•  Unit testing will be conducted on all of software subsystems including
  1. Daily reminders
  2. Viewing and editing information
  3. Viewing and printing reports
  4. Logging on to the system
  5. Enrollment
  6. Waiting lists
  7. Viewing and printing invoices
  8. Immunization alerts
   
• Test cases for black box testing will be based on equivalence categories. These categories will include values that lie on and around the boundary values of a function. For example, if a function can accept values from 0 to 100 then the test cases will include the values -1, 0, 1, 99, 100, and 101.
   
• Acceptance testing will be conducted at the customer’s site.

7.2 Expected software response

• The software should display an appropriate error message when a value outside the accepted limits is entered.
   
• The software should not be capable of deleting a customer record even if they withdraw from the Care Center.
  
   

7.3 Performance Bounds

• The system shall support up to 100 simultaneous users against the Website/Web Server at any given time.
  The system will provide access to the database management system with a latency of no more than 20 seconds.
  
   

Appendix A: Glossary

Appendix B: Issues List
Should parents have access to the NCCM system?
What is the minimum enrollment to keep a classroom open?
Should there be a search function for retrieving records?
Need to find a Web service provider for ASP.NET.

^ TOP

| Home | Hosting | Domains | Support |  Contacts |
| Terms & Condition | Privacy Policy |

Copyright © 2005 by HostItWise.com Read our Copyright. All rights reserved.