NivaarExam PrepOfficial exam papers ↗

19-Soft-A7 Software Development Process · Undated paper

Question 4 of 8: UML Modelling of a Hospital Patient Registration System

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

National Exams — 04-Soft-A7, Software Process (closed book, two aid sheets, 3 hours). Notes on the paper: eight questions constitute the exam paper; answer FIVE of the eight, and the first FIVE as they appear in the answer book are marked. Each question is of equal value, and each sub-question within a question is of equal value (shown here as 20 marks per question on a 100-mark basis) — this solution answers all eight as a full study resource. Question 3 asks for a Gantt/timeline schedule for a personal address-book application; Question 4 introduces a hospital patient-registration system that Question 5's Function-Point estimate builds on.

Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 2 (Software Processes), Ch. 3 (Agile Software Development), Ch. 5 (System Modeling), Ch. 8–9 (Testing), Ch. 22–23 (Project Management, Configuration Management), Ch. 9 (Software Evolution/Maintenance); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 2–3 (Process Models, Agile), Ch. 23–24 (Project Management, Risk Management), Ch. 29 (Function-Point sizing), Ch. 22 (SQA), Ch. 24 (Software Configuration Management); IEEE/ISO 12207 (Software Life Cycle Processes); SWEBOK v4 (Software Engineering Process, Software Configuration Management, Software Maintenance KAs).

Question 4: UML Modelling of a Hospital Patient Registration System (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part a) — use-case diagram, entry/exit conditions, and quality requirements. The primary actor is the Hospital Clerk, who registers both outpatients and inpatients; the Doctor/Department actor receives patients once they are dispatched. Three use cases are modelled: Register Outpatient & Schedule Visit (log an outpatient and their appointment, then dispatch to the relevant doctor), Register Inpatient & Allocate Bed (log a new inpatient and assign an available bed), and Dispatch to Department (route a registered, bed-assigned inpatient to the correct department).

Patient Registration System — Use-Case DiagramPatient Registration SystemHospitalClerkDoctor /DepartmentRegister Outpatient& Schedule VisitRegister Inpatient& Allocate BedDispatch toDepartment
Figure 3 — Use-case diagram: the Hospital Clerk participates in Register Outpatient & Schedule Visit and Register Inpatient & Allocate Bed; the Doctor/Department participates in Register Inpatient & Allocate Bed and Dispatch to Department.
Use caseEntry conditionExit conditionQuality requirement
Register Outpatient & Schedule VisitAn outpatient presents at the registration desk with a scheduled or walk-in appointment.Patient is logged with a unique record and dispatched to the requested doctor/facility.Registration must complete within 3 minutes of the clerk starting entry (availability/throughput requirement).
Register Inpatient & Allocate BedA new inpatient requires admission and no bed has yet been assigned.Patient is logged, a specific available bed is reserved, and status becomes "Admitted."No two inpatients may ever be allocated the same bed concurrently (data-integrity/safety requirement).
Dispatch to DepartmentA registered, bed-assigned inpatient (or a scheduled outpatient) is ready to be routed.Patient's location/destination department is recorded and the department is notified.The receiving department must be notified within 60 seconds of dispatch (safety-relevant latency requirement).

Part b) — class diagram for the use cases. Five classes capture the domain: Clerk registers patients; Patient is the central record, distinguished as outpatient or inpatient by its type attribute; Visit captures an outpatient's scheduled appointment; Admission captures an inpatient's bed-allocated stay; and Bed is the resource an admission references.

Patient Registration System — Class DiagramClerk- clerkId- name- role+ registerPatient()Patient- patientId- name- dob- type+ updateStatus()Bed- bedId- ward- status+ checkAvailability()Visit- visitId- patientId- doctorId- apptTime- statusAdmission- admissionId- patientId- bedId- admitTime- status+ allocateBed()1*registers1*has1*has*1references
Figure 4 — Class diagram: one Clerk registers many Patients; each Patient may have one or more Visits and/or Admissions; each Admission references exactly one Bed.

Part c) — would agile change the specifications, or just focus on implementation? Under agile, the specifications would change — not be frozen and left to implementation alone. Agile's product backlog is itself a form of specification that is deliberately expected to evolve: after Sprint 1 delivers the Register Outpatient core, real clerk feedback (e.g. "bed status also needs a 'cleaning' state, not just occupied/free") would refine the Patient/Bed specification for the next sprint, rather than being deferred as an implementation-only detail or a formal change request against a frozen SRS (as it would be under Question 1's waterfall). The specification and the implementation co-evolve sprint by sprint; focusing only on implementation and treating Question 4's specification as fixed would defeat agile's core premise.