1 · Web viewSRS . Clinic Appointment. Scheduler System. C.A.S.S. September 30, 2005. Concordia...

SOFTWARE REQUIREMENTS SPECIFICATION

SRS

CLINIC APPOINTMENT

SCHEDULER SYSTEM

C.A.S.S.

September 30, 2005

Software Requirements Specification

Concordia University

Clinic Appointment Scheduler System (C.A.S.S.) Page 1


TEAM MEMBERS

Name ResponsibilityJulie Petrusa Section 1, EditorLoay Qasem MySQL Configuration, Administrator Use CasesNuzhat Jilani Functional Requirements, Doctor Use CasesYun Xu Web Server Configuration, Patient Use CasesMohammad Yassine Section 3, Administrator Use Cases, EditorYuhuai Zhang Domain Model, Patient Use CasesCarlos Villarruel(Team Leader)

Section 2, Doctor Use Cases



CONTENTS

1. INTRODUCTION1.1 Purpose.................................................................................................................51.2 Scope....................................................................................................................51.3 Definitions, Acronyms, and Abbreviations.........................................................7

1.3.1 Definitions...................................................................................................71.4 References............................................................................................................8

2. OVERALL DESCRIPTION..............................................................................................92.1 Product Perspective....................................................................................................92.2 Product Funtions......................................................................................................102.3 User Characteristics.................................................................................................112.4 Assumptions and Dependencies..............................................................................11

3. SPECIFIC REQUIREMENTS.........................................................................................123.1 Functional Requirements...................................................................................123.1.1 Domain Model......................................................................................................123.1.2 Use case model..................................................................................................133.2 Performance Requirements................................................................................26

3.2.1 Static Requirements..........................................................................................263.2.2 Dynamic Requirements....................................................................................26

3.3 Logical Database Requirements........................................................................263.4 Design Constraints.............................................................................................263.5 Security Requirements.......................................................................................273.6 Software System Attributes............................................................................ 27y



APENDIXES

A. Analysis Model 29 A.1 Structural model 29 A.1.2 Domain Model 29 A.2 Behavioral Model 30 A.2.1 Use Case Model 30 A.2.1.1 Use Case Diagram 30 A.2.1.2 Sequence Diagrams 31



LIST OF FIGURES

Figure 1 Domain Model Diagram 29Figure 2 Use Case Model 30Figure 3 CASS-FR-PT-SD-Book-Appointment 31Figure 4 CASS-FR-PT-SD-Cancel-Appointment 32Figure 5 CASS-FR-PT-SD-Edit-Personal-Information 33Figure 6 CASS-FR-PT-SD-Create-Account 33Figure 7 CASS-FR-PT-SD-Consult-Appointments 34Figure 8 CASS-FR-DR-SD-Cancel-Appointments 35Figure 9 CASS-FR-DR-SD-Schedule-Special-Appointments 36Figure 10 CASS-FR-DR-SD-Edit-Personal-Information 37Figure 11 CASS-UC-Use-Cases-Generalization 37Figure 12 CASS-FR-DR-SD-View-Appointments-By-Date 38Figure 13 CASS-FR-DR-SD-View-Appointments-By-Name 38Figure 14 CASS-FR-DR-SD-View-Appointments-All 38Figure 15 CASS-FR-AD-SD-Create-Doctor-Account 39Figure 16 CASS-FR-AD-SD-Configure-Employee-x-Department 40Figure 17 CASS-FR-AD-SD-Configure-Clinic-Departments 41Figure 18 CASS-FR-AD-SD-Configure-Department-Appointment-Duration 42Figure 19 CASS-FR-AD-SD-Suspend-Doctor’s-Account 43Figure 20 CASS-FR-AD-SD-Schedule-Doctor’s-Unavailability 44



1. INTRODUCTION

The Software Requirements and Specifications document (SRS) collects, analyzes, and defines high-level needs and features of the web-based Clinic Appointment Scheduler System (C.A.S.S.). Hospitals, clinics and other medical facilities will use C.A.S.S. to manage all aspects of scheduling appointments for their patients. This software replaces the tasks that would normally be given to a receptionist or secretary by allowing patients to schedule their own appointments and by allowing doctors to manage their appointments. This application can also be adapted to businesses that schedule appointments for their clients, for example, car dealers, beauty salons, etc. For simplicity, this SRS will only refer to medical facilities, doctors and patients. The document will describe the product functions, requirements and constraints of the web-based Clinic Appointment Scheduler System.

The details of how the web-based Clinic Appointment Scheduler System fulfills these needs are explained in the use-cases. More details will be available in the upcoming system design phase report.

1.1 PurposeThe purpose of this document is to define the requirements and the specifications of the web-based Clinic Appointment Scheduler System. It will describe the product functions, specific requirements, constraints and an analysis model. The analysis model will include use-case diagrams, class diagrams, sequence diagrams and state transition diagrams. This document is intended primarily for the modeling and design team developers of the web-based Clinic Appointment Scheduler System and the project co-coordinator and shall serve as a basis for the upcoming phases of the project.

1.2 ScopeThis web-based Clinic Appointment Scheduler System shall enable patients and doctors to schedule and manage their appointments with the latest software technology from the comfort of their homes and offices. C.A.S.S. is capable of many interdependent tasks, some of which relate to patients scheduling their appointments, and some of which relate to doctors managing their appointments. C.A.S.S. consists of three user interfaces: the patient interface, the doctor interface, and the administrator interface.

There are three user levels for this software, namely: Patient

Doctor

Administrator

The scope of the patient is limited to: Logging into the patient interface of the system using a username and password: This

applies to returning patients only.

Entering their personal information: New patients are required to fill in a form in order to enter their personal information. The patient’s personal information will be stored in



a database. The patient’s personal information includes their name, address, telephone number, e-mail address, SIN, Medicare card number, username, password, etc.

Modifying their personal information: Once a returning patient is logged in, they will be able to update their personal information if necessary.

Scheduling their appointment(s): Patients can schedule their own appointments via the Internet. The patient will be able to choose the type of appointment he/she needs, for example, the appointment could be for a regular check-up, a blood test, an operation, etc. Each of these appointment types will require a different amount of time, for example, a regular check-up can be half an hour while an operation can be three hours. Also, each appointment type will be associated with a different doctor. Once the patient has chosen their appointment type, they will be able to choose a date and time for their appointment. The time slots will depend on the time that is needed for the appointment type that was chosen and the availability of the doctor that is associated with that appointment type.

Modifying their appointment(s): Returning patients will be able to modify their appointments if necessary.

Canceling their appointment(s): Returning patients will be able to cancel their appointments if necessary.

Viewing, printing or emailing their schedule: Once the patient has made their schedule, they will be able to view it on their screen, print it or email it.

The scope of the doctor is limited to: Logging into the doctor interface of the system using a username and password: This

applies to returning doctors only.

Entering their personal information: New doctors are required to fill in a form in order to enter their personal information. The doctor’s personal information will be stored in the database. The doctor’s personal information consists of their name, address, telephone number, social security number, etc.

Modifying their personal information: Once a returning doctor is logged in, they will be able to update their personal information if necessary.

Scheduling the time(s) that they will not be available to meet with patients: For example, they can set their lunch hour from 12:00 to 1:00 so that patients will not be able to schedule appointments during this time.

Modifying the time(s) that they will not be available to meet with patients: Returning doctors will be able to modify their availability if necessary.

Canceling the time(s) that they will not be available to meet with patients: Returning doctors will be able to cancel their unavailable times if necessary.

Viewing, printing or emailing their schedule: Once the doctor has made their schedule, they will be able to view it on their screen, print it or email it. Their schedule will also contain information about their patients.



1.3 Definitions, Acronyms, and Abbreviations

1.3.1 Definitions1.3.1.1 Technical Definitions

Operating System: In computing, an operating system (OS) is the system software responsible for the direct control and management of hardware and basic system operations. Additionally, it provides a foundation upon which to run application software such as word processing programs and web browsers.1

Database: A database is a collection of data elements (facts) stored in a computer in a systematic way, such that a computer program can consult it to answer questions. The answers to those questions become information that can be used to make decisions that may not be made with the data elements alone. The computer program used to manage and query a database is known as a database management system (DBMS).2

Web Server: A web server is a computer responsible for serving web pages, mostly HTML documents, via the HTTP protocol to clients, mostly web browsers.3

HTML: In computing, HyperText Markup Language (HTML) is a markup language designed for the creation of web pages and other information viewable in a browser. HTML is used to structure information -- denoting certain text as headings, paragraphs, lists and so on -- and can be used to define the semantics of a document.4

PHP: PHP is a popular open-source; reflective programming language used mainly for developing server-side applications and dynamic web content, and more recently, other software.5

1.3.1.2 Domain Definitions Medical Facility: In this document, the terms medical facility, hospital and clinic will be

used interchangeably. A medical facility is an institution for professional health care provided in part by physicians and nurses.6

Doctor: In this document, the terms doctor, physician and medical professional will be used interchangeably. A doctor is a person who practices medicine.7

Patient: A patient is any person who receives medical attention, care, or treatment. A patient is often ill or injured and is being treated by, or in need of treatment by, a physician or other medical professional.8

Administrator: One who administers affairs; one who directs, manages, executes, or dispenses, whether in civil, judicial, political, or ecclesiastical affairs; a manager.9

1 Definitions taken from “http://www.wikipedia.org/”

2 Definitions taken from “http://www.wikipedia.org/”3 Definitions taken from “http://www.wikipedia.org/”4 Definitions taken from “http://www.wikipedia.org/”5 Definitions taken from “http://www.wikipedia.org/”6 Definitions taken from “http://www.wikipedia.org/”7 Definitions taken from “http://www.wikipedia.org/”8 Definitions taken from “http://www.wikipedia.org/”9 Definitions taken from “http://www.wikipedia.org/”


http://www.wikipedia.org/










Appointment: An appointment is a time reserved for something such as a doctor visit, much like a reservation.10

Schedule: In this document, the terms schedule and timetable will be used interchangeably. A schedule is an organized list or timetable, usually set out in tabular form, providing information about a series of arranged events: in particular, the time at which it is planned these events will take place.11

1.3.2 Abbreviations

SRS – Software Requirements SpecificationsC.A.S.S. - Clinic Appointment Scheduler SystemDr – DoctorAdmin – AdministratorSIN – Social Insurance NumberOS – Operating SystemDB – DatabaseDBMS – Database Management SystemHTML – HyperText Markup LanguageHTTP – HyperText Transfer ProtocolPHP – PHP Hypertext Preprocessor or Personal Home Page

1.4 References[1] Pankaj Kamthan, http://cmvl.cs.concordia.ca/courses/comp-5541/fall-2005/ (current September 22, 2005).

[2] Wikipedia, http://www.wikipedia.org/ (current September 22, 2005).

10 Definitions taken from “http://www.wikipedia.org/”11 Definitions taken from “http://www.wikipedia.org/”



http://cmvl.cs.concordia.ca/courses/comp-5541/fall-2005/




2. OVERALL DESCRIPTION

2.1 Product PerspectiveC.A.S.S. is intended to be used in Medical clinics in order to help improve appointment services. There already exists a wide variety of similar products on the market. Most of these commercial applications are intended to be very general and try to cover any possible business. Although these products exist, Medical clinics still exhaust a great deal of time and money scheduling their appointments. This is because Medical clinics have very specific needs that differ from other businesses. C.A.S.S. is a web-based application that is tailored to a Medical clinic’s needs.

2.1.1 System InterfacesNot required.

2.1.2 User InterfacesCASS contains three different types of users, and can be seen from different perspectives:

1) Patients. Patients will be able to:a. Book an appointmentb. Cancel an appointmentc. Edit Personal informationd. Create his/her accounte. Consult his/her appointments

2) Doctors. Doctor shall be able to:a. Cancel appointmentsb. Schedule special appointmentsc. Edit his/her profile. Meaning s/he will be able to change his/her address, etc.

S/he can also make changes to his/her schedule, for example, set vacations, days off, etc.

d. Consult his/her appointments3) Administrators. Administrator will be able to:

a. Activate or deactivate a doctorb. Configure employee catalogsc. Configure departmentsd. Configure employees in a departmente. Create an doctor’s account

2.1.3 Hardware InterfacesNot required

2.1.4 Software InterfacesNot required

2.1.5 Communication InterfacesNot required



2.1.6 Memory ConstraintsCASS is supported by any web browser and can be accessed by any computer with internet access.The following is needed for the architecture of our web browser:Pentium IV 256 MG Ram250 GB HDD

2.1.7 OperationsBackup the database on a monthly basis.

2.1.8 Site Adaptations requirementsNot required.

2.2 Product Funtions

2.2.1 Patients

2.2.1.1 Book AppointmentThe patient shall be able to book an appointment with any doctor. There are some types of appointments that can only be made by a doctor, e.g. a surgery.

2.2.1.2 Cancel an AppointmentThe patient can cancel his own appointment, as long as he cancels it 60 hours in advance.

2.2.1.3 Edit Personal InformationThe patient will be able to modify his/her personal information such as his/her address, telephone number, etc.

2.2.1.4 Create a Patient AccountThe patient needs to register with CASS in order to book appointments. The patient must provide the following information: Medicare card number, contact information, username and password.

2.2.1.5 View AppointmentsThe patient will be able to consult all of his or her active appointments.

2.2.2 Doctors

2.2.2.1 Cancel Patient AppointmentsIn the case of an emergency, a doctor may need to cancel his/her appointments. The system will send an e-mail to all the patients affected by the change.



2.2.2.2 Consult AppointmentsA doctor may need to identify all of the appointments that have been scheduled for a specific day or week.

2.2.2.3 Edit Personal InformationThere are certain exceptions in which a doctor will not be able to follow his/her regular schedule. For example, vacations, illness, etc. CASS allows the doctor to modify his/her schedule for a short period of time.Scenario CASS-FR-DR-SD-Edit-Personal-InformationPreconditions:

1) System must be online2) Doctor account must exist3) Doctor must log into CASS

2.2.2.4 Schedule Special AppointmentsWhen surgery is needed, an administrator must schedule the appointment on the doctor’s behalf. The patient will not have control over the time and date.

2.2.3 Administrator

2.2.3.1 Management CatalogsThe administrator will be responsible for the following tasks: add a new doctor, add department information, add types of appointments, and set time limits for each type of appointment.

2.2.3.2 Create Doctors AccountsEach time a new doctor joins the clinic, the administrator needs to add the doctor to the network.

2.2.3.3 Delete Doctors AccountsIf a doctor leaves the clinic, the administrator will delete this doctor’s information and re-assign all of his/her appointments to another doctor.

2.3 User CharacteristicsIn general, there are no specific user requirements. There is, however, one person responsible for the web server, the RDBMS. The responsibility of the RDBMS is to ensure that the application is on-line at all times.

2.4 Assumptions and DependenciesA patient cancellation can only take place 60 hours in advance.A doctor cancellation can only take place 48 hours in advance.A patient is required to have his/her Medicare card number to register into CASS.



3. SPECIFIC REQUIREMENTS

3.1 Functional Requirements

3.1.1 Domain ModelFigure 1 in Appendix A.1.1 lists the candidate concept classes and describes the relationship types and the attributes of CASS.

3.1.1.1 Concept Classes Doctor: The user who uses this system to manage the schedule and appointment. Patient: The user who makes an online appointment with the doctor. Agenda: Exactly the same concept as an agenda in real life. It is used by a doctor to

manage his or her schedule. Each day in the agenda has the following attribute: Date, weekday, and status. The status shows whether the day is a holiday, or weekend, or vocation day, or work day.

Appointment: Patient can book or cancel an appointment with the doctor. Appointment Type: Appointment reason is grouped into some appointment type.

Appointment Type such as blood test, health examination, is defined by the doctor. Time Slot: One day is split into many small pieces of time slots with equal length. For

example, if we set the minimum measure unit of the appointment duration as 10 minutes, then one day consists of many time slots: 8:00, 8:10, 8:20 etc.

3.1.1.2. Class Attributes:

3.1.1.2.1 DoctorName, phone number, address, e-mail address.

3.1.1.2.2 PatientName, Medicare card number, SIN, phone number, address, email address.

3.1.1.2.3 Agenda Date represents one calendar date on the agenda. Weekday represents the weekday in a week, such as Monday, Tuesday, Wednesday,

etc. Status represents whether the day is a holiday, or a workday. Office Hour Start: the open time of that day, like 8:30AM Office Hour End: the close time of that day, like 5:30PM

3.1.1.2.4 Appointment Sequence Number: used to identify one appointment uniquely. It’s a confirmation

number of the appointment. Patients and doctors can use this number to identify an appointment, and then cancel it, modify it and so on.

Date: appointment date. Start Time: the time when an appointment starts. Description: more detailed information about the appointment reason.



Status: states whether the appointment is valid, or canceled, or just missed (the patient failed to show up without notifying the doctor in advance)

3.1.1.2.5 Appointment Type Type: the type of appointment reason, such as blood test. Description, the detail description about this type of appointment. Estimated Duration: the estimated time duration of this kind of appointment type. For

example, 20 minutes for blood test.

3.1.1.2.5 Time Slot Start Time: the start time of one piece of time. Example: 8:10 End time: the end time of one piece of time: Example: 8:20 Status: the state of this piece of time. It shows whether this piece of time slot is

available or not available to the patient.

3.1.1.3. Concept Class Interrelation A doctor uses an agenda to manage his or her schedule and appointment. One

agenda is only used on one doctor (owner). One doctor only has one agenda. Agenda is represented by many calendar day, whereas each calendar day is

composed of many time slot-- the equal length time pieces. One patient can book many appointments with doctors. One appointment is only

associated with one patient and one doctor. One appointment belongs to one appointment type. The estimated appointment

duration is determined by the appointment type. Appointment can modify the status of a set of continuous time slot on the appointment

day on the doctor’s agenda.

For example, one doctor, Joe, has an agenda to mange his appointment and schedule. The agenda is represented by many calendar days, like September 23, 2005, September 24, 2005 etc.If one calendar day, say September 23, 2005, is a workday of this doctor, and if the office start time is 9:00am of that day, then this workday is represented by a set of continuous time slot, such as 9:00am, 9:10am, 9:20am, 9:30am etc. Initially, the status of these time slots is “available.” A patient books an appointment with the doctor Joe on September 23, 2005 at 9:10, and the type of this appointment is “blood test.” Because the estimated time for a blood test is 20 minutes, The status of the continuous time slots, 9:10, and 9:20 on September 23, 2005 on the doctor Joe’s agenda will become “unavailable” (occupied).

3.1.2 Use case modelFigure 2 in Appendix A.2.1.1 lists the candidate concept classes and describes the relationship types and the attributes of the CASS.

1) Patients. Patients will be able to:Book an appointmentCancel an appointmentEdit Personal informationCreate his/her account



Consult his/her appointments 2) Doctors. Doctor shall be able to:

Cancel appointmentsSchedule special appointmentsEdit his/her profile. Meaning, s/he will be able to change his/her e-mail, his/her

address, some changes in his/her name. Also his schedule, for example vacations, days off and so on.

Consult his/her appointments.3) Administrators. Administrator will be the person responsible to control active doctor and

configuration of catalogues related with the clinic’s employeesActivate or deactivate a doctor.Configure employees catalogConfigure DepartmentsConfigure Employees in a departmentCreate a doctor’s account

3.1.2.1 Use Case CASS-FR-PT-SD-Book-AppointmentPurposeThis function allows a registered patient to book an appointment with a doctor through internet.ActorsThe main actors are registered patients.Pre-ConditionThe user must login the system successfully.Main Scenario

A1. The user accesses the system and chooses “book appointment” function.A2. The user browses the doctor list and chooses one doctorA3. The system shows this week’s agenda of the doctor A4. The user can browse the calendar, for example, go to next month, or go to next week. Then, the system will display the corresponding agenda.A5. The user chooses the appointment date and time, select the appointment type (the reason of the appointment), and input the description of the appointment, and then submit the appointment request.A6. The system verifies the appointment request, approves the appointment, and displays the results.

Alternative Scenario:B2. The user can view the detail information about the selected the doctor, and the system shows the related information of the doctor.C6. If the time of requesting appointment is conflicted with the doctor’s agenda (overlapping), the system shows error message, and the patient re-books an appointment.D6. If the requesting appointment is too close to the closing office hour (overlap with the closing office hour), the system shows error messages, and the patient re-books an appointment.

Post-ConditionThe appointment updates the doctor’s schedule properly.



Related Use CasesNot availableInteraction DiagramThe system sequence diagram in Appendix A.2.1.2 Figure 3 shows the visual representation of how the user interacts with the system to complete the function.Non Functional RequirementOverlapping time <= 5 minutes is acceptable. For example, supposed that the doctor’s office hour is 9:00 to 5:00pm, if a patient requests an appointment from 4:20 to 5:05, this time overlapping (<=5 minutes) is tolerable.

3.1.2.2 Use Case CASS-FR-PT-SD-Cancel-AppointmentPurposeThis function enables the patients to cancel an appointment he has made.ActorsThe main actors are the patient.Pre-ConditionThe user has logged into the CASS with a client account. Main ScenarioA1. The user view the new appointment list firstA2. The user choose the appointment he or she wants to cancel. A3. Click cancel. The system will check this record, and delete it from database.Alternative scenarioNot availablePost-ConditionThe appointment record is deleted from the system.Related Use CasesNot available

Interaction Diagram

The system sequence diagram in Appendix A.2.1.2 figure 4 shows the visual representation of how the user interacts with the system to complete the function.



3.1.2.3 Use Case CASS-FR-PT-SD-Edit-Personal-InformationPurposeThis function allows a registered patient to update his or her personal information, such as address, phone number etc. ActorsThe main actors are registered patients.Pre-ConditionThe user must login the system successfully.Main Scenario

A1. The user accesses the system and chooses “view and edit my profile” function to view and edit the user’s personal information. A2. The system gets the information of the login user, and displays the information to the user. A3. The user chooses the “edit my profile” function.A4. The system provides a form to user to edit the personal information data.A5. The user edits the data on the form and submits it.A6. The system check the validity of the user’s input. If the data is valid, the system returns the confirming information to the user.

Alternative Scenario:B6. If the user’s password and reentry password are not identical, the system shows an error message. Then the system displays the registration form, and the user goes to step A3.

Post-ConditionNot availableRelated Use CasesNot availableInteraction DiagramThe system sequence diagram in Appendix A.2.1.2 Figure 5 shows the visual representation of how the user interacts with the system to complete the function.Non Functional Requirement

Error message should be clear to the users.

When the user is asked to refill out the form, the correct data that the user submitted last time should be there.



3.1.2.4 Use Case CASS-FR-PT-SD-Create-AccountPurposeThis function allows a new patient to create a user account and register with the system. ActorsThe main actors are new patients who have not registered to this system and do not have a valid user account.Pre-ConditionNot availableMain Scenario

A1. The user accesses the system and chooses the new user register function to create a user account. A2. The system displays a registration form, including Email address, name, password, health card number, phone number, address etc. A3. The user fills out the registration form, and submits it.A4. The system verifies the submitted information. If the data is valid, the system returns the confirming information to the user, shows the user a welcome message, the user account, and the password.

Alternative scenarioB4. If the user’s email address has already existed in the system, the system shows an error message. Then the system displays the registration form, and the user goes to step A3.C4. If the user’s password and reentry password are not identical, the system shows an error message. Then the system displays the registration form, and the user goes to step A3.

Post-ConditionAfter a new patient register to the system successfully, the patient can use the user account and password to login the system and perform other tasks.Related Use CasesNot availableInteraction DiagramThe system sequence diagram in Appendix A.2.3.1 Figure 6 shows the visual representation of how the user interacts with the system to complete the function.Non Functional Requirement

Error message should be clear to the users.

When the user is asked to refill out the form, the correct data that the user submitted last time should be there.



3.1.2.5 Use Case CASS-FR-PT-SD-Consult-AppointmentsPurposeThis function enables the patients to view appointments he has made.ActorsThe main actors are the patient.Pre-ConditionThe user has logged into the CASS with a client account.Main ScenarioThe user clicks the URL that links to this function pages. Both of the new appointment and historical appointments can be traced.Alternative scenarioNot availablePost-ConditionNot availableRelated Use CasesNot availableInteraction DiagramThe system sequence diagram in Appendix A.2.1.2 figure 7 shows the visual representation of how the user interacts with the system to complete the function.

3.1.2.6 Use Case CASS-FR-AD-SD-Schedule-Special-AppointmentsPurposeThis use case allows the Administrator to schedule special appointments requested by the doctors especially for their patients (for e.g. Surgery, blood test etc.)ActorsMain actor: AdministratorPre-ConditionThe Administrator must be authenticated.He must have details of the patient, and the requirements for the appointment.Main ScenarioThe Administrator accesses the CASS and chooses the Schedule-Special-Appointments option. Then: He chooses a specific department He chooses type of appointment The system returns available appointment slots He chooses a date from available dates He chooses a particular time slot from available time slots He fills in patient informationPost-ConditionThe Administrator is able to fix special appointment for the patient. The patient receives an email regarding the details of the appointment.



Interaction DiagramThe system sequence diagram in Appendix A.2.3.1 Figure 9 shows the visual representation of how the user interacts with the system to complete the function.

3.1.2.7 Use Case CASS-FR-DR-SD-Edit-Personal-InformationPurposeThis functionality allows the doctors to manipulate their personal information.

ActorsThe main actor in this scenario is a Doctor.

Pre-condition The account of doctor must exist Doctor must logged in CASS CASS should be on-line

Main ScenarioAfter the doctor has logged into CASS, s/he will choose the option “Modify Personal Information”. Doctors will be able to see their information such name, address, e-mail, phone number, and their schedule availability. They will have the opportunity to add a day off, a week off, vacations and some changes in their schedules.

Alternative ScenarioIf the date doctors have chosen to vacations has already appointments the system will allow to select those date; however, they will have to go to the system and cancel the appointments for that period of time.

Post-ConditionNot available in this release. Release 2 may contain automatic cancellation at the time at day off is selected by the doctor.

Related Use CasesNot applicable


3.1.2.8 Use Case CASS-FR-DR-UCD-Consult-AppointmentsPurposeThis functionality allows the doctors to select appointments based on different arguments.

ActorsThe main actor in this scenario is a Doctor.

Pre-conditionThe doctor must be authenticated.

Main ScenarioAfter doctors have logged into CASS, they will choose the option “Consult Appointments”. Doctors will be able to see their appointments. They may choose:

1) Name and will go to Use Case CASS-FR-DR-SD-View-Appointments-By-Name



2) Date and will go to Use Case CASS-FR-DR-SD-View-Appointments-By-Date3) All and will go to Use Case CASS-FR-DR-SD-View-Appointments-All

Alternative ScenarioNot applicable

Post-ConditionScreen report displayed

Related Use CasesCASS-FR-DR-SD-View-Appointments-By-NameCASS-FR-DR-SD-View-Appointments-By-DateCASS-FR-DR-SD-View-Appointments-All

Interaction DiagramThe system sequence diagram in Appendix A.2.3.1 Figure 11 shows the specialization/Generalization relationship between this use-case and others.

3.1.2.9 Use Case CASS-FR-DR-SD-View-Appointments-By-DatePurpose This functionality allows the doctors to consult their appointments on a specific date.

Actors The main actor in this scenario is a Doctor.

Pre-condition1. The doctor must know the date and this date must be valid and the next format

DD/MM/YYYY2. The doctor must be authenticated.

Main ScenarioAfter doctors have logged into CASS and have chosen “Consult Appointments by Date”, doctors will have to enter the date they want to consult. CASS will show all appointments that this doctor has in that specific date.


Post-ConditionNot applicableRelated Use CasesNot availableInteraction DiagramThe system sequence diagram in Appendix A.2.3.1 Figure 12 shows the visual representation of how the user interacts with the system to complete the function.

3.1.2.10 Use Case CASS-FR-DR-SD-View-Appointments-By-NamePurpose This functionality allows the doctors to consult their appointments based on Patient’s name.Actors The main actor in this scenario is a Doctor.



Pre-condition1. Doctor must know the complete name of the patient2. The doctor must be authenticated.

Main ScenarioAfter doctors have logged into CASS and have chosen “Consult Appointments by Name”, doctors will have to enter the complete Patient’s name that they want to consult. CASS will show all appointments that this patient has even if they are with another doctor.

Alternative ScenarioNot Applicable

Post-ConditionNot Applicable

Related Use CasesNot available


3.1.2.11 Use Case CASS-FR-DR-SD-View-Appointments-AllPurpose This functionality allows the doctors to consult all their appointments.

Actors The main actor in this scenario is a Doctor.

Pre-conditionThe doctor must be authenticated.

Main ScenarioAfter doctors have logged into CASS and have chosen “Consult ALL Appointments”, doctors will be able to see all the appointments that are pending.


Post-ConditionCASS will generate a report.



3.1.2.12 Use Case CASS-FR-AD-SD-Cancel-AppointmentsPurposeThis use case allows the administrator to cancel an appointment for a patient



ActorsMain actor(s): AdministratorSecondary actor: N/A

Pre-ConditionThe administrator must be authenticated.

Main ScenarioThe administrator accesses the CASS and chooses the Cancel-an-Appointment option. Then:

A1 He chooses a user’s name

A2 Chooses the specifies appointment to be cancelled

A3 The system asks for confirmation

A4 The administrator confirms

Alternative scenarioB2 The user chosen does not have an appointment

B3 The system informs the administrator.

Post-ConditionThe doctor’s schedule is in active and no further appointments possible with that doctor.



3.1.2.13 Use Case CASS-FR-AD-SD-Suspend-Doctor’s-AccountPurposeThis use case allows the administrator to make the account of a doctor inactive.

ActorsMain actor(s): administratorSecondary actor: N/A


Main ScenarioThe administrator accesses the CASS and chooses the doctor-account-suspension. Then:

A1 He chooses a doctor’s name.

A2 System asks for confirmation.

A3 The administrator confirms.

Alternative scenarioB2 The doctor chosen already has a suspended account

B3 The system returns the proper information message.



Post-ConditionThe doctor’s schedule is in active and no further appointments possible with that doctor.



3.1.2.14 Use Case CASS-FR-AD-SD-Create-Doctor’s-AccountPurposeThis use case allows the administrator to create a new doctor profile.



Main ScenarioThe administrator accesses the CASS and chooses the create-doctor-Account option. Then:

A1 He fills a form with a doctor’s personal information.

A2 He submits the form.

A3 The system returns a unique employee username and a password.

Alternative scenarioB1 The doctor’s SIN already exists.

B2 The system displays a proper error message.

Post-ConditionA new doctor-profile is created with a new unique username and a password assigned for the doctor.



3.1.2.15 Use Case CASS-FR-AD-SD-Configure-Employee-x-DepartmentPurpose This functionality allows the administrator to add the department to the doctor's file in the clinic.

Actors The primary actor in this scenario is an Administrator. The secondary actor in this scenario is a doctor.



Pre-condition1. Administrator must logged in CASS2. Doctor profile should be exist in CASS3. The department code should be exist in CASS4. CASS should be on-line

Main ScenarioAfter the administrator have logged into CASS and have chosen “Add Doctor to Department”, the administrator will have to enter the doctor id and then assign the department.

Alternative ScenarioThe administrator enters a non-existent doctor id. Then, The CASS system prompts the administrator for the correct doctor id.The administrator enters a non-existent department type. Then, The CASS system prompts the administrator for the correct department.The administrator enters an existent doctor id with a non-existent department type. Then, The CASS system prompts the administrator to enter the department type first.

Post-ConditionCASS will generate a report.A department be assigned to each doctor


3.1.2.16 Use Case CASS-FR-AD-SD-Configure-Clinic-DepartmentsPurpose This functionality allows the administrator to add the departments working in the clinic.

Actors The main actor in this scenario is an Administrator.

Pre-condition1. Administrator must logged in CASS2. CASS should be on-line3. Department should not be exist

Main ScenarioAfter the administrator have logged into CASS and have chosen “Add New Department”, the administrator will have to enter the code and description of each department.

Alternative ScenarioAn error message will inform the user if the department is existent.

Post-ConditionCASS will generate a reportDepartment will exists in the system




3.1.2.17 Use Case CASS-FR-AD-SD-Configure-Department-x-AppointmentPurpose This functionality allows the administrator to add the appointment types for each department available in the clinic.

Actors The main actor in this scenario is an Administrator.

Pre-condition Doctor must logged in CASS The department code and the Appointment code should be exist in CASS The Appointment type should have a duration exist in CASS CASS should be on-line

Main ScenarioAfter the administrator have logged into CASS and have chosen “Add Duration for Appointment Type”, the administrator will have to enter the department code and the appointment code in order to add duration.

Alternative ScenarioThe administrator enters a non-existent department id. Then, The CASS system prompts the administrator for the correct department id.The administrator enters a non-existent appointment type. Then, The CASS system prompts the administrator for the correct appointment type.The administrator enters an existent department id with a non-existent appointment type. Then, The CASS system prompts the administrator to enter the appointment type first.

Post-ConditionCASS will generate a report.An appointment type(s) will be assigned to each department


3.1.2.20 Use Case CASS-FR-AD-SD-Scheduling-Doctor’s-UnavailabilityPurposeThis use case allows the administrator to specify the days and times for a certain doctor in which He can’t receive any patients.



Main ScenarioThe administrator accesses the CASS and chooses the schedule unavailability option. Then:

A1 He chooses a doctor’s name

A2 The system returns the doctor’s schedule



A3 He selects the day and time at which the doctor is unavailable

Alternative scenarioB2 The doctor chosen is inactive or suspended

B3 The system should return the proper information message.

Post-ConditionThe doctor’s schedule is changed and will contain some time-slots of unavailability.



3.2 Performance Requirements

3.2.1 Static Requirements The System should be able to service multiple terminal connections simultaneously. At

least 50 internet users should be able to use the system without any connection delay issues

The system should process textual and numerical data

3.2.2 Dynamic Requirements The software should be able to process more that 90% of the user queries (like

reserving an appointment, modifying an appointment, etc.) in a fraction of 1 second. No Restriction is applied on the number of queries performed be a user as long as he

is authorized to do perform them. The time needed to display information of users’ queries on a web client, varies

according to the system load and users’ internet connection speed. For a specific time in a specific date, all users have same priority to reserve that slot.

Users are served in a First-Come First-served fashion.

3.3 Logical Database Requirements The database should store different data types of information like integers, time

formats, date format, real numbers and strings.

A fault tolerance and crash recovery plan should be implemented on the system by configuring automatic backup in the DBMS.

The database should be able to handle up to 50 simultaneous user queries.

The database design and relationships should be in a BCNF normal form to guarantee maximum space usage efficiency and a response time of less than three seconds.

3.4 Design Constraints The system should work on any internet browser with GUI whether the underlying

Operating System is Windows, Linux/Unix or Macintosh.



Only the old obsolete command-line web browsers won’t be able to connect to the system.12

3.5 Security Requirements User authentication is needed to use the system. Users should not be able to create

or delete reservations for other users. Thus, a track of each user’s reservations is needed in order to apply these constraints.

Personal information collected upon registration should not be revealed for the sake of privacy. A user needs only to know whether a certain time slot is reserved or not, without the need to reveal the patient’s name.

3.6 Software System Attributes

3.6.1 UsabilityThe System’s interface should be user-friendly:

All web pages used by the users should consistent with standardized colors and fonts. The presentation of the web pages should be made friendly be provided the users

with on-the-spot instructions concerning the step they are. In case of errors, help links should be provided or instructions for correct use. An HTML online documentation should be available and accessible to the users on all

pages and steps of system usage.

3.6.2 ReliabilityThe system should insure that the user actions are performed correctly as the user requires:

The system’s database should handle the maximum number of users (50) without failure.

If the user entered invalid data, the system should be able to recover and react robustly with the error, by sending a message back to the user

The System should be set up on a dedicated computer machine for s 24-hours a day and 7-days a week availability.

The system’s backup plan should support the protection of the DB data and assure the functioning of the system after recovery of a crash

3.6.3 Portability Because the appointment scheduler is a web based system, it can be accessed by

users having any operating system with GUI internet browser installed; thus insuring high portability and minimum system requirements.

100% of the client code is host independent. The PHP language used at the hosting machine is system independent. System can be work under Windows or Linux.

3.6.4 Correctness All algorithms implemented in the system should be correct; meaning they should be

performed as required. The testing phase insures correctness of the software by trying all possible case and matching their output with the documentation.

12 http://www.w3schools.com/browsers/browsers_stats.asp



3.6.5 Interoperability Since the system relies on the web agents (browsers) in its interoperability, and all

web agents interoperates with other software packages, then the system can work with other software. For example, it can provide an Acrobat Reader version of the documentation.

3.6.6 Maintainability The client side scripting is of the system can be easily fixed and enhanced due to

simplicity. The server side scripting is well maintainable also as all models and code is preceded by related design and this requirements document.



APPENDIX A

A.1 Structural Model:

A.1.1 Domain Model:

DoctorNamePhoneNumberAddress

PatientnamehealthCardIDSocialInsurceNumberPhoneNumberAddress

AppointmentTypetypedescriptionEstimatedDuration

AgendaDateweekdaystatus11 11

has

TimeSlotstartTimeendTimestatus

0..n

1

0..n

1

has

AppointmentsequenceNumberstartTimeDiscriptiondoctor

0..n1 0..n1

book

1

0..n

1

0..n

belongs

modify

Figure1. Domain Model Diagram



A.2 Behavioral ModelA.2.1 Use Case Model

A.2.1.1 Use Case Diagram

Consult Doctor Appointments

(from Use Cases)Doctor

(f rom Actors)

Create Account Doctor

(from Use Cases)

Configure Catalogs

(from Use Cases)

Manage Doctor Accounts

(from Use Cases)

CreateAppointment

(from <Use Case Name>)

Cancel Appointment

(from Use Cases)

Edit Patient Profile

(from Use Cases)

Consult Appointment

(from Use Cases)

Patient

(f rom Actors)

Health Card System

(f rom Use-Case Model)

Create Account Patient

(from Use Cases)

Cancel Patient Appointment

(from Use Cases)

Schedule Special Appointments

(from Use Cases)

Administrator

(f rom Actors)

Edit Doctor Profile

(from Use Cases)

Figure 2 Use Case Model



A.2.1.2 Sequence Diagrams

:Patient:Patient:System:System

Start book appointment

return informetive message

choose one doctor

display doctor's agenda

submit appointment request

display results

Figure 3 CASS-FR-PT-SD-Book-Appointment



Figure 4 CASS-FR-PT-SD-Cancel-Appointment



:patient:patient :System:System

start to veiw & eidt profile

display profile

edit profile

display profile form

submit form

Display results

Figure 5 CASS-FR-PT-SD-Edit-Personal-Information

:new patient:new patient :System:System

start register

show registration form

Submit register form

Display results

Figure 6 CASS-FR-PT-SD-Create-Account



Figure 7 CASS-FR-PT-SD-Consult-Appointments



a1 : Administratora1 : Administrator

:System:System

1:start_Patient_Appointment_Cancelling

2:Information Message

3:choose_Patient_Name


5:select_Appointment_to_Cancel


7: submit_Cancelling

8: Confirmation Message

9:submit_confirmation


Figure 8 CASS-FR-DR-AD-Cancel-Appointments



Figure 9 CASS-FR-AD-SD-Schedule-Special-Appointments


: Administrator :System

1: Start Schedule Special Appointment;

2: Informative message

3: Enter Department Code


5: Enter Appointment Type


7: Enter date

8: Enter time

9: Enter Patient details

10: Confirmation message

11: End Schedule Special Appointment


: Doctor : Doctor:System:System

1: Request Doctor's Information

2: Display Name, Address, e-mail, Phone # & Agenda

3: Enter new Name

4: Enter new Address

5: Enter new e-mail

6: Enter new Phone #

7: Enter new Password

8: Enter new Agenda

9: Display "Information Updated"

Figure 10 CASS-FR-DR-SD-Edit-Personal-Information

View Appointments By NameView Appointment By Date

Consult Doctor Appointments

View All Appointments

Figure 11 CASS-UCD-Use-Cases Generalization



: Doctor : Doctor :System:System

1: Enter Date

2: Display Patients names and time

Figure 12 CASS-FR-DR-SD-View-Appointments-By-Date


1: Enter Name

2: Display Patient Name, Doctor's Name, Date & time of the Appointment

Figure 13 CASS-FR-DR-SD-View-Appointments-By-Name


1: Request All Appointments

2: Display Date, Patient's Name, Time

Figure 14 CASS-FR-DR-SD-View-Appointments-All



a1 : Administratora1 : Administrator

:System:System

1:start Account Creation

2:Informative Message

3:enter Doctor's Personal Info


5:Create Account

6:Confirmation Message

Figure 15 CASS-FR-AD-SD-Create-Doctor-Account



Figure 16 CASS-FR-AD-SD-Configure-Employee-x-Department



1: Start Employee-x-Department;


3: Enter Doctor id


5: Enter Department code

6: Conformation message

7: End Employee-x-Department


Figure 17 CASS-FR-AD-SD-Configure-Clinic-Departments



1: Start Department Configuration;


3: Enter Dept Code


5: Enter Dept Description


7: End Department Configuration;


Figure 18 CASS-FR-AD-SD-Configure-Department-Appointment-Duration



1: Start Department-Appointment-configuration


3: Choose Departement Name


5: Specify Department Appointment Time


7: End Department appointment configuration


c4 : Administratorc4 : Administrator

:System:System

1:start Suspending Account


3:Enter Doctor's Name


5:Confirm Suspension


7: Suspend Doctor


Figure 19 CASS-FR-AD-SD-Suspend-Doctor’s-Account



c3 : Administratorc3 : Administrator

:System:System

1:start Schedule Unavailable

2: Informative Message

3:enterDoctor's Name


5:choose Day and Time


7:Submit Schedule Unavailable


Figure 20 Use Case CASS-FR-AD-SD-Schedule doctor’s unavailability


Date post:	28-Apr-2018
Category:	Documents
Upload:	lammien
View:	215 times
Download:	2 times

1 · Web viewSRS . Clinic Appointment. Scheduler System. C.A.S.S. September 30, 2005. Concordia...

Documents