Software Requirements Specification Document Template

Software Requirements Specification 4.0

Googolplex Dental Office Scheduling System

Team 2: Peter Anania, Vijay Gangareddygari, Ronald Olaski, Nicole Staretz, and Melisa Tyira

SE 516 Engineering of Software Systems Fall 2002 Table of Contents

1. INTRODUCTION 6

1.1 PURPOSE OF THIS DOCUMENT 6 1.2 SCOPE OF THIS DOCUMENT 6 1.3 OVERVIEW 6 1.4 BUSINESS CONTEXT 6

2. GENERAL DESCRIPTION 6

2.1 PRODUCT FUNCTIONS 7 2.2 SIMILAR SYSTEM INFORMATION 7 2.3 USER CHARACTERISTICS 7 2.4 USER PROBLEM STATEMENT 7 2.5 USER OBJECTIVES 7 2.6 GENERAL CONSTRAINTS 7

3. FUNCTIONAL REQUIREMENTS 8

3.1 THE SYSTEM WILL STORE AND MANIPULATE APPOINTMENT DATA. 8 DESCRIPTION 8 CRITICALITY 8 TECHNICAL ISSUES 8 COST AND SCHEDULE 8 RISKS 8 DEPENDENCIES WITH OTHER REQUIREMENTS 8 3.2 THE SYSTEM WILL STORE AND MANIPULATE PATIENT DATA. 8 DESCRIPTION 8 CRITICALITY 8 TECHNICAL ISSUES 8 COST AND SCHEDULE 9 RISKS 9 DEPENDENCIES WITH OTHER REQUIREMENTS 9 3.3 THE SYSTEM WILL STORE/MANIPULATE APPOINTMENT LOCATION. THE SYSTEM WILL STORE PERSONNEL DATA. 9 DESCRIPTION 9 CRITICALITY 9 TECHNICAL ISSUES 9 COST AND SCHEDULE 9 RISKS 9 DEPENDENCIES WITH OTHER REQUIREMENTS 9 3.4 THE SYSTEM WILL DISPLAY APPOINTMENTS. 9 DESCRIPTION 9 CRITICALITY 9 TECHNICAL ISSUES 9

2 COST AND SCHEDULE 10 RISKS 10 DEPENDENCIES WITH OTHER REQUIREMENTS 10 3.5 THE SYSTEM WILL DISPLAY THE SCHEDULE OF ANY GIVEN DENTIST, DENTAL ASSISTANT OR DENTAL HYGIENIST FOR THE WEEK. 10 DESCRIPTION 10 CRITICALITY 10 TECHNICAL ISSUES 10 COST AND SCHEDULE 10 RISKS 10 DEPENDENCIES WITH OTHER REQUIREMENTS 10

4. INTERFACE REQUIREMENTS 10

4.1 USER INTERFACES 10 4.1.1 GUI 10 4.1.2 CLI 12 4.1.3 API 12 4.1.4 DIAGNOSTICS OR ROM 12 4.1.5 HARDWARE INTERFACES 12 4.1.6 COMMUNICATIONS INTERFACES 12 4.1.7 SOFTWARE INTERFACES 12

5. PERFORMANCE REQUIREMENTS 12

6. OTHER NON-FUNCTIONAL ATTRIBUTES 12

6.1 SECURITY 12 6.2 BINARY COMPATIBILITY 12 6.3 RELIABILITY 12 6.4 MAINTAINABILITY 12 6.5 PORTABILITY 12 6.6 EXTENSIBILITY 12 6.7 REUSABILITY 13 6.8 APPLICATION AFFINITY/COMPATIBILITY 13 6.9 RESOURCE UTILIZATION 13 6.10 SERVICEABILITY 13

7. OTHER REQUIREMENTS 13

7.1 USE CASE: ENTER PATIENT DATA 13 7.1.1 DIAGRAM 13 7.1.2 BRIEF DESCRIPTION 14 7.1.3 INITIAL STEP-BY-STEP DESCRIPTION 14 7.1.4 DETAILED DESCRIPTION 14 7.2 USE CASE: ENTER APPOINTMENT DATA 15

3 7.2.1 DIAGRAM: 15 7.2.2 BRIEF DESCRIPTION 15 7.2.3 INITIAL STEP-BY-STEP DESCRIPTION 15 7.2.4 DETAILED DESCRIPTION 15 7.3 USE CASE: VIEW PATIENT DATA 16 7.3.1 DIAGRAM 16 7.3.2 BRIEF DESCRIPTION 16 7.3.3 INITIAL STEP-BY-STEP DESCRIPTION 16 7.3.4 DETAILED DESCRIPTION 16 7.4 USE CASE: VIEW SCHEDULE BY MONTH 17 7.4.1 DIAGRAM 17 7.4.2 BRIEF DESCRIPTION 17 7.4.3 INITIAL STEP-BY-STEP DESCRIPTION 17 7.4.4 DETAILED DESCRIPTION 18 7.5 USE CASE: VIEW SCHEDULE BY DENTIST 18 7.5.1 DIAGRAM 18 7.5.2 BRIEF DESCRIPTION 18 7.5.3 INITIAL STEP-BY-STEP DESCRIPTION 18 7.5.4 DETAILED DESCRIPTION 19 7.6 USE CASE: VIEW SCHEDULE BY DENTAL ASSISTANT 19 7.6.1 DIAGRAM 19 7.6.2 BRIEF DESCRIPTION 19 7.6.3 INITIAL STEP-BY-STEP DESCRIPTION 20 7.6.4 DETAILED DESCRIPTION 20 7.7 USE CASE: VIEW SCHEDULE BY PATIENT. 20 7.7.1 DIAGRAM 20 7.7.2 BRIEF DESCRIPTION 21 7.7.3 INITIAL STEP-BY-STEP DESCRIPTION 21 7.7.4 DETAILED DESCRIPTION 21 7.8 USE CASE: MODIFY PATIENT DATA 21 7.8.1 DIAGRAM 22 7.8.2 BRIEF DESCRIPTION 22 7.8.3 INITIAL STEP-BY-STEP DESCRIPTION 22 7.8.4 DETAILED DESCRIPTION 22 7.9 USE CASE: MODIFY APPOINTMENT DATA 22 7.9.1 DIAGRAM 22 7.9.2 BRIEF DESCRIPTION 23 7.9.3 INITIAL STEP-BY-STEP DESCRIPTION 23 7.9.4 DETAILED DESCRIPTION 23 7.10 USE CASE: DELETE PATIENT 23 7.10.1 DIAGRAM 24 7.10.2 BRIEF DESCRIPTION 24 7.10.3 INITIAL STEP-BY-STEP DESCRIPTION 24 7.10.4 DETAILED DESCRIPTION 24 7.11 USE CASE: DELETE APPOINTMENT 24 7.11.1 DIAGRAM 25 7.11.2 BRIEF DESCRIPTION 25 7.11.3 INITIAL STEP-BY-STEP DESCRIPTION 25 7.11.4 DETAILED DESCRIPTION 25

4 8 ENTITY RELATIONSHIP DIAGRAM 26

9. GLOSSARY 27

5 1. Introduction 1.1 Purpose of this document This document is written for the client, the Googolplex Dental Office – Scranton Pennsylvania, to explicitly describe the appointment software product that is to be delivered.

1.2 Scope of this document

This document is meant to describe the entire product, its intended features and prescribed use. Based on determinations made by the requirements elicitation team (Peter Anania, Vijay Gangareddygari, Ronald Olaski, Nicole Staretz, and Melisa Tyira) It was determined that the intended user of this system was the Dentist’s office secretary. This software is to be developed for the Googolplex Dental Office, by the engineering and development team (Peter Anania, Vijay Gangareddygari, Ronald Olaski, Nicole Staretz, and Melisa Tyira).

The requirements were gathered within the specified time period of 2 weeks (9/11/02 through 9/25/02.) There was no cost associated with the gathering of these requirements, and no specialty software was used to develop them.

1.3 Overview Based on the results of the requirements elicitation, the system is described as: a patient appointment scheduling system whose only user is to be the secretary making the appointments. The system is to store appointment time, type, date, location and personnel data as well as patient data to include name, address and phone number/s. In addition, dentist, dental hygienist, or assistant, germane to the appointment, are to be stored as well. The user will be able to schedule appointments for any day in the future, and a mechanism by which corrections and updates to the data can be made, is to exist also. This information can be displayed by the user upon request. In addition, a mechanism will exist that allows the user to view the dentist, dental hygienist and dental assistant schedules as well.

1.4 Business Context The project sponsor is the Googolplex Dental Office. They are a small-to-medium size dental office in the Scranton, PA area. The organization’s mission statement includes, in addition to objectives germane to providing quality dental care, items pertaining to maintaining accurate records of patient care received at the facility, as well as providing that information to it’s patients, staff and doctors. This product is an intended ‘first step’ towards meeting these goals.

2. General Description

6 2.1 Product Functions The product stores appointment and patient records, allows for addition, deletion and modification of those records and provides views of those records.

2.2 Similar System Information At present this product is meant to be a standalone product that is not intended to integrate with any pre-existing software. Future versions of the system will provide additional functionality.

2.3 User Characteristics The user has standard experience with commercial office productivity software and standard PC operating systems, and has heretofore accomplished this application with those products. Although the user does have an extensive background within the application’s domain, this is to be the first software product specifically designed for this purpose that the user will encounter.

2.4 User Problem Statement The Googolplex Dental Office has four dentists, 10 assistants, one secretary, and 500 clients. This project is to design a scheduling system for the dental office. It keeps track of when dentists are available and allows clients to make appointments for their preferred dentists. The system shall provide a list of appointments for next business day so the secretary can contact clients to confirm their appointments. It should display, during regular business hours, clients and the rooms the clients are assigned to and which dentist each client is waiting to see, and the location of each dentist and each assistant.

2.5 User Objectives The user desires a system whereby the appointment scheduling and manipulation occur as described, but the system would also have the following capabilities: viewing of appointments by matching patient, viewing of appointments by doctors and staff, appointment reminder tracking (for use by the user,) nightly backup capabilities and password changing capability. Although the development team feels confident that they could deliver such a system, the user has a definite timeline that precludes those features from being developed. These time parameters will limit what functionality can be accomplished.

2.6 General Constraints  The system must be implemented by December 6th, 2002.  The system must be implemented on a standard PC hardware platform.  The system must be implemented on a standard PC Operating System.  Appointment blocks (blocks of time) are 30 minutes.  Available hours are Monday through Friday: 9 AM to 5 PM.  Holidays are to be excluded from available hours.  Appointment ‘rooms’ are to be system parameters.  Available dentists are to be system parameters.

7  Available dental assistants are to be system parameters.  Available dental hygienists are to be system parameters.  The system will include the following system parameter values: Dentists – 10, Dental Assistants – 6, Dental Hygienists – 4, Rooms – 10,  System parameters cannot be changed by the user.  The system has no industry standard protocol constraints.  The patient data stored by the system is protected by the US Privacy Act.  No other constraints are known at this time.  No password changes.  No nightly backup of system.

3. Functional Requirements 3.1 The system will store and manipulate appointment data. Description The system must allow addition, deletion and modification of appointment records. Criticality High. Technical issues A data repository of some sort must be used to accomplish this. Cost and schedule As this is the primary requirement, and because it addresses the majority of the systems functionality, this requirement constitutes as much as 50% of the code development time and cost. Risks The success of this requirement’s functionality is crucial to the entire project’s success. If the development of this requirement fails to meet projected goals, in terms of time and cost, the project will fail. The critical issue for this requirement is what type of data repository to utilize. The system needs to meet three sub-requirements: it must be able to be deployed on a PC, it cannot require specialty knowledge and/or training for the intended user and it must respond (speed of processing) under the given utilization (Maximum of 3,600 records created from 3 tables. Please see Functional Requirement 4, Section 3 below.) Dependencies with other requirements Because the other functionalities depend heavily on this interaction performing properly, it is imperative that this requirement be developed in a fully encapsulated manner which provides a standard interface for all other related functionalities to use. In this way development of the other functionalities can proceed swiftly from this point.

3.2 The system will store and manipulate patient data. Description The system must allow addition, deletion and modification of patient records. Patient information to be included: name, address, multiple phone numbers (home, work, emergency) Criticality High. Technical issues

8 This data must be ‘linked’ to the corresponding appointment data, yet be independent to allow for individual queries against it. The success of this requirement depends entirely upon the successful achievement of requirement 1, and speaks to the same issues as those mentioned in requirement 1 – section 3 above. Cost and schedule Because the development of requirement 1, if successful, will expedite the development of this requirement, this requirement is allotted only 10% on the code development time and cost. Risks See Requirement 1 – Section 5 above. Dependencies with other requirements See Requirement 1 – Section 6 above.

3.3 The system will store/manipulate appointment location. The system will store personnel data. Description The system must allow addition, deletion and modification of appointment location. The system must allow storing of personnel records. Criticality High. Technical issues This data must be ‘linked’ to the corresponding appointment data, yet be independent to allow for individual queries against it. The success of this requirement depends entirely upon the successful achievement of requirement 1, and speaks to the same issues as those mentioned in requirement 1 – section 3 above. Cost and schedule Because the development of requirement 1, if successful, will expedite the development of this requirement, this requirement is allotted only 10% on the code development time and cost. Risks See Requirement 1 – Section 5 above. Dependencies with other requirements See Requirement 1 – Section 6 above.

3.4 The system will display appointments. Description The system is to display all of the appointments from the current day to XX days hence. Criticality High. Technical issues Assuming there are 10 dentists, 6 dental assistants, 4 dental hygienists, 10 rooms and 16 available time slots per day (see constraints above,) calculations yield 160 possible appointments per day maximum. This in turn yields (via calculation) a possible 3600 appointments per month with a 10,000 possible outcomes. An interface must be developed to allow the user simple navigation through this data. In addition, because this data is derived from the appointment data repository, text translations would likely cause system performance degradation. Further, this functionality must be developed in a fully encapsulated manner, which provides a standard interface for other related functionalities to use.

9 Cost and schedule As this is a primary requirement, and because it addresses a major portion of the systems functionality, this requirement constitutes as much as 20% of the code development time and cost. Risks The most critical risk associated with the development of this requirement is scope creep. Although it is necessary to provide the user with all relevant data via this display, care must be taken to not allow this display ‘scheme’ to evolve into something more robust or different entirely. This would cause the projected development of this component to ‘creep’ in cost and time, thus causing the project to not be delivered on time. Dependencies with other requirements This requirement depends on the successful completion of requirements 1 through 3, because the data being delivered to this display depends upon it.

3.5 The system will display the schedule of any given dentist, dental assistant or dental hygienist for the week. Description The system is to display all of the appointments of the chosen week of any given dentist, dental assistant or dental hygienist. Criticality Medium. Technical issues These views are independent of the appointment calendar view. The success of this requirement depends largely upon the successful achievement of requirement 4, and speaks to the same issues as those mentioned in requirement 4 – section 3 above. Cost and schedule Because the development of requirement 4, if successful, will expedite the development of this requirement, this requirement is allotted only 10% on the code development time and cost. Risks See Requirement 4 – Section 5 above. Dependencies with other requirements See Requirement 4 – Section 6 above.

4. Interface Requirements

4.1 User Interfaces 4.1.1 GUI The following diagram is an example of a proposed schedule view to allow the user to view the availability of rooms for any given day by appointment increments.

Room1 Room2 Room3 Room4 Room5 9:00 AM Dentist Dentist Dentist Personnel Personnel Personnel Patient Patient Patient

9:30 AM Dentist Dentist Dentist

10 Personnel Personnel Personnel Patient Patient Patient

10:00 AM Dentist Dentist Personnel Personnel Patient Patient

10:30 AM Dentist Dentist Personnel Personnel Patient Patient

11:00 AM Dentist Dentist Dentist Dentist Dentist Personnel Personnel Personnel Personnel Personnel Patient Patient Patient Patient Patient

11:30 AM Dentist Dentist Dentist Personnel Personnel Personnel Patient Patient Patient

12:00 PM Dentist Dentist Dentist Dentist Personnel Personnel Personnel Personnel Patient Patient Patient Patient

12:30 PM Dentist Dentist Dentist Personnel Personnel Personnel Patient Patient Patient

11 4:30 PM Dentist Dentist Dentist Personnel Personnel Personnel Patient Patient Patient

4.1.2 CLI No command line interfaces will be available in this system.

4.1.3 API

4.1.4 Diagnostics or ROM Diagnostic data will not be provided in this version. The user is encouraged to suggest integration of such tools, in the next version of the program.

4.1.5 Hardware Interfaces Standard PC keyboard interface. 4.1.6 Communications Interfaces No networking capabilities are planned for this version.

4.1.7 Software Interfaces This product is a stand-alone product, and thus has no software interfaces.

5. Performance Requirements The system is to perform at the same speed, co-operate in the same memory and require normalized disk utilization as that of a commercially available office productivity application software product. Currently these requirements range as such: 300 – 700 MHz CPU, 32 – 128 MB DRAM and .2 – 20 GB of permanent disk storage.

6. Other non-functional attributes Specifies any other particular non-functional attributes required by the system. Examples are provided below. 6.1 Security Program requires log on, records must be secure (Privacy Act data.) 6.2 Binary Compatibility 6.3 Reliability The system must provide all functionality whenever in use. System crashes are not to impair the data. System crashes are not to impair the system. 6.4 Maintainability The system is to be maintained entirely by the end user after delivery. 6.5 Portability 6.6 Extensibility

12 The system must be modifiable, as described above, for future enhancements. 6.7 Reusability The system components must be reusable (and thus work from a standard interface) for the current and future versions of this product. Development reusability within the development organization is not necessary. 6.8 Application Affinity/Compatibility The system should not conflict with the most well-known, standard PC application software. 6.9 Resource Utilization The system should be limited to the resources normally allocated to a commercially available PC application product. 6.10 Serviceability The system is to be serviced by contract only, and thus should be serviceable as is commensurate with company policies.

7. Other Requirements

The Googolplex Dental Office Scheduling System application is a web-based system and will be written to conform with Internet Explorer v5.5 or higher. Output will be displayed in an HTML file in the default browser.

The secretary is the main user of the system. The system stores appointment time, type, date, location and personnel data as well as patient data to include name, address, phone number(s). The secretary will be able to schedule appointments for any day in the future and update this data. This information will be displayed by the secretary upon request through the appropriate schedule view. In addition, a mechanism will exist that allows the secretary to view the dentist, dental hygienist and dental assistant schedules as well.

Pre-Condition: For all the use cases, it is the pre-condition that the user is logged into the system.

Post-Condition: The user can log off the system after the completion of each use case instantiation.

7.1 Use case: Enter Patient data

7.1.1 Diagram

13 Enter Patient Data

Secretary

7.1.2 Brief Description The use case Enter Patient Data is used by the secretary to add the patient’s information to the database.

It must be done after the secretary logs into the system and at least once before View Patient Data and View Schedule by Patient use cases. This operation may be performed several times as needed.

7.1.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has already logged into the system. The secretary clicks on the Add New Patient button. S/He enters all the required fields (Patient ID, Name, Address, Phone numbers, Insurance). The secretary clicks on the Save Patient button. The system loads the patient’s data and notifies completion.

7.1.4 Detailed Description

Use Case Name Enter Patient Data Priority Essential Trigger Choosing add new patient Precondition The Secretary is logged into the system. Basic Path The secretary clicks on Add New Patient System provides form to fill in. The secretary fills in form and pushes Save Patient button. Repeat the steps until done. Alternative Paths If Duplicate ID, the system prompts “Patient already exists”. Postcondition Patient is added to the database. Exception Paths None See Also Brief description: Enter Patient Data Other

14 7.2 Use Case: Enter Appointment Data

7.2.1 Diagram:

Enter Appointment Data

Secretary

7.2.2 Brief Description The use case Enter Appointment Data is used by the secretary to add all the appointment information to the database.

7.2.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has already loaded the Patient data. 1. The secretary clicks on the chosen day to add appointment to. 2. S/He clicks on the add appointment button. 3. S/He chooses the patient from the patient list box. 4. S/He selects the available dentist. 5. S/He selects the available dental assistant. 6. S/He selects the available room. 7. S/He selects the start time and appointment end time. 8. The Secretary clicks on the save appointment button. 9. The system loads the appointment data and notifies completion.

Use Case Name Enter Appointment Data Priority Essential Trigger Clicking chosen day to add appointment to. Precondition Patient Data is loaded. Basic Path The secretary chooses day to add appointment to. System provides form to fill in. The secretary fills in the form and pushes Save Appointment button. Repeat steps until done.

15 Alternative Paths If the appointment for that time is already scheduled, the system prompts “Time Blocked- Select yes for new time” The secretary clicks on the yes button. Focus is returned to the Enter Appointment Dialog Box.

Postcondition The appointment data is loaded into the database. Exception Paths None See Also Brief description: Enter Appointment Data Other

7.3 Use case: View Patient Data

7.3.1 Diagram

View Patient Data

Secretary

7.3.2 Brief Description

The use case View Patient Data is used by the Secretary to view the information.

7.3.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has loaded the patient data. 1. The secretary clicks on the View Patient Data button. 2. S/He chooses the patient’s name. 3. S/He clicks on the Go button. 4. The System presents the patient information.

Use Case Name View Patient Data Priority Essential Trigger Clicking View Patient Data. Precondition Patient Data is loaded. Basic Path The secretary chooses View Patient Data.

16 The System provides form to fill in. The secretary fills in the form and pushes Go button. The System provides the Patient’s information. The use case instance terminates.

Alternative Paths If the patient data asked for does not exist in the database, the system prompts, “Patient Not Found- Select yes to add new patient.” The secretary clicks on the yes button. Enter Patient Data use case is initiated.

Postcondition The Patient Data is presented for viewing. Exception Paths Operation may be cancelled. See Also Brief description: View Patient Data Other

7.4 Use Case: View Schedule by Month

7.4.1 Diagram

View Schedule by Month

Secretary

7.4.2 Brief Description The use case View Schedule by month is used by the secretary to view the schedule for the month.

Before this use case can be initiated, the secretary has scheduled appointments by the month. This operation may be performed several times as needed.

7.4.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has already scheduled appointments by the month. 1. The secretary clicks on the View Schedule button. 2. S/He selects a month or week to view. 3. The secretary clicks on the Go button. 4. The system presents the schedule with the time period selected.

17 7.4.4 Detailed Description

Use Case Name View Schedule by Month Priority Essential Trigger Clicking View Schedule button. Precondition Appointment Data is loaded. Basic Path The secretary chooses View Schedule button. The secretary selects a month or week to view and pushes Go button. The System provides the Schedule. The use case instance terminates.

Alternative Paths If the appointments for that month or week are not scheduled, the system prompts, “Appointments Not Yet Scheduled- Select yes to Add New Appointment.” The secretary clicks on the yes button. Enter Appointment Data use case is initiated.

Postcondition The Schedule by Month is presented for viewing. Exception Paths Operation may be cancelled. See Also Brief description: View Schedule by Month use case. Other

7.5 Use Case: View Schedule by Dentist

7.5.1 Diagram

View schedule by dentist

Dentist

7.5.2 Brief Description The use case View Schedule by Dentist is used by the Dentist to view the schedule.

Before this use case can be initiated, the secretary has scheduled appointments for the dentist. This operation may be performed several times as needed.

7.5.3 Initial Step-by-Step Description

18 Before this use case can be initiated, the secretary has already scheduled appointments for that dentist. 1. The Dentist clicks on the View Dentist Schedule button. 2. S/He chooses a week to view. 3. S/He selects his/her name. 4. S/He clicks on the Go button 5. The system presents the schedule with the time period selected.

Use Case Name View Schedule by Dentist Priority Essential Trigger Clicking View Dentist Schedule button. Precondition Appointment Data is loaded. Basic Path The Dentist chooses View Schedule button. The dentist makes selections and pushes Go button. The System provides the Schedule. The use case instance terminates.

Alternative Paths If the appointments for that week are not scheduled, the system prompts, “Appointments Not Yet Scheduled” Focus is returned to the View Dentist Schedule Dialog Box.

Postcondition The Schedule by Dentist is presented for viewing. Exception Paths Operation may be cancelled. See Also Brief description: View Schedule by Dentist. Other

7.6 Use Case: View Schedule by Dental Assistant

7.6.1 Diagram

View schedule by dentist

Dental Assistant

19 The use case View Schedule by Dental Assistant is used by the Dental Assistant to view the schedule.

Before this use case can be initiated, the secretary has scheduled appointments for the Dental Assistant. This operation may be performed several times as needed.

7.6.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has already scheduled appointments for that dentist. 1. The Dental Assistant clicks on the View Dental Assistant Schedule button. 2. S/He chooses a week to view. 3. S/He selects his/her name. 4. S/He clicks on the Go button 5. The system presents the schedule with the time period selected.

Use Case Name View Schedule by Dental Assistant Priority Essential Trigger Clicking View Dental Assistant Schedule button. Precondition Appointment Data is loaded. Basic Path The Dental Assistant chooses View Dental Assistant Schedule button. The dental Assistant makes selections and pushes Go button. The System provides the Schedule. The use case instance terminates.

Alternative Paths If the appointments for that week are not scheduled, the system prompts, “Appointments Not Yet Scheduled” Focus is returned to the View Dental Assistant Schedule Dialog Box.

Postcondition The Schedule by Dental Assistant is presented for viewing. Exception Paths Operation may be cancelled. See Also Brief description: View Schedule by Dental Assistant. Other

7.7 Use Case: View Schedule by Patient.

7.7.1 Diagram

20 View schedule by dentist

Patient

7.7.2 Brief Description The use case View Schedule by Patient is used by the Patient to view the schedule.

Before this use case can be initiated, the secretary has scheduled appointments for the Patient. This operation may be performed several times as needed.

7.7.3 Initial Step-by-Step Description 1. Before this use case can be initiated, the secretary has already scheduled appointments for that patient. 2. The Patient clicks on the View Patient Schedule button. 3. S/He chooses a month or week to view. 4. S/He selects his/her name. 5. S/He clicks on the Go button 6. The system presents the schedule with the time period selected.

Use Case Name View Schedule by Patient Priority Essential Trigger Clicking View Patient Schedule button. Precondition Appointment Data is loaded. Basic Path The Patient chooses View Patient Schedule button. S/He makes selections and pushes Go button. The System provides the Schedule. The use case instance terminates.

Alternative Paths If the appointment for that month or week not scheduled, the system prompts, “Appointments Not Yet Scheduled” Focus is returned to the View Patient Schedule Dialog Box.

Postcondition The Schedule by Patient is presented for viewing. Exception Paths Operation may be cancelled. See Also Brief description: View Schedule by Patient. Other

7.8 Use Case: Modify Patient Data

21 7.8.1 Diagram

Modify Patient Data

Secretary

7.8.2 Brief Description The use case Modify Patient Data is used by the Secretary to modify the patient’s information.

7.8.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has loaded the patient data. 1. The secretary clicks on the View Patient Data button. 2. S/He chooses the patient’s name. 3. S/He clicks on the Modify button. 4. The System presents the patient information. 5. The Secretary makes the changes and clicks ‘Done’. 6. The System presents the patient information with the modifications

Use Case Name Modify Patient Data Priority Essential Trigger Selection from Menu. Precondition The Patient data is already loaded. Basic Path The Patient chooses View Patient Schedule button. S/He makes selections and pushes Modify button. The System provides the patient data. The secretary makes changes and clicks done. The System modifies the patient information. The use case instance terminates.

Alternative Paths None. Postcondition There Patient data is updated. Exception Paths Operation may be cancelled. See Also Brief description: Modify Patient Data Other

7.9 Use Case: Modify Appointment Data

7.9.1 Diagram

22 Modify Appointment Data

Secretary

7.9.2 Brief Description The use case Modify Appointment Data is used by the Secretary to modify appointments.

7.9.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has loaded the appointment data. 1. The secretary clicks on the chosen appointment to modify. 2. The system presents the appointment data 3. S/He clicks on the ‘Modify Button’. 4. S/He modifies the appointment data. 5. S/He clicks on the ‘Done’ Button. 6. The system presents the modified appointment data.

Use Case Name Modify Appointment Data Priority Essential Trigger Clicking on the chosen appointment to modify Precondition The Appointment data is already loaded. Basic Path The Secretary clicks on the chosen day. S/He makes selections and pushes Modify button. The System provides the patient data. The secretary makes changes and clicks done. The System modifies the appointment information. The use case instance terminates.

Alternative Paths None Postcondition The Appointment data is updated. Exception Paths Operation may be cancelled. See Also Brief description: Modify Appointment Data Other

7.10 Use Case: Delete Patient

23 7.10.1 Diagram

Delete Patient

Secretary

7.10.2 Brief Description The use case Delete Patient is used by the Secretary to delete a patient.

7.10.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has already loaded the patient data. 1. The Secretary clicks on the Delete Patient button. 2. S/He chooses the patient to be deleted. 3. S/He clicks on the delete button. 4. The System asks for the confirmation of the deletion. 5. The secretary confirms the deletion by clicking ‘Yes’. 6. The system deletes the patient data.

Use Case Name Delete Patient Priority Essential Trigger Clicking on Delete Appointment button. Precondition The Patient Data is loaded. Basic Path The Secretary chooses Delete Patient button. S/He makes selections and pushes delete button. The System upon confirmation deletes the patient data. The use case instance terminates.

Alternative Paths None Postcondition The schedule refreshes with the deleted appointment. Exception Paths Operation may be cancelled. See Also Brief description: Delete Patient Other

7.11 Use Case: Delete Appointment

24 7.11.1 Diagram

Delete Appointment

Secretary

The use case Delete Appointment is used by the Secretary to delete an appointment.

Before this use case can be initiated, the secretary has scheduled the appointment.

7.11.3 Initial Step-by-Step Description Before this use case can be initiated, the secretary has already scheduled the appointment. 1. The Secretary clicks on the Delete Appointment button. 2. S/He chooses the appointment to be deleted. 3. S/He clicks on the delete button. 4. The System asks for the confirmation of the deletion. 5. The secretary confirms the deletion by clicking ‘Yes’. 6. The system deletes the appointment and presents the refreshed schedule.

Use Case Name Delete Appointment Priority Essential Trigger Clicking on Delete Appointment button. Precondition The Appointment Data is loaded. Basic Path The Secretary chooses Delete Appointment button. S/He makes selections and pushes delete button. The System upon confirmation deletes the appointment data. The use case instance terminates.

Alternative Paths None Postcondition The schedule refreshes with the deleted appointment. Exception Paths Operation may be cancelled. See Also Brief description: Delete Appointment Other

25 8 Entity Relationship Diagram The following diagram represents the high level entities of the Googolplex Dental System. The ERD (Entity Relationship Diagram) will change as the data entities are further explored throughout the design and possibly into the beginning of the development phase of the project.

ID FN LN DATE ADDR1 INS

EMER PATIENT SCHEDULE APPOINTMENT PH

WORK CITY PH HOME STATE PH ZIP Uses ASSIGN

ID EMPLOYEE

TIME SLOT

FN TYPE LN ROOM Room ID Desc TIME SLOT End Start ID Time Time

26 9. Glossary

Dentist - Member of the Googolplex Dental Office who works as a dentist. Dental Assistant - Member of the Googolplex Dental Office who works as a dental Assistant. HTML - Hypertext Markup Language. Functional Requirements - A detailed list of all the services provided by the system. Patient - A person who visits the Googolplex Dental Office for treatment. Secretary - Member of the Googolplex Dental Office who is in charge of the Googolplex Dental Office Scheduling System.