System Requirements Document for jemaat-gereja-data

1. Introduction

jemaat-gereja-data is the implementation project for EcclesiaCare, a Sistem Informasi & Data Jemaat Gereja — a church member information and data system for Indonesian congregations. The product exists so that a congregation's living record — who its members are, where they live, which family and ministry they belong to, which sacraments they have received, who showed up to worship, what the church owns, and who is scheduled to serve — can be recorded once, kept accurate, synchronized in real time through the cloud, and turned into reports, dashboards, reminders, and notifications that help church leadership care for people.

The audience is the internal working team of a congregation: the staff and volunteers who maintain member data, the pastors/imams and church leaders who coordinate ministry and monitor the congregation's health, the administrative and reporting officers who produce monthly and weekly reports and communicate with members, and the officers who look after the church's physical assets. EcclesiaCare is a working tool for these people, not a public-facing congregational portal.

2. System Overview

EcclesiaCare is delivered as a first-party web application with an application-owned identity layer, a cloud-synchronized database, background automation for birthday reminders and weekly reporting, generated PDF and Excel documents, and outbound push notifications to members and workers.

Actors. Four accepted human personas use the system: the Administrator Data Jemaat, the Pemimpin/Pelayan Gereja (Pendeta, Imam, Pengurus), the Petugas Administrasi & Pelaporan, and the Petugas Inventaris Aset Gereja. Non-persona actors are the cloud synchronization service, the background automation scheduler, the push notification delivery service, and the PDF/Excel document generator.

Accepted behavior. The system records member master data (nomor induk jemaat, nama, tempat/tanggal lahir, jenis kelamin, NIK, alamat lengkap, nomor HP/WA, pekerjaan, pendidikan terakhir/sekolah) together with sacramental history (penyerahan anak, baptisan air, pemberkatan nikah); synchronizes that data in real time on a cloud basis; groups members by age group (anak sekolah minggu, kaum muda remaja, dewasa muda, usia lanjut), wilayah, keluarga, and jenis pelayanan; provides fast and accurate member search through specific filter criteria; presents an attendance statistics dashboard and a congregation growth dashboard; sends automatic birthday reminders for registered members; sends push notifications for weekly worship schedules and church events; produces automatic weekly reporting of worship activities and attendance; exports monthly reports in PDF and Excel; manages church asset inventory; and manages ministry/imam service together with scheduled task lists for each ministry member.

Ownership. All member data, grouping, attendance, growth, reporting, event, inventory, and ministry-task work is owned by first-party EcclesiaCare pages. Identity establishment and returning verification are owned by first-party access surfaces. Birthday reminders, weekly report generation, and push notification dispatch are background automation owned by the system, with their human-visible results surfaced on the pages that own the corresponding responsibility.

Exclusions. EcclesiaCare does not provide public congregational self-service, member-facing portals, online giving or financial accounting, or general church financial management. It does not replace the church's own pastoral decision-making. No capability beyond those listed above is in scope.

2a. Product Interpretation and Delivery Boundary

EcclesiaCare is a cloud-synced internal system. Every record a user creates or edits is written to the cloud database and synchronized in real time, so two workers editing different members, or one worker checking attendance while another updates a member profile, see a consistent, current picture rather than a stale local copy.

Access is application-owned. Because member records, sacramental history, attendance, ministry assignments, and asset records are durable, person-specific, and must remain bound to the correct worker and congregation, the system establishes identity on first use and verifies it on return. The public entry surface is anonymous and explains what EcclesiaCare is; the working surfaces that hold member data and church operations are protected. Access to individual working surfaces follows the responsibility each persona holds, so that member data, reporting, ministry coordination, and asset records are each handled by the people accountable for them.

Delivery is current for everything described in this document. Background automation — birthday reminders, weekly worship and attendance reporting, and push notification dispatch — runs without a user present, but every result it produces is visible and actionable on a first-party page. Generated documents (monthly PDF and Excel reports) are produced by the system and delivered to the user who requested them. Push notifications are delivered to their recipients by the notification service; the system owns the schedule, content, and trigger, and the recipient's device owns display.

Nothing in this document is deferred to a future horizon. There is no planned second phase, no member-facing application, and no external provider surface that the congregation's workers must use to complete their accepted work.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous public entry that explains EcclesiaCare as the Sistem Informasi & Data Jemaat Gereja — what it records (member master data and sacramental history), what it synchronizes (real-time cloud data), and what it produces (attendance and growth dashboards, monthly PDF/Excel reports, weekly worship reporting, birthday reminders, and push notifications for weekly worship and church events). Presents the four headline metrics as static illustrative tiles: Total Jemaat, Kelahiran Bulan Ini, Ulang Tahun Minggu Ini, Kehadiran Ibadah.
• Primary actions: Navigate to Sign Up to establish access; navigate to Login to verify returning access.
• Supporting actions: Scroll through colour-blocked sections describing member records, sacramental history, grouping, reporting, inventory, and ministry coordination.
• Domain entities: None persisted; illustrative metric tiles only.
• Component responsibilities: Full-width cream hero with a coral colour block on the left third carrying the three-line Sora headline "Data Jemaat yang Hidup" and a pill CTA beneath it; right two-thirds carries the custom flat illustration of a church family gathered around a tablet showing a dashboard; below the illustration, a row of four chunky white metric tiles with coral numbers and 2px muted-sand borders; alternating cream/coral/blue full-bleed section bands; thick-stroked rounded icons; footer with access links.
• States: Loading — hero illustration and tiles render immediately as static content, no data fetch. Empty — not applicable; the page carries fixed explanatory content. Success — page renders fully at 375px, 768px, and 1280px with headline, tiles, and CTAs entirely inside the viewport. Error — if the illustration asset fails, the coral colour block and headline remain intact and the illustration area collapses to a muted-sand block. Recovery — user can still reach Sign Up or Login from the pinned CTA and footer.

Sign Up

• Information and state: Anonymous first-use identity establishment for internal church workers. Collects the worker's name, email address, and password, and the congregation/ministry context they are joining.
• Primary actions: Submit registration to create the worker's EcclesiaCare identity.
• Supporting actions: Navigate to Login if the worker already has an identity; return to Landing.
• Domain entities: Worker identity (name, email, credential, congregation context).
• Component responsibilities: Centred white card on cream ground with 24px radius and soft offset shadow; Sora all-caps section label; Outfit body inputs with 2px muted-sand borders; coral pill submit button; inline field-level validation messages; link to Login.
• States: Loading — submit button shows an in-progress state and inputs lock while the identity is created. Empty — all fields blank with placeholder guidance. Success — identity created and the worker is taken into the protected application. Error — duplicate email, invalid email format, weak password, or missing required field shows a specific inline message and preserves entered values. Recovery — the worker corrects the flagged field and resubmits, or switches to Login.

Login

• Information and state: Returning verification for workers who already hold an EcclesiaCare identity.
• Primary actions: Submit credentials to verify identity and enter the protected application.
• Supporting actions: Navigate to Sign Up for first-time workers; return to Landing.
• Domain entities: Worker identity (email, credential).
• Component responsibilities: Centred white card on cream ground; Sora all-caps label; Outfit email and password inputs; coral pill submit button; inline error region; link to Sign Up.
• States: Loading — submit button shows an in-progress state while credentials are verified. Empty — blank fields with placeholder guidance. Success — verified and routed to the working surface matching the worker's responsibility. Error — incorrect credentials or unverified identity shows a specific message without revealing which field was wrong. Recovery — the worker retries, or moves to Sign Up if no identity exists.

Jemaat

• Information and state: The member register. Lists members with nomor induk jemaat, nama, jenis kelamin, kelompok usia, wilayah, keluarga, jenis pelayanan, nomor HP/WA, and a birthday indicator when the member's birthday falls within 7 days. Shows the active filter criteria and the result count.
• Primary actions: Create a new member record; open a member's details; apply specific filter criteria to search the register quickly and accurately.
• Supporting actions: Clear or adjust filters; sort the register; page through results; jump to Groups to manage groupings.
• Domain entities: Jemaat (nomor induk jemaat, nama, tempat/tanggal lahir, jenis kelamin, NIK, alamat lengkap, nomor HP/WA, pekerjaan, pendidikan terakhir/sekolah), Kelompok Usia, Wilayah, Keluarga, Jenis Pelayanan.
• Component responsibilities: White rounded data table card on cream ground with muted-sand row hover and striped rows; filter bar with specific criteria controls (nomor induk jemaat, nama, kelompok usia, wilayah, keluarga, jenis pelayanan, jenis kelamin, rentang tanggal lahir); coral primary "Tambah Jemaat" pill; row click expands into a card with a thick-outlined circular avatar, sacrament history as coloured tags (coral for baptisan air, blue for pemberkatan nikah, sand for penyerahan anak), and a birthday cake icon when the birthday is within 7 days; real-time sync indicator showing the register is current.
• States: Loading — table skeleton rows in muted sand while the register loads. Empty — bold spot illustration of a friendly clipboard with guidance to add the first member or relax the filters. Success — rows render with current cloud-synced values; a newly saved member appears without a manual refresh. Error — a failed load shows a retry affordance and preserves the active filter criteria; a failed save shows an inline message on the affected row. Recovery — retry reloads the register; the user can re-open the member form with values preserved.

Jemaat Details

• Information and state: The full profile of one member: nomor induk jemaat, nama, tempat/tanggal lahir, jenis kelamin, NIK, alamat lengkap, nomor HP/WA, pekerjaan, pendidikan terakhir/sekolah, plus their kelompok usia, wilayah, keluarga, and jenis pelayanan memberships, and their complete sacramental history.
• Primary actions: Edit profile fields; record a sacrament (penyerahan anak, baptisan air, pemberkatan nikah) with its date and place; update or correct an existing sacrament entry.
• Supporting actions: Return to the Jemaat register; move the member between kelompok usia, wilayah, keluarga, or jenis pelayanan; view the member's birthday reminder status.
• Domain entities: Jemaat, Riwayat Sakramen (jenis sakramen, tanggal, tempat), Kelompok Usia, Wilayah, Keluarga, Jenis Pelayanan.
• Component responsibilities: Header band with thick-outlined circular avatar, member name in Sora, and nomor induk jemaat; colour-blocked profile card with 2px muted-sand borders; sacrament history rendered as coloured tags (coral baptisan air, blue pemberkatan nikah, sand penyerahan anak) each expanding to date and place; edit and add-sacrament pill buttons; real-time sync indicator.
• States: Loading — profile skeleton with muted-sand blocks while the record loads. Empty — a member with no recorded sacraments shows a bold spot illustration and a prompt to record the first sacrament. Success — saved edits and new sacrament entries appear immediately and are reflected in the register. Error — a failed save shows an inline message and keeps the edited values in the form; a failed load offers retry. Recovery — retry reloads the profile; the user resubmits the preserved values.

Groups

• Information and state: The four accepted grouping dimensions and their current membership: kelompok usia (anak sekolah minggu, kaum muda remaja, dewasa muda, usia lanjut), wilayah, keluarga, and jenis pelayanan. Shows each group's member count and its member list.
• Primary actions: Create, rename, and remove a group within any of the four dimensions; assign and reassign members into groups.
• Supporting actions: Open a member's details from within a group; filter the member list by group; return to the Jemaat register.
• Domain entities: Kelompok Usia (anak sekolah minggu, kaum muda remaja, dewasa muda, usia lanjut), Wilayah, Keluarga, Jenis Pelayanan, Jemaat.
• Component responsibilities: Four colour-blocked section bands (cream, coral, blue, sand) each holding its dimension's group cards; group cards with 2px muted-sand borders, group name in Sora, member count as a bold coral number, and a small character illustration in the corner that waves on hover; member chips with thick-outlined circular avatars; assignment control with searchable member picker.
• States: Loading — group cards render as muted-sand skeletons. Empty — a dimension with no groups shows a bold spot illustration and a prompt to create the first group. Success — created groups and assignments appear immediately across all views. Error — a failed assignment shows an inline message on the affected member chip and leaves the previous grouping intact. Recovery — retry the assignment; the member picker retains the selection.

Attendance

• Information and state: Attendance statistics dashboard for worship services: attendance counts per service, per week, and per group, with trends over the selected period and comparison against prior periods.
• Primary actions: Select the period and service to analyze; read attendance statistics per service, week, and group.
• Supporting actions: Drill from a statistic into the underlying attendance records; move to Weekly Reports for the narrative weekly report; move to Growth Dashboard for congregation growth.
• Domain entities: Kehadiran Ibadah (service, date, member, group), Jemaat, Kelompok Usia, Wilayah, Keluarga, Jenis Pelayanan.
• Component responsibilities: 12-column grid of large metric tiles, each with a bold coral number that counts up on scroll into view, a small thick-stroked icon, a 2px muted-sand border, and a corner character illustration that waves on hover; period and service selectors as pill controls; attendance trend chart in coral and blue on white card; per-group breakdown table on a white rounded card with muted-sand row hover.
• States: Loading — metric tiles show muted-sand placeholders and the chart shows a soft skeleton. Empty — a period with no recorded attendance shows a bold spot illustration of a friendly calendar with guidance to record attendance. Success — tiles and charts render current cloud-synced statistics. Error — a failed statistics load shows a retry affordance and preserves the selected period and service. Recovery — retry reloads the statistics for the same selection.

Growth Dashboard

• Information and state: Congregation growth statistics: total members over time, additions and departures per period, growth by kelompok usia (anak sekolah minggu, kaum muda remaja, dewasa muda, usia lanjut), by wilayah, by keluarga, and by jenis pelayanan.
• Primary actions: Select the growth period and the grouping dimension to analyze; read growth statistics.
• Supporting actions: Drill from a growth figure into the contributing member records; move to Attendance for worship attendance context; move to Reports to export the monthly report.
• Domain entities: Jemaat, Kelompok Usia, Wilayah, Keluarga, Jenis Pelayanan, pertumbuhan jemaat over time.
• Component responsibilities: Large growth metric tiles with bold coral numbers counting up on scroll into view and corner character illustrations; growth trend chart in coral and blue; dimension breakdown as colour-blocked cards; period selector as pill controls.
• States: Loading — tiles and chart render as muted-sand skeletons. Empty — insufficient history shows a bold spot illustration with an explanation that growth appears once records accumulate. Success — current cloud-synced growth statistics render. Error — a failed load shows a retry affordance and preserves the selected period and dimension. Recovery — retry reloads the same selection.

Reports

• Information and state: Monthly report generation and export. Shows the available monthly periods, the report contents included (member data, groupings, attendance, growth, sacraments), and the export history with format and generation time.
• Primary actions: Generate the monthly report; export it in PDF format; export it in Excel format.
• Supporting actions: Select the month to report; preview the report contents before export; re-export a previously generated monthly report.
• Domain entities: Laporan Bulanan (period, contents, format PDF/Excel, generation time), Jemaat, Kehadiran Ibadah, pertumbuhan jemaat, Riwayat Sakramen.
• Component responsibilities: Month selector as pill controls; report content summary card with 2px muted-sand borders; coral "Ekspor PDF" and blue "Ekspor Excel" pill buttons; export history table on a white rounded card with muted-sand row hover; generation progress indicator.
• States: Loading — generation shows a progress indicator with the period named. Empty — no exports yet shows a bold spot illustration of a friendly document with a prompt to generate the first monthly report. Success — the PDF or Excel file is produced and offered for download, and the export appears in history with its format and time. Error — a failed generation or export shows a specific message naming the period and format, and the export is not recorded as successful. Recovery — retry generation or export for the same period and format.

Weekly Reports

• Information and state: Automatic weekly reporting of worship activities and attendance. Shows each week's generated report with the worship activities held, the attendance recorded, and the generation time, and indicates that the report was produced automatically.
• Primary actions: Read a week's automatic report; regenerate a week's report if it is missing or needs refreshing.
• Supporting actions: Move to Attendance for the underlying statistics; move to Events for the worship schedule that produced the activities; move to Reports for monthly export.
• Domain entities: Laporan Mingguan (week, worship activities, attendance, generation time), Kehadiran Ibadah, jadwal ibadah.
• Component responsibilities: Week list as colour-blocked cards with Sora week labels and coral attendance numbers; automatic-generation badge; report detail panel with activity list and attendance table on a white rounded card; regenerate pill button.
• States: Loading — week cards render as muted-sand skeletons while reports load. Empty — a week with no report yet shows a bold spot illustration and the automatic-generation status. Success — the week's report renders with its activities, attendance, and generation time. Error — a failed load or regeneration shows a specific message for that week and leaves other weeks readable. Recovery — retry the load or regeneration for the affected week.

Events

• Information and state: The schedule of weekly worship services and church events that feeds push notifications. Shows each event's title, type (ibadah or acara), date and time, location, and notification status.
• Primary actions: Create and edit a worship service or church event; set its schedule; trigger or schedule the push notification for it.
• Supporting actions: Cancel an event and its pending notification; view which events are upcoming this week; move to Weekly Reports to see the resulting worship activity report.
• Domain entities: Jadwal Ibadah, Acara Gereja (title, type, date, time, location, notification status), push notification.
• Component responsibilities: Event list as colour-blocked cards with Sora all-caps type labels and coral date blocks; create/edit form with Outfit inputs and 2px muted-sand borders; notification status chip; coral pill save button; slow-scrolling all-caps Sora marquee of the week's events with coral dots between items at the top of the surface.
• States: Loading — event cards render as muted-sand skeletons. Empty — no events scheduled shows a bold spot illustration of a friendly calendar with a prompt to add the first service or event. Success — created or edited events appear immediately and their notification status updates. Error — a failed save or failed notification dispatch shows a specific message on the affected event and preserves the entered values. Recovery — retry the save or the notification dispatch for that event.

Inventory

• Information and state: The church asset inventory: each asset's name, category, quantity, condition, location, acquisition date, and notes, with the total asset count and a condition summary.
• Primary actions: Record a new church asset; update an existing asset's details, quantity, condition, or location.
• Supporting actions: Filter and search the inventory by category, condition, or location; mark an asset as removed or no longer held.
• Domain entities: Aset Gereja (name, category, quantity, condition, location, acquisition date, notes).
• Component responsibilities: White rounded inventory table card with muted-sand row hover and striped rows; filter bar with category, condition, and location controls; coral "Tambah Aset" pill; condition chips in coral, blue, and sand; asset detail panel with 2px muted-sand borders.
• States: Loading — table skeleton rows in muted sand. Empty — no assets recorded shows a bold spot illustration of a friendly box with a prompt to record the first asset. Success — recorded and updated assets appear immediately with current cloud-synced values. Error — a failed save shows an inline message on the affected row and preserves the entered values. Recovery — retry the save with values preserved.

Ministry Tasks

• Information and state: Ministry/imam management and the scheduled task list for each ministry member. Shows the ministry roster (pendeta, imam, pengurus, and other pelayanan members), each member's scheduled tasks with date, time, service or event, and role, and the coordination status of each task.
• Primary actions: Add and manage ministry members; create and assign a scheduled task to a specific ministry member; update a task's schedule, role, or status.
• Supporting actions: View a ministry member's full task list; filter tasks by date, service, or member; move to Events for the service or event a task belongs to.
• Domain entities: Pelayanan/Imam (name, role), Tugas Terjadwal (member, date, time, service or event, role, status).
• Component responsibilities: Ministry roster as thick-outlined circular avatars with Sora names and role labels; task list as colour-blocked cards with coral date blocks and status chips; assignment control with searchable ministry-member picker; coral pill save button; 2px muted-sand borders throughout.
• States: Loading — roster and task cards render as muted-sand skeletons. Empty — a ministry member with no tasks shows a bold spot illustration and a prompt to schedule the first task. Success — created and updated tasks appear immediately on the member's list and in the coordination view. Error — a failed assignment or update shows a specific message on the affected task and preserves the entered values. Recovery — retry the assignment or update with values preserved.

3. Functional Requirements

FR-01 — Member master data recording (explicit) As an Administrator Data Jemaat, I should record each member's nomor induk jemaat, nama, tempat/tanggal lahir, jenis kelamin, NIK, alamat lengkap, nomor HP/WA, pekerjaan, and pendidikan terakhir/sekolah, so that the congregation holds one complete and accurate record per member.

• Trigger/input: The administrator opens the Jemaat register and creates or edits a member record, entering the listed fields.
• Observable result: The member record is saved with all entered fields and appears in the register.
• Access state: Protected; role-restricted to the Administrator Data Jemaat.
• Failure/recovery: A failed save shows an inline message on the affected record and preserves the entered values for resubmission.
• Continuation: The administrator opens the member's details to complete sacramental history or grouping.

FR-02 — Sacramental history recording (explicit) As an Administrator Data Jemaat, I should record each member's sacramental history for penyerahan anak, baptisan air, and pemberkatan nikah, so that the congregation's sacramental record for every member is preserved.

• Trigger/input: The administrator opens a member's details and records a sacrament with its type, date, and place.
• Observable result: The sacrament appears in the member's sacramental history as a coloured tag (coral baptisan air, blue pemberkatan nikah, sand penyerahan anak) and is reflected in the member's record.
• Access state: Protected; role-restricted to the Administrator Data Jemaat.
• Failure/recovery: A failed save shows an inline message and keeps the entered sacrament values in the form.
• Continuation: The administrator continues recording further sacraments or returns to the register.

FR-03 — Real-time cloud data synchronization (explicit) As an Administrator Data Jemaat, I should have every member record, sacrament entry, grouping change, attendance record, event, asset, and ministry task synchronized in real time on a cloud basis, so that all workers always see the current state of the congregation's data.

• Trigger/input: Any user saves a change to any record.
• Observable result: The change is written to the cloud database and appears on other open surfaces without a manual refresh; a sync indicator shows the data is current.
• Access state: Applies to all protected working surfaces.
• Failure/recovery: A failed synchronization shows a specific message on the affected record and preserves the local values for retry.
• Continuation: The user retries the save; other records remain readable.

FR-04 — Monthly report export in PDF and Excel (explicit) As a Petugas Administrasi & Pelaporan, I should export the monthly report in PDF format and in Excel format, so that the congregation can distribute and archive its monthly reporting in the formats it requires.

• Trigger/input: The officer selects a month on Reports and chooses the PDF or Excel export.
• Observable result: A monthly report file in the chosen format is produced and offered for download, and the export is recorded in export history with its format and generation time.
• Access state: Protected; role-restricted to the Petugas Administrasi & Pelaporan.
• Failure/recovery: A failed generation or export shows a specific message naming the period and format, and is not recorded as a successful export.
• Continuation: The officer retries the export for the same period and format, or exports the other format.

FR-05 — Attendance statistics dashboard (explicit) As a Pemimpin/Pelayan Gereja (Pendeta, Imam, Pengurus), I should see a dashboard of attendance statistics for worship services, so that I can monitor how the congregation is participating in worship.

• Trigger/input: The leader opens Attendance and selects a period and service.
• Observable result: Attendance counts per service, per week, and per group render as metric tiles and trend charts with current cloud-synced values.
• Access state: Protected; role-restricted to the Pemimpin/Pelayan Gereja.
• Failure/recovery: A failed statistics load shows a retry affordance and preserves the selected period and service.
• Continuation: The leader drills into the underlying attendance records or moves to Weekly Reports.

FR-06 — Automatic birthday reminders for registered members (explicit) As a Petugas Administrasi & Pelaporan, I should have the system automatically remind the congregation of the birthdays of members registered in the system, so that members are remembered and celebrated on their birthdays.

• Trigger/input: Background automation evaluates registered members' birth dates against the current date.
• Observable result: A birthday reminder is produced for each registered member whose birthday falls due, and members whose birthday falls within 7 days are marked with a birthday cake icon in the Jemaat register and on their details.
• Access state: The reminder result is visible on protected surfaces; the automation itself runs without a user present.
• Failure/recovery: If the automation does not produce a reminder for a due birthday, the affected member is visibly unmarked and the officer can identify the gap from the register.
• Continuation: The officer acts on the reminder through the congregation's normal member contact using the member's recorded nomor HP/WA.
• Constraint: Reminders apply only to members registered in the system.

FR-07 — Push notifications for weekly worship and church events (explicit) As a Petugas Administrasi & Pelaporan, I should send push notifications for the weekly worship schedule and church events, so that members and workers are informed of what is happening at church.

• Trigger/input: The officer creates or edits a worship service or church event on Events and triggers or schedules its push notification.
• Observable result: The push notification is dispatched for the scheduled worship service or church event, and the event's notification status reflects the dispatch.
• Access state: Protected; role-restricted to the Petugas Administrasi & Pelaporan.
• Failure/recovery: A failed dispatch shows a specific message on the affected event and preserves the event's schedule and content.
• Continuation: The officer retries the dispatch for that event.
• Constraint: Push notifications are for the weekly worship schedule and church events.

FR-08 — Member grouping by age, region, family, and ministry (explicit) As an Administrator Data Jemaat, I should group members by kelompok usia, wilayah, keluarga, and jenis pelayanan, so that the congregation can be understood and served along the dimensions that matter to its life.

• Trigger/input: The administrator creates or edits a group within one of the four dimensions on Groups and assigns members to it.
• Observable result: The group exists with its member list and member count, and each assigned member shows the grouping on their record.
• Access state: Protected; role-restricted to the Administrator Data Jemaat.
• Failure/recovery: A failed assignment shows an inline message on the affected member and leaves the previous grouping intact.
• Continuation: The administrator retries the assignment or continues grouping other members.

FR-09 — Age group categories (explicit) As an Administrator Data Jemaat, I should have the kelompok usia dimension cover anak sekolah minggu, kaum muda remaja, dewasa muda, and the usia lanjut category, so that every member belongs to an age group that reflects the congregation's own categories.

• Trigger/input: The administrator assigns a member to a kelompok usia on Groups or on the member's details.
• Observable result: The member appears in the assigned age group, and the age group's member count reflects the assignment.
• Access state: Protected; role-restricted to the Administrator Data Jemaat.
• Failure/recovery: A failed assignment shows an inline message and leaves the previous age group intact.
• Continuation: The administrator retries or continues assigning members.
• Constraint: The kelompok usia dimension includes anak sekolah minggu, kaum muda remaja, dewasa muda, and usia lanjut.

FR-10 — Church asset inventory management (explicit) As a Petugas Inventaris Aset Gereja, I should record and update the church's asset inventory, so that the congregation's assets are recorded and maintained centrally in the system.

• Trigger/input: The officer records a new asset or updates an existing asset's name, category, quantity, condition, location, acquisition date, or notes on Inventory.
• Observable result: The asset appears in the inventory with its current values, and the total asset count and condition summary reflect the change.
• Access state: Protected; role-restricted to the Petugas Inventaris Aset Gereja.
• Failure/recovery: A failed save shows an inline message on the affected asset and preserves the entered values.
• Continuation: The officer retries the save or continues updating other assets.

FR-11 — Fast and accurate member search with specific filter criteria (explicit) As an Administrator Data Jemaat, I should search member data quickly and accurately using specific filter criteria, so that I can find the right member without scanning the whole register.

• Trigger/input: The administrator applies one or more specific criteria on the Jemaat register — nomor induk jemaat, nama, kelompok usia, wilayah, keluarga, jenis pelayanan, jenis kelamin, or rentang tanggal lahir.
• Observable result: The register narrows to the matching members, showing the active criteria and the result count.
• Access state: Protected; role-restricted to the Administrator Data Jemaat.
• Failure/recovery: A failed search shows a retry affordance and preserves the active criteria.
• Continuation: The administrator opens a matching member's details, adjusts the criteria, or clears the filters.

FR-12 — Congregation growth statistics dashboard (explicit) As a Pemimpin/Pelayan Gereja (Pendeta, Imam, Pengurus), I should see a dashboard of statistics showing congregation growth, so that I can understand how the congregation is developing over time.

• Trigger/input: The leader opens Growth Dashboard and selects a period and grouping dimension.
• Observable result: Growth statistics render as metric tiles and trend charts showing total members over time, additions and departures, and growth by kelompok usia, wilayah, keluarga, and jenis pelayanan.
• Access state: Protected; role-restricted to the Pemimpin/Pelayan Gereja.
• Failure/recovery: A failed load shows a retry affordance and preserves the selected period and dimension.
• Continuation: The leader drills into contributing member records or moves to Reports.

FR-13 — Automatic weekly worship activity and attendance reporting (explicit) As a Petugas Administrasi & Pelaporan, I should have the system automatically report worship activities and attendance every week, so that each week's worship life is documented without manual compilation.

• Trigger/input: Background automation compiles each week's worship activities and recorded attendance.
• Observable result: A weekly report for the week is produced and readable on Weekly Reports, showing the worship activities held, the attendance recorded, and the generation time, marked as automatically generated.
• Access state: The report is readable on protected surfaces by the Petugas Administrasi & Pelaporan and the Pemimpin/Pelayan Gereja; the automation runs without a user present.
• Failure/recovery: A week whose report is missing or needs refreshing is visibly identifiable, and the officer can regenerate it.
• Continuation: The officer reads the report, regenerates it, or moves to Attendance for the underlying statistics.
• Constraint: Automatic reporting covers worship activities and attendance each week.

FR-14 — Ministry/imam management with scheduled task lists (explicit) As a Pemimpin/Pelayan Gereja (Pendeta, Imam, Pengurus), I should manage the pelayanan/imam roster and maintain a scheduled task list for each ministry member, so that ministry coordination runs smoothly.

• Trigger/input: The leader adds or manages a ministry member on Ministry Tasks and creates or updates a scheduled task assigned to a specific member with its date, time, service or event, and role.
• Observable result: The ministry member appears on the roster, and the scheduled task appears on that member's task list with its schedule, role, and status.
• Access state: Protected; role-restricted to the Pemimpin/Pelayan Gereja.
• Failure/recovery: A failed assignment or update shows a specific message on the affected task and preserves the entered values.
• Continuation: The leader retries the assignment or continues scheduling tasks for other members.
• Constraint: Scheduled task lists are maintained for each ministry member so that coordination runs smoothly.

FR-15 — First-use identity establishment (required_inference) As a church worker, I should establish my EcclesiaCare identity on first use, so that my work on member data, reporting, ministry, and assets is bound to me and remains continuous.

• Trigger/input: An anonymous visitor on Landing chooses to establish access and submits their name, email address, password, and congregation context on Sign Up.
• Observable result: The worker's identity is created and they enter the protected application.
• Access state: Anonymous entry; the resulting identity grants access to the protected surfaces matching the worker's responsibility.
• Failure/recovery: Duplicate email, invalid email format, weak password, or a missing required field shows a specific inline message and preserves entered values.
• Continuation: The worker corrects the flagged field and resubmits, or moves to Login if an identity already exists.

FR-16 — Returning verification (required_inference) As a church worker, I should verify my identity on return, so that I can resume my work on the congregation's protected data.

• Trigger/input: A worker with an existing identity submits their credentials on Login.
• Observable result: The worker is verified and routed to the working surface matching their responsibility.
• Access state: Anonymous entry; successful verification grants access to the protected surfaces matching the worker's responsibility.
• Failure/recovery: Incorrect credentials or an unverified identity shows a specific message without revealing which field was wrong.
• Continuation: The worker retries, or moves to Sign Up if no identity exists.

FR-17 — Responsibility-based access to working surfaces (required_inference) As a church worker, I should reach the working surfaces that match my responsibility and not be routed into work I am not accountable for, so that member data, reporting, ministry coordination, and asset records are each handled by the people responsible for them.

• Trigger/input: A verified worker navigates the application.
• Observable result: The worker reaches the surfaces matching their responsibility — member data and grouping for the Administrator Data Jemaat; attendance, growth, and ministry tasks for the Pemimpin/Pelayan Gereja; monthly and weekly reporting and events for the Petugas Administrasi & Pelaporan; inventory for the Petugas Inventaris Aset Gereja.
• Access state: Protected; access follows the worker's responsibility.
• Failure/recovery: An attempt to reach a surface outside the worker's responsibility does not expose that surface's data and returns the worker to a surface they hold.
• Continuation: The worker continues on a surface they hold.

FR-18 — Background automation for reminders and weekly reporting (required_inference) As a Petugas Administrasi & Pelaporan, I should have birthday reminders and weekly worship and attendance reports produced automatically in the background, so that these recurring obligations are met on schedule without manual initiation.

• Trigger/input: The background automation runs on its schedule against registered members' birth dates and each week's worship activities and attendance.
• Observable result: Birthday reminders are produced for due registered members and weekly reports are produced for each week, both visible on the surfaces that own them.
• Access state: Runs without a user present; results are visible on protected surfaces.
• Failure/recovery: A missed reminder or missing weekly report is visibly identifiable on the owning surface, and the officer can act on the gap.
• Continuation: The officer acts on the reminder or reads or regenerates the weekly report.

4. User Personas

Administrator Data Jemaat

Product context. This persona is the custodian of the congregation's member record. They work in the register and in individual member profiles, and they are the person who decides how a member is described and where that member belongs in the congregation's groupings. Their work is the foundation every other persona depends on: attendance, growth statistics, monthly reports, and ministry coordination all read from the records this persona maintains.

Primary goal. Keep every member's record complete, accurate, and correctly grouped, and be able to find any member again quickly and precisely.

Distinct accepted responsibilities. Recording member master data across nomor induk jemaat, nama, tempat/tanggal lahir, jenis kelamin, NIK, alamat lengkap, nomor HP/WA, pekerjaan, and pendidikan terakhir/sekolah; recording sacramental history for penyerahan anak, baptisan air, and pemberkatan nikah; grouping members by kelompok usia, wilayah, keluarga, and jenis pelayanan, including the age categories anak sekolah minggu, kaum muda remaja, dewasa muda, and usia lanjut; and searching the register with specific filter criteria.

Relevant inputs and decisions. The persona decides which fields describe a member, which sacrament entries belong to a member and when they occurred, which age group, wilayah, keluarga, and jenis pelayanan a member belongs to, and which filter criteria will isolate the members they need. Their inputs are the member's identity and contact details, the sacrament type with its date and place, and the grouping assignments.

Interactions with other accepted participants. This persona's records are read by the Pemimpin/Pelayan Gereja through the attendance and growth dashboards and by the Petugas Administrasi & Pelaporan through monthly and weekly reporting. The persona's grouping work determines how those other personas see the congregation broken down. The persona does not produce reports, coordinate ministry tasks, or manage assets.

Observable success. Every member record is complete and current in the cloud-synced register, every sacrament is recorded against the right member, every member sits in the right kelompok usia, wilayah, keluarga, and jenis pelayanan, and any member can be found again through specific filter criteria without scanning the whole register.

Pemimpin/Pelayan Gereja (Pendeta, Imam, Pengurus)

Product context. This persona carries pastoral and ministerial responsibility for the congregation. They are not primarily data-entry workers; they read the congregation's condition and coordinate the people who serve it. Their work spans two distinct concerns: understanding how the congregation is participating and growing, and making sure the ministry roster and its scheduled tasks are coordinated.

Primary goal. See how the congregation is doing in worship attendance and growth, and keep ministry service coordinated so that every ministry member knows their scheduled tasks.

Distinct accepted responsibilities. Reading the attendance statistics dashboard; reading the congregation growth statistics dashboard; managing the pelayanan/imam roster; and maintaining scheduled task lists for each ministry member.

Relevant inputs and decisions. The persona selects the period, service, and grouping dimension they want to analyze, and decides what the attendance and growth figures mean for pastoral action. On the ministry side, they decide who serves, in what role, on which date and time, for which service or event, and what the status of each task is.

Interactions with other accepted participants. This persona depends on the Administrator Data Jemaat's member records and groupings for every statistic they read. They read the weekly reports produced for the Petugas Administrasi & Pelaporan's reporting responsibility. Their ministry task schedules are tied to the worship services and church events that the Petugas Administrasi & Pelaporan maintains on Events.

Observable success. Attendance and growth statistics render current, correctly grouped figures for the selected period; the ministry roster is complete; and every ministry member has a scheduled task list showing their date, time, service or event, role, and status, so coordination runs smoothly.

Petugas Administrasi & Pelaporan

Product context. This persona turns the congregation's data into the documents and communications the church runs on. They work at the boundary between the system and the congregation: producing the monthly report in the formats the church requires, relying on the automatic weekly reporting of worship activities and attendance, and managing the reminders and notifications that reach members.

Primary goal. Have the monthly and weekly reports available on time in the required formats, and make sure members receive their birthday reminders and the push notifications for weekly worship and church events.

Distinct accepted responsibilities. Generating and exporting the monthly report in PDF and Excel; reading and regenerating the automatic weekly worship activity and attendance reports; monitoring the automatic birthday reminders for registered members; and creating and editing the weekly worship schedule and church events that drive push notifications, including triggering or scheduling those notifications.

Relevant inputs and decisions. The persona selects the month to report and the export format, decides whether a weekly report needs regenerating, and decides the content and schedule of each worship service and church event and when its push notification should go out.

Interactions with other accepted participants. This persona's monthly and weekly reports draw on the Administrator Data Jemaat's member records and groupings and on the attendance the congregation records. Their event schedule is the source the Pemimpin/Pelayan Gereja's ministry tasks attach to. Their birthday reminders and push notifications reach members and workers outside the system.

Observable success. The monthly report is exported in PDF and Excel for the selected month and recorded in export history; each week's worship activity and attendance report is available and marked as automatically generated; birthday reminders are produced for registered members whose birthdays fall due; and each scheduled worship service and church event has its push notification dispatched with its status reflected on the event.

Petugas Inventaris Aset Gereja

Product context. This persona is accountable for the physical property of the congregation. Their work is separate from member data and ministry coordination: they maintain the record of what the church owns, in what quantity, in what condition, and where it is kept.

Primary goal. Keep the church's asset inventory recorded and maintained centrally in the system so that the congregation knows what it holds.

Distinct accepted responsibilities. Recording new church assets and updating existing assets' details, quantity, condition, location, acquisition date, and notes; and filtering and searching the inventory by category, condition, or location.

Relevant inputs and decisions. The persona decides how an asset is categorized, what quantity is held, what condition it is in, where it is located, when it was acquired, and what notes matter for its care.

Interactions with other accepted participants. This persona's work is independent of the member-facing and ministry-facing work of the other personas; the inventory record is maintained centrally in the same cloud-synced system so that it is current and available alongside the congregation's other records.

Observable success. Every church asset is recorded with its current values, the total asset count and condition summary reflect the inventory, and any asset can be located by category, condition, or location.

5. Core User Flows

Flow 1 — Administrator Data Jemaat records a new member and their sacramental history

1. The Administrator Data Jemaat opens Landing and chooses to establish access, moving to Sign Up.
2. On Sign Up, the administrator enters their name, email address, password, and congregation context and submits. The identity is created and they enter the protected application.
3. The administrator opens Jemaat and selects "Tambah Jemaat".
4. The administrator enters the member's nomor induk jemaat, nama, tempat/tanggal lahir, jenis kelamin, NIK, alamat lengkap, nomor HP/WA, pekerjaan, and pendidikan terakhir/sekolah, and saves.
5. The member record is written to the cloud database and appears in the register immediately, with the sync indicator showing the register is current.
6. The administrator opens the member's Jemaat Details and records the member's sacraments — penyerahan anak, baptisan air, and pemberkatan nikah — each with its date and place.
7. Each sacrament appears in the member's sacramental history as a coloured tag: coral for baptisan air, blue for pemberkatan nikah, sand for penyerahan anak.
8. Failure and recovery: If a save fails, an inline message appears on the affected record and the entered values are preserved; the administrator corrects the issue and resubmits.
9. Continuation: The administrator moves to Groups to place the member in their kelompok usia, wilayah, keluarga, and jenis pelayanan.

Flow 2 — Administrator Data Jemaat groups members and finds them with specific filters

1. The Administrator Data Jemaat opens Groups.
2. The administrator creates or selects a group within one of the four dimensions — kelompok usia, wilayah, keluarga, or jenis pelayanan — and assigns members to it.
3. For kelompok usia, the administrator assigns members to anak sekolah minggu, kaum muda remaja, dewasa muda, or usia lanjut.
4. Each assignment appears immediately on the group's member list and member count, and on the member's own record.
5. Failure and recovery: If an assignment fails, an inline message appears on the affected member chip and the previous grouping remains intact; the administrator retries with the selection preserved.
6. The administrator opens Jemaat and applies specific filter criteria — nomor induk jemaat, nama, kelompok usia, wilayah, keluarga, jenis pelayanan, jenis kelamin, or rentang tanggal lahir.
7. The register narrows to the matching members and shows the active criteria and the result count.
8. The administrator opens a matching member's Jemaat Details to confirm the record.
9. Continuation: The administrator adjusts or clears the criteria and continues working the register.

Flow 3 — Pemimpin/Pelayan Gereja monitors attendance and congregation growth

1. The Pemimpin/Pelayan Gereja opens Login and submits their credentials. They are verified and routed to a working surface matching their responsibility.
2. The leader opens Attendance and selects the period and service to analyze.
3. Attendance counts per service, per week, and per group render as metric tiles whose coral numbers count up on scroll into view, alongside trend charts and a per-group breakdown table.
4. The leader drills from a statistic into the underlying attendance records to see which members and groups are represented.
5. The leader opens Growth Dashboard and selects the growth period and grouping dimension.
6. Growth statistics render showing total members over time, additions and departures, and growth by kelompok usia, wilayah, keluarga, and jenis pelayanan.
7. Failure and recovery: If a statistics load fails, a retry affordance appears and the selected period and dimension are preserved; the leader retries the same selection.
8. Continuation: The leader moves to Weekly Reports to read the week's worship activity and attendance report, or to Reports to have the monthly report exported.

Flow 4 — Pemimpin/Pelayan Gereja coordinates ministry and scheduled tasks

1. The Pemimpin/Pelayan Gereja opens Ministry Tasks.
2. The leader adds a ministry member to the pelayanan/imam roster, entering their name and role.
3. The ministry member appears on the roster as a thick-outlined circular avatar with their name and role label.
4. The leader creates a scheduled task for that member, entering the date, time, the service or event it belongs to, and the member's role, and saves.
5. The task appears on that member's task list with its schedule, role, and status, and in the coordination view.
6. The leader repeats this for each ministry member so that every member has a scheduled task list.
7. Failure and recovery: If an assignment or update fails, a specific message appears on the affected task and the entered values are preserved; the leader retries.
8. Continuation: The leader filters tasks by date, service, or member to check coordination, or moves to Events to confirm the service or event a task belongs to.

Flow 5 — Petugas Administrasi & Pelaporan produces the monthly report

1. The Petugas Administrasi & Pelaporan opens Login and submits their credentials. They are verified and routed to a working surface matching their responsibility.
2. The officer opens Reports and selects the month to report.
3. The officer reviews the report content summary, which covers member data, groupings, attendance, growth, and sacraments for the month.
4. The officer selects "Ekspor PDF". A progress indicator shows generation for the named period.
5. The monthly report PDF is produced and offered for download, and the export is recorded in export history with its format and generation time.
6. The officer selects "Ekspor Excel" for the same month.
7. The monthly report Excel file is produced and offered for download, and the second export is recorded in export history.
8. Failure and recovery: If generation or export fails, a specific message names the period and format, the export is not recorded as successful, and the officer retries for the same period and format.
9. Continuation: The officer re-exports a previously generated monthly report from export history when needed.

Flow 6 — Petugas Administrasi & Pelaporan relies on automatic weekly reporting

1. The Petugas Administrasi & Pelaporan opens Weekly Reports.
2. Each week's automatically generated report is listed, showing the worship activities held, the attendance recorded, and the generation time, marked as automatically generated.
3. The officer opens a week's report and reads the worship activities and attendance for that week.
4. Failure and recovery: If a week's report is missing or needs refreshing, the officer selects regenerate for that week; if regeneration fails, a specific message appears for that week and the other weeks remain readable.
5. Continuation: The officer moves to Attendance to examine the underlying statistics for the week, or to Reports to export the monthly report.

Flow 7 — Petugas Administrasi & Pelaporan schedules worship, events, and push notifications

1. The Petugas Administrasi & Pelaporan opens Events.
2. The officer creates a weekly worship service or a church event, entering its title, type, date, time, and location.
3. The event appears in the event list as a colour-blocked card with its type label and coral date block, and in the slow-scrolling all-caps marquee of the week's events.
4. The officer triggers or schedules the push notification for the event.
5. The push notification is dispatched for the scheduled worship service or church event, and the event's notification status reflects the dispatch.
6. Failure and recovery: If the save or the notification dispatch fails, a specific message appears on the affected event and the entered values are preserved; the officer retries the save or the dispatch.
7. Continuation: The officer cancels an event and its pending notification if plans change, or moves to Weekly Reports to see the resulting worship activity report.

Flow 8 — Petugas Administrasi & Pelaporan monitors automatic birthday reminders

1. The Petugas Administrasi & Pelaporan opens Jemaat and reviews the register for members marked with the birthday cake icon, which indicates a birthday within 7 days.
2. The background automation has produced birthday reminders for registered members whose birthdays fall due.
3. The officer opens a marked member's Jemaat Details and reads the member's recorded nomor HP/WA.
4. The officer acts on the reminder through the congregation's normal member contact.
5. Failure and recovery: If a due birthday is not marked, the officer can identify the gap from the register and confirm the member's birth date on their details.
6. Continuation: The officer continues through the remaining marked members.

Flow 9 — Petugas Inventaris Aset Gereja maintains the church asset inventory

1. The Petugas Inventaris Aset Gereja opens Login and submits their credentials. They are verified and routed to a working surface matching their responsibility.
2. The officer opens Inventory and selects "Tambah Aset".
3. The officer enters the asset's name, category, quantity, condition, location, acquisition date, and notes, and saves.
4. The asset appears in the inventory table with its current values, and the total asset count and condition summary reflect the change.
5. The officer updates an existing asset's quantity, condition, or location as the asset's situation changes.
6. Failure and recovery: If a save fails, an inline message appears on the affected row and the entered values are preserved; the officer retries.
7. Continuation: The officer filters the inventory by category, condition, or location to locate assets, or marks an asset as removed when it is no longer held.

Flow 10 — Returning worker verifies identity and resumes work

1. A church worker who already holds an EcclesiaCare identity opens Landing and moves to Login.
2. The worker submits their email address and password.
3. The credentials are verified and the worker is routed to the working surface matching their responsibility.
4. Failure and recovery: If the credentials are incorrect or the identity is unverified, a specific message appears without revealing which field was wrong; the worker retries, or moves to Sign Up if no identity exists.
5. Continuation: The worker resumes their work — member data and grouping, attendance and growth and ministry tasks, reporting and events, or inventory — with the congregation's cloud-synced data current.

6. Visuals Colors and Theme

Muse and headline. The visual language follows Haraldur Thorleifsson — big-hearted boldness for a congregation's living record. The headline idea is Data Jemaat yang Hidup: the congregation's record presented with warmth, saturated colour blocking, and character-led illustration, so the tool reads as a system for people rather than a faceless institution.

Colour tokens (light mode).

Colour blocking is used in section openers and dashboard tiles, alternating cream, coral, and blue full-bleed bands. No blue-indigo primary on white; no gradient-blob heroes; no soft violet→pink→sky gradients.

Typography. Headings use Sora — bold geometric sans, weight 700–800 for display and 600 for section headers, large sizes, tight leading, generous word spacing; section labels set in all-caps, hero headline in sentence case. Body uses Outfit. Modular scale 1.25: 64 / 48 / 36 / 24 / 18 / 16 on desktop, 36 / 28 / 22 / 18 / 16 / 14 on mobile. Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are not used for headings or body.

Shape language. Chunky rounded rectangles with 16–24px radii; pill buttons; soft offset shadows 0 4px 0 rgba(0,0,0,0.08); colour-blocked cards with 2px solid borders in muted tones; friendly circular avatars with thick outlines.

Spacing rhythm. Generous gutters — 24px on mobile with vertically stacked tiles, wider column gutters on the 12-column desktop grid; consistent vertical rhythm between colour-blocked bands and card groups.

Imagery style. Custom flat character illustrations of church community members — families, children, elderly, pastors — in warm flat colours with simple line details. Bold spot illustrations for empty states (a friendly calendar, a gift box for birthdays, a clipboard for attendance, a friendly document, a friendly box). No stock photography. Icons are thick-stroked and rounded.

Readability rule. Headlines, wordmarks, labels, numbers, and card text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, with no other element covering them. Imagery, decoration, and motion may be cropped, bled, rotated, or overlapped as the direction asks, provided they cover no readable text or control. Moving and scrollable content — the event marquee, horizontally scrollable rows — may cross the viewport or container edge by design and is judged by whether it moves and whether every item becomes fully readable as it passes. Under prefers-reduced-motion, items wrap into rows or become horizontally scrollable so each item can be brought fully into view.

7. Signature Design Concept

The public entry is a full-width cream hero split into a coral colour block and a living illustration.

The left third is an oversized coral (#E85A4F) colour block carrying the Sora headline "Data Jemaat yang Hidup" stacked in three lines that span the block, with a pill CTA pinned beneath it in accent blue (#2E86AB) leading to Sign Up and a secondary text link to Login. The right two-thirds carries a custom flat illustration of a diverse church family — grandparent, parent, teen, child — gathered around a tablet showing a dashboard, drawn in warm flat colours with simple line details and layered so the figures sit at slightly different depths.

Below the illustration, a row of four chunky white metric tiles sits on the cream ground: Total Jemaat, Kelahiran Bulan Ini, Ulang Tahun Minggu Ini, Kehadiran Ibadah. Each tile has a 2px muted-sand (#F2E8DC) border, a bold coral number, a small thick-stroked icon, and a small character illustration in the corner that waves on hover.

The hero is flat 2D with layered illustration elements that parallax slightly on scroll. There are no gradient blobs and no blue buttons. The composition recomposes only accepted content — the product's identity, its four headline metrics, and its two access paths — and introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: The custom flat illustration of a diverse church family — grandparent, parent, teen, child — gathered around a tablet showing a dashboard, layered over the coral colour block and cream ground.
• Input → transformation → outcome thesis: As the visitor scrolls the entry, the layered illustration elements move at slightly different rates, so the family group separates gently in depth and settles back into a composed arrangement; the four metric tiles below scale in with a gentle spring and their coral numbers count up as they enter view. The outcome is a first frame that reads as a warm, populated congregation record rather than an empty template, with the two access paths — Sign Up and Login — always whole and reachable.
• Motion vocabulary: Lively entrance animations; tiles scale in with a gentle spring; numbers count up on scroll into view; hover states pop with a 4px lift and shadow growth; character illustrations blink or wave on hover; a slow-scrolling all-caps Sora marquee of the week's events with coral dots between items at the top of the dashboard.
• Composed first frame: Cream ground; coral colour block on the left third with the three-line Sora headline "Data Jemaat yang Hidup" and the blue pill CTA pinned beneath it; the layered church-family illustration on the right two-thirds; the row of four white metric tiles with coral numbers and muted-sand borders beneath the illustration.
• Reduced-motion state: All entrance animation, parallax, count-up, and hover lift settle into a static arrangement. The illustration renders as a single composed flat image, the metric tiles show their final numbers immediately, and the event marquee wraps into rows or becomes horizontally scrollable so every event becomes fully readable. No readable text or control is ever cropped, clipped, or covered.

9. Non-Functional Requirements

NFR-01 — Cloud-based real-time synchronization (explicit) Data synchronization must be cloud-based and real-time. Every saved change to member records, sacraments, groupings, attendance, events, assets, and ministry tasks must reach the cloud database and become visible on other open surfaces without a manual refresh. Rationale: the source states real-time cloud synchronization as a hard constraint, and multiple workers operate on the same congregation data concurrently.

NFR-02 — Report export formats (explicit) Report export must support both PDF and Excel formats. Rationale: the source states both formats as a hard constraint for the monthly report.

NFR-03 — Monthly reporting period (explicit) The exported reports are monthly reports. Rationale: the source states the exported report is the monthly report.

NFR-04 — Birthday reminder eligibility (explicit) Automatic birthday reminders apply only to members registered in the system. Rationale: the source states the reminder is for jemaat yang terdaftar di sistem.

NFR-05 — Push notification scope (explicit) Push notifications are for the weekly worship schedule and church events. Rationale: the source states the notification scope as jadwal ibadah dan acara gereja mingguan.

NFR-06 — Age group coverage (explicit) The kelompok usia dimension must cover anak sekolah minggu, kaum muda remaja, dewasa muda, and the usia lanjut category. Rationale: the source states these categories as a hard constraint.

NFR-07 — Weekly automatic reporting scope (explicit) Automatic reporting must cover worship activities and attendance each week. Rationale: the source states the weekly reporting scope as kegiatan ibadah serta kehadiran setiap minggunya.

NFR-08 — Scheduled task coverage (explicit) Scheduled task lists must be maintained for each ministry member so that coordination runs smoothly. Rationale: the source states the task list is for setiap anggota pelayanan.

NFR-09 — Search speed and accuracy (explicit) Member search must be fast and accurate through specific filter criteria. Rationale: the source states pencarian data jemaat yang cepat dan akurat melalui fitur filter kriteria yang spesifik.

NFR-10 — Data completeness and accuracy (explicit) Member records must be maintainable in full across all listed fields — nomor induk jemaat, nama, tempat/tanggal lahir, jenis kelamin, NIK, alamat lengkap, nomor HP/WA, pekerjaan, pendidikan terakhir/sekolah — and sacramental history must be recordable for all three sacrament types. Rationale: the source enumerates these fields and sacrament types as the required record content.

NFR-11 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, and card text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Rationale: stated as a project-wide readability constraint in the creative direction.

NFR-12 — Reduced-motion support (explicit) All motion must respect prefers-reduced-motion by settling into a usable static arrangement, with moving and scrollable content wrapping into rows or becoming horizontally scrollable so each item can be brought fully into view. Rationale: stated in the creative direction's motion and readability rules.

NFR-13 — Identity continuity for durable records (required_inference) Because member records, sacramental history, attendance, ministry assignments, and asset records are durable and person-specific, the system must establish identity on first use and verify it on return, and must keep protected working surfaces unavailable until identity is established. Rationale: required to make the accepted journeys executable and to keep commitments and records bound to the correct worker.

NFR-14 — Responsibility-based access (required_inference) Access to working surfaces must follow the responsibility each worker holds, so that member data and grouping, attendance and growth and ministry coordination, reporting and events, and asset inventory are each handled by the accountable worker. Rationale: required to keep the accepted responsibilities with their accepted owners.

NFR-15 — Background automation reliability (required_inference) Birthday reminders and weekly worship and attendance reports must be produced automatically on schedule without a user present, and any missed reminder or missing weekly report must be visibly identifiable on the surface that owns it. Rationale: required to make the accepted automatic reminder and automatic weekly reporting obligations dependable and recoverable.

10. Tech Stack

• Frontend: React web application. (Default — not specified by user)
• Backend: Python with FastAPI. (Default — not specified by user)
• Storage: A cloud-hosted relational database supporting real-time synchronization of member, sacrament, grouping, attendance, event, asset, and ministry-task records. (Default — not specified by user; the cloud-based real-time synchronization requirement is explicit.)
• Document generation: Server-side PDF and Excel generation for the monthly report. (Default — not specified by user; both formats are explicit.)
• Push notification delivery: A push notification service for weekly worship schedule and church event notifications. (Default — not specified by user; the push notification capability is explicit.)
• Background automation: A scheduled background worker for birthday reminders and weekly worship activity and attendance reporting. (Default — not specified by user; both automatic behaviours are explicit.)
• Containerization: Docker with docker-compose for local and deployment packaging. (Default — not specified by user)
• Orchestration: Kubernetes is not required for the accepted scope. (Default — not specified by user)

11. Assumptions and Constraints

Assumptions

• A1. The congregation's workers are the only users of EcclesiaCare; there is no member-facing or public self-service surface beyond the anonymous Landing entry. (Assumption — consistent with the accepted scope, which names only internal worker personas.)
• A2. A worker's responsibility determines which working surfaces they reach; the accepted personas each hold a distinct set of responsibilities. (Assumption — derived from the accepted persona catalog and the responsibility-based access requirement.)
• A3. Push notification recipients are reached through the notification service's delivery to their devices; the system owns the schedule, content, and trigger. (Assumption — the source specifies push notifications but not the recipient device handling.)
• A4. The monthly report draws on the member data, groupings, attendance, growth, and sacraments held in the system for the selected month. (Assumption — the source specifies monthly PDF and Excel export without enumerating report contents.)
• A5. The weekly automatic report draws on the worship activities scheduled on Events and the attendance recorded for those services. (Assumption — the source specifies automatic weekly reporting of worship activities and attendance.)

Constraints

• C1. Data synchronization must be cloud-based and real-time. (Explicit)
• C2. Report export must support PDF and Excel formats. (Explicit)
• C3. The exported reports are monthly reports. (Explicit)
• C4. Automatic birthday reminders apply only to members registered in the system. (Explicit)
• C5. Push notifications are for the weekly worship schedule and church events. (Explicit)
• C6. The kelompok usia dimension includes anak sekolah minggu, kaum muda remaja, dewasa muda, and usia lanjut. (Explicit)
• C7. Automatic reporting covers worship activities and attendance each week. (Explicit)
• C8. Scheduled task lists are maintained for each ministry member so that coordination runs smoothly. (Explicit)
• C9. Member search must be fast and accurate through specific filter criteria. (Explicit)
• C10. The visual language must not use a blue-indigo primary on white, Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body, gradient-blob heroes, photography-heavy heroes or stock imagery of people, or complex 3D or WebGL scenes. (Explicit — creative direction)
• C11. Readable text and controls must stay whole and uncovered at 375px, 768px, and 1280px. (Explicit — creative direction)
• C12. All motion must respect prefers-reduced-motion. (Explicit — creative direction)

Out of scope

• Public congregational self-service, member-facing portals, and member self-registration.
• Online giving, financial accounting, and general church financial management.
• Any capability not enumerated in the accepted requirement thread.

12. Glossary

• EcclesiaCare — The product name for the Sistem Informasi & Data Jemaat Gereja, the church member information and data system delivered by the jemaat-gereja-data project.
• Jemaat — A church member; also the name of the member register surface.
• Nomor Induk Jemaat — The member's unique registration number in the congregation's record.
• NIK — Nomor Induk Kependudukan, the Indonesian national identity number recorded for a member.
• Riwayat Sakramen — A member's sacramental history, covering penyerahan anak, baptisan air, and pemberkatan nikah.
• Penyerahan Anak — Child dedication, one of the three recorded sacrament types.
• Baptisan Air — Water baptism, one of the three recorded sacrament types.
• Pemberkatan Nikah — Marriage blessing, one of the three recorded sacrament types.
• Kelompok Usia — The age-group dimension of member grouping, covering anak sekolah minggu, kaum muda remaja, dewasa muda, and usia lanjut.
• Anak Sekolah Minggu — The children's Sunday school age group.
• Kaum Muda Remaja — The youth and adolescent age group.
• Dewasa Muda — The young adult age group.
• Usia Lanjut — The elderly age group.
• Wilayah — The region or area dimension of member grouping.
• Keluarga — The family dimension of member grouping.
• Jenis Pelayanan — The ministry-service dimension of member grouping.
• Pelayanan/Imam — The ministry roster of pastors, imams, and church officers who serve the congregation.
• Tugas Terjadwal — A scheduled task assigned to a specific ministry member, with date, time, service or event, role, and status.
• Kehadiran Ibadah — Worship service attendance, recorded per service, week, and group.
• Laporan Bulanan — The monthly report, exportable in PDF and Excel.
• Laporan Mingguan — The automatically generated weekly report of worship activities and attendance.
• Aset Gereja — A church asset recorded in the inventory with its category, quantity, condition, location, acquisition date, and notes.
• Pengingat Ulang Tahun — The automatic birthday reminder produced for members registered in the system.
• Notifikasi Push — The push notification sent for the weekly worship schedule and church events.
• Pertumbuhan Jemaat — Congregation growth, shown on the growth statistics dashboard.