Skip to content

2. Elicitation Plan

This section defines the structured approach used to elicit, refine, and validate user and stakeholder requirements for the initial release of Sillah (صلة).

The elicitation process builds directly upon the Vision & Scope defined in Phase 1 and translates business objectives into structured, traceable user requirements.

2.1 Objectives

The primary objective of elicitation is to transform high-level business requirements into well-defined, prioritized, and evidence- supported system requirements.

  • Family Workflows

    Clarify detailed family-user workflows and preventive-health scenarios.

  • Risk Detection

    Validate expectations for rule-based hereditary-risk screening.

  • Bilingual Usability

    Confirm Arabic RTL and English LTR interface requirements.

  • Privacy and Security

    Identify privacy expectations and PDPL-aligned safeguards.

  • Alerts and Recommendations

    Capture expectations for preventive alerts and actionable guidance.

  • Traceable Outputs

    Produce a prioritized and evidence-backed requirement set.

2.2 Elicitation Techniques

Multiple complementary techniques were used to ensure balanced stakeholder input and requirement validation.

  • Interviews

    Conducted with family users and a healthcare provider to understand preventive-health workflows, privacy concerns, and usability expectations.

    Purpose: Extract qualitative functional and non-functional requirements.

  • Bilingual Survey

    Distributed to gather usability preferences and interface expectations across a broader user sample.

    Purpose: Validate patterns and identify preference trends.

  • Document Analysis

    Reviewed PDPL regulations and preventive-health guidelines.

    Purpose: Identify regulatory constraints and compliance requirements.

  • Observation & Competitive Review

    Analyzed current informal health-tracking behaviors and competing platforms.

    Purpose: Identify gaps and differentiation opportunities.

2.3 Participants

  • Family Members

    Primary end users who shaped profile management, alerts, and usability expectations.

  • Healthcare Providers

    Domain experts who validated screening logic and recommendation relevance.

  • Survey Respondents

    General users who broadened input on interface preferences and access expectations.

  • Regulatory and Public-Health Perspectives

    Addressed through document analysis rather than direct interviews.

2.4 Expected Outputs

  • Functional Requirements

    Structured user-facing system capabilities.

  • Non-Functional Requirements

    Security, usability, reliability, and related quality constraints.

  • Prioritized Requirement List

    Requirements ranked using the MoSCoW model.

  • Traceable Evidence Links

    Connections between requirements and elicitation sources.

  • Conflict Notes

    Identified ambiguities and resolution outcomes.

2.5 Risks and Mitigation

Risk Potential Impact Mitigation Strategy
Incomplete interview data Weak requirement clarity Cross-validation with survey responses
Conflicting stakeholder expectations Requirement ambiguity Consolidation discussions and prioritization
Scope expansion Delays and requirement creep Restrict to Phase 1 objectives
Privacy concerns Reduced participation Clarify anonymity and confidentiality
Response bias Misleading usability assumptions Use mixed techniques (interviews + survey)