Skip to content

5. Family User Requirements

The following family user requirements were derived from interview findings, survey validation, and supporting document analysis.

Requirements were prioritized using the MoSCoW technique.


5.1 Requirement Format

  • ID

    Unique identifier for traceability.

  • Requirement Statement

    Written in mandatory system behavior form.

  • Evidence Source

    Linked to the elicitation activity that supports it.

  • Priority

    Assigned using the MoSCoW method.

  • Acceptance Criteria

    Measurable conditions used to verify the requirement.


5.2 Prioritized Family Requirement List

ID Requirement Statement Evidence Source Priority Acceptance Criteria
FUR-01 The system must allow authenticated users to create, edit, and delete multiple family member profiles, where each profile includes demographic information such as age, gender, relationship, and associated health records. Family Interview Must Users can create, update, and delete profiles; required profile attributes are stored; data persists after saving; only authorized users can modify profiles.
FUR-02 The system must allow users to record hereditary conditions for each family member, including cardiac disease, diabetes, hypertension, and high cholesterol. Family Interview Must Users can select or enter conditions; conditions are stored per profile; data is retrievable and editable.
FUR-03 The system must generate personalized preventive alerts based on predefined screening rules applied to recorded family health data. Family Interview + Healthcare Provider Interview Must Alerts are triggered when rule conditions are met; alerts are specific to the user's data; alerts are displayed clearly in the interface.
FUR-04 The system must display preventive recommendations alongside generated alerts. Family Interview Should Each alert includes a corresponding recommendation; recommendations are relevant to the detected risk; recommendations are clearly distinguishable from alerts.
FUR-05 The system must support a bilingual interface in Arabic (RTL) and English (LTR), allowing users to switch languages dynamically. Survey Results Must Users can switch language at any time; layout adjusts correctly for RTL/LTR; interface text is translated consistently.
FUR-06 The system must allow users to simulate booking a clinic appointment. Family Interview Should Users can submit booking details; the system confirms submission; a confirmation message is displayed.
FUR-07 The system must allow users to view previously generated alerts and notification history. Family Interview Should Users can access alert history; alerts appear in a structured format such as a list or timeline; past alerts remain accessible after new alerts are generated.
FUR-08 The system must require secure authentication before allowing access to personal health data. Document Analysis Must Users must log in before accessing protected features; unauthorized access is denied; session management is enforced.
FUR-09 The system must restrict access to health data based on user role. Document Analysis Must Users can only access permitted data; role-based permissions are enforced; unauthorized actions are blocked.

5.3 Key Observations

  • Profile-Based Tracking

    Family users need multiple linked profiles rather than a single-person record.

  • Personalized Guidance

    Preventive alerts and recommendations are expected to be relevant and easy to understand.

  • Bilingual Experience

    Arabic and English support is a core requirement, not an optional enhancement.

  • High Security Expectations

    Users expect strong protection for sensitive family health data.