Back to the 2026 paper

Module 1: Introduction & SDLC

20267m

A healthcare company plans an application through which patients can register, consult doctors online, upload medical reports, receive prescriptions and make payments. Requirements are expected to evolve after pilot deployment. Analyse the requirement and formulate an appropriate SDLC strategy, major functional and nonfunctional requirements, one suitable prototyping activity and two risks that should influence process selection.

Worked SolutionAI Assisted

Healthcare Application: Requirement Analysis and SDLC Strategy

1. Requirement analysis

Stakeholders: patients, doctors, administrators, pharmacy/lab staff, payment provider.
Key points: health data is sensitive, so privacy and security are critical; requirements are expected to evolve after the pilot, so the process must absorb change.

2. Major functional requirements

  • FR1 Patient registration and login
  • FR2 Doctor search and appointment booking
  • FR3 Online consultation (video/chat)
  • FR4 Upload and view medical reports
  • FR5 Doctor issues e-prescription; patient views/downloads it
  • FR6 Online payment and receipts
  • FR7 Notifications and reminders
  • FR8 Admin: manage users, doctors and reports

3. Major non-functional requirements

Quality Requirement
Security & privacy Encrypted data, role-based access, consent, audit log, compliance with health-data laws
Availability High uptime, especially for consultations
Performance Fast page loads, smooth video, large report uploads
Usability Simple UI for non-technical patients and elderly users
Reliability/Integrity Prescriptions and reports must never be lost or altered
Scalability Handle growth in patients and doctors
Interoperability Work with payment gateways and hospital systems

4. Appropriate SDLC strategy

Iterative-incremental with prototyping, run in an Agile/Spiral style.

  • Requirements are unclear and will change after the pilot, so a one-pass Waterfall is unsuitable.
  • Build and release in increments: registration and booking first, then consultation, then reports and prescriptions, then payments.
  • Use the pilot deployment as a feedback cycle; update the backlog before the next increment.
  • Add a risk review in every cycle (Spiral element) because of the sensitive data.

5. One prototyping activity

Build a throw-away UI prototype of the appointment booking and online consultation flow (clickable wireframes). Show it to a few patients and doctors, collect feedback on screens, navigation and steps, then refine the requirements before coding.

6. Two risks that influence process selection

Risk Effect on process choice
Requirement volatility after the pilot Needs an iterative/incremental model with change handling
Data privacy / regulatory compliance and security breaches Needs early and repeated security review (risk analysis every cycle), traceable documentation

Other possible risks: payment-gateway failures, video-service downtime, low user adoption.

Conclusion

An iterative, incremental, prototype-driven process with risk analysis (Agile/Spiral hybrid) fits best: it manages changing requirements while keeping security and privacy under control.

Similar questions

AI LearningWeb Platform

Coursify — Personal AI Course Generator

Struggling with a difficult subject or concept? Turn any engineering topic into a structured course with interactive lessons, quizzes, and research-backed explanations.