Computer System For A Pet Store Computer Science Essay

Published:

KU Pets - a private clinic for pets - has decided to implement a new centralized database to overcome the issues of sharing information between all the other branches from UK. In order to set up this new system, the DSDM Atern methodology was chosen. By adopting this framework, it will be guaranteed that there will be no compromise on time, quality and cost but it also be imperative the user involvement. The system will be broken down into increments, each increment developed iteratively and every piece of work will start from baseline requirements at a high level. In order to align to the real business needs of the private clinic, all the changes throughout the development are reversible and even encouraged as long as they are clearly documented.

The strategic goal of our clinic is to eliminate the current problems they have, regarding the share of information and substitute it with a more reliable system that provides communication facilities and is easy to use by the clinic staff and the pet owner. DSDM offers an on track solution in term of money and costs and this is the main reason is one of the best approaches.

Project Plan

First-cut estimates of effort and time (for the assignment):

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

I will divide my assignment into a series of tasks, each of them with certain durations. This scheduling will be explained better in the following Gantt Diagram. I will start by studying DSDM principles and also creating the project plan. Each stage necessary in the project is given a certain period of time which will be recorded in the Timebox planning and in the Gantt diagramming as well. In addition to the research done about DSDM and the tools needed, the documentation part is also prepared in parallel. I chose this approach for justifying my first cut estimates of time because is the most intuitive and easy to follow. Each step is necessary to take in order to reach the final result. Moreover, most of them depend on the executions of the previous ones, but in the final stages some of the activities can be elaborated in parallel (e.g. finalize use- case diagram, finalize architecture, implement functional changes).

Figure : Project Gantt diagram:

gantt2.JPG

Figure : Timebox planning:

timeboxe planning final.JPG

I chose to divide my assignment into timeboxes as to make sure that every feature and document will be delivered in time. Each timebox is composed of different phases that will allow me to make sure that every aspect of my project is taken into consideration or even maybe changed. Moreover I have to review every step of the way otherwise the DSDM Atern framework won't have the expected benefits.

A timebox is composed of five stages, and all of them must be respected and applied accordingly, as each of them has a predefined scope. Figure 3 presents the theoretical framework of a timebox with its components: Kick Off, Investigation, Refinement, Consolidation and Close Out. The core stages of a timebox (Investigation, Refinement, and Consolidation) propose a certain structure of analysis that guarantees good results. All these steps (Identify, Plan, Evolve, and Review) must be accomplished in order to obtain effective deliverables.

Figure : Timebox phases: (Dr Islam slides, 2011)

Figure 4: Timeboxing stages (Unity information systems, Timebox manager):

All the iterations needed in my assignment (Figure 2) will have a bigger impact if I also categorize them by the stages of the timebox.

Figure 5: Timeboxes explained by stages:

timeboxes by stage.JPG

Prototypes to be developed and the classes of users to be involved in their development:

The prioritised requirements after the kick-off workshop are:

KU Pets need to:

Register pet owners. (M)

Input appointment details (M)

List all appointments for the coming week. (S)

Provide access to a central database via the Internet. (M)

Input pet details. (M)

Input staff information. (S)

List all staff at a particular clinic. (S)

Report on historical appointments (C)

Link payment to insurance company details. (C)

According to their type and functionality these requirements can be grouped in different classes of users that will be involved in their development.

Figure 6: Prototypes:

Requirements

Prototype

Type

User class

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

1

Prototype 1

User interface

System admin, secretaries

2,5,6

Prototype 2

User interface

System admin, secretaries, nurses

3,7

Prototype 3

Functional

System admin, secretaries, nurses, vets

4

Prototype 4

Functional

System admin

8

Prototype 5

Functional

System admin, secretaries

9

Prototype 6

Functional

System admin, secretaries

Prototype 1: This prototype will be strictly related to the Pet_Owner table from the class diagram. The user (that can be the secretary or maybe the system admin) will be able to click a button called "create user" and then they will be prompted with an input user form that will ask for more details of the pet owners. After the details will satisfy the form validation, they will be submitted and the new pet owner will be created into the system.

Prototype 2: Prototype number 2 will involve three tables: Appointments, Pets and Staff. At this stage the system admin, the secretary or the nurses will fill in with details the above mentioned tables from the database. The data provided by the users (system admin, nurses, secretaries) will be about pets, appointment details or other staff details.

Prototype 3: This prototype is more connected to a functional requirement because the user (represented by the vets, nurses, secretaries and system admin) will be able to query the database. The information wanted will come from the Appointments and Staff tables or maybe a join between these two. The result of the staff's query will be stored in a new table.

Prototype 4: This prototype is the core functionality and the reason we implemented this new system. The information hold by each clinic will be shared over the internet using HTML dynamic pages, XML files and JavaScript so that all UK clinics will have access to this information. The new system will proposed a centralized web server for sharing the information between the clinics with the possibility to be extended into a cloud if the clinic decides to further extend.

Prototype 5: By querying the Pets or the Appointments table, the user (system admin, secretaries) should be able to find the previous appointments for a pet. This will be an important issue as the recovery of previous information and also its adaptation to the new system is very sensitive. This 'migration' of data will receive enough consideration.

Prototype 6: The prototype number 6 offers an important functionality for the final user (system admin, secretary) and involves the Pet Owner and Appointments tables. When the pet owner wants to pay for the consultation, the system automatically links his payment with the insurance company that provided the pet's care.

In Figure 7 is presented the initial class diagram, with the minimum of information, provided by the initial case study. As we haven't been provided with enough information this is just the first draft of the class diagram that gives the minimum information about the functionality of the system. Therefore no methods or multiplicity will appear in Figure 7.

Figure 7: Class diagram (done in Jude Community, UML tool):

Class Initial.png

The business processes that will be supported by the proposed system along with their information requirements

All the information systems that we build nowadays must adopt a business process approach (Penadés and Borges, 2005). Regarding the KU clinic system, the main business process is represented by the actions taken by the pet owner. The pet owners have an insurance for which they pay instalments and this insurance pays for the treatment of their pet in case of a problem. Furthermore the insurance company will pay the clinic for the services provided, and the clinic manager will pay its veterinary doctors and the staff. This chain is represented in the class diagram (Figure 5), but only from the interactions that take place inside the clinic. In addition to the vets, the clinic also has to pay its staff represented by the system admin, secretaries, and nurses. In the class diagram the only assumption made is the fact that there can be only one manager per clinic. The activities supported by our proposed system have to be interconnected (e.g. the payment system provided by the information system of the clinic has to be in agreement with that of the insurance company) building the context of the overall process.

The classes of users impacted by the development and introduction of the proposed system

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

The users impacted by this new system come from different backgrounds. Therefore their work processes will suffer significant adjustments and we have to take these into consideration. The users of the system (secretaries, nurses, vets, system admin) have to feel comfortable using the new system therefore workshops will be conducted during the system's development. Respecting the DSDM Atern principle the user involvement is highly important therefore all the workshops will also involve at least two of the final users. In this case the Business Ambassador will be one of the vets, the secretary or even one of the nurses. Moreover the non functional requirements must be well documented even if the DSDM practice does not involve too much work done up front. But taken into consideration the fact that the final customer is not necessarily an IT person the training conducted shouldn't allow for more than 2 mistakes for a 5 minute period. Another aspect regarding the users impacted is the change management that had to be applied carefully by an authorised person and also some user interaction tests should be conducted. Documentation of the system will also be provided for easy referrals when problems are encountered.

The following use case diagram shows how the users will interact with the system at the initial configuration. The first step was to create the system boundaries and find out who are the actors and the use cases scenarios. This is the initial version before having the results of the workshop. Outside the system there are two other systems, the payment one and the centralized database that interact with our main system.

Figure 8: Use case diagram (designed in Jude Community, UML tool):

UseCase initial.png

Interfaces with other systems (human or automated)

The database system must have an interface with the payment system, also authorized by the insurance company. This is the way the clinic manager can monitor if the pet owner paid his debt and that all the prescription and consultations are also paid. In this category I can mention another payment system regarding the vets' wages. The best solution in this case I think would be to build a SAP (System Application & Products) program where all the doctors can report the time they spend in the clinic and according to this time they will be paid.

The clinic can buy a website hosting where to deploy all the information that needs to be shared across the UK clinic. This will be a more expensive solution but on the other hand extremely reliable. The information will come from the clinic SQL server.

Another solution viable in this case will be for the clinic to start thinking to future possibilities of extension and start developing a cloud. All the data will be stored in the clinic small servers but it will be much easier for the pet owners to have access to it. Seen from another point of view this would also be a secure solution since the clinic would have full control over it.

With the same idea of developing further the business in a few years, the clinic can start thinking about a complete architecture that would offer a new blue print of the business. In this case a possible solution can be TOGAF (The Open Group Application Framework).

The information from previous years also has to be imported into the new system. Appointments history for the last 2 years could be imported into the new database if there is any compatibility otherwise it would be registered manually.

I chose to list all this possible interfaces because I considered them to be the most important ones. However, the human interface remains the most important interface and this is a good argument to use DSDM Atern as this framework really focuses on people.

A common understanding of the technical architectures to be used during development (development environment) and implementation (target environment)

Development environment:

The database will be developed using MySQL Server 5.0. This is a cost effective solution, the distributers come up regularly with different updated version and is also easy to maintain.

Web development: for this aspect it will be used NetBeans as an IDE for building the actual web pages. The languages used will be: HTML, CSS (for the page layout), XML, Javascript and Java.

System architecture: It will be used 2 different laptops having the same specifications:

This is the laptop that will be used

Operating system: Windows 7

Processing speed: 2.53 GHz

Processor : Intel Core 2 Duo

RAM: 2 GB

The end user should be able to use the application on all browsers: Internet Explorer version 9, Mozilla Firefox version 4, Google Chrome and Opera. It will also be available a mobile platform. Tests will be conducted to check compatibility and eventual bugs.

Target environment:

The clinic needs a server machine on which to run the application. This server has to support the scripting languages (CSS, Javascript) and also interpret Java language. The application will be able to run and be shared across multiple client machines. The clinic's server should also act as a web server since it needs a DNS (Domain Name Server) and Email Server for the staff to communicate easier and also keep these aspects related to the clinic confidential. Another part of the target environment is the FTP (File Transfer Protocol) Server that will allow the staff to easily exchange files.

As I mentioned in the previous subchapter the final user will be able to access the application using different kinds of browsers: Internet Explorer, Mozilla Firefox, Opera, and Google Chrome.

The operating system has to be Windows XP, Vista or 7.

The process of delivering the data from the laptop where is produced to the desktop of the final user can be described with the following picture.

Figure 9: The target environment:

The developer's computer

The centralized server

Website hosting (maybe a cloud in the future)

The final user's computer

Due to the chosen development environment, the KU pet system will have enough flexibility in terms of usage. Moreover, the target environment supports this concept of flexibility by offering the opportunity for the system to adapt to possible new technologies. In my opinion cloud architecture should be adopted in the near future.

Change Control to include:

Process

Documentation

The DSDM Atern approach towards gathering the requirements requires just enough work done up front. This approach takes into account the fact that the user's wishes may change at some point and the work done must take them into consideration. Moreover there are not enough time and resources to work for the features wanted. At this point the DSDM framework offers a solution: everything increment is time bound and given a certain prioritisation. The MoSCoW prioritisation offers control over the process ensuring that what is mandatory for the system to work, will be included in the final result.

At this stage of the project we already have the 'must haves', 'should haves' and 'could haves'.

KU Pets need to:

Register pet owners. (M)

Input appointment details. (M)

List all appointments for the coming week. (S)

Provide access to a central database via the Internet. (M)

Input pet details. (M)

Input staff information. (S)

List all staff at a particular clinic. (S)

Report on historical appointments. (C)

Link payment to insurance company details. (C)

Attention should be paid to the 'must haves' without which the system wouldn't deliver any final result. The 'should haves' are also an important aspect of the project, therefore should be a balance between the number of the requirements and their priority. Having too many 'must haves', would just endanger the feature delivered at the end of the iteration. This situation should be avoided even if the client would want all the 'must haves'.

Keeping in mind that changes are vital for the well development of a project, we have to be aware that they require time and effort. Every iteration is important because after its completion, feedback can be provided and the features reviewed. Furthermore, if the timebox cannot be delivered within the agreed time and cost, the particular increment needs to be de-scoped or other sections need to be altered. Flexibility in terms of change and requirements development is the most important aspect that characterizes the DSDM Atern framework.

9. Functional prototype

Iteration 1 of the prototype "Register pet owners".

Figure 10: The home screen of the application, where the user chooses where to go in case he clicks on the "Pet Owners".

home_screen.JPG

The user will then be redirected to the Pet Owners table which can have some records or can be empty. Then the user clicks on "Add New User".

Figure 11: Add new owner:

screen2.JPG

The user is then redirected to a new page where they can input the details of the new pet owner and then they just have to click on the button for "Add new owner".

Figure 12: Create new owner:

screen3.JPG

After this stage a new user is created and appears in the log table. In the next section the user has the possibility to edit the details of a certain owner, add or delete owner.

Figure 10: Show the created user:

screen4.JPG

Control change

The prototype shown to the user is "Register Owner". In order to obtain their feedback and monitor the changes needed, a prototype review form was handed to the client to fill in.

Prototype Review Form1 (Register Pet Owners): (http://www.gantthead.com/templates/download.cfm?ID=6353)

Project Name:

KU Pets Veterinary System

Date:

22/03/2011

Iteration Number:

1

Reviewed by:

KU Vets Manager

Part 1: Presentation:

Check:

Comments:

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Overall Look and Feel

User friendly

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Overall Consistency

Is easy to scroll through it

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Overall Ease of Use

Is intuitive

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Menu bar

Simple to use

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Toolbar

Not very useful

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Title bar

Short and good coloristic

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Icons

Too many

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Controls

Not very intuitive

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Fonts

Easy to read

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Colors

Good combination of colors

Likes: I liked the fact that the prototype is easy to use and interpret, but some features lack the properties I really need.

Part 2: Navigation:

Check:

Comments:

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Conforms to User Work Flow

Good instructions that help the user know what they need to click in order to do a task

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Conforms to User Work Style

Every feature is intuitive

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Overall Organization

The color scheme and buttons are consistent, this will help the staff to get used to the system

Part 3: Functionality:

Check:

Comments:

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Meets Process Requirements

It does what was intended to do

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Meets Data Requirements

It provides the information we needed

C:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Satisfies Functional Scope

We can extend some features but the overall is good.

Part 4: Overall Feedback:

Other suggestions:

The overall look and feel is pretty good. One important aspect that has to be solved is the level of detail provided so far. For example for now we have the name and address on the same line and it would be better to have them split in different input fields: last name, first name, street name, street number, post code, city. This aspect would make our application easier to organize and read by the end user.

After we had a proper feedback from the end user some changes were requested by the manager. These are documented in the following Change Request Forms.

Change request form 1:

(http://www.gantthead.com/templates/download.cfm?ID=6353)

Project name: KU Pets Veterinary system Date: 23/03/2011

Project Manager: Dr. Islam Choudhury

Part 1: Change Request Overview

Request No:

1

Requestor Name:

KU Pets Manager

Requestor's Email:

t.smith@hotmail.com

Request Date:

23/03/2011

Type of change:

User interface: Input field split for the Register New Pet Owner prototype.

Reason for change:

To make Owner address and name details more organized and easy to enter for staff. It will also be easier to find in the database when we will query it to get the information needed.

Required by (date):

27/03/2011

Priority of change:

High

Part 2: Change description (detailed)

Change description:

Breaking down the "Address Field" in the pet owner details screen to have four different fields for street, street number, city and postcode instead of just one field for all. The same rule applies for the name, which will be divided in last name and first name.

Impact if not implemented:

Staff may miss out on certain details of the address if they are just entering it into one field. Querying the database having the address and name organized like this will be much more difficult.

Alternatives

No alternative, this is definitely the best approach for both sides: the user and the staff.

Part 3: Impact analysis

Impact on scope and/or deliverables

This change does not affect the scope of the project but it definitely has great impact on the time the project will be delivered. However this particular change must be implemented in accordance with the client's requirements as it makes it more organized and easy to enter and refer to an owner's address.

Impact on resources and/or quality

This change will make the quality of input better.

Impact on time and cost

The change will affect the time in which the product has to be delivered. However, change is always considered in a DSDM Atern project therefore we have enough provisions.

Impact on hardware/software

It will be necessary to build some new input fields and also validate them, therefore some more code to be written. No impact on hardware.

Risks

The validation of the fields may not work properly from the first attempt therefore some more testing could be needed. Therefore more resource involved and more time.

Part 4: Approval

Change resolution:

AcceptedC:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Denied

Elena Lepadatu Date: 23/03/2011

Signature

Change request form 2:

(http://www.gantthead.com/templates/download.cfm?ID=6353)

Project name: KU Pets Veterinary system Date: 25/03/2011

Project Manager: Dr. Islam Choudhury

Part 1: Change Request Overview

Request No:

2

Requestor Name:

KU Pets Manager

Requestor Email:

t.smith@hotmail.com

Request Date:

25/03/2011

Type of change:

Functional change of the system

Reason for change:

The manager thinks the system should have a new requirement "print out invoice for the pet owner" with a must have priority.

Required by (date):

30/03/2011

Priority of change:

High

Part 2: Change description (detailed)

Change description:

The system will be able to print out the invoice for the pet owner after the consultation has taken place.

Impact if not implemented:

The pet owner will not have a detailed explanation of the procedure and the cost of which of the features applied or even of solution or medicine used during the treatment.

Alternatives

The secretaries could email the pet owner with the detailed invoice and possible methods for paying it. In case he has any issues with it, he can print it and come with it in the clinic to ask for further information.

Part 3: Impact analysis

Impact on scope and/or deliverables

The requirements will need to be re-assessed. Since this change is a must priority in the MoSCoW scale, other factors such as deliverables, prioritization of the rest of the requirements and timeboxes will have to be reviewed, so as not to have too many 'must haves' requirements.

Impact on resources and/or quality

The quality of the services offered by the clinic will improve and the pet owners will be more satisfied having the invoice printed and handed in.

Impact on time and cost

This change will have an impact on the time spent in that specific timebox. The secretaries need to create first the document and verify it so there is no financial mistake before sending it to the printer and then handing it to the pet owner.

Impact on hardware/software

No impact

Risks

Other functionality of the system must be dropped or offered a different priority so we can implement this one.

Part 4: Approval

Change resolution:

AcceptedC:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Denied

Elena Lepadatu Date: 25/03/2010

Signature

Change request form 3:

(http://www.gantthead.com/templates/download.cfm?ID=6353)

Project name: KU Pets Veterinary system Date: 27/03/2010

Project Manager: Dr. Islam Choudhury

Part 1: Change Request Overview

Request No:

3

Requestor Name:

KU Pets Manager

Requestor's Email:

t.smith@hotmail.com

Request Date:

27/03/2010

Type of change:

Functional change of the system

Reason for change:

The manager of the clinic thinks that "List all appointments for the coming week" should be a 'must have' feature in the system even though it was originally prioritised as a 'should have'.

Required by (date):

05/04/2010

Priority of change:

High

Part 2: Change description (detailed)

Change description:

The system must be able to list all appointments for the coming week

Impact if not implemented:

It will be more difficult without this requirement for the staff admin, the secretaries and nurses to plan the next week's activities. It will be helpful to have a better organization within the clinic.

Alternatives

Instead all listing .all the appointment for the whole week, it can display the appointment daily, what happens the next day at the end of the current one.

Part 3: Impact analysis

Impact on scope and/or deliverables

The requirements will need to be re-assed. Since this change is a must to be implemented, other factors such as deliverables, prioritization of requirements and timeboxes will have to be reviewed.

Impact on resources and/or quality

The quality of the clinic in terms of planning, organizing and avoiding delays will be improved.

Impact on time and cost

Things will be better organized over time but at the begging we will have a longer timebox in which to implement this requirement.

Impact on hardware/software

This has an impact on the software since the database should successfully be able to handle the query and select appropriate fields from the database for the upcoming appointments.

Risks

We will have too many requirements with a 'must have' prioritization. Some other requirement/s will have to be dropped.

Part 4: Approval

Change resolution:

AcceptedC:\Users\Sasha\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\ISW5AVPD\MC900432530[1].png

Denied

Elena Lepadatu Date: 27/03/2010

Signature

10.1 Results of change 1:

After the changes have been documented, the class diagram will also be modified as follows (Figure 12). The "register Pet Owner "prototype changes as well, in order to comply with the new requirement. I implemented the initial change proposal, splitting the initial field in four different fields as this would be easier to use by the staff and also easier to register and afterwards query the database.

Changes in the prototype: the name and address fields have been changed according with the requests.

Figure 11: Prototype changed:

screen5.JPG

Figure 12: Class diagram after the change:

class_final.png

10.2 Results of change 2 and 3:

As mentioned in the change request we cannot have all the requirements of the system set up with a 'must have' priority. This would make our delivery on time and budget almost impossible. The timeboxes will be affected by these 2 new requirements that were approved to have a 'must have' priority on the MoSCoW scale: print out invoice for the owner and list all appointments for the coming week. In this scenario a viable solution is to change the status of the following requirements: "Report on historical appointments" and "link payment to insurance company details" to a 'won't have' priority. This change will allow us to change the 'should haves' such as 'Input staff information' and 'list all staff at a particular clinic' to a 'could have' priority so as to introduce the two approved changes as a 'must have'. In this way the system will fulfil at its maximum capabilities, providing real business needs for the KU Vets Clinics. A change will also be notice in the use case diagram presented in the next figure.

The new set of requirements is:

KU Pets need to:

1. Register pet owners. (M)

2. Input appointment details (M)

3. List all appointments for the coming week. (M)

4. Provide access to a central database via the Internet. (M)

5. Input pet details. (M)

6. Input staff information. (C)

7. List all staff at a particular clinic. (C)

8. Print invoice for the owner. (M)

Figure 13: Use Case Diagram after changes have been accepted:

UseCase final.png

Figure 14: Home screen changed for the functional prototype:

Change for functional prototype.JPG

Appendix:

Change request form:

Project name: KU Pets Veterinary system Date: 20/03/2011

Project Manager: Dr. Islam Choudhury

Section 1: Change Request Overview

Request No:

Requestor Name:

Requestor Email:

Request Date:

Type of change:

Reason for change:

Required by (date):

Priority of change:

Section 2: Change description (detailed)

Change description:

Impact if not implemented:

Alternatives

Section 3: Impact analysis

Impact on scope and/or deliverables

Impact on resources and/or quality

Impact on time and cost

Impact on hardware/software

Risks

Section 4: Approval

Change resolution:

Accepted

Denied

_________________________ __________________________

Signature Date:

Protype Review Form

Project Name:

<Project Name>

Date:

<MM/DD/YYYY>

Iteration Number:

< Number>

Reviewed by:

<Name>

Presentation

Chk:

Comments:

Overall Look and Feel

Overall Consistency

Overall Ease of Use

Menu bar

Toolbar

Title bar

Icons

Controls

Mnemonics

Fonts

Colors

Likes:

Suggestions/Objections:

Navigation

Chk:

Comments:

Conforms to User Work Flow

Conforms to User Work Style

Overall Organization

Functionality

Chk:

Comments:

Meets Process Requirements

Meets Data Requirements

Satisfies Functional Scope

Part 4: Overall Feedback:

Other suggestions: