Lvl 1 Group Title # Comments in Each Lvl 1 Lvl 1a Group Title (not all Sum # of

Group branches of the tree have Comments in Each

to be of equal depth) Lvl 1a Group

Easy to Clean Up 5
Simplicity 7
Low Maintenance 6
Cost / Perceived Value 4
Durable 6 Robustness 8
Reliable 3
Safety 7
Tactile 2 Style 13
Friendly Toys 5
Appearance 9
Sounds 3
Natural Components 2
Game / Puzzle Quality 4
Educational 10
Creativity / Self-Experssio 7
Grown-Up Play 4
Active toys 7
Completeness 2
Maintenance 3
Multiplayer 7
Indoor Safe Toy 2
Simplicity 4

109
Group Lvl 2 Titles Sum # of Comments in Group Lvl 3 Titles (aka Area Sum # of Comments
Each Lvl 2 Group Titles since they are at the top in Each Lvl 3 Group
level)

Ease of Use 18 Quality of Toy 38

How Well Built 20

1st Impression 21 Look 18

Learning
Exploration
25 25

25 Safety 25
cautious

109 109
Patient Search for Medical History

Initial Conditions
1. The user should be login to the system

User (Patient)
The patient clicks the button to view the past medical history

Ending Conditions
1. The user in the login state and can view more details related to that particular appointment history.
 System (KEP)

The system shall get the user identification

The system shall get the user medical history

The system shall return the medical history data in data structure format
The system shall display the medical history to the patient

ated to that particular appointment history.

Medical History

Patient medical History fetched from the database

Patient give feedback to Doctor

Initial Conditions
1. The user should be login to the system

User (Patient)
The patient clicks the button to give the feedback to doctor
Patient will fill the form and press submit

Ending Conditions
1. The user in the login state
System (KEP)

The system shall get the user identification

The system shall save the form details with respect to doctors

The system shall display the success/ error message to the patient
Doctor

Patient medical appointment data saved in the database for this doctor
Doctor Search For the past appointments

Initial Conditions
1. The Doctor should be login to the system

User (Doctor)
The Doctor clicks the button to view the past appointment history

Ending Conditions
1. The Doctor in the login state and can view more details related to that particular appointment history.
 System (KEP)

The system shall get the user identification

The system shall get the user appointment history

The system shall return the appointment history data in data structure format
The system shall display the appointment history to the doctor

elated to that particular appointment history.

Medical History

Doctors appointment History fetched from the database

Index Originating Requirement
DR.1 The system shall saves the users details to database
DR.2 The system shall display one particular details of the patient medical history
DR.3 The system shall ask for the additional special requirements for the appointment
DR.4 The system shall get the the user details from the user
DR.5 The System shall ask for the more details of the patient
DR.6 The system shall ask for the star rating for the appoinment
DR.7 The System shall generate the pdf and excel reports
DR.8 The system shall collect the payment in several ways
DR.9 The system shall remove the user from database in many ways
DR.10 The system shall display current hours appointments
Abstract Function Name Source OR
Save OR.1
Display OR.4
Ask OR.7
Get OR.11
Ask OR.14
Rating OR.15
Report OR.17
Collect OR.19
Remove OR.26
Display OR.30
Patient Management system Scheduling Management system
The system shall assign the The system shall register the patients
bed/room to the patient appointment with the doctor

Small Room App

Medium Room Physical
Large Room Website
Single Bed
Double Bed
Semi Private
Private Room

The system shall register the

patients appoitment with the The system shall return the medical
doctor history data in data structure format

Form Array
Call String
SMS Hashtable
Map
List

The system shall be able to

cancel the patients appoitment The system shall manage the users
due to particular reasons

Form Physical
Call Website
SMS App
Cancel Button on Web/Mobile

The system shall generate the The system shall update the profiles of
medical reports for the patients the users

PDF Website
Excel App
Doctor Management system Attendance Management system
The system shall give the doctor The system shall mark the attendence
to view its all past appointments of the users

Array Card
String Finger
Hashtable System login
Map Face Recognization
List

The system shall save the form The system shall get the user medical
details with respect to doctors history

Form Array
Call String
SMS Hashtable
Map
List

The system shall mark the appoitment

The system shall register the user
completed

Form Form
Call Complete Button on Web/Mobile
SMS

The system shall collect the The system shall manage the finance
payments for the appoitments of the hospital

Physical Physical
Website Website
App App
Registration Management System
The system shall get the user
identification for loggin to the user

Array
String
Hashtable
Map
List

The system shall get the user

identification

Form
Call
SMS

The system shall give the feedback to

the doctor
Form

The system shall return the appointment

history data in data structure format

Array
String
Hashtable
Map
List
Index Originating Requirement
OR.1 The system shall get the user identification
OR.2 The system shall get the user medical history
OR.3 The system shall return the medical history data in data structure format
OR.4 The system shall display the medical history to the patient
OR.5 The system shall save the form details with respect to doctors
OR.6 The system shall display the success/ error message to the patient
OR.7 The system shal register the patients appoitment with the doctor
OR.8 The system shall be able to cancel the patients appoitment due to particular reasons
OR.9 The system shall manage the users
OR.10 The system shall mark the attendence of the users
OR.11 The system shall register the users
OR.12 The system shall mark the appoitment completed
OR.13 The system shall give the doctor to view its all past appoinments
OR.14 The system shall gives the patients family to view the patient relevant details
OR.15 The system shall give the feedback to the doctor
OR.16 The system shall assign the bed/room to the patient
OR.17 The system shall generate the medical reports for the patients
OR.18 The system shall update the profiles of the users
OR.19 The system shall collect the payments for the appoitments
OR.20 The system shall manage the finance of the hospital
OR.21 The system shall get the user appointment history
OR.22 The system shall return the appointment history data in data structure format
OR.23 The system shall display the appointment history to the doctor
OR.24 The system shall create the users
OR.25 The system shall update the users
OR.26 The system shall remove the users
OR.27 The system shall manage the resources
OR.28 The system shall manage the attendences of the users
OR.29 The system shall display all the present users
OR.30 The system shall display all the todays appointments with details
Abstract Function Name
Identify
Fetch
History
Display
Saves
Message
Register
Cancel
Manage
Mark
Register
Mark
View
Details
Feedback
Assign
Reports
Update
Payments
Finance
Fetch
History
Display
Create
Update
Remove
Manage
Manage
Display
Display
The system shall assign the bed/room to the patient

Small Room
Medium Room
Large Room
Single Bed
Double Bed
Semi Private
Private Room
The system shall return the appointment history data in data structure format

Array
String
Hashtable
Map
List
The system shall mark the attendence of the users

Card
Finger
System login
Appearance
The system shall return the Medical history data in data structure format

Array
String
Hashtable
Map
List
Goals

System must reserve the patient’s appointment with the doctor.

Make the system easy to search past appointments with doctors
Make the system easy to find the medical history
Patient must easily give the feedback to Doctors appointment
Make the system easy for doctor to accept or reject the appointment
Make the system Safe for the users
Make the system performance fast for the users
System must be able to register user account easily
Doctor should easily view its past and future appointements
Question1

Does patient complete the profile in the system?

Does the patient have laready appointments history?

Does the patient successfully completed the appointment?
Question 2 Data Collection

How long it will take to get the confirmation on the appointment? Questionnaire
Questionnaire
How long it will take to get the patients history? Questionnaire
What are the criteria for giving the feedback to doctor? Questionnaire
Questionnaire
Questionnaire
Questionnaire
Questionnaire
Questionnaire
Ideal Matric (Question 1) Approximate matric (Question 1) Ideal Matric (Question 2)

Partial Answer: Yes or no No substitute. Within five minutes

Partial Answer: Yes or no No substitute. Within five seconds

Partial Answer: Yes or no No substitute. understanding
Approximate matric (Question 2)

Within an hour.

Within five minutes

timelines
 Project Title
Kidney Exchange Program (KEP)
Developed by 1
Imran Ahmed Khan 2
Last Updated 3
10/26/2020 4
5
6
7
Relationships 8
++ Strong Positive 9
+ Positive 10
Neutral, Not Applicable 11
x Negative 12
xx Strong Negative 13
14
15
16
17
18
19
20
21
22
23
24
25
26
ID 1
Algorithm
Analysis

Relative
Importa
nce
Performa Direction of Change ↑ ↓ ↑
ID Full Attri Short Name 2.60
1 Patients can make appointment(s) easily on KEP 0.40 ++
2 Doctors can accpet the appointment 0.40 +
3 Patients can search for medical history 0.25 +
4 Doctors can search for appointment history 0.25 +
5 Patients can find the donor for kidney exchange 0.70 ++
6 Users can easily mark the attendence 0.25 X
 7 Patients can search for the appointment history 0.25 +
8 Patients can provide feedback to doctor 0.10 +
9
10
11
12
ompetitor Legend Measurement Units Algorith
B eHospital Systems Good
C ERP4Health Bad
D Affinity ERP Medium
E SoftClinic Worst
F ModDoc Best
Targets Best
Imputed Importance 4
Technical Difficulty (1 Low, 5 High) 5
Estimated Cost (1 Low, 5 High) 4
 ↑

+
++
Cost
Analysis

X
X

XX
++
++
Storage
Analysis

X
X

XX
++
++
Performanc
e Analysis

+
+

X
++
++
Design

5
Features

+
+

X
++
++
Test

6
Execution

X
X

XX
++
++
code

7
Structure

X
X
++
++
++
++
Human

8
interaction

++
9
Downtime

+
+
+

X
++
++
Time to

10
Develop

11
 + ++ ++ X X ++ ++ +
+ + + + + + + +

requiremeDatabaseAlgorith Interface Test CasCode RevHCI Server mCoding S

5000$ Good Good 3 out of 15 Good Good zero 1 year
2000$ Bad Bad 4 out of 14 Bad Bad zero 2 year
1542$ Medium Best 5 out of 45 Best Best zero 3 year
5421$ Worst Good 6 out of 51 Good Excellent1 time a 4 year
4588$ Best Best 7 out of 100 Best Best zero 5 year
2500$ Best Best 8 out of 150 ExcellentExcellentzero 1.5 years
1 3 3 3 3 3 4 1 4
4 3 4 4 3 2 3 4 4
5 4 3 2 4 5 4 4 5
12 13 14 15 16 17 18 19 20 21
0 0 0 0 0
22 23 24 25 26 Engineering Characteristics

Customer Perception / Performance Scores

Normalized & Unweighted
A(low) A(high) A(target) B C
3 4 5 3 4
2 4 5 4 5
2 5 5 4 5
4 5 5 4 5
4 5 5 4 4
2 5 5 2 5
 1 5 5 4 5
4 5 5 4 5

0 0 0 0 0
/ Performance Scores
Normalized & Weighted
A(low) A(high) A(target) B C
3 4 5 3 4
2 4 5 5 4
2 5 5 4 5
4 5 5 4 5
4 5 5 3 5
2 5 5 4 5
1 5 5 1 5
4 5 5 4 5
Interface Trace Matrix Excerpt : Patient Management system
Patient Management system Scheduling Management system Doctor Management system
Provided to Provided to
Provided to
Provided to
Provided to

Provided to Provided to
ement system Login Scheduling
yes yes
yes no
yes no
yes no
yes no
yes no
Appointment
yes
yes
yes
no
no
no
Last Updated Last Updated By
6/21/2020 Barbara
6/22/2020 Imran
6/23/2020 Barbara
6/24/2020 Barbara
6/28/2020 Imran
6/29/2020 Imran
Interface Champ.
Barbara
Scot
Scot
Imran
Scot
Imran
Est. Update Due Date Actual Due Date
7/21/2020 8/21/2020
7/22/2020 8/22/2020
7/23/2020 8/23/2020
7/24/2020 8/24/2020
7/25/2020 8/25/2020
7/26/2020 8/26/2020
Row #
1
2
3
4
5
6
Patient Management system
Patient registers for Appointment
Patient search for Appointment
Patient search for his/her medical history
Patient gives feedback to Doctor
Patient registers on system
Patient search for medical history
Combination Table

The system shall return the appointment history The system shall mark the
data in data structure format attendence of the users

Array Card
String Finger
Hashtable System login
Map Appearance

Combine Concept

The system shall return the appointment history The system shall mark the
data in data structure format attendence of the users

Array and Card

String and Finger
Hashtable and System login
Map and Appearance
Test # Test Method Test Facilities
Test Procedure: Patient finds for the System is ready, Appointment module is
TP.1
appointment integrated
Test Procedure: Patient searches for the System is ready, history module is
TP.2
past appointments integrated
Test Procedure: Doctor Take the System is ready, Appointment module is
TP.3
Appointment integrated
Entry Condition Exit Condition

Completed protype with all modules Found the appointment

Completed protype with all modules Found the history of past appointments

Completed protype with all modules Appointment is scheduled

Req # Requirement Abstract Function Name Test # Test Method

The system shall mark the Test Procedure: Staff marks

OR.10 attandence of the users Mark TP.4 the attandence

The system shall register the Test Procedure: User register

OR.11 Register TP.5
users into the system

Test Procedure: Patient give

The system shall give the
OR.15 Feedback TP.6 the feedback to Doctor after
feedback to the doctor
Appointment
Varificaiton on
Method (A,I,D,T) Test Facilities Entry Condition Exit Condition
System is ready,
Completed protype
I hardware is associated with all modules Attandence is marked
with system

System is ready,
Completed protype
I Registration module is User is registered
with all modules
integrated

System is ready,
Completed protype Feedback is given to the
I Feedback module is
with all modules Doctor
integrated
 OR.1 OR.2 OR.3 OR.4 OR.5 OR.6 OR.7 OR.8 OR.9

TP.1 X
TP.2
TP.3
TP.4
TP.5
TP.6
OR.10 OR.11 OR.12 OR.13 OR.14 OR.15 OR.16 OR.17 OR.18 OR.19

X
X
X
X
OR.20 OR.21 OR.22 OR.23 OR.24 OR.25 OR.26 OR.27 OR.28 OR.29

X X
X

X
OR.30
 Risk Priority Number
Failure Mode # Subsystem Failure Mode
(RPN)
Patient
Appoitnemnt module is
F.1 Management down for error failure
32
system

Scheduling Scheduling of the

F.2 Management appointment failed 36
system due to crash

Doctor Doctor not getting the

F.3 Management appointments 21
system correctly

Attendance
Attandence reader got
F.4 Management failed
18
system

Attendance Attandence Not

F.5 Management marked due to the 15
system service failure

Scheduling Appointment is not

F.6 Management scheduled due to the 36
system service failure

Risk Priority Number (RPN) Definition Table

Likelihood

10 10 20 30
9 9 18 27
8 8 16 24
7 7 14 21
6 6 12 18
5 5 10 15
4 4 8 12
3 3 6 9
2 2 4 6
1 1 2 3
1 2 3
Corrective Action

Test the module before going to the

production, and varified.

Robust the system by testing the

code of the scheduling before going
towards the production phase
Risk Criticality Ranges

Increase the robustness of the

system by testing good in testing
phase and varified this module

the hardware have to cater all the

cases with increasing the
robustness plus new hardware have
to be in the backup
33-40
There should be test cases run on
the hardware associated with the
system 12-32

Robust the system by testing the

code of the scheduling before going
towards the production phase
6-10
3-5
1-2

9
8
7
6
5
4
3
2
40 1
36
32
28
24
20
16
12
8 Severity
4 4
4 Severity 3
2
1
High Risk

Medium High Risk

Medium Risk
Medium Low Risk
Low Risk

Occurs greater than once a week, Occurs in 5-10% of the operations

Occurs no more than once a week
Occurs between to once every 2 weeks to once every 3 months
Occurs less than once every 3 months
Occurs less than once every 6 months
Occurs less than once every 7 months
Occurs less than once every 8 months
Occurs less than once every 10 months
Occurs less than once every 1 year

Cost is more than 20% of the total budget, Requires more than 2 weeks to address, Performance is adversely affected by great
Cost is 10%-20% of the total budget, Requires 1-2 weeks to address, Performance is adversely affected by 10-20%, no harm to
Cost is 5%-10% of the total budget, Requires 1-6 days to address, Performance is adversely affected by 5-10%, no harm to a pe
Cost is less than 5% of the total budget, Requires less than 1 day to address, Performance is adversely affected by less than 5%
Features Criteria Usefull User Interface (Apperance) Performance

Medical History Search 5 5 5

Past Appointment Search 4 4 5
Schedule Appointment 5 3 4
Mark Appointment Completed 4 5 5
Manage All Users 3 5 3
Give Feedback to Doctor 3 3 4
Easiness Cost Usability Weight (1-5) Total Weightage Total

4 4 1 5 24 120
5 5 3 3 26 78
3 5 5 5 25 125
4 4 1 4 23 92
2 5 2 3 20 60
5 2 3 4 20 80

Total 138 555

 Patient Management system Scheduling Management system
Patient (Operator)

Patient do the login to

the system
Info. Event ("Login
System")

Patient search for medical history

YES
NO (Goto "Login System")
Info. Event ("Search History")
Patient register/Schedule appointment for
doctor
Info. Event ("Register Appointment")
Doctor Management system Attendance Management system State

Login

Login, HistoryFound

Doctor take the appointment/ Login,

Schedule AppointmentTake

Info. Event ("Accept Appointment")

Clinical staff mark the attendance Login,

AttendenceMarked
Time
Target

1 Second

2 Second

2 Second

2 Second

3 Second
 Login Login, HistoryFound Login, AppointmentTake

Login
Login, HistoryFound Login System
Login,
AppointmentTake Search History
Login,
AttendenceMarked Accept Appointment
Login, AttendenceMarked
 System must reserve the
patient’s appointment with the

0.075
doctor.

0.25
Make the system easy to
search past appointments with

0.075
0.25
doctors
0.3
Make the system easy to find

0.075
0.25
the medical history

Patient must easily give the

Make the system easy for Patient

feedback to Doctors

0.075
0.25
appointment
system

Patient
safe for

Make the system Safe for the

Make the

0.2
1
users
0.2
fast

Make the system performance

system
Make the

0.1
fast for the users
0.1

1
Analytical Hierarchy Process

Doctor should easily view its

past and future

0.18
0.6

appointements
0.3

Make the system easy for

easy for Doctor

doctor to accept or reject the

Make the system

appointment
0.12
0.4
 Other
System must be able to
register user account easily

0.1

1
1
 [1 - (1 - Pd)(1-Ps P

1 - (1 - Pd)(1-Ps Pci Pcc) =0.5

Pd = 0.5 OR

Ps = 0.1
 [1 - (1 - Pd)(1-Ps Pci Pcc)] Psh = 1

i Pcc) =0.5
AND Psh = 0.5

OR
Ps Pci Pcc = 0.5

AND Pci = 0.1 Pcc = 0.8

Seq No Task Name Start Date End Date Status Duration
1 Literature Review 25-9-2020 27-9-2020 Completed 2
2 Software Requirement Document 27-9-2020 30-9-2020 Completed 3
3 Software Design Document 1/10/2020 5/10/2020 Completed 5
Logical Design
4 UML Diagrams 6/10/2020 10/10/2020 Completed 5
Physical Design
5 ERD 11/10/2020 15/10/2020 Completed 5
6 Database Design 16/10/2020 20/10/2020 Completed 5
7 GUI 21/10/2020 30/10/2020 Completed 10
Coding
8 Front End 1/11/2020 10/11/2020 Completed 10
9 Back End 11/11/2020 20/11/2020 Completed 10
Testing
10 Alpha Testing 21/11/2020 25/11/2020 Completed 5
11 Beta Testing 26/11/2020 30/11/2020 Completed 5
12 Report Writing 1/12/2020 15/12/2020 In progress 15
13 Project Deployment 16/12/2020 20/12/2020 Not Start 5
Assigned To Deliverable
Imran Khan Past work compiled in a document
Imran Khan All requirements gathered in a document
Imran Khan All requirements are converted to design

Imran Khan UML diagrams

Imran Khan Entity relationship diagram

Imran Khan Database schema and scripts
Imran Khan Graphical interface designs

Imran Khan Front end screens

Imran Khan Back end screens

Imran Khan Alpha testing of the KEP application

Imran Khan Beta testing of the KEP application
Imran Khan Report writing for the whole project
Imran Khan Project live on the server.