← Back to portfolio
Case Study 02 · Requirements Specification · Academic team project

Writing a specification precise enough that someone could build from it — and then auditing it until it held.

A full requirements package for moving a medical clinic's new patient intake from paper to an online form — current- and future-state process models, a use case with five alternate flows, thirteen business rules, a fourteen-element data dictionary, three fully specified screens, and end-to-end traceability from business goal down to individual UI component. The artifact set follows BABOK, the business analysis profession's standard body of knowledge.

1 + 5use case & alternate flows
13 · 14business rules & data elements
34specified UI components
13spec defects found & resolved

Those four figures are artifact counts — countable properties of the deliverable itself. There are no performance figures in this hero because nothing was built or measured.

About this case study

Read this first — what this case study is, and what it is not.

This is academic coursework, produced by a seven-person student team in the Information Systems Business Analysis program at George Brown College (May 2026). “Bay & Dundas Family Health” is a fictional clinic. The stakeholder was played by course faculty. Nothing here was built, deployed or measured.

Every number on this page therefore carries a provenance label: scenario means it was supplied in the course brief, target means it is a stakeholder-set objective, never a measured outcome, artifact fact means it is a countable property of the deliverable itself, and my judgment marks an analytical decision I made and would defend. There are no results claimed on this page, because there are no results.

Why this sits next to the Canadian Tire case study

The two are deliberately different halves of the job.

Case 01 — Canadian Tire is diagnosis: a real operational failure at my own workplace, root-caused with observed data, where the deliverable was finding out why the system lied.

Case 02 — this one is specification: taking a decided direction and writing it down precisely enough to hand to a build team, where the deliverable is unambiguous, traceable, testable requirements. Neither is much use on its own.

My contribution, and the team's

Seven analysts authored the source document. Naming who did what matters more than claiming all of it.

  • Mine: the detailed use case specification — basic flow, the five alternate flows, the business rules register, the business data catalogue, the three UI specifications with their component tables, and the notification set.
  • Team: goals and objectives, problem statements, the current- and future-state process maps, the scope model, the non-functional requirements and the trace matrix.
  • Course-supplied: the scenario, the stakeholder role, the baseline metrics and the target percentages.

Everything presented here as my judgment — the reconciliation of the two ID schemes, the defect log in section 9, the added context entity, the reconciled component numbering — is post-submission analysis I did for this write-up, not team work.

Teammates and faculty are not named on this page. They co-authored a course deliverable; they did not agree to appear in my portfolio. Names are available privately on request.

01 — Context

A twenty-minute wait to hand over information the clinic already needed

New patients at the clinic register on arrival, on paper. They are given a blank intake form, fill it in by hand in the waiting room, and hand it back. A Medical Administrator then reads it, checks that every required field is present and legible, verifies the identity and health-card details, and types the whole thing into the patient record. Anything unclear goes back to the patient to redo.

Two things follow from that design, and they are the reason the project exists. First, every defect is discovered after the patient has already done the work — the form has no way to object while it is being filled in. Second, a skilled administrator spends their day as a transcription and proof-reading service, which is both slow and the point at which most errors enter the record.

Current-state metrics

Supplied in the course brief as the clinic's baseline. The team did not observe or time this process, and I have not presented these as measurements. scenario

CSPM-001 process metrics — as given in the scenario
MeasureBaselineWhat it represents
Average cycle time30–60 minutesArrival to a completed record in the patient management system
Non-value-added waiting15–25 minutesTime the patient spends waiting with nothing to do
Error rate10–15%Records with incomplete, illegible or incorrect entries requiring rework
Throughput8–12 new patients/dayVolume achievable before the front desk becomes the bottleneck

Where the time actually goes — DOWNTIME analysis

DOWNTIME is a lean checklist of eight waste types. Listing them in the abstract proves nothing, so the team mapped each one to the specific process step that produces it. Turn the overlay on in the next section and the tags appear pinned to the steps they belong to.

DDefects — illegible handwriting, missing fields, transcription errors
OOverproduction — intake forms printed in advance, most never used
WWaiting — the patient waits idle while paper is retrieved and read
NNon-utilised talent — clinical admin staff proof-reading handwriting
TTransportation — the same form changing hands three or four times
IInventory — a backlog of unreviewed forms at peak arrival
MMotion — repeated trips between front desk and workstation
EExtra processing — the same form checked two and three times over
The analytical point

Six of the eight wastes are consequences of a single design decision: validation happens after submission, when it needs to happen during. That makes the problem information design, not staffing. The solution direction follows: a form that refuses to be submitted wrong (BR009). More people at the front desk would not have fixed it. my judgment

Root cause analysis

The three-step reduction the team used to get from symptom to solution direction. It is deliberately short: the value is in the middle column, and everything downstream on this page is an answer to it.

1 — The gap

Patients wait while a Medical Administrator reads and checks a form by hand, and accuracy is poor because handwriting, missing fields and incorrect entries are only discovered at that point. Both symptoms — waiting time and form quality — sit at the same moment in the process.

2 — The root cause

A paper intake form cannot object. It accepts anything written on it, so the checking has to happen afterwards, by a person, with the patient waiting. Every waste in the DOWNTIME analysis above is downstream of that one property.

3 — The direction

Replace the form with one that can refuse to be submitted wrong: mandatory fields, electronic document capture, validation on entry and a submission gate. The check moves from a person after the fact to the interface during it.

Note what the root cause is not: it is not that staff are slow, and it is not that patients are careless. Both would have led to a training or staffing solution, and neither would have worked. my judgment

Goals, objectives and the problems they answer

Every downstream requirement on this page traces back to one of these six statements. Click any identifier to inspect it.

GO001–GO002, OB001–OB004, PO001–PO002
IDStatementTypeTraces to
GO001Increase annual new patient registrations and establish the clinic as a high-volume medical service provider.Goal—
GO002Streamline the digital new patient registration process to reduce administrative workload and improve operational efficiency.Goal—
OB001Reduce the duration of new patient registration by 95% for patients and by 100% for administrative staff. targetObjectiveGO001
OB002Reduce manual data entry errors by 95%. targetObjectiveGO002
OB003Reduce time spent on manual patient registration processes by 75%. targetObjectiveGO002
OB004Increase patient satisfaction by bringing line waiting time down to a maximum of 10 minutes. targetObjectiveGO001
PO001Administrative staff spend disproportionate time on registration, increasing workload and slowing patient onboarding. Streamlining reduces registration time and improves efficiency.ProblemOB001 OB003
PO002Manual transcription into the patient management system risks data-entry errors, incomplete records and duplicates, consuming further staff time in review and correction.ProblemOB002 OB004

The objective targets are stated as the course stakeholder set them. I would push back on OB001 in a real engagement — a 100% reduction in administrative registration duration claims the work disappears entirely, when in practice exception handling (AF03) and coverage review (BR013) still land on a human. my judgment

02 — Process analysis

Two states of one process, at two levels of detail

Cross-functional (swimlane) models at Level 2 — the end-to-end journey — and Level 3, which decomposes the single activity where the failure concentrates. All four were originally drawn in Lucidchart; they are reproduced here as inline diagrams so they stay legible, searchable and consistent with the rest of the site. artifact fact

AS-IS. The clinic's only intake path. Note that the loop back to “fill out the intake form” is a full restart, not a correction — the patient re-does the form from scratch.

CSPM-001  Level 2 — Patient arrives at the clinic

As-Is Level 2 (CSPM-001) — Patient arrives at the clinic Patient Medical Admin Yes No — start the form again Start Patient arrives at the clinic W — Waiting: the patient queues at the front desk before anyone can helpW Fill out the intake form by hand D — Defects: illegible handwriting and missing fieldsD W — Waiting: 15–25 minutes of non-value-added waitW End Hand over a blank intake form O — Overproduction: forms printed in advance, most never usedO T — Transportation: paper passed back and forth between desk and patientT Complete and legible? I — Inventory: a backlog of unreviewed forms builds up at peak arrivalI N — Non-utilised talent: skilled admin staff proof-reading handwritingN Transcribe into the patient record M — Motion: repeated trips between the front desk and the workstationM D — Defects: 10–15% of records carry a transcription or entry errorD Ran as the clinic's only intake path. Cycle time 30–60 min, of which 15–25 min is non-value-added waiting.

CSPM-001.S1  Level 3 — Review the patient information

The decomposition of the single Level 2 activity that generates the rework: the manual review.

As-Is Level 3 (CSPM-001.S1) — Review the patient information Medical Admin Patient Yes No Rework loop Start Receive the completed intake form T — Transportation: the form changes hands yet againT Check every required field is filled E — Extra processing: a manual completeness pass the form should enforce itselfE Verify name, DOB, contact, health card N — Non-utilised talent: character-by-character checking by clinical adminN E — Extra processing: corrected forms are re-checked a second and third timeE Complete and accurate? Send forward for registration End Hand the form back to correct D — Defects: a rework loop with no root-cause fixD W — Waiting: the patient waits through an entire second cycleW Every defect is caught after the patient has already filled the form, so each one costs a full second cycle.
What the Level 3 model exposes

Three consecutive manual checks — completeness, then detail verification, then an accuracy gate — all performed on a document that has already left the patient's hands. The rework loop returns to the start of the review, so a single missing version code costs the full cycle again. The target state has to eliminate that structure. Speeding it up is not enough.

TO-BE. Registration completes before the first visit. The Medical Admin lane is gone — the work is removed, not moved to someone else.

FSPM-001  Level 2 — Registration of the patient

To-Be Level 2 (FSPM-001) — Registration of the patient Patient Clinic Management Start Complete the registration form online UI001 Submit the form and card image UI002 Receive the confirmation UI003 · NO001 End Receive the completed registration record REP001 There is no Medical Admin lane. The manual review, transcription and paper handling are removed, not reassigned.

FSPM-001.S1  Level 3 — Processes in filling the form

UC001 in section 5 elaborates this activity, and section 7 makes it executable.

To-Be Level 3 (FSPM-001.S1) — Processes in filling the form Patient EMR System Approved Needs revision Submit Start Fill out the form BR001 Correct what the form flags AF01 · NO002 Upload the health card image DE009 Review and confirm UI002 End Validate the uploaded document BR006 · BR007 Application decision BR009 Validation moves upstream: errors surface while the patient is still on the form, not after a front-desk review.
The structural change in one sentence

The accuracy gate moves from after the patient's work (a person reading paper) to during it (BR009, the submission gate), so the To-Be revision loop returns the patient to a single field. The form does not restart.

The two states side by side

Structural comparison — what changes, and which requirement makes it change
DimensionAs-Is (CSPM-001)To-Be (FSPM-001)Enabled by
Where validation happensAfter submission, by a person reading paperDuring entry, by the form itselfHLR002 BR009
Who transcribesMedical Admin, by hand, into the recordNobody — the record is created from what the patient enteredBR014
Cost of one errorA full second cycle, patient presentAn inline message on one fieldAF01 NO002
When registration happensOn arrival, in the waiting roomAny time before the first visitNFR001
Identity verificationVisual check of the card at the deskImage capture plus a provincial coverage checkBR007 BR013
Lanes in the modelPatient, Medical AdminPatient, EMR System, Clinic ManagementACT002
AbandonmentNot possible — the patient is physically presentExpected, and designed for: drafts persistAF04 BR012
A gap the To-Be model creates and the source document did not close

Moving registration off-site introduces a failure mode the paper process could not have: the patient who starts and never finishes. There is no queue to lose your place in, so nothing pulls them back. AF04 and BR012 handle draft retention mechanically, but nobody owns the resulting funnel — no report counts abandoned drafts, and REP002 only logs applications that were actually returned for revision. I would add abandonment to REP003 before build. my judgment

03 — Scope

What the solution is responsible for, and what it deliberately is not

Scope on this project is mostly an exercise in refusing adjacent work. Registration touches booking, billing and identity verification, and each of those is a plausible next feature; naming them as excluded, with the reason, is what stops them arriving mid-build.

In scope — high-level requirements

  • HLR001 Patients complete and submit registration online. HIGH
  • HLR002 The system verifies the form and validates documents, returning specific errors before submission. HIGH
  • HLR003 On approval the patient is registered and notified by email. HIGH
  • HLR004 Clinic Management receives a record of each completed registration. MEDIUM

Out of scope — with rationale

  • OS001 Appointment booking and scheduling — registration creates the record; it does not schedule anything.
  • OS002 Billing, insurance submission and payment — no financial transaction occurs during registration.
  • OS003 In-person document validation by admin staff at the first visit — in-person activity is outside an online registration flow.

Each exclusion is surfaced to the patient in the interface, never left implicit — CO026 tells them what this form is not asking for, and CO032 tells them the clinic will call to book.

BCD001 — Business context diagram

The scope model: the system under study, the four actors that cross its boundary, and the information that flows over it.

BCD001 — Business Context DiagramBCD001 · BUSINESS CONTEXT DIAGRAMDashed entity added during review — ACT003 acts in the use case but was absent from the original diagram (QA-12).EMR SystemACT002 · system under studyvalidate · store · notifyPatientACT001 · primary actorHealth Card ValidationACT003 · external serviceClinic ManagementACT004 · receiving systemForm + health card image —DE001–DE010Corrections — NO002 · NO003Confirmation + reference —NO001Card number + version code —DE004 · DE005Coverage result — BR013Registration record — REP001Scope boundary — appointment booking (OS001), billing and insurance (OS002) and in-person document checks (OS003) sit outside this context.
ACT001–ACT004 — actor summary
IDActorRoleResponsibility at the boundary
ACT001PatientPrimaryCompletes registration unaided, before the first visit. Supplies DE001–DE010.
ACT002EMR SystemPrimarySystem under study. Validates entries and documents, creates and stores the record, issues notifications.
ACT003Health Card Validation SystemSecondaryExternal provincial service confirming the card number and version code. Non-blocking per BR013.
ACT004Clinic Management SystemPrimaryReceives the completed registration record and the summary listing REP001.
Why the diagram above has a dashed box the original did not

ACT003 appears in the actor list and acts at step 5 of the use case, but was missing from the context diagram in the source document — so the scope model showed no external dependency at all, and a reader would have had no reason to ask what happens when the provincial service is unreachable. Adding it forced that question, which is answered by BR013. Logged as QA-12. my judgment

04 — Solution requirements

Four high-level requirements, and the qualities the system has to hold while meeting them

The high-level requirements say what the solution must do; every rule, data element and screen later on exists to satisfy one of them. The non-functional requirements say how well, and they are the part of this specification I trust least — explained below.

HLR001–HLR004 — high-level requirements
IDRequirementPriorityTraces toRealised by
HLR001The system must allow a patient to complete and submit registration forms online.HIGHPO001UI001 BR001 NFR001
HLR002The system must automatically verify the form and validate the documents, returning specific errors to the patient before submission.HIGHPO002BR009 AF01 NO002 CO012
HLR003The system must register the patient on form and document approval, and notify them by email.HIGHPO001 PO002BR014 BR015 NO001 UI003
HLR004The system must provide clinic management with a record of each completed patient registration.MEDIUMPO001REP001 ACT004

Non-functional requirements

NFR001–NFR007 — operating conditions and quality expectations
IDCategoryRequirementApplied in this use case
NFR001Hours of usageAvailable 24 hours a day.A patient may register at any time before their first visit.
NFR002Days of usageAvailable every day.No weekday-only restriction on registration.
NFR003Usage exceptionsScheduled maintenance limited to one window per month.NO006 is displayed during that window.
NFR004Response timePages load within 3 seconds.Each pre-submission check resolves without the patient waiting on the field.
NFR005Concurrent events200 concurrent events. scenarioSupports 200 concurrent registration sessions.
NFR006System users10–15 internal clinic staff plus 1,000 concurrent external patient users. scenarioSizing for the public form.
NFR007Peak events50 registration submissions per hour at peak without failure. scenarioPeak sizing for the submission path.
I would not sign off on NFR005–NFR007 as written

The scenario baseline is 8–12 new patients per day. NFR007 requires the system to absorb 50 submissions per hour — roughly five days of demand every hour — and NFR006 asks for 1,000 concurrent patient users, about a hundred times the clinic's entire daily volume. NFR005 then caps concurrent events at 200, which contradicts the 1,000-user figure directly: either the numbers describe different things, or one of them is wrong.

These read as figures chosen to sound robust. Nothing derives them from the demand. Capacity requirements drive infrastructure cost, so over-stating them is not a harmless safety margin. The correct analyst move is to take them back to the stakeholder with the arithmetic and ask which number is real. Logged as QA-09. my judgment

05 — Use case specification

UC001 — Register as a new patient online

The elaboration of FSPM-001.S1. One successful path and five ways it can deviate. The alternate flows are the part that matters: the basic flow describes the day everything works, and almost no day is that day.

Pre-conditions

  1. The registration page is available (NFR001).
  2. The patient has an internet-connected device and the clinic registration link.
  3. The patient has a photograph or scan of their health card.
  4. The patient is 16 or older (BR004).
  5. No active patient record exists for this health card number (BR010).

Post-conditions

  1. A registration record exists with DE013 = Submitted, a unique DE011 and a DE012 timestamp.
  2. The health card image DE009 is retained and linked to the record (BR016).
  3. The patient has received NO001 at the address in DE007.
  4. UC002 — Verify form and validate documents — is triggered.
  5. If unsuccessful, entries are retained with DE013 = Draft and the patient is told what to do next.

Flow explorer

Select a flow. The rail shows where it branches from the basic flow and where it rejoins — or that it terminates unsuccessfully.

The shortest successful path: fifteen steps, no deviation. Steps that can branch are marked on the rail.

UC001 — basic flow
#StepRules appliedBranch / UI
1The patient opens the clinic's new patient registration link.—UI001
2The system displays the form with the progress stepper at step 1 of 3 and the pre-submission panel showing five open checks.—CO001 CO012
3The patient enters their personal details.BR001DE001–DE008
4The system validates each entry as the patient leaves the field.BR002 BR003 BR004 BR005AF01 · NO002
5The system submits the card number and version code to the Health Card Validation System and records the coverage result.BR013ACT003
6The system updates the pre-submission check panel with the result of each check.—DE014 CO013
7The patient uploads the health card image — the only document collected.BR001DE009 CO010
8The system checks the uploaded file.BR006 BR007AF02 · NO003
9The patient confirms consent to collection of the information.BR008DE010 CO011
10The system enables Continue to review once all five checks return Pass.BR009AF04 · CO015
11The patient selects Continue to review; the system presents the entered details and the attached image for confirmation.—UI002
12The patient selects Submit registration; the system checks for an existing record.BR010AF03
13The system creates the registration record.BR011 BR014AF05 · DE011
14The system displays the confirmation screen and sends the submission notification.BR015UI003 · NO001
15Use case ends. Control passes to UC002.——

Branches at step 4 · rejoins at step 4. The most frequent deviation, and the one the whole design exists to make cheap.

AF01 — entry fails validation
#StepRules / UI
1Starts at basic flow step 4 when an entry fails a format or validity rule.BR002 BR003 BR004 BR005
2The system marks the field and displays the correction message beside it, naming the specific problem and how to fix it.NO002 CO016
3The system holds the related check open in the pre-submission panel and keeps Continue to review disabled.BR009 CO012
4The patient corrects the entry.—
5Flow returns to step 4 of the basic flow.—

The source document numbered this flow 1, 2, 3, 4, 4 — two steps sharing a number, with the terminal step unreachable. Renumbered here; logged as QA-05.

Branches at step 8 · rejoins at step 8. Rejecting an unreadable image at upload is the single highest-value control in the specification: it is the one check that, in the As-Is process, could not be done until the patient had already gone home.

AF02 — document cannot be read
#StepRules / UI
1Starts at basic flow step 8 when the uploaded image fails the file-type, size or readability check.BR006 BR007
2The system rejects the file, leaves the upload area empty, and displays guidance for retaking the image.NO003
3The patient uploads a replacement file.CO010
4Flow returns to step 8 of the basic flow.—

Branches at step 12 · ends unsuccessfully. An exception flow, not an alternate one — the patient cannot resolve this themselves, so the design hands them a phone number. There is no retry.

AF03 — existing patient record found (exception)
#StepRules / UI
1Starts at basic flow step 12 when an active record matches the health card number and date of birth.BR010
2The system stops the submission and displays the duplicate message with the clinic phone number.NO004
3The system retains the submission with DE013 = Draft and flags it for Clinic Management review.ACT004
4Use case ends, unsuccessfully.—
Design note

This flow contradicts OB001's claim of a 100% reduction in administrative effort: a flagged duplicate lands on a human every time.

Branches from step 3 onward · resumes at step 2. The flow that only exists because registration moved off-site.

AF04 — patient saves and finishes later
#StepRules / UI
1Starts at any point from basic flow step 3, when the patient selects Save and finish later.CO014
2The system saves all entered values and the uploaded image, sets DE013 = Draft, and emails a resume link.NO005
3The draft is retained for 14 calendar days from last activity, then purged.BR012
4Use case ends, incomplete. The patient re-enters at step 2 using the resume link.—

Two different retention periods appeared in the source document — one month with three reminders in the business rules section, 14 days in the detailed specification and in the notification text. Resolved to 14 days; logged as QA-02.

Branches at step 13 · ends unsuccessfully. The technical exception. Its only real requirement is that the patient's work survives.

AF05 — submission cannot be completed (exception)
#StepRules / UI
1Starts at basic flow step 13 when the record cannot be written because the system is unavailable or the request times out.NFR003
2The system retains all entries with DE013 = Draft and displays the retry message.NO006
3The system logs the failure for the support team.—
4Use case ends, unsuccessfully.—
All five flows are executable in section 7

Rather than asking you to take the alternate flows on trust, the live UI specification below can trigger each one — enter a bad version code for AF01, upload a blurred card for AF02, or use the simulation controls for AF03, AF04 and AF05. Jump to the prototype →

06 — Business rules, data & messages

The registers a build team would actually work from

Four registers: the rules that govern behaviour, the data the system holds, the messages it sends, and the reports it produces. These are the least glamorous artifacts in business analysis and the ones that decide whether a build goes smoothly. Every entry carries the step it applies at, so a developer can find it from the flow and a tester can find the flow from it.

16business rules
14data elements
34UI components
6notifications
3reports
7non-functional requirements

Counts of what the reconciled specification actually contains. artifact fact

One canonical numbering scheme

The source document carried two competing schemes — BR01–BR05 and DE01–DE14 in the requirements sections, BR001–BR013 and DE001–DE014 in the detailed specification — overlapping in meaning but not in number, with cross-references pointing at both. Everything below is renumbered into the single register the detailed specification used, with the earlier rules folded in as BR014–BR016. Logged as QA-01 and QA-06. my judgment

Business rules — BR001 to BR016

Rule type: Definitional rules state what something is and cannot be violated; behavioural rules constrain what the system or a person may do.
IDNameTypeRuleStep
BR001Mandatory field setDefinitionalFirst name, last name, date of birth, health card number, version code, phone, email, home address, health card image and consent must all be provided before a registration can be submitted.3, 7, 9
BR002Health card number formatDefinitionalDE004 must be exactly 10 numeric digits, displayed as ####-###-###.4
BR003Version code formatDefinitionalDE005 must be exactly two alphabetic characters, stored upper case.4
BR004Date of birth validityBehaviouralDE003 must be a valid calendar date in the past. Self-registration is limited to patients aged 16 or older; a patient under 16 is directed to call the clinic.4
BR005Contact formatBehaviouralDE006 must be 10 numeric digits. DE007 must be a valid address, as it is the destination for every registration notification.4
BR006Document file type and sizeDefinitionalDE009 must be JPG, PNG or PDF and no larger than 10 MB. It is the only document collected during registration.8
BR007Document readabilityBehaviouralThe image must be legible enough for the system to read the patient name and card number. A failing image is rejected at upload, before it reaches clinic review.8
BR008Consent requiredBehaviouralDE010 must equal TRUE before submission. The clinic may not collect the information without it.9
BR009Submission gateBehaviouralContinue to review is enabled only when all five pre-submission checks return Pass. This rule replaces the manual front-desk review and is the primary control behind HLR002 and OB002.10
BR010Duplicate registrationBehaviouralA registration is rejected where an active patient record already exists with the same health card number and date of birth.12
BR011Registration reference formatDefinitionalDE011 is system-generated as REG-YYYYMMDD-NNNN, where NNNN is sequential within the day.13
BR012Draft retentionDefinitionalAn incomplete registration is retained for 14 calendar days from last activity and is then purged.AF04.3
BR013Health card coverage checkBehaviouralCard number and version code are checked against the provincial validation service. A failed check does not block submission; the record is flagged for clinic review at UC002.5
BR014Automatic record creationBehaviouralA patient record is created only after all completeness and format validations pass. No manual data entry is performed in the standard flow.13
BR015Notification ruleBehaviouralA confirmation notification is sent only after successful record creation. Rejection notices state the reason and direct the patient to the walk-in path.14
BR016Health record retentionDefinitionalUploaded identity documents and health card data are retained for 7 years, per Ontario health-record retention requirements.Post-condition

Data dictionary — DE001 to DE014

Business data catalogue. New marks an element that does not exist in the current paper process.
IDBusiness termStatusDefinition & rulesExampleStep
DE001First nameExistingGiven name as printed on the health card. Mandatory. Alphabetic, hyphen and apostrophe permitted, 1–40 characters.Amara3
DE002Last nameExistingFamily name as printed on the health card. Mandatory. 1–40 characters.Osei3
DE003Date of birthExistingMandatory. Format YYYY-MM-DD. Must be a past date and imply age ≥ 16 (BR004).1994-03-183
DE004Health card numberExistingProvincial number identifying coverage. Mandatory. 10 numeric digits (BR002).1234-567-8903
DE005Version codeExistingTwo-letter code printed after the card number. Mandatory, upper case (BR003).AB3
DE006Phone numberExistingNumber at which the clinic can reach the patient. Mandatory. 10 numeric digits.647-555-01883
DE007Email addressExistingDestination for all registration notifications. Mandatory, valid format, single address only.amara.osei@email.com3
DE008Home addressExistingResidential address. Mandatory. Street, city, province and postal code in ANA NAN format.88 Dundas St W, Toronto, ON M5G 1C73
DE009Health card imageNewPhotograph or scan of the card front — the only document collected. JPG, PNG or PDF, max 10 MB, must be legible (BR006, BR007).health-card-front.jpg7
DE010Consent indicatorNewConsent to collection and retention of the information for care. Mandatory boolean, must be TRUE (BR008).TRUE9
DE011Registration referenceNewUnique identifier issued for this registration. System-generated, format REG-YYYYMMDD-NNNN (BR011).REG-20260811-014713
DE012Submission date/timeNewWhen the registration was submitted; used to measure cycle time for REP003. Local clinic time.2026-08-11 14:3213
DE013Registration statusNewState of the registration in the EMR. System-set. Permitted values: Draft, Submitted, Returned for revision, Registered.Submitted13
DE014Validation check resultNewPass/open state of each of the five pre-submission checks shown to the patient. System-derived, displayed as “n of 5”.4 of 56
Two elements that vanished between document levels

The scope-level use case made a medical history questionnaire and a separate patient record ID mandatory at submission. Neither appears in the detailed specification, the business rules, or any of the three screen designs — the requirement was dropped somewhere between levels without a decision being recorded. I have kept it out of the register here, because a specification should not claim to cover what it does not, and flagged it for stakeholder confirmation instead. Logged as QA-07. my judgment

Notifications — NO001 to NO006

Every notification names what happened and what the patient should do next. Written as the patient reads them, not as the system logs them.

IDNameTriggerMessageChannel
NO001Registration submittedStep 13 completes“We've got your registration. Your reference is DE011. The clinic will confirm by email once you're registered, usually the same day.”Screen + email
NO002Entry needs correctingBR002–BR005 fails“Add your version code — the two letters printed just after the card number. Without it the clinic can't confirm your coverage.” Text varies by the rule that failed and always names the field and the fix.Screen, beside the field
NO003Document can't be readBR006 or BR007 fails“We can't read this image. Take the photo in good light with all four corners of the card showing, then upload it again.”Screen, in the upload area
NO004You may already be registeredBR010 finds an active record“Our records show a patient with this health card number. Call the clinic at 416-555-0142 and we'll sort it out — please don't register twice.”Screen
NO005Draft savedPatient selects Save and finish later“Saved. We've emailed you a link to pick up where you left off. It works for 14 days.”Screen + email
NO006Registration temporarily unavailableRecord cannot be written at step 13“We couldn't submit this just now. Your answers are saved — try again in a few minutes, or call the clinic at 416-555-0142.”Screen

Reports — REP001 to REP003

IDReportData contributed by this use caseMeasures
REP001Patient registration reportEach successful submission contributes DE001, DE002, DE011, DE012 and DE013 to the summary listing used to track new-patient volume.GO001 HLR004
REP002Registration exception reportEach occurrence of AF01, AF02 and AF03 contributes the failed rule ID, the field or image affected, and the notification issued.OB002 PO002
REP003Registration volume & cycle timeStart time captured at step 1, end time at DE012, giving end-to-end duration per patient alongside submission counts.OB001 OB003

REP002 is the one that makes this specification self-correcting: it turns every alternate flow into a counted event, so the clinic learns which rule fails most often and can fix the field. The paper process never had that feedback loop. my judgment

07 — User interface specification

The specification, running

Three screens are specified in this project: the registration form, the review screen and the confirmation. Rather than describe them, this is a working recreation built only from the specification above — the validation rules are BR002–BR008, the gate is BR009, the messages are NO001–NO006, and the reference format is BR011.

If a requirement were ambiguous, this prototype could not have been built without asking a question. That was the whole test.

Analyst view overlays every component ID — click one to inspect its data element, rules and trace.
Trigger a flow

Below is a working recreation of the three specified screens, built from the specification alone. It is deliberately styled as the clinic product would be, not as this portfolio — the point is to show what the spec produces.

Bay & Dundas Family Health
New patient registration Trouble with the form? Call the clinic
416-555-0142 · Mon–Fri, 8am–6pm
Analyst view is on. Every labelled control below carries its component ID from UI001. Click any ID chip to open its specification — data element, validation rule, governing business rule, the notification it can fire, and its trace up to the business goal.

Register as a new patient

Fill this in before your first visit. We check your details as you go, so nothing gets sent back to you later.

01
Your details
02
Documents
03
Review and submit

About you

Ten digits, printed on the front of your card.

Documents

Health card — front
health-card-front.jpg · 1.8 MB READABLE

We read the name and number off this image, so you don't retype them. This is the only document we need — take the photo in good light with all four corners showing.

Saved 2 minutes ago

Before you submit

The clinic used to check these by hand at the front desk. Now the form does it, while you're still here to fix things.

Ready to submit 0 of 5

What happens next

Once all five checks clear, your registration goes straight to the clinic's records — no front-desk retyping. You'll get a confirmation email the same day.

Not asked for here

Appointments. The clinic calls you to book your first visit after you're registered.

Payment or insurance. Nothing is charged or collected on this form.

SCREEN UI001 · SUBMIT REGISTRATION FORM AND DOCUMENTS TRACED TO: HLR001 · HLR002 · FSPM-001.S1 · UC001 · OB002
Building it surfaced a gap the document did not

The pre-submission panel specified in CO012 shows exactly five checks, but BR001's mandatory set has ten elements. Home address and consent are mandatory and are not represented in the panel — so a patient could see “5 of 5” against an incomplete form, which is precisely the false reassurance the design exists to prevent. This prototype gates the button on the full mandatory set and shows the discrepancy in analyst view. It is the kind of defect you only find by building the thing. Logged as QA-11. my judgment

Component specification

All 34 components across the three screens. Click any ID for its full entry.

UI001 — New patient registration form
IDComponentDataTypeDisplayed / enabled rules
CO001Progress stepper—DisplayThree steps. Current step highlighted; completed steps shown in solid rule.
CO002First nameDE001TextMandatory (BR001). Helper text notes the name must match the health card.
CO003Last nameDE002TextMandatory (BR001).
CO004Date of birthDE003Date pickerMandatory. Future dates not selectable (BR004).
CO005Health card numberDE004TextMandatory. Input masked to ####-###-### (BR002).
CO006Version codeDE005TextMandatory. Maximum two characters (BR003). Displays error state and NO002 when the check fails.
CO007PhoneDE006TextMandatory. Input masked to ###-###-####.
CO008EmailDE007TextMandatory. Helper text states the confirmation is sent here (HLR003).
CO009Home addressDE008TextMandatory. Address lookup offered on entry.
CO010Health card uploadDE009File uploadMandatory. The only upload control on the screen. Displays file name and a Readable indicator once BR006 and BR007 pass.
CO011Consent checkboxDE010CheckboxMandatory. Must be selected before CO015 is enabled (BR008).
CO012Pre-submission check panelDE014Display panelLists the five checks and refreshes as each field is completed. Failed checks displayed with the correction message.
CO013Ready-to-submit meterDE014Progress barDisplays the count of passed checks out of five.
CO014Save and finish later—ButtonAlways enabled from step 3 onward. Triggers AF04.
CO015Continue to review—ButtonDisabled until all five checks return Pass (BR009). Enabled state advances to UI002.
CO016Inline error message—DisplayRendered beside the field that failed validation. Content per NO002.
CO017Clinic help line—DisplayStatic. Displayed on every step so the patient can reach a person at any point.
UI002 — Review and submit  ·  UI003 — Registration confirmation
IDComponentDataTypeDisplayed / enabled rules
CO018Details summaryDE001–DE008DisplayRead only. Each group carries an Edit control returning to UI001.
CO019Document summaryDE009DisplayRead only. Shows the file name and a thumbnail of the health card image.
CO020Consent recordDE010DisplayRead only. Restates the consent given and the timestamp it was recorded.
CO021Progress stepper (step 3)—DisplayAll three steps shown complete.
CO022Edit details control—ButtonReturns to UI001 with all values retained.
CO023Replace document controlDE009ButtonReturns to the upload control; re-runs BR006 and BR007.
CO024Consent confirmationDE010DisplayShows the recorded date and time of consent.
CO025All-checks-clear panelDE014Display panelConfirms all five pre-submission checks passed before the commit control is offered.
CO026Out-of-scope notice—DisplayStates what this form does not do, per OS001 and OS002.
CO027Back to form—ButtonReturns to UI001 with all values retained.
CO028Submit registration—ButtonCommits the registration. Triggers BR010 then BR011 and BR014.
CO029Confirmation message—DisplayContent per NO001.
CO030Registration referenceDE011DisplayRead only. Presented for the patient to quote when calling the clinic.
CO031Submission date/timeDE012DisplayRead only. Local clinic time, the start point for REP003.
CO032Next steps—DisplayStates that the clinic confirms by email and calls to book the first visit (OS001).
CO033Email copy noticeDE007DisplayConfirms the address the copy of NO001 was sent to.
CO034Correction help—DisplayExplains that a submitted registration is corrected by phone, not online.

The component tables in the source document numbered UI002 and UI003 as CO018–CO024, while the annotated screen designs for the same two screens used CO018–CO034. Reconciled here to the design's numbering, which is the more granular of the two and the one a build team would be looking at. Logged as QA-13. my judgment

08 — Traceability

Every requirement answers to a goal, and every goal reaches a screen

Traceability is the artifact that decides whether a requirements package survives contact with change. When a stakeholder asks “why are we building this field?”, the answer should be a chain, not an opinion. Select any identifier below and the ladder shows what it descends from and what depends on it.

Nothing selected — showing everything or click any GO001-style chip anywhere on this page
Goals
Objectives
Problems
Requirements
Process & use case
Rules
Screens & reports

Data elements (DE001–DE014), components (CO001–CO034) and notifications (NO001–NO006) sit one level below the ladder; open any rule or screen to walk down to them.

Requirements trace matrix

The condensed matrix, one row per high-level requirement. A stakeholder signs this view. An analyst works in the ladder above.

GoalsObjectivesProblemsHLRScopeProcess L2Process L3ActorsUse casesReportsSupporting
GO001 GO002 OB001 OB003 PO001 HLR001 BCD001 FSPM-001 FSPM-001.S1 ACT001 ACT002 UC001 REP003 NFR001 NFR002 NFR003 NFR005 NFR007 · UI001
GO001 GO002 OB002 OB004 PO002 HLR002 BCD001 FSPM-001 FSPM-001.S1 ACT001 ACT002 ACT003 UC002 UC003 · AF01 AF02 REP002 BR009 BR013 · CO012
GO001 GO002 OB001 OB002 OB003 OB004 PO001 PO002 HLR003 BCD001 FSPM-001 FSPM-001.S1 ACT001 ACT002 UC004 — NFR006 · NO001 UI003
GO001 GO002 OB001 OB003 PO001 HLR004 BCD001 FSPM-001 — ACT004 UC005 REP001 —
What the matrix is actually for

Read a row left to right and it justifies a requirement. Read it right to left and it does the more valuable job: if REP002 is cut for budget, the matrix says immediately that OB002 loses its only means of measurement. Coverage is the cheap benefit; impact analysis is the real one. my judgment

09 — Specification QA

What a line-by-line audit of our own document found

Transcribing a specification onto a portfolio page proves nothing. Auditing it does. Before writing a word of this case study I read the source document as if I had been handed it by someone else and had to build from it — every identifier resolved, every cross-reference followed, every number checked against the scenario it came from.

It found thirteen defects, four of which would have caused real problems in a build: a contradiction about how long a draft survives, a broken reference to a rule that did not exist, a mandatory requirement that disappeared between document levels, and a status panel narrower than the rule it reports on. All are fixed in the version presented on this page. my judgment

13specification defects found
5numbering & consistency
3contradictions & broken references
3coverage gaps
2scope & plausibility
QA-01Two competing identifier schemes for the same objectsNumbering
FoundThe requirements sections numbered rules BR01–BR05 and data DE01–DE14; the detailed specification numbered the overlapping set BR001–BR013 and DE001–DE014. Cross-references pointed at both.
Why it mattersA developer reading “BR04” gets draft retention in one section and date-of-birth validity in another. Ambiguity in an identifier is worse than no identifier, because it looks resolved.
ResolvedRenumbered to the single register used throughout this page, folding the earlier rules in as BR014–BR016.
QA-02Draft retention specified as two different periodsContradiction
FoundThe business rules section said an unsubmitted draft is retained for one month with three automated reminders. The detailed specification and the notification text both said 14 calendar days, with no reminders.
Why it mattersThe rule governs retention of health information. Two answers means one of them is being implemented by accident, and the patient-facing message may promise a window the system does not honour.
ResolvedResolved to 14 days as BR012, because two independent artifacts agreed on it and NO005 already tells the patient so. The reminder sequence is dropped, and flagged as a decision for the stakeholder to confirm. I should not make it alone.
QA-03Post-condition referenced a rule that did not existBroken reference
FoundThe use case post-condition cited “BR06” as the authority for seven-year document retention. Under one scheme BR06 was document file type and size; under the other, no retention rule existed at all.
Why it mattersA legal retention obligation with no rule behind it is a requirement nobody is accountable for implementing.
ResolvedRetention established explicitly as BR016 and referenced from the post-condition.
QA-04Problem statements traced to non-existent objective IDsNumbering
FoundBoth problem statements traced to OBJ001 and OBJ003. The objectives are numbered OB001–OB004.
Why it mattersSmall, but it is the trace matrix's foundation. An automated coverage check would report these as orphans.
ResolvedCorrected to OB001 and OB003.
QA-05Alternate flow with two steps numbered 4Numbering
FoundThe scope-level AF01 ran 1, 2, 3, 4, 4 — the second step 4 (“use case ends”) contradicting the first (“resumes at step 4 of the basic flow”).
Why it mattersTest cases are written against step numbers. Two steps with one number produces either a missing test or a test for the wrong behaviour — and here the two steps describe opposite outcomes.
ResolvedRenumbered 1–5 with a single terminal step returning to basic flow step 4.
QA-06Data dictionary skipped two numbers that were in use elsewhereNumbering
FoundThe data dictionary jumped from DE08 to DE11. The scope-level use case had already assigned DE09 and DE10 to the medical history questionnaire and the consent indicator.
Why it mattersThe same identifiers denote different elements in different sections of one document.
ResolvedSingle contiguous register, DE001–DE014.
QA-07A mandatory requirement disappeared between document levelsScope
FoundThe scope-level use case listed a medical history questionnaire and a separate patient record ID as mandatory at submission. Neither appears in the detailed specification, the rules register, the data catalogue, or any of the three screen designs.
Why it mattersThe most serious class of specification defect: a requirement stated once and then silently dropped. Nobody decided to remove it, so nobody can say whether the clinic still needs it — and a medical history questionnaire is a clinical data set with its own consent and retention implications.
ResolvedDeliberately excluded from the register and raised as an open question for the stakeholder. Quietly reinstating it would have hidden the gap. A specification should not claim coverage it does not have.
QA-08Coverage check described as blocking in one place and non-blocking in anotherContradiction
FoundThe use case description stated that the system “validates the submission, including real-time OHIP eligibility” — implying a gate. BR013 states explicitly that a failed check does not block submission and the record is flagged for review instead.
Why it mattersThese produce opposite systems. Under one reading, a patient whose provincial service is momentarily unreachable cannot register at all; under the other, they register and a human checks later. The second is right — an external dependency should never be able to stop a patient registering — but the document supported both.
ResolvedBR013 governs. The description is corrected, and the non-blocking behaviour is now visible in the context diagram as a bidirectional flow to ACT003.
QA-09Capacity requirements not derived from the stated demandPlausibility
FoundAgainst a baseline of 8–12 registrations per day: NFR007 requires 50 submissions per hour, NFR006 requires 1,000 concurrent patient users, and NFR005 caps concurrent events at 200 — which contradicts NFR006 directly.
Why it mattersCapacity requirements drive infrastructure cost and are quoted against in procurement. Over-specifying them is not a free safety margin.
ResolvedNot silently rewritten — that would be an analyst substituting their own judgment for a stakeholder's. Flagged with the arithmetic attached, for the stakeholder to resolve.
QA-10An eligibility rule the patient could not discoverCoverage gap
FoundBR004 limits self-registration to patients aged 16 or over. Nothing on any screen, in any notification, or in the scope-level requirements said so — a 15-year-old would complete the entire form before being turned away, if the form told them at all.
Why it mattersA rule the user cannot see until they have failed it is an accessibility and fairness problem, not just a usability one.
ResolvedSurfaced at the date-of-birth field with the alternative path (call the clinic), and stated in the use case preconditions.
QA-11The status panel reports on fewer fields than the rule requiresCoverage gap
FoundCO012 displays five pre-submission checks. BR001's mandatory set contains ten elements. Home address and consent are mandatory and unrepresented in the panel.
Why it mattersThe panel can read “5 of 5” against an incomplete form. That was precisely the false reassurance the whole design exists to eliminate, reproduced inside the fix. Found by building the prototype in section 7, not by reading the document.
ResolvedThe prototype gates on the full mandatory set and shows the discrepancy in analyst view. Recommendation: add the two missing checks and change the label from a fixed “five” to a derived count.
QA-12An external actor missing from the context diagramCoverage gap
FoundACT003, the provincial health card validation service, appears in the actor list and acts at step 5 — but was absent from BCD001, which showed no external dependency at all.
Why it mattersThe context diagram is where a reader learns what the solution depends on. Omitting the one external service means nobody is prompted to ask what happens when it is unavailable.
ResolvedAdded as a dashed entity with both flows shown. Asking the question it raised is what surfaced QA-08.
QA-13Component tables and screen designs numbered differentlyNumbering
FoundThe component tables for UI002 and UI003 numbered CO018–CO024. The annotated designs for those same two screens carried CO018–CO034.
Why it mattersThe design is what a developer builds from and the table is what a tester works from. Different numbers for the same control means the two artifacts cannot be reconciled.
ResolvedReconciled to the design's numbering — the more granular of the two — and the tables rewritten to match.
QA-14Third-party personal information in the source documentPublication
FoundThe document control section carried six classmates' full names with their institutional email addresses, plus two faculty names.
Why it mattersNot a specification defect — a publication one. They co-authored a course deliverable; they did not agree to appear in my portfolio, and their contact details are not mine to publish.
ResolvedRemoved entirely. Contributions are credited by role in the panel at the top of this page.
10 — Limitations & reflection

What this specification does not prove

Honest limitations

  • No real stakeholder. The requirements were elicited from a course brief and a faculty member playing a role. Real elicitation involves contradictory stakeholders, and none of that pressure is present here.
  • No implementation, therefore no validation. Every objective on this page is a target. Requirements that look unambiguous on paper routinely fail their first contact with a developer, and this specification has never had that contact — except from me, building section 7.
  • No clinical review. A real registration flow would need sign-off on privacy, consent wording and record retention from people I did not have access to. BR016 cites a retention period; it has not been verified against the actual regulation.
  • Volume assumptions untested. See QA-09 — I flagged the capacity numbers but could not resolve them, because there was no one to resolve them with.
  • Accessibility is under-specified. The screens define validation and error states but say nothing about screen-reader behaviour, keyboard order, or the reading level of the error text. For a public health form serving the whole population, that is a gap I should have caught during the project. I caught it afterwards.

What I would do differently

  • Establish the identifier scheme before writing anything. Five of the thirteen defects are numbering collisions, and every one of them was avoidable with a single agreed register on day one. With seven authors, that convention is infrastructure, not admin.
  • Build the prototype during analysis, not after. QA-11 — the check panel narrower than its own rule — was invisible in the document and obvious within minutes of building it. Prototyping is an elicitation technique, not a presentation one.
  • Trace downward as well as upward. Our matrix proved every requirement had a parent. It would not have caught QA-07, where a requirement had a parent and simply no children.
  • Ask about volume before writing NFRs. The capacity figures were invented because nobody asked what the clinic actually expected. One question would have replaced three unusable requirements.

The point of a specification is that someone else can act on it without you in the room. By that standard the document we submitted was good and not finished: the analysis was sound, the models were right, and thirteen defects would still have reached a build team — most of them the unglamorous kind that cost a day each.

Auditing your own work as though a stranger wrote it is the step that turns a document into a deliverable.

Source document

The original team submission — Business Analysis Requirements: Online New Patient Registration, May 2026 — is available on request, with classmate and faculty details redacted. This page presents the reconciled version described in section 9, not the document as submitted.