ASSIGNMENT 1 BIT302 SOFTWARE ENGINEERING PROJECT PLAN

STUDENT ID : E0800109

PROJECT PLAN DOCTOR RESERVATION SYSTEM FOR A CLINIC

1.

Project Scope 1.1 Background Today, information technology has become very popular. By the existence of information technology, especially the information system, many of the human tasks can be done faster and in an easy way. These are the reasons that almost every institutions or businesses has started to use information technology in their sector. This is also affects the clinic. As we all know that clinic is one of a business sector which is providing health service. Before, clinic is just a small place and doesnt have many doctors and patient. But nowadays, as the population is growing, clinic may have many doctors in charge and many patients. It means that it will need much effort of the nurse in doing the daily tasks,especially in making an appointment between the doctor and the patient. And this become the main reason behind the idea of developing the system. This Doctor Reservation System is expected to help the nurse in completing the task in arranging an appointment for the patient and the doctor. This task is also quite critical among the whole process which is available on a clinic. Therefore, this system is expected will be able to increase the accuracy of the reservation process, which can lead to better service for all of the patients, doctors, or even the nurses.

1.2 Scope The Doctor Reservation System is expected to allow the nurses doing some activities as follows: 1. Registering new doctor 2. Registering new patient 3. Registering new nurse 4. Registering new schedule 5. Searching / Checking the doctor schedule 6. Making an appointment 7. Searching appoinment

8. Add Specialist 9. Add Doctor Schedule From the functions above, the objectives of this sytem is that it must be able to do these jobs : 1. Nurse can check the schedule of each doctors available at the clinic. 2. Nurse can arrange an appointment between the patient and the particular doctors. 3. Nurse can search a particular appointment by the appointment number or the patient number. 4. Nurse can add new nurse detail, delete a paticular nurse, or update nurses information. 5. Nurse can add new patient detail, delete a particular patient, or update patients information. 6. Nurse can add new doctor detail, delete a particular doctor, or update the doctors information. 7. Nurse can add new schedule in the clinic. 8. Nurse can add new specialists available. 9. Nurse can add new doctors schedule

2.

Project Schedule 2.1 Work Breakdown Structure

1. Feasibility Study 1.1 1.2 Gather User Requirement Project Initiation and Planning

2. Detailed Analysis 2.1 2.2 2.3 2.4 Review User Requirement Develop Schedule Budget Estimation Develop Project Plan

3.

Detailed Design 3.1 Define System Design 3.2 Prototyping 3.3 Design User Interface 3.4 Review System Design

4.

Construction 4.1 Coding

5.

Testing 5.1 Define Alpha and Beta Tester 5.2 Alpha and Beta Testing 5.3 Review System

6.

System Delivery 6.1 Training

7.

Operation and Maintenance

2.2
Jan 2013

Gantt Chart
Feb 2013 Mar 2013 Apr 2013 May 2013

Task Name

ID

Start

Finish

Duration
28 29 30 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

1. Feasibility Study 1.1 Gather User Requirement 1.2 Project Initiation and Planning 2. Detailed Analysis 2.1 Review User Requirement 2.1 Develop Schedule 2.3 Budged Estimation 2.4 Develop Project Plan 3. Detailed Design 3.1 Define System Design 3.2 Prototyping 3.3 Design User Interface 3.4 Review System Design 4. Construction 4.1 Coding 5. Testing

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

1/28/2013 1/31/2013 2/6/2013 2/11/2013 2/13/2013 2/15/2013 2/18/2013 2/20/2013 2/25/2013 3/1/2013 3/4/2013 3/12/2013 3/18/2013 3/21/2013 3/25/2013 4/29/2013 4/30/2013 5/3/2013 5/10/2013 5/15/2013 5/16/2013 5/24/2013

1/30/2013 2/5/2013 2/8/2013 2/12/2013 2/14/2013 2/15/2013 2/19/2013 2/22/2013 2/28/2013 3/1/2013 3/11/2013 3/15/2013 3/20/2013 3/22/2013 4/26/2013 4/29/2013 5/2/2013 5/9/2013 5/14/2013 5/15/2013 5/23/2013 5/30/2013

3d 4d 3d 2d 2d 1d 2d 3d 4d 1d 6d 4d 3d 2d 25d 1d 3d 5d 3d 1d 6d 5d

5.1 Define Alpha and Beta Testing 17 5.2 Alpha dan Beta Testing 5.3 Review System 6. System Delivery 6.1 Trainning 7. Operation and Maintenance 18 19 20 21 22

3.

Project Team Management 3.1 Roles and Respnsibility

System Analyst System analysts are in charge of collecting the user requirement for the system, helping in the proces of developing the project plan and estimating budget, designing the system, and working closely with the programmer during the coding process

System Designer System Designers are in charge of designing and developing the interface of the system, developing the design prototype of the system, reviewing the design, and also work collaboratively with Analysts and Programmers during the designing process.

Programmer Programmers are in charge of developing and implementing the designed made by the analysts and designers in the form of coding, developing all necessary algorithms needed by the system, and also work in collaboration with the Analysts and Designers during the cosing process.

System Tester Testers are in charge of testing the system thoroughly to make sure that the system is run in accordance with the requirement. If there are any errors or mistakes found, the the testers should work collaboratively with the analysts and programmers in order to fix them.

Trainer Trainers are in charge of providing assistance and training to the end-users during the system delivery and providing maintenance support for the end-users. Therefore, before all of the trainers done their jobs, they must learn and clearly understand how the system runs.

4.

Technical Description of The Proposed System 4.1 Technical Description Doctor Reservation System is a system which is expected to help some of the jobs in the clinic. There are several functions which is owned by this system, they are : 1. Registering new doctor. This function is used to create a data of a new doctor. This function also support the data renewal (update) of a particular doctor, and the data abolition of a particular doctor.

2. Registering new patient. This function is used to create a data of a new patient. Beside that, this function also support the data renewal (update) of a particular patient, and the data abolition of a particular patient.

3. Registering new nurse This function is used to create a data of a new nurse. This function also support the data renewal (update) of a particular nurse, and the data abolition of a particular nurse.

4. Checking the doctor schedule This functions allows the user to check for the schedule of a particular doctors by just entering the name of the doctor.

5. Making an appointment This function will facilitate the reservation between the doctor and the patient. But, if the patient is nor registered yet as the patient of the clinic, the he/she must registered themsleves first.

6. Search appointment This functions allows the user to check for a particular appointment by entering the appointment number.

7. Registering new Schedule This function allows the user to make a new schedule available in the clinic. 8. Add Specialist This functions allows the users to add a new specialist in the clinic.

9. Add Doctor Schedule This functions allow the users to add a schedule of a particular doctor.

4.2 Hardware and Software In order to accomplish these functions, the hardware platform that will be used during the development of the system is planned as follows : 1. For the developer group which is consist of the Analyst and Programmer This group uses a core i3 computers with Windows as its OS. 2. For the designer group which is consist only the Designer This group will also use a core i3 computers with Windows as its OS. 3. For the Tester group which is consist only the Testers This group will use a dual-core computers with Windows as its OS. This system will have the capability to run in dual-core or Pentium 4 processor with Windows 7 as its OS. And for the software platform, this sytem will be developed in Windows 7 based Operating System with VB.net as its programming language and SQL Server 2000 for its Database Management System.

5.

Project Standards, Procedures, and Proposed Techniques and Tools 5.1 Project Standard and Procedure The development process of this project is using the waterfall model. The reasons behind this chosen model is in order to make this project done in a sequencial model. Therefore, as the consequences of the election of this model, the schedule must be planned carefully, in order to make the system complete on time. Beside that, all of the activities and progresses done within this project development must be all documented completely. And the program standard codes also has to be documented and easy to follow, low coupling, and high cohesion along with the pseudocode included to help all of the members understand the code.

5.2 Proposed Techniques and Tools This system is developed using the Object Oriented Techniques using UML. For the tools, this project will use StarUML as an aid tools for the Analyst to draw certain diagram such as Use Case Diagram. And for the documentation, this project will used Microsoft Word 2007 as an aid tools.

6.

Quality Assurance Plan In the development process of this project, we also pay much attention in the quality of the software in order to maintain a high satisfaction level of the user. So, there are the plans to maintain the quality assurance : 1. Plans and schedules will be given to all of the stakeholders involved in the project. 2. Every member of the team development must strictly follows all of the plans that has been agreed. 3. If a problem occurs all of the problem must be addressed and done according to its area. 4. Ensuring the testing process is done thoroughly and and in detail to make sure that every little mistakes is covered and fixed before the system is delivered to the user. 5. All of team activities will be monitored and under the control of project management.

7.

Configuration Management Plan This configuration management plan provides the details of how we will track changes to the requirements, design, code, test plans, and document. These are the following plans :

1. Configuration Manager Configuration Manager has the responsibility of managing the project entirely and all of the activities that is related to the Configuration Management, they are : Manage the Configuration Members Make meeting with the Configuration Members Review proposed change from the configuration members Assign, approve, or reject proposed changes and items.

2. Configuration Vice Manager Configuration Vice Manager has the responsibility in assisting the Configuration Manager in reviewing the proposed change or giving some advices about the changing matters. The other responsibility is helping the Configuration Manager in managing the configuration activity related to Configuration Management.

3. Cofiguration Technical Manager Configuration Technical Manager has the responsibilty in identifying all of the hardware and software configuration items to the Configuration Manager. Beside that, Configuration Technical Manager also in charge of the overall system design and system needs.

4. Configuration Application Manager Configuration Application Manager has the responsibility in identifying all the application software to the Configuration Manager. Configuration Application Manager also in charge of the overall design, implementation, and deeds of this sytem.

8.

Documentation Plan Documentation is a very critical yet important part in developing a project. This documentation later will be used as a report either for the stakeholders nor the developer team. These are the documentations plan : 1. Every progress done by each team must be documented in the form of Microsoft Word 2007, consisting a clear and detail result and activity done in each phase. 2. Every problem occured in the developing process must be stated and documented clearly along with the solution or recommended action to solve those kind of problems. 3. All user requirement also must be documented. 4. All of the data obtained from the Analysts must be also documented. 5. All of the data obtained from the Designers must be also documented. 6. All of the data and progress from the Programmers must be documented thoroughly. Every functions which is being added or implemented must be stated clearly along with all the problem occurs during the process. 7. All of activities, data, and result of the Testing phase must also be documented thoroughly. 8. All of the activities and result of the Training phase must also be documented clearly along with the problem occured during the process. 9. All of the activities during the Operation and Maintenance Process must be documented thoroughly including the problem reported by the user or any additional features that the user needs. This documentation are all made to be used as a guidance and report in order to improve the development of the similiar projects in the future.

9.

Data Management Plan To ensure that the data can be distributed well amongst the project team and also used efficiently by those who need it, so the data will be managed in these ways : 1. All of the data that has been collected during the feasibility study about the user requirement or any other data obtained from the user related with system must be created and saved in the form of Microsoft Word 2007.

2. All of the team members are connected and integrated in a computer network and in control of the computer server. So, any other people who are not in charge of this project may not obtained any single data. This is done in order to maintain the confidentiality of every single data which has been a shared responsibility amongst the team. 3. All of the data that contains sensitive information about the stakeholders must be kept as a secret and only used for the analysis process. As soon as the analysis process is done, these data must be destroyed to avoid unwanted events, such as data leaks.

10. Resource Management Plan To ensure that this project will be run properly, so every single resource involved in this project will be managed these ways : 1. In this project, the team is divided into five smaller groups. Each group has their own roles and responsibilities, which is clearly stated on the project team management. 2. Each team will be supported with a workstation, completed with a computer that has all of the specification needed. 3. All of the workstations are connected using a computer network and controlled by a computer server which is in charge of data distribution. 4. If there are any resource insufficiency, then they can submit a report and request for an additional resource, along with a clearly and reasonable reasons stated on this report.

11. Test Plan To ensure that the system is run in accordance with the requirement, the the testers will play their role according to this plan : 1. The first step of the testing process is to test the usability of the interface. This is done in order to find out whether the interface is good enough for the user and will not cause any confusion for the user. 2. Next is to check whether the database is working properly or not. In this step, the testers must ensure that the relation of all data is perfect, so there will be no error in the process

of adding, deleting, and updating the patient details, doctors detail and schedules, and the patient appointment. 3. Third is to check the security. The testers must make sure that people who dont have any rights (in this case : people who is not a nurse of the clinic) cant access and cant make any appointment. 4. Fourth is to check the doctor schedule checking can work properly. The testers must ensure that the nurse can check for all of the doctors schedule. 5. Fifth is to check the appointment search feature is work properly. To ensure this the tester must ensure that the nurse can search the appointment by the appointment number. 6. Last is to check the feature of making appointment can work properly. The testers must ensure that the nurses are able to make an appointment and cancel it. When the cancellation is happen, then testers must ensure that the appointment cancelled is wellerased. Besides that, testers must ensure that there wont be any double reservation.

12. Training Plan The training process is done in order to help the user know the basic step in using the system and what the system can perform. The training process will be done according to these steps : 1. Trainers must help and demostrate to users how to istall the system step by step 2. Trainers must train the user to input the patient and doctor details and schedule, also how to search for doctors schedule. 3. Trainers must show user how to arrange an appointment between the doctors and the patient, how to cancel it, and how to search for the appointment that has been made. 4. Trainers also should train the user the basic troubleshooting such as when the nurse got a problem in changing password, cancelling the appointment, or viewing a doctors or doctors schedule, and also when they make an unintensional mistake when inputting the data. 5. Last, trainers also have to explain the system behavior.

13. Security Plan In order to ensure that the system has a high security in every aspects, then the security plan will be as follow : 1. To control the access rights, then this system will be completed with a log in and log out which required a username and password. 2. It is very important to make sure that only admin ( in this case : nurse in charge) can add, delete, or update the patient details and doctors details and schedule. 3. It is also very important to make sure that whoever is not a nurse of the clinic may not access the system.

14. Risk Management Plan In order to manage each risk that might be appear during this system development, then we will follow these plans : 1. Before the work is started there will be a briefing about what they will do within the next hours, and before the team left their workstation to go home to discuss about what they have done and what they will do the next day. This is done in order to prevent any miscommunication. 2. All of the activities within the team and about the project must be documented in the format of Microsoft Word 2007. There will be several copies available, and it is all stored in a secure place and cant be shared outside the team member. This is done in case of any unexpected events happen and one of the copy is lost, there will be the other copy. 3. When one of the team member is unable to do their jobs beacuse of any reason, then his/her task is shared among the other team member. 4. If on the way of the project, there is a team who need any additional resource, then they can submit a request with a clear and reasonable reasons clearly stated on it. 5. When one of the team member quits the job because of any reasons, then his/her rights in accessing any data and using any resources is eliminated and erased.

6. Any sensitive information about the stakeholders or users are not to be shared among all of the members, only several people who are in charge may access the data. This is to avoid any data leaks. 7. If there is a new (additional) member, he/she will used the documentation that has been made in order to learn about how this project will be done or has been done, and what are his/her responsibilities.

15. Maintenance Plan To ensure that the system is work properly on its best state and about the future development of the system, the we will follow these plans : 1. Before the system is being delivered to the user, the system must be tested thoroughly in order to make sure that it will run properly and no errors found. 2. Adjust system change for the new OS, hardware, and software for future development. 3. The report of each maintenance done, will be used as a guidance to improve the system quality. 4. New feature will be developed according to user needs. 5. The maintenance of the system isn not only the trainers responsibility, but also the analysts, designers, and programmers responsibility. 6. The maintenance process also including the existing features.

SOFTWARE REQUIREMENT DEFINITION DOCUMENT

1.

Introduction This document is the Software Requirement Definition Document for Doctor Reservation System for a Clinic. This document contains a complete description about the goals of the system that the clients expected. This document lists these following features as the high-level requirements for the Doctor Reservation System for a Clinic : Doctor Management Include adding, deleting, and updating doctors information. Nurse Management Include adding, deleting, and updating nurses information. Patient Management Include adding, deleting, and updating patients information. Specialist Management Including adding, deleting, and updating specialist available on the clinic Doctor Schedule Management Including the adding, deleting, and updating the schedule of a particular doctor Schedule Management Including adding, deleting, and updating schedule Check Doctor Schedule Allow nurse to check the doctors schedule Appointment Management Including makin an appointment and search for a particular appointment This document also contains a general description of the project along with the general constraint and all of the assumption and dependencies of the system.

1.1 Purpose The purpose in writting this document is to represents a contract between the developer team and the clients, describing what functionality the developer promises to deliver to the client. Any other functionality or reqirements that appear outside what has been written in this document is not valid. This document is written for the clients. Therefore, the making of this document is in the terms of the client, in order to gain a great understanding whithin the developer and the clients to support the success of this project.

1.2 Scope The proposed system in this project is Doctor Reservation System for a Clinic. This system will be used in order to help the nurses doing their job faster. This system will help the nurse registering new doctor, registering new nurse, registering new patient, registering schedule, checking doctor schedule, making an appointment, and searching an appointment. This sytem will not handle the transaction and the treatment of the clinic. Just up to the appointment or doctor reservation. The goals of this system are facilitating the growth of the clinic in 5-10 years ahead and also helping the clinic as apublic helath service in order to be able to give a better service. The benefits of this system is that the nurse will be able to work more efficiently and accurately and reduce the time needed when searching into a particular file. And the objectives of this system is allowing the nurse to enhace their performance on the clinic and increasing the patient satisfaction.

1.3 Definition/abbreviation Here are some definitions and abbreviations that is needed to be understand either by the developers or the clients to improve the good understanding :

DRS Use Case Diagram

Doctor Reservation System A diagram that represent all of the functions available on the system and show all of the actors

Actor(s)

Everyone involved in the system directly or indirectly

1.4 Refernces This software requirement definition refers to the Sample Format of Requirements Definition Document Based on IEEE Standard 830 : Software Requirements Specification. Retrieved on November 4th, 2011 from:

http://www.csee.wvu.edu/~katerina/Teaching/CS-230-Spring-2006/CS-230-SampleFormats.pdf. And a book :

1.5 Overview This Software Requirement Definition is the documentation about the requirements intended by the user that formally specifies the DRS system. It includes the business analysis and systems analysis efforts. Various techniques were used to elicit the requirements and we have identified all of the clients need, analyzed, and refined them. The objectives of this document is to formally describe the system high-level requirements, business rules, and any other constraints. The remainder of this document provides an overview of the business domain that the proposed DRS will support. These include the general description of the system, user characteristic, general constraint and any assumptions for this system, and also a use case diagram to complement. This document demonstrate the developers understanding about the business domain and the clients need, also the willingness in exploring the abilities within the team in order to build a system that truely support the business and the users needs.

2.

General Description

2.1 Product Perspective This Doctor Reservation System is an independent and self-contained program. This system manages the reservation activities and also all the data maintenance in a clinic. This system is available as a replace for the former system which is a paper-based system and done manually. Various stakeholders are also involved in this system.

2.2 System Evolution The life cycle model that will be used in this development process is the waterfall model. The chosen of this model is beacuse we want to make the system in the sequencial model. There are 7 phases in this model, they are : Feasibility Study This is the phase where the evaluation of costs and benefits are done including the feasibility report. Detailed Analysis This is the phase where all requirements are identified. Detailed Design This is the phase where the system is decomposed into modules. Construction This is the phase where the coding process is be held. Testing This is the phase where the system that has been made is being tested thoroughly. System Delivery This is the phase where the system is ready to be delivered and then the training process will be held. Operation and Maintenance

The training process will be held as soon as the system is being delivered to the clients. This delivering process is also including the first installation.

2.3 Product Function This system has several functions overall. Here are the description of each function available in the system : Registering new doctor : allow the nurse to register a new doctor Registering new patient : allow the nurse to register a new patient Registering new nurse : allow the nurse to register a new nurse Registering new schedule : allow the nurse to register a new schedule of the clinic. Searching / checking doctors schedule : allow the nurse to search on the schedule of a particular doctor. Making an appointment : allow the nurse to arrange or made an appointment between the patient and the doctor according to the doctor schedule on the clinic. Searching an appointment : allow the nurse to search a particular appointment that has been made. Register specialist : allow the users to add a new specialist to register a new specialist on the clinic Add Doctor Schedule : allow the users to add the schedule of a particular doctor. It also support the deleting and updating process.

2.4 Users of the Product There are several users that will use this system either directly or indirectly. Here is the description : User that directly use the system is the nurse that is available on the clinic. The condition is that not every nurse is familiar in using a computer. For those who is already familiar with the computer, they will have training about how to use this system. While those who are not familiar with computer will get a complete

training including the basic knowledge about using a computer. And the nurses are automatically assign as the one who is responsible for the use of this system. User who is indirectly use the system are the doctors and the patients. And they have no rights in accessing the system.

2.5 General Constraint There are several general constaraints that must be paid in good attention of this system, they are : The system must be delivered within 4 months The language used in this system is English The Database used in this system is SQL Server 2000 in order to accomodate many data

2.6 Assumption and Deependencies The development of this system is based on these assumptions and dependencies : We assume that client / user already has a set of computers that is compatible with this system. We assume that all of the functions mentioned in this document has been mutually agreed by the developer and the client. We assume that every client and user are familiar with English language

3. Use Case Diagram

SOFTWARE REQUIREMENT SPECIFICATION

1.

Introduction 1.1 Purpose This document is the Software Requirement Definition Document for Doctor Reservation System for a Clinic or. This document contains a complete description about the requirements of the system that the clients expected. This document lists these following features as the high-level requirements for the Doctor Reservation System for a Clinic : Doctor Management Include adding, deleting, and updating doctors information. Nurse Management Include adding, deleting, and updating nurses information. Patient Management Include adding, deleting, and updating patients information. Schedule Management Including adding, deleting, and updating schedule Check Doctor Schedule Allow nurse to check the doctors schedule Appointment Management Including makin an appointment and search for a particular appointment Schedule Management Including adding, deleting, and updating schedule Check Doctor Schedule Allow nurse to check the doctors schedule Appointment Management Including makin an appointment and search for a particular appointment

This document also contains a general description of the project along with the general constraint and all of the assumption and dependencies of the system.

1.2 Document Conventions The highest priority of the higher-level requirements is in the make appointment. This is the main of all of the function exist in this system. Therefore, put more effort in this section will be better. Please note that dont ever underestimate the other functions or higher-level requirements.

1.3 Intended Audience and Reading Suggestion The inteded user for this Software Requirement Specification is the developer team, including the analysts, designers, programmers, testers, trainers, and also the project manager. The remainder of this document is specifying the system requirements, including the functional requirements and the non-functional requirements. For the designers, programmers, testers, and trainers the more detail specification can be read on the design specification document.

1.4 Project Scope The proposed system in this project is Doctor Reservation System for a Clinic. This system will be used in order to help the nurses doing their job faster. This system will help the nurse registering new doctor, registering new nurse, registering new patient, registering schedule, checking doctor schedule, making an appointment, and searching an appointment. This sytem will not handle the transaction and the treatment of the clinic. Just up to the appointment or doctor reservation. The goals of this system are facilitating the growth of the clinic in 5-10 years ahead and also helping the clinic as apublic helath service in order to be able to give a better service. The benefits of this system is that the nurse will be able to work more efficiently and accurately and reduce the time needed when searching into a particular file. And the objectives of this system is allowing the nurse to enhace their performance on the clinic and increasing the patient satisfaction.

1.5 References

This Software Requirement Specification refers to the Software Requirements Specification Templates. Retrieved on November 5th, 2011 from:

http://www.processimpact.com/goodies.shtml#reqs.

2.

Overall Description 2.1 Product Perspective This Doctor Reservation System is an independent and self-contained program. This system manages the reservation activities and also all the data maintenance in a clinic. This system is available as a replace for the former system which is a paper-based system and done manually. Various stakeholders are also involved in this system. Here is the Use Case Diagram that represent the functionality of the system :

2.2 Product Features This system has several features overall. Here are the description of each function available in the system : Registering new doctor : allow the nurse to register a new doctor, including deleting, and updating Registering new patient : allow the nurse to register a new patient, including deleting, and updating Registering new nurse : allow the nurse to register a new nurse, including deleting, and updating Registering new schedule : allow the nurse to register a new schedule of the clinic, including deleting, and updating Searching / checking doctors schedule : allow the nurse to search on the schedule of a particular doctor. Making an appointment : allow the nurse to arrange or made an appointment between the patient and the doctor according to the doctor schedule on the clinic. Searching an appointment : allow the nurse to search a particular appointment that has been made. Add Specialist : allow the nurse to add a specialist on the clinic, including deleting, and updating Add Doctor Schedule : allow the nurse to add a schedule of a particular doctor, including deleting, and updating

2.3 User Classes and Characteristic There are several users that will use this system either directly or indirectly. Here is the description : User that directly use the system is the nurse that is available on the clinic. The condition is that not every nurse is familiar in using a computer. For those who is already familiar with the computer, they will have training about how to use this system. While those who are not familiar with computer will get a complete training including the basic knowledge about using a computer. And the nurses are automatically assign as the one who is responsible for the use of this system.

User who is indirectly use the system are the doctors and the patients. And they have no rights in accessing the system.

2.4 Operating Environment The environment in which the system will operate is described as follows : Operating System and versions : Windows 7 Processors : Pentium 4 or Dual-core processor

2.5 Design and Implementation Constraint There are some constraints which is appear in the design and implementation process, they are : The system must be delivered within 4 months The language used in this system is English The Database used in this system is SQL Server 2000 in order to accomodate many data

2.6 User Documentation The documentation components that will be delivered along with the software are : User Manual

2.7 Assumption and Dependencies The development of this system is based on these assumptions and dependencies : We assume that client / user already has a set of computers that is compatible with this system. We assume that all of the functions mentioned in this document has been mutually agreed by the developer and the client. We assume that every client and user are familiar with English language

3.

System Features 3.1 System Feature 1 : AddDoctor

Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse want to enter new doctors information 2. The nurse input the new doctor information to the system Alternatives course of Events (none)

AddDoctor To allow the addition of new doctor Nurse (none)

System Response

3. The system add and save all of the data of the new doctor

3.2 System Feature 2 : AddNurse Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. A new nurse come to the clinic 2. The other nurse verify the qualification of the nurse 3. The nurse add the new nurse data into the system 4. The system add and save the data of the new nurse System Response AddNurse To allow the addition of new nurse Nurse (none)

Alternatives course of Events Line 3 : If the new nurse cant fulfill the qualification, then the addition process is terminated.

3.3 System Feature 3 : AddPatient Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse want to add a new schedule 2. The nurse enters the new 3. The system add and save the new schedule System Response AddSchedule To allow the addition of new schedule Nurse (none)

schedule into the system Alternatives course of Events (none)

3.4 System Feature 4 : AddSchedule Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. A new patient come to the clinic 2. The nurse asking for some information System Response AddPatient To allow the addition of new patient Nurse Patient

3. The nurse enter the informations given by the patient Alternatives course of Events

4. The system add and save the data of the new patient

Line 3 : If the patient has been registered before, then the addition process is terminated.

3.5 System Feature 5 : AddSpecialist Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse wants to add new specialist 2. The nurse enters the new 3. The system add and save the new specialist System Response AddSpecialist To allow the addition of new specialist Nurse (none)

specialist to the system Alternatives course of Events (none)

3.6 System Feature 6 : SearchSchedule Use Case Name Goal in Context SearchSchedule To allow the searching process of a schedule Primary Actor Secondary Actor Typical Course of Events Actor Action System Response Nurse (none)

1. The nurse wants to search for the schedule of a particular doctor 2. The nurse enter the name of the doctor 3. The system search for the schedule schedule Alternatives course of Events Line 2 : If the doctor is not available, then the display process will terminated. and display the

3.7 System Feature 7 : AddAppointment Use Case Name Goal in Context AddAppointment To allow the addition of new

appointment Primary Actor Secondary Actor Typical Course of Events Actor Action 1. A new patient calls or comes to make an appointment with a particular doctor 2. The nurse ask for a patient ID 3. The patient give the patient ID 4. The nurse enters the patient ID 5. The system validate the patient number 6. The patient ask for the doctor that the patient want to see 7. The patient mention the name of the doctor System Response Nurse Patient

8. The patient enters the doctors name 10. The nurse inform the doctors schedule and ask the patient which schedule do the patient want 11. The patient give choose the schedule 12. The nurse complete and

9. The

system

validate

the

doctors name and display the schedule

confirm the appointment form 13. The patient agree and end the calls or leave Alternatives course of Events Line 4 : If the patient doesnt have a patientID, the the process is canceled, and the patient can be registered first. Line 8 : If the doctor is not exist, then the patient may change the doctor, or process will be terminated Line 13 : If the patient doesnt agree, then the process will be terminated 14. The system add and save the appointment made

3.8 System Feature 8 : SearchAppointment Use Case Name Goal in Context SearchAppointment To allow the searching process of an appointment Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse want to search for a System Response Nurse (none)

particular appointment 2. The nurse enter the appointment number 3. The system validate the

appointment number 4. The system display the

appointment detail Alternatives course of Events Line 3 : If the appointment number is not valid, then the display process will be terminated.

3.9 System Feature 9 : Add Doctor Schedule Use Case Name Goal in Context AddDoctorSchedule To allow the addition a schedule of a particular docto Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse want to add a schedule for a particular doctor 2. The nurse choose the doctor 4. The nurse enter the data 3. The system serach for the doctor 5. The system add and save the schedule Alternatives course of Events Line 2 : If the doctor is not available, terminate the process System Response Nurse (none)

4.

External Interface Requirements 4.1 User Interfaces This system must be used a GUI or Graphical User Interface in order to make it easier for the user to understand in using this system. The function keys which is available on each screen will be made as convenient as it can be. The function keys will also completed with a short explanation about the function itself. Beside that, every screen is also completed with the help functions in order to give a quick help to the user.

4.2 Communication Interfaces This system will be associated with a communication function which is a network server communications protocols in helping the data distribution within several nurse in charge.

5.

Other Non-Functional Requirements 5.1 Performance Requirements The performance requirements of this system is described as follows : 1. This system must give responses in 1 second after the command is inputed. 2. The system must have the capacity of thousands record data. 3. The user-interface screen must be able to respond within 5 seocnds.

5.2 Safety Requirements The safety requirements of this system is specified as follows : 1. The system must provide the capability of back-up data 2. The system must keep a log of all errors.

5.3 Security Requirements The security requirements of this system is specified as follows : 1. Only nurse of the clinic may access the system

2. The access rights of the nurse is granted by the highest authorization on the clinic and transformed to the system in the form of account in the system. 3. Any modification for the database must be synchronized and done only by the adminisrator of the system.

5.4 Software Quality Attribute The other quality characteristic that will be important for the customer is the portability of the system. Here are the requirements : 1. The system must be made compatible with the Windows environment from the version of Windows 7 and upward and either 32-bits or 64bits. 2. The system must be made compatible with the Pentium 4 processors and upward.

SOFTWARE DESIGN SPECIFICATION

1.

Analysis Modelling

1.1 Data Entities and Relationship The specification of data entities and its relationship of this system is decribed in the following Class Diagram :

Clinic 1 1 maintain 1..* Schedule +ScheduleID +Day +Time 1 maintain

ClinicMember +Name 1..* +Gender +Address +Telp

maintain 1..* Specialist +SpecID +Specialization

Nurse Doctor +DoctorID Patient +PatientID +NurseID 1 handle 0..*

1 1 had by 1..* 1..* DoctorSchedule +Room 1 has involved 1..* 1 0..* make

Appointment +AppointmentNum +AppMadeDate +LineNum

1.2 Information Flow and Transform The specification of the dynamic behavior of the information flow and the transform that are applied as data move from input to output is described in the following System Sequence Diagram :

SSD for Use Case 1 : AddDoctor

SSD for Use Case 2 : AddNurse

SSD for Use Case 3 : AddSchedule

SSD for Use Case 4 : AddPatient

SSD for Use Case 5 : AddSpecialist

SSD for Use Case 6 : SearchDoctorSchedule

SSD for Use Case 7 : AddAppoitnment

SSD for Use Case 8 : SearchAppointment

SSD for Use Case 9 : AddDoctorSchedule

2.

Functional Requirements The functional requirements of this system will be specified in the expanded use case which has clearly stated all about how the transformation of inputs and outputs is achieved.

Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse want to enter new doctors information 2. The nurse input the new doctor information to the system Alternatives course of Events (none)

AddDoctor To allow the addition of new doctor Nurse (none)

System Response

3. The system add and save all of the data of the new doctor

Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. A new nurse come to the clinic 2. The other nurse verify the

AddNurse To allow the addition of new nurse Nurse (none)

System Response

qualification of the nurse 3. The nurse add the new nurse data into the system Alternatives course of Events Line 3 : If the new nurse cant fulfill the qualification, then the addition process is terminated. 4. The system add and save the data of the new nurse

Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse want to add a new schedule 2. The nurse enters the new schedule into the system Alternatives course of Events (none)

AddSchedule To allow the addition of new schedule Nurse (none)

System Response

3. The system add and save the new schedule

Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. A new patient come to the clinic 2. The nurse asking for some

AddPatient To allow the addition of new patient Nurse Patient

System Response

information 3. The nurse enter the informations given by the patient Alternatives course of Events Line 3 : If the patient has been registered before, then the addition process is terminated. 4. The system add and save the data of the new patient

Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse wants to add new specialist 2. The nurse enters the new specialist to the system Alternatives course of Events (none)

AddSpecialist To allow the addition of new specialist Nurse (none)

System Response

3. The system add and save the new specialist

Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse wants to search for the schedule of a particular doctor 2. The nurse enter the name of the doctor Alternatives course of Events

SearchSchedule To allow the searching process of a schedule Nurse (none)

System Response

3. The system search for the schedule and display the schedule

Line 2 : If the doctor is not available, then the display process will terminated.

Use Case Name Goal in Context Primary Actor Secondary Actor Typical Course of Events Actor Action 1. A new patient calls or comes to make an appointment with a particular doctor 2. The nurse ask for a patient ID 3. The patient give the patient ID 4. The nurse enters the patient ID

AddAppointment To allow the addition of new appointment Nurse Patient

System Response

5. The system validate the patient number

6. The patient ask for the doctor that the patient want to see 7. The patient mention the name of the doctor 8. The patient enters the doctors name 10. The nurse inform the doctors 9. The system validate the doctors name and display the schedule

schedule and ask the patient which schedule do the patient want 11. The patient give choose the schedule 12. The nurse complete and confirm the appointment form 13. The patient agree and end the calls or leave Alternatives course of Events Line 4 : If the patient doesnt have a patientID, the the process is canceled, and the patient can be registered first. 14. The system add and save the appointment made

Line 8 : If the doctor is not exist, then the patient may change the doctor, or process will be terminated Line 13 : If the patient doesnt agree, then the process will be terminated

Use Case Name Goal in Context

SearchAppointment To allow the searching process of an appointment

Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse want to search for a particular appointment 2. The nurse enter the appointment number

Nurse (none)

System Response

3. The system validate the appointment number 4. The system display the appointment detail

Alternatives course of Events Line 3 : If the appointment number is not valid, then the display process will be terminated.

Use Case Name Goal in Context

AddDoctorSchedule To allow the addition a schedule of a particular docto

Primary Actor Secondary Actor Typical Course of Events Actor Action 1. The nurse want to add a schedule for a

Nurse (none)

System Response

particular doctor 2. The nurse choose the doctor 4. The nurse enter the data Alternatives course of Events Line 2 : If the doctor is not available, terminate the process 3. The system serach for the doctor 5. The system add and save the schedule

3.

Non-Functional Requirements

3.1 External User Interface Requirements This system must be used a GUI or Graphical User Interface in order to make it easier for the user to understand in using this system. The function keys which is available on each screen will be made as convenient as it can be. The function keys will also completed with a short explanation about the function itself. Beside that, every screen is also completed with the help functions in order to give a quick help to the user.

3.2 Performance Requirements The performance requirements of this system is described as follows : 4. This system must give responses in 1 second after the command is inputed. 5. The system must have the capacity of thousands record data. 6. The user-interface screen must be able to respond within 5 seocnds.

3.3 Design Constraints 3.3.1 Standard Compliance The regulation in the clinic right now is that the data of each patient must be keep forever. This means that the system must be able to keep a lot amount of data. This is resulting in the Database choosing process. The database that we use must be able to hold quite much data.

3.3.2 Hardware Limitation For thr hardware limitation, the system will need the memory of minimal 128 MB to make the system work optimally.

3.4 Quality Attributes 3.4.1 Availability Regarding the availability of the system, there are several requirements that particular attention must be paid to quality aspect : 1. This system must always be available during the work hours which is from 9 a.m to 9 p.m. 2. The system will stop working only when the system is being shutted down when the work hours is finished.

3.4.2 Security Regarding the security of the system, there are several requirements that particular attention must be paid to quality aspect : 1. Only nurse of the clinic may access the system 2. The access rights of the nurse is granted by the highest authorization on the clinic and transformed to the system in the form of account in the system. 3. Any modification for the database must be synchronized and done only by the adminisrator of the system.

3.4.3 Portability Regarding the portability of the system, there are several requirements that particular attention must be paid to quality aspect : 1. The system must be made compatible with the Windows environment from the version of Windows 7 and upward and either 32-bits or 64bits. 2. The system must be made compatible with the Pentium 4 processors and upward.

3.4.4 Maintainability Regarding the maintainability of the system, there are several requirements that particular attention muste be paid to quality aspect : 1. The system must provide the capability of back-up data 2. The system must keep a log of all errors.

REFERENCES

Pfleeger, Shari Lawrence. & Atlee, Joanne M. (2010). Software Engineering (4th.ed.). New Jersey : Pearson.