Software Analysis Meets Hospital Web ApplicationSillah
A comprehensive presentation of the Sillah project journey based only on the approved Phase 1, Phase 2, and Phase 3 reports: from vision and scope, to elicitation, to software requirements analysis for a family-centered preventive health web platform.
Presentation Map
Top-level sections for quick navigation through the complete project story.
Project In One View
The reports consistently position Sillah as a family-centric preventive-health web platform aimed at hereditary condition awareness and early risk detection.
Vision & scope, elicitation, and requirements analysis.
Used to validate the proposed system direction.
Documented in the Phase 3 analysis package.
The minimum meaningful operational release.
Listed among the Phase 3 quality attributes.
Problem Context
Phase 1 identifies a rising number of inherited heart diseases and other hereditary conditions in Saudi Arabia, paired with the lack of a proper family-centered system for monitoring health records and advising on inherited risks.
Project Direction
The reports align around a web-based, bilingual, preventive-health platform with family profile management, health-event recording, rule-based alerts, dashboard summaries, and simulated clinic-oriented support.
- Aligned with Saudi Vision 2030 and preventive healthcare digitization.
- Constrained by prototype scope, privacy requirements, and non-diagnostic positioning.
- Designed to be mobile-first, accessible, and secure.
How The Project Progressed
The project moved in a classic software analysis sequence: define the product, elicit stakeholder needs, then formalize the specification.
Vision And Scope
Phase 1 framed the business need, the target users, the feature scope, the project priorities, and the product limitations for the first release.
Requirements Elicitation
Phase 2 gathered evidence through interviews, surveys, observation, document analysis, and competitive review to refine traceable user requirements.
Requirements Analysis
Phase 3 translated those needs into a structured SRS with functional requirements, interfaces, quality expectations, business rules, and a domain model.
Definition And Scope Control
Versioned document history in Phase 1 shows refinement from template population to final revision, keeping the scope anchored around the initial preventive-health experience.
Evidence And Prioritization
MoSCoW prioritization and stakeholder-specific requirements helped separate essential functions from future enhancements and cross-check assumptions against real feedback.
Specification And Validation
The approved SRS consolidated the project into an implementation-ready analysis package while retaining limits such as no diagnosis and no hospital-system integration in the current release.
Vision, Scope, And Business Case
This phase established why Sillah should exist, what the first release should contain, and what the prototype should explicitly avoid.
Business Opportunity
The reports position Sillah as a response to the lack of a unified, family-centric digital system in Saudi Arabia that can track hereditary cardiac conditions, detect risk patterns, provide personalized alerts, connect users to clinics, offer culturally relevant awareness content, and support bilingual accessibility.
Business Objectives
- Increase early detection of hereditary cardiac risks through structured family health data collection and screening.
- Provide a user-friendly digital tool for recording and analyzing family health data.
- Reduce long-term healthcare costs through preventive action.
- Support national health initiatives and demonstrate prototype feasibility.
Initial Release Scope
- Family member and health event management.
- Rule-based hereditary risk detection for cardiac disease, diabetes, hypertension, and high cholesterol.
- Personalized alerts and recommendations.
- Awareness Hub, clinic booking simulation, bilingual interface, authentication, and responsive UI.
Limitations And Exclusions
- No real medical diagnosis.
- No hospital electronic health record integration in the prototype.
- No AI or machine-learning prediction in the current version.
- No real-time clinic availability, production-grade notifications, or genetic-testing data ingestion.
Usability And Completion
Phase 1 sets targets such as at least 80% onboarding completion, family tree creation in under five minutes, and a System Usability Scale score of at least 80.
Adoption, Data, And Compliance
Business risks include low trust in sharing sensitive health data, inaccurate entry, evolving clinical rules, overlapping competitors, and prototype-level compliance demands.
Hospital-Web Readiness
Deployment considerations emphasize HTTPS, secure authentication, Saudi-wide access, mobile-first usage, AST scheduling alignment, and full Arabic support with culturally appropriate content.
Requirements Elicitation And Stakeholder Evidence
This phase turned the Phase 1 vision into evidence-backed user requirements with clear stakeholder coverage.
Elicitation Techniques
- Interviews with healthcare providers.
- Bilingual survey in Arabic and English.
- Document analysis using PDPL and screening guidelines.
- Observation of family health tracking habits.
- Competitive review of similar health platforms.
Stakeholders
- Families as primary users.
- Healthcare providers as clinical validators.
- System administrators for operational control.
- Legal and regulatory stakeholders for PDPL alignment.
- Public health authorities as future integration stakeholders.
Dr. Lama Alalula
ENT surgeon, interviewed on 15 March 2026. Phase 2 records a preference for concise patient summaries and highlights the value of family history and clinically useful recommendations.
Dr. Alhanouf Alaloola
Cardiac surgeon, interviewed on 28 March 2026. Phase 2 notes support for summaries tailored to appointment context and concern for workflow disruption.
32 Responses
The survey validated family-centered features, preventive alerts, bilingual support, role-based access control, and strong interest in privacy and usability.
What Stakeholders Wanted
Track chronic and hereditary conditions, include pediatric profiles from birth, show meaningful alerts, provide specialist referrals or lifestyle guidance, and preserve medically appropriate language.
Core User Expectations
Create and manage multiple family profiles, record hereditary conditions, generate personalized alerts, view notification history, simulate appointments, and switch dynamically between Arabic and English.
Accuracy And Control
Providers wanted validated data, concise patient summaries, and clinically appropriate guidance. Administrators needed role management, user account control, educational-content management, and secure oversight.
Survey Highlights
- 87.5% female respondents.
- 84.4% aged 19–25 years.
- 59.4% interested in managing family profiles.
- 87.5% agreed on role-based access control.
- Language preference split confirmed the need for bilingual support.
Observation And Document Analysis
Phase 2 found that many families do not have a structured way to organize health information, while PDPL and preventive screening guidelines shaped the security, privacy, and consent expectations for the system.
Software Requirements Analysis And SRS
Phase 3 formalized the system into release scope, interfaces, detailed features, quality attributes, business rules, and a domain model.
Operating Context
- Runs in modern browsers including Chrome, Firefox, Edge, and Safari.
- Frontend stack: React and Vite.
- Backend stack: Node.js and Express.
- Supabase supports authentication and application data storage; MySQL supports the CS340 Phase 5 demo layer.
- Intended for cloud hosting and access from desktop and mobile devices.
Release Scope
The current release focuses on web-based family health tracking, health event recording, risk alert generation, dashboard summaries, and a limited database interaction layer, while direct diagnosis, real-time clinical decision-making, and hospital-system integration remain out of scope.
User Account Management
Registration, authentication, secure access control, credential validation, and logout capabilities form the secured entry point of the system.
Family Member Management
Add, edit, delete, and persist family member profiles while linking every profile to the owning user account.
Health Event Tracking
Record, store, view, update, and delete health event history for each tracked family member.
Risk Alert System
Evaluate stored health data against predefined rules, generate alerts, and update them dynamically as new information is entered.
Dashboard And Visualization
Summarize family health records, display active alerts, and refresh derived insights in real time or on demand.
Database Demo Layer
Provide controlled SQL execution and CRUD demonstration workflows through the application interface.
Quality And Safety Requirements
- Support 100 concurrent users.
- Load key pages within 3 seconds and action responses within 2 seconds.
- Maintain at least 99% availability excluding scheduled maintenance.
- Ensure HTTPS, authentication, owner-only access, secure credential storage, and privacy awareness.
- Keep alerts informational and preventive rather than diagnostic.
Domain Model
Phase 3 defines the key entities as User, Family Member, Health Event, Risk Alert, Appointment, and Dashboard Summary, reinforcing a user-owned data model in which one user manages multiple family members and each member can hold events and alerts.
Prototype And Presentation Imagery
You added real prototype screens in the project images folder, so this section now uses them directly to support the report-driven narrative.
Dashboard As The Operational Hub
This screen aligns with the Phase 3 feature set by surfacing family-member counts, appointments, health records, unread alerts, quick actions, and a privacy-focused access message in one view.
Supports: dashboard visualization, owner-controlled access, and the family-centered workflow described across the reports.
Family Tree And Condition Tracking
The family health tree visual supports the Phase 2 and Phase 3 emphasis on adding, editing, and reviewing family-member profiles together with hereditary-condition data.
Supports: the documented “Manage Family Members” use case and the user-owned domain model.
Provider Dashboard
The doctor portal reinforces the provider-facing needs captured during elicitation: patient access, appointment handling, medication workflows, and a clinically structured portal experience.
Supports: healthcare-provider requirements and future clinical workflow alignment discussed in Phase 2.
Alert And Recommendation Flow
The medical alerts interface visually complements the reports’ emphasis on rule-based preventive alerts, notification history, and recommendation content that guides users toward next steps without crossing into diagnosis.
Why These Screens Fit The Presentation
These images map directly to major report themes: family-centered data ownership, preventive alerting, dashboard summaries, privacy-aware access, and the bridge between patient and provider workflows in a healthcare web application.
How The Platform Feels In Use
These additional screens make the presentation feel complete by showing entry, guidance, prevention, and follow-up moments across the user journey.
Secure Entry Point
The login screen supports the reports’ repeated emphasis on secure authentication, controlled access to sensitive health data, and a clean bilingual-friendly patient-facing experience.
Risk Assessment
A direct visual match for the preventive-alert and rule-based screening story documented in all three phases.
Appointments
Supports the simulated booking and follow-up workflow repeatedly described in the scope and user requirements.
Awareness Hub
This screen reinforces one of Sillah’s strongest differentiators in the reports: culturally relevant preventive education, curated resources, and guided health-awareness content for families.
Evidence Of Acceptance And Quality
The reports include both quantitative and qualitative support for the direction of the system.
Stakeholder Acceptance
Phase 3 records strong positive agreement around preventive-health tracking, risk alert functionality, and the family-centered interaction model, noting that more than 80% of participants accepted the proposed system features.
Survey-Backed Direction
Phase 2 highlights clear demand for family-centered functionality, preventive alerts, security and privacy protections, and bilingual usability, while also identifying future interest in AI prediction, emergency alerts, wearable integration, and trend tracking.
Security And Privacy
Role-based access control and privacy protection received strong stakeholder emphasis, consistent with PDPL-aware handling across the reports.
Bilingual Readiness
The language preference split in Phase 2 and the repeated Phase 1 and Phase 3 requirements make bilingual Arabic and English support a validated necessity, not just a design preference.
Clinical Framing
Healthcare interviews helped shape the system as a preventive support tool with structured summaries and recommendations, while keeping diagnosis out of scope.
What We Delivered Through The Reports
Taken together, the three reports show a coherent software-analysis arc from business need to structured specification.
Source basis for this presentation: Phase 1 Vision & Scope, Phase 2 Requirements Elicitation, and Phase 3 Requirements Analysis reports, plus the local project images already present in the repository. No additional project facts were introduced beyond those materials.