Skip to content

Use Cases

Phase 3 documents the interaction logic of the Sillah system through use-case style analysis. The detailed example in the approved report focuses on Manage Family Members, while the surrounding features follow the same actor-centered structure.

Primary Use Case Catalog

Use Case Primary Actor Goal
Register / Log In User Gain secure access to the system
Manage Family Members User Add, edit, and remove family member profiles
Record Health Events User Store and maintain health event history
Review Risk Alerts User View preventive-health alerts generated by the system
View Dashboard User Monitor summaries, trends, and current alerts
Run Demo Queries User / Evaluator Execute approved SQL-based demo interactions

Detailed Use Case: Manage Family Members

Field Value
Use Case ID 1
Use Case Name Manage Family Members
Created By Shoug Alomran
Last Updated By Ghala Alsaqer
Date Created 10/4/2026
Date Last Updated 23/4/2026
Actors User

Description

A user accesses the Sillah system through a web browser, reviews the existing family member profiles linked to the account, and can add, edit, or delete family member information.

Preconditions

  1. The user is logged into the system.

Postconditions

  1. Family member information is stored or updated in the system.
  2. The latest family member data is reflected in the interface.

Normal Flow

  1. User navigates to the family management section.
  2. System displays a list of existing family members.
  3. User chooses to add, edit, or delete a family member.

Add family member

  1. System displays a form for entering family member details.
  2. User enters the required information.
  3. System validates the input data.
  4. System saves the new family member profile.

Edit family member

  1. User selects an existing family member.
  2. System displays the current details.
  3. User modifies the information.
  4. System validates the updated data.
  5. System saves the change.

Delete family member

  1. User selects a family member to delete.
  2. System requests confirmation.
  3. User confirms deletion.
  4. System removes the family member profile.

Alternative Flow

  1. User cancels the operation at any step.
  2. System returns to the family member list without saving changes.

Exception Flow

  1. System detects missing or invalid required fields.
  2. System displays error messages.
  3. User corrects the input data before resubmitting.

Includes

None

Priority and Frequency

  • Priority: High
  • Frequency of Use: Frequently used by all users to manage family data
  • BR-2 A user may create, update, or delete multiple family member profiles associated with their account.
  • BR-3 Health events and conditions shall be recorded only for existing family members.
  • BR-10 The system shall ensure that all required fields are completed before storing any health-related data.

Special Requirements

  • The system shall validate all required fields before saving data.
  • The system shall display confirmation messages after successful operations.

Assumptions

  • Users provide accurate and complete family member information.

Notes

  • Future versions may introduce additional health-related attributes for each family member.

Use-Case Design Observations

The analyzed use cases highlight several recurring patterns across the system:

  • authenticated access before any health-data interaction
  • input validation before data is stored
  • confirmation feedback after successful actions
  • explicit ownership of records by the logged-in user
  • dynamic updates when health data changes alert outcomes

These interaction rules are reused across the wider Phase 3 feature set, even when only one use case is documented in full detail in the report.