Worked Project: CampusCare Appointment System

Before we start

Why this matters

Outline · All labs

Topics in this chapter

Select a topic to jump to the slide that explains it.

1. The project
2. Step 1 · Proposal and plan
3. Step 2 · LaTeX report
4. Step 3 · SRS
5. Step 4 · SDLC model
6. Step 5 · DFD
7. Step 6 · Use cases
8. Step 7 · Sequence and communication
9. Step 8 · Class diagram
10. Step 9 · Wireframes
11. Summary

Worked project

Meet the project: CampusCare

The university medical centre books appointments on a paper register at the reception desk. Students queue before classes, and doctors cannot see who is coming. Team Pulse (four students) builds CampusCare: a web app where students and staff book, cancel and get reminders for appointments; doctors see their queue and record visit notes; the receptionist manages doctors’ schedules.

The nine steps you will see

1. Proposal and plan

Worked project

Meet the project: CampusCare (cont.)

2. Report in LaTeX
3. IEEE SRS
4. SDLC model choice
5. DFD Level 0 and 1
6. Use cases
7. Sequence and communication
8. Class diagram
9. Wireframes

Step 1 · Proposal and plan

Step 1 · Problem, objectives and related work

SMART objectives

1. By week 10, a registered user can book an appointment for the next 7 days in under 2 minutes.
2. The system sends an SMS reminder 24 hours before every appointment.
3. Doctors see their queue for the day and record a visit note for each patient.

Step 1 · Proposal and plan

Step 1 · Problem, objectives and related work (cont.)

4. The receptionist can publish a doctor’s weekly schedule in under 5 minutes.

Related work (comparison)

The gap: nothing combines university login, free slots and reminders at no cost to the centre.

Step 1 · Proposal and plan

Step 1 · Feasibility, plan, budget and risks

Step 1 · Proposal and plan

Step 1 · Feasibility, plan, budget and risks (cont.)

Gantt chart (weeks)

Step 2 · LaTeX report

Step 2 · The report in LaTeX

Rakib creates an Overleaf project from the course template. Each chapter is one file, so all four members can write at the same time without conflicts.

\documentclass[12pt]{report}
\usepackage{amsmath, graphicx, booktabs, float}
\usepackage[style=ieee]{biblatex}
\addbibresource{references.bib}
\title{CampusCare: Medical-Centre Appointment System}
\author{Team Pulse, CSE 308}
\begin{document}
\maketitle
\tableofcontents

Step 2 · LaTeX report

Step 2 · The report in LaTeX (cont.)

\input{ch1-proposal}   % Nafisa
\input{ch2-srs}        % Nafisa
\input{ch3-sdlc}       % Arif
\input{ch4-design}     % Arif, Tania
\input{ch5-ui}         % Tania
\printbibliography
\end{document}

Step 2 · LaTeX report

Step 2 · The report in LaTeX (cont.)

Step 2 · LaTeX report

Step 2 · The report in LaTeX (cont.)

Each \input file starts with its own \chapter; their text is shortened here. The contents and the reference list are generated.

Every diagram on the following slides is exported as PDF from draw.io or Figma and inserted as a numbered figure:

\begin{figure}[H]
  \centering
  \includegraphics[width=0.8\textwidth]{dfd-level1}
  \caption{Level 1 DFD of CampusCare.}
  \label{fig:dfd1}
\end{figure}
As Figure~\ref{fig:dfd1} shows, process 2.0 reads
the free slots from store D2~\cite{demarco1978}.

Step 2 · LaTeX report

Step 2 · The report in LaTeX (cont.)

Step 2 · LaTeX report

Step 2 · The report in LaTeX (cont.)

In the full report the number would be 4.2 (chapter 4, second figure); the reference number comes from references.bib.

Step 3 · SRS

Step 3 · SRS: user classes and one feature

Scope: booking and reminders for the university medical centre. Out of scope: lab results, pharmacy stock, billing.

Step 3 · SRS

Step 3 · SRS: non-functional requirements

Step 4 · SDLC model

Step 4 · Choosing the SDLC model

Step 5 · DFD

Step 5 · DFD Level 0

Step 5 · DFD

Step 5 · DFD Level 0 (cont.)

• The Patient sends sign-up and booking data and receives confirmations.
• The Receptionist supplies doctor schedules; the Doctor supplies visit notes.
• The SMS gateway is an external system that only receives reminders.
• No data stores yet: they are inside the system.

Step 5 · DFD

Step 5 · DFD Level 1

Step 5 · DFD

Step 5 · DFD Level 1 (cont.)

Balancing check: sign-up → 1.0 (registration details); booking → 2.0; confirmation ← 2.0; doctor schedules → 3.0; visit notes → 5.0; reminder ← 4.0. Every store has a flow in and a flow out.

Step 6 · Use cases

Step 6 · Use case diagram

Step 6 · Use cases

Step 6 · Use case diagram (cont.)

• Primary actors: Patient, Receptionist, Doctor. Secondary: SMS gateway.
• «include»: Book, Cancel, View, Manage schedules and Record notes all need Log in.
• «extend»: Join waiting list extends Book appointment only when the chosen slot is taken (FR-2.3).
• Send reminder is started by time (the day before), not by a person.

Step 6 · Use cases

Step 6 · Use case description: Book appointment

Step 7 · Sequence and communication

Step 7 · Sequence diagram: Book appointment

Step 7 · Sequence and communication

Step 7 · Sequence diagram: Book appointment (cont.)

Messages 8–13 implement FR-2.1 and FR-2.4; the [else] operand implements FR-2.3. Each message becomes an operation in the class diagram: reserve(slot) → Slot.reserve(), create(p, slot) → the Appointment constructor.

Step 7 · Sequence and communication

Step 7 · Communication diagram

Step 7 · Sequence and communication

Step 7 · Communication diagram (cont.)

Step 8 · Class diagram

Step 8 · Class diagram

Step 8 · Class diagram

Step 8 · Class diagram (cont.)

Step 9 · Wireframes

Step 9 · Wireframes and testing

Step 9 · Wireframes

Step 9 · Wireframes and testing (cont.)

Summary

Summary: one requirement through every step

Follow FR-2.3 (“if the chosen slot is taken, offer the waiting list”) through the whole project:

Check yourself

Quiz

Resources

Further learning

Hand-picked material to go deeper. Links open in a new tab.

Summary

Summary

• A design project is one system seen through many models: proposal, SRS, SDLC, DFD, use case, sequence, communication, class and UI.
• Requirements get IDs in the SRS and are traced through every later model.
• The SDLC choice is argued with a weighted matrix and tied to the schedule.
• DFD levels balance; use cases group goals; sequence messages become class operations.
• Wireframes are traced to use cases and tested with real users; failures lead to changes.