Purpose, Scope & Audience
This SRS defines the functional and non-functional requirements of the Sillah Family Health Management System. It is intended to create a shared understanding between stakeholders and developers and to guide design, implementation, and validation.
The current release focuses on web-based family health tracking, health event recording, risk alert generation, dashboard summaries, and a limited database interaction layer. Direct diagnosis, real-time clinical decision-making, and hospital-system integration remain outside the current release scope.
Developers, testers, project managers, family-user stakeholders, healthcare validators, and the SE311 course evaluator each use this analysis package from a different angle. The document aligns with IEEE-style SRS expectations and consolidates the approved Phase 3 analysis content into one readable view.
The analyzed system centers on user registration and login, family member profile management, recording health conditions and events, generating preventive-health risk alerts, visualizing important health summaries on a dashboard, and supporting controlled SQL-based demo queries.
Interfaces & Operating Context
The detailed documented use case in the report is Manage Family Members. It captures the expected preconditions, normal flow, exceptions, and validation feedback patterns that recur across the wider Sillah feature set.
System Features
| Feature | Priority | Summary | Requirement IDs |
|---|---|---|---|
| User Account Management | HIGH | Registration, authentication, secure access control, and logout. | REQ-1 to REQ-5 |
| Family Member Management | HIGH | Add, edit, delete, and persist profiles linked to a user account. | REQ-6 to REQ-10 |
| Health Event Tracking | HIGH | Record, store, view, update, and delete health event history. | REQ-11 to REQ-15 |
| Risk Alert System | HIGH | Evaluate health data, generate alerts, and keep them associated with family members. | REQ-16 to REQ-20 |
| Dashboard & Visualization | MEDIUM | Summarize family health data, display active alerts, and refresh derived data clearly. | REQ-21 to REQ-25 |
| Database Interaction Demo Layer | MEDIUM | Support controlled SQL execution and CRUD demonstration workflows through the application. | REQ-26 to REQ-30 |
The approved report documents Manage Family Members in full detail. It shows a user navigating to the family-management area, selecting add/edit/delete actions, receiving validation feedback, confirming deletions, and seeing the list refreshed after save operations.
This use case also introduces two cross-cutting special requirements that shape the rest of the system: required-field validation before save and confirmation messaging after successful operations.
Non-Functional & Business Rules
Support 100 concurrent users, load key pages within 3 seconds, return action responses within 2 seconds, and show success confirmations promptly.
The system must not present itself as a diagnostic tool and should frame alerts as informational preventive guidance only.
Use HTTPS, require authentication, restrict access to owner data, securely store credentials, and respect privacy expectations including PDPL awareness.
The approved SRS explicitly requires bilingual Arabic and English support, including RTL/LTR layout handling, while also reinforcing privacy and confidentiality expectations under Saudi PDPL-aware handling.
Domain Model & Data Dictionary
| Entity | Description | Key Attributes | Notes |
|---|---|---|---|
| User | Registered person who owns and manages tracked family health records. | `user_id`, `email`, `password`, `role`, `created_at` | Unique account; secure authentication required. |
| Family Member | Tracked person linked to one user account. | `family_member_id`, `user_id`, `member_name`, `relationship`, `date_of_birth` | Supports one-to-many ownership from user to family members. |
| Health Event | Recorded condition or medical event tied to a family member. | `event_id`, `family_member_id`, `condition_name`, `severity`, `status` | Stores the timeline and status of health-related entries. |
| Risk Alert | Preventive-health notification generated from stored data and rules. | `alert_id`, `family_member_id`, `alert_title`, `risk_level`, `is_read` | Alerts remain informational and linked to the relevant family member. |
| Appointment | Booking or simulated clinic appointment linked to the health workflow. | `appointment_id`, `family_member_id`, `clinic_name`, `appointment_date`, `status` | Included as a supporting entity in the report appendix. |
| Dashboard Summary | Derived rollup data shown to the user after login. | `total_family_members`, `total_health_events`, `active_alerts_count` | Calculated from stored operational records. |
The domain model reinforces a user-owned data architecture: one user controls many family members, each family member can own multiple health events and risk alerts, and dashboard values are derived from the accumulated records. This keeps the system centered on family-tracking workflows rather than provider-owned records.
Priority Summary
User account management, family member management, health event tracking, and risk alert generation together represent the minimum meaningful operational release. These features create the secure, family-centered preventive-health workflow described throughout the SRS.
Dashboard visualization and the database interaction demo layer provide visibility, reporting, and demonstration support, but they rely on the high-priority features to produce useful data and user value.
Validation & Approval
The Phase 3 report notes strong positive agreement around preventive-health tracking, risk alert functionality, and the family-centered interaction model. Overall, more than 80% of participants accepted the proposed system features, supporting alignment with user needs.
Approved By: Dr. Lama Alalula
The approved PDF also includes signed approval evidence in Appendix E.