01
Elicitation Plan
Objectives
The elicitation process aims to refine the Phase 1 Vision & Scope into structured, traceable user requirements for the initial release of Sillah. Specifically:
OBJ-1
Clarify detailed family user needs and workflows.OBJ-2
Validate rule-based hereditary risk detection expectations.OBJ-3
Confirm bilingual usability requirements (Arabic RTL / English LTR).OBJ-4
Identify security and privacy expectations aligned with PDPL.OBJ-5
Capture preventive health alert and recommendation expectations.OBJ-6
Produce a prioritized and evidence-supported set of user requirements.Elicitation Techniques
Facilitated
T-1
Interviews with healthcare providersT-2
Bilingual survey (Arabic + English)Independent
T-3
Document analysis (PDPL + screening guidelines)T-4
Observation of family health tracking habitsT-5
Competitive review of similar health platformsRisks & Mitigation
| Risk | Impact | Mitigation |
|---|---|---|
| Incomplete interview data | Weak requirement clarity | Cross-validation with survey |
| Conflicting stakeholder expectations | Requirement ambiguity | Consolidation discussion |
| Scope expansion | Delay in delivery | Restrict to Phase 1 features |
| Privacy concerns | Limited participation | Clarify confidentiality |
02
Stakeholder Analysis
Identified Stakeholders
Primary
Families
Individuals who use the system to track hereditary health conditions and receive preventive alerts.
Clinical
Healthcare Providers
Doctors who validate the medical relevance of risk detection and recommendations.
Operational
System Administrators
Responsible for managing content, user roles, and system integrity.
Regulatory
Legal / Regulatory (PDPL)
Ensure compliance with the Personal Data Protection Law.
Stakeholder Mapping
| Stakeholder | Role | Interest | Influence | Engagement |
|---|---|---|---|---|
| Families Primary Users |
Track hereditary health and receive alerts | Early detection, usability, privacy | High | Survey |
| Healthcare Providers | Validate medical screening logic | Clinical accuracy, preventive guidance | High | Interview |
| System Administrators | Manage roles, content, system integrity | Secure access control, content reliability | Medium | Document Analysis |
| Legal / PDPL Authority | Ensure data protection compliance | Protection of sensitive health data | High | Document Analysis |
| Public Health Authority Future |
Potential national integration partner | Population-level insights, Vision 2030 alignment | Medium | Document Analysis |
03
Interviews
Session 1
Dr. Lama Alalula
Ear-Nose-Throat (ENT) Surgeon
Date: 15 March 2026
Session 2
Dr. Alhanouf Alaloola
Cardiac Surgeon
Date: 28 March 2026
Key Findings
Functional Findings
Both providers collect family medical history directly from patients or parents. Chronic conditions, cancer history, and congenital heart disease were identified as the most valuable to track. Both agreed children should be included from birth for early risk detection. Preventive actions should include screening tests, specialist referrals, and lifestyle modifications.
Data Reliability Findings
Extended family medical information is often incomplete or unknown. Both providers expressed low trust in patient-entered data — one explicitly recommended that data should be entered or validated by a healthcare professional.
Usability & Workflow Findings
Neither provider has used a dedicated family health platform. Both were uncertain about medically appropriate alert phrasing. One preferred a brief summary; the other preferred summaries tailored to appointment type. Time constraints and preference for direct patient interaction were identified as adoption barriers.
System Integration Findings
One provider highlighted the importance of integration with existing national health platforms, suggesting that future scalability depends on interoperability with existing healthcare infrastructure.
Extracted Requirements from Interviews
MUST
SHOULD
COULD
| ID | Requirement Statement | Evidence | Priority | Acceptance Criteria |
|---|---|---|---|---|
| HPR-I01 | The system allows healthcare professionals to enter or validate family health data to ensure reliability. | Session 1 & 2 | MUST | Verified data is clearly distinguished from patient-entered data. |
| HPR-I02 | The system tracks the history of cancer as a key hereditary condition. | Session 1 | MUST | Users can record cancer history with type, age of onset, and family relationship. |
| HPR-I03 | The system tracks congenital heart disease as a key hereditary condition. | Session 2 | MUST | Users can record congenital heart disease with diagnosis details and affected members. |
| HPR-I04 | The system includes pediatric profiles from birth for early risk screening. | Session 1 & 2 | MUST | Users can add family members from age 0; risk screening applies to all age groups. |
| HPR-I05 | The system provides a patient summary view with brief medical history. | Session 1 | SHOULD | Summary displays key medical history including chronic conditions and family history. |
| HPR-I06 | The system provides a patient summary view tailored to appointment reason. | Session 2 | COULD | Summary highlights relevant health data based on the patient's scheduled appointment type. |
| HPR-I07 | The system integrates with existing national health platforms. | Session 1 | COULD | Future release supports API integration with national platforms for data exchange. |
04
Family User Requirements
Requirement Format
Each Family User Requirement (FUR) includes: a unique ID for traceability, a requirement statement in the "must" format, the evidence source linked to an elicitation method, a MoSCoW priority, and measurable acceptance criteria for verification.
MUST — Essential
SHOULD — Important
COULD — Nice to have
| ID | Requirement Statement | Evidence | Priority | Acceptance Criteria |
|---|---|---|---|---|
| FUR-01 | The system must allow authenticated users to create, edit, and delete multiple family member profiles with demographic information and associated health records. | Family Interview | MUST | Profiles include required attributes, persist after saving, and only authorized users can modify them. |
| FUR-02 | The system must allow users to record hereditary conditions — cardiac disease, diabetes, hypertension, and high cholesterol — for each family member. | Family Interview | MUST | Conditions are stored per profile and are retrievable and editable. |
| FUR-03 | The system must generate personalized preventive alerts based on predefined screening rules applied to recorded family health data. | Family + HP Interviews | MUST | Alerts triggered when rule conditions are met, specific to user data, clearly displayed. |
| FUR-04 | The system must display preventive recommendations alongside generated alerts. | Family Interview | SHOULD | Each alert includes a corresponding recommendation, relevant to detected risk. |
| FUR-05 | The system must support a bilingual interface (Arabic RTL and English LTR), allowing users to switch languages dynamically. | Survey Results | MUST | Layout adjusts correctly (RTL/LTR) and all interface elements are translated. |
| FUR-06 | The system must allow users to simulate booking a clinic appointment. | Family Interview | SHOULD | Users can submit booking details and receive a confirmation message. |
| FUR-07 | The system must allow users to view previously generated alerts and notification history. | Family Interview | SHOULD | Alerts displayed in a structured format (list or timeline) and remain accessible after new alerts. |
| FUR-08 | The system must require secure authentication before allowing access to personal health data. | Document Analysis | MUST | Unauthorized access denied; session management enforced. |
| FUR-09 | The system must restrict access to health data based on user role. | Document Analysis | MUST | Role-based permissions enforced; unauthorized actions blocked. |
05
Healthcare Provider Requirements
Source & Format
Derived from healthcare provider interviews and supported by survey findings to ensure clinical relevance and real-world workflow alignment. Each requirement uses the "shall" format with a unique HPR identifier, MoSCoW priority, and measurable acceptance criteria.
| ID | Requirement Statement | Evidence | Priority | Acceptance Criteria |
|---|---|---|---|---|
| HPR-01 | The system shall allow healthcare providers to enter, update, and validate family medical history data to ensure accuracy and reliability. | Session 1 & 2 | MUST | Providers can mark data as verified; verified data is clearly distinguishable from unverified. |
| HPR-02 | The system shall allow healthcare providers to view a summarized patient profile including key medical history and hereditary conditions. | Session 1 & 2, Survey | MUST | Summary accessible during consultation in a concise format. |
| HPR-03 | The system shall allow healthcare providers to access patient data relevant to the reason for the appointment. | Session 2 | SHOULD | Data displayed aligns with appointment type; irrelevant information is minimized. |
| HPR-04 | The system shall generate clinically appropriate preventive alerts based on patient and family health data. | Session 1 & 2, Survey | MUST | Alerts triggered on predefined rules; medically relevant and clearly displayed. |
| HPR-05 | The system shall provide recommended actions after risk detection including screening tests, specialist referrals, and lifestyle advice. | Session 1 & 2, Survey | SHOULD | Each alert includes at least one recommendation, relevant to detected risk. |
| HPR-06 | The system shall present alerts and recommendations using clear, standardized, and medically appropriate language. | Session 1 & 2 | SHOULD | Alerts use consistent phrasing; providers can interpret without additional clarification. |
| HPR-07 | The system shall be designed to minimize disruption to healthcare providers' workflow. | Session 2 | SHOULD | Key information accessible within minimal steps; navigation is efficient and intuitive. |
| HPR-08 | The system shall support pediatric patient profiles to enable early hereditary risk screening from birth. | Session 1 & 2 | MUST | Providers can manage profiles for patients aged 0+; screening rules apply to pediatric profiles. |
| HPR-09 | The system shall support future integration with existing national health platforms through secure APIs. | Session 1 | COULD | Architecture allows API integration; data exchange follows secure standards. |
06
Survey
Survey Design
A bilingual survey (Arabic and English) was distributed to collect general and role-specific requirements from patients, family members, healthcare providers, and administrative staff. Structured into three sections: demographic questions, general system usage and preferences, and role-specific questions. The purpose was to validate requirements from interviews and capture usability, functionality, security, and preventive health expectations.
Response Summary — 32 Total Responses
87.5%
Female respondents
84.4%
Aged 19–25 years
50%
Used digital health tracking before
53.1%
Use health apps only occasionally
59.4%
Interested in managing family profiles
87.5%
Agreed on role-based access control
Language Preferences
56.3%
Preferred English interface
40.6%
Preferred Arabic interface
Key Insights
1
Strong Demand for Family-Centered Functionality
The majority showed clear interest in managing multiple family profiles, reinforcing the importance of a family-based system design.
2
Need for Preventive Health Features
High interest in automated alerts and recommendations indicates users value proactive health management and early risk detection.
3
Low Engagement with Existing Health Applications
Most users reported only occasional or rare use, suggesting current solutions may lack usability or relevance. The system should prioritize simplicity, clarity, and ease of use.
4
Importance of Security and Privacy
Strong agreement on role-based access control highlights the importance of protecting sensitive health data and ensuring PDPL compliance.
5
Requirement for Bilingual Support
The distribution of language preferences confirms the need for a bilingual system supporting both Arabic (RTL) and English (LTR).
6
Interest in Advanced Future Features
Open-ended responses suggested AI-based risk prediction, emergency alert systems, integration with wearable devices, and health trend tracking for future enhancements.
07
Administrator Requirements
Focus
Administrator requirements (AUR) focus on system management, access control, and operational oversight. Each requirement uses the "shall" format with MoSCoW priority and measurable acceptance criteria.
| ID | Requirement Statement | Evidence | Priority | Acceptance Criteria |
|---|---|---|---|---|
| AUR-01 | The system shall allow administrators to manage user roles and enforce access permissions. | Survey + Interview | MUST | Admin can assign roles; unauthorized users cannot access restricted data. |
| AUR-02 | The system shall allow administrators to manage user accounts (create, update, deactivate). | Survey + System Logic | MUST | Changes are saved and reflected immediately; only authorized admin can modify accounts. |
| AUR-03 | The system shall ensure secure authentication and protect user health data. | Survey + Doc Analysis | MUST | Users must log in before accessing; unauthorized access is denied; data is protected. |
| AUR-04 | The system shall allow administrators to manage awareness and educational content. | Survey + Doc Analysis | MUST | Admin can add, edit, and delete content; updates visible to users; content stored correctly. |
| AUR-05 | The system shall allow administrators or authorized roles to validate and ensure the accuracy of health data. | Interview | MUST | Verified data is clearly marked; system distinguishes verified from unverified data. |
| AUR-06 | The system shall record all administrative actions in an audit log. | Survey | SHOULD | All admin actions recorded with action type and timestamp; logs accessible by admin. |
| AUR-07 | The system shall allow administrators to add and manage clinics in the system. | Survey | SHOULD | Admin can add new clinics; clinic information is stored, retrievable, and visible to users. |
| AUR-08 | The system shall allow administrators to review and approve content before publishing. | Interview + Doc Analysis | SHOULD | Only approved content is visible; system tracks content status (approved/pending). |
| AUR-09 | The system shall allow administrators to monitor system activity. | System Logic | SHOULD | Admin can view system activity; errors are logged and visible. |
08
Document, Observation & Competitive Analysis
Document Analysis
Reviewed PDPL of Saudi Arabia, preventive health screening guidelines for hereditary conditions, data protection best practices, and privacy policy guidelines. Objective: identify legal/regulatory constraints, privacy requirements, authentication mechanisms, and user consent considerations.
Observation Notes
Observed how families currently track health information, particularly for hereditary conditions. Finding: many families lack a structured method — information is either remembered from conversations or written in scattered locations, making it easy to forget important preventive screening details.
Competitive Review
Reviewed existing health-related applications to identify common preventive-health features, analyze alert presentation styles, review multilingual support implementation, and evaluate UI simplicity. Purpose: understand industry norms and identify usability improvements — not to replicate competitors.
Key Observation Insight
Most families do not have a structured way of organizing health information. Information is either remembered from conversations or written in different places, revealing usability gaps and inefficiencies — demonstrating the need for a simpler and more organized approach to tracking preventive screenings and family health history.
09
Consolidated Prioritized User Requirements
Overview
Final consolidated list from all elicitation activities — interviews, surveys, document analysis, observation, and competitive analysis — combining requirements from all stakeholder groups (Family Members, Healthcare Providers, and Administrators) and prioritized using MoSCoW.
| ID | Requirement Statement | Priority | Stakeholder |
|---|---|---|---|
| UR-01 | The system shall allow users to track medication schedules and receive reminders. | MUST | Family |
| UR-02 | The system shall allow users to monitor health indicators such as blood pressure and glucose levels. | MUST | Family |
| UR-03 | The system shall allow healthcare providers to view patient health data remotely. | MUST | Healthcare Provider |
| UR-04 | The system shall allow healthcare providers to update patient medical records. | MUST | Healthcare Provider |
| UR-05 | The system shall provide emergency alert functionality for critical health situations. | MUST | Family |
| UR-06 | The system shall allow administrators to manage user accounts and roles. | MUST | Administrator |
| UR-07 | The system shall generate reports for healthcare providers based on patient data. | SHOULD | Healthcare Provider |
| UR-08 | The system shall allow communication between patients and healthcare providers. | SHOULD | Family / HP |
| UR-09 | The system shall provide data visualization (charts/graphs) for health trends. | COULD | Family |
| UR-10 | The system shall support integration with wearable health devices. | COULD | Family |
6
Must Have requirements
2
Should Have requirements
2
Could Have requirements
3
Stakeholder groups