SIPEDAS: A Human-Centered Evaluation of Traceable Digital Workflows for Local-Government Waste Administration

2.2 Requirements Traceability and System Design

A requirements-to-evidence traceability structure was developed to connect identified administrative problems with operational requirements, implemented system mechanisms, and the functional scenarios used for verification. Rather than presenting system features as isolated technical components, this structure makes explicit why each major capability was introduced and what evidence was available to verify its implementation. Table 1 summarizes this chain from observed workflow limitation to recorded functional test.

The system specification defined two primary authorization roles: Administrator and Employee. The Administrator role manages agency profiles, employee and leadership records, account creation, credential delivery, user status, system notifications, and audit-log access. The Employee role manages operational waste records, master data, waste-bank information, filtering, reporting, and dashboard-based monitoring. Leadership access was implemented as a monitoring view within the documented authorization structure rather than as a third primary role. This authorization structure follows role-based access-control principles, in which permissions are associated with organizational responsibilities rather than assigned independently to individual users [16]. Figure 1 summarizes the interaction boundaries.

The implemented scope included authentication; administrator and waste-management dashboards; sub-district, waste-category, and landfill master data; waste-reduction, handling, and unhandled-waste records; facilities and infrastructure; waste sources and waste-generation estimates; waste-bank profiles, processing, and customer records; reporting; filtering; PDF export; notifications; activity logging; and logout. These functions were integrated around a shared relational data structure rather than implemented as independent application features. Security, usability, availability, performance, reliability, scalability, browser compatibility, and maintainability were specified as non-functional requirements or design objectives, but only functional conformance and perceived usability were empirically evaluated in the retained study record.

2.3 System Architecture, Data Integrity, and Traceability Controls

SIPEDAS was implemented as a decoupled web application designed to separate user interaction, application logic, and persistent data management. The frontend was developed using React and TypeScript, with Tailwind CSS supporting the presentation layer, while the backend was implemented in Laravel (PHP) as a RESTful API. Persistent records were maintained in a centralized MySQL relational database. This arrangement enabled the client interface to communicate with server-side business logic through structured JSON-based requests and responses while maintaining a common data layer for administrative and operational records. Figure 2 summarizes the resulting architecture and the interaction among the React/TypeScript client, Laravel RESTful API, and MySQL database.

REST was used as the application communication model because it provides a standardized interface between client-side and server-side components and is well suited to modular information-system architectures. Comparative API research indicates that REST can provide practical performance for information-intensive applications, although relative performance depends on workload, implementation, and comparison conditions [17]. REST is therefore treated here as an architectural mechanism supporting component separation and structured data exchange, not as evidence of superior system performance. The study did not include comparative API benchmarking or production-load testing.

Access governance was implemented through Laravel Sanctum-based authentication combined with role middleware. Authentication determines whether a user can establish an authorized session, whereas role middleware restricts functions according to organizational responsibilities, in line with role-based access-control principles [16].

At the data layer, the retained relational schema documents primary and foreign keys across user, master-data, operational, waste-bank, reporting, and activity-log entities. User accounts include a unique username/NIP constraint, controlled role values define authorization categories, and master tables provide shared reference values across operational modules. The documented application flow indicates that input validation occurs before records are committed to the database. These mechanisms support referential integrity and consistency but do not independently establish the factual correctness or completeness of data entered by users.

Traceability was supported through the log_aktivitas audit-trail structure. Each documented log entry contains a unique identifier, a foreign key referencing the responsible user, an action category documented for LOGIN, CREATE, UPDATE, or DELETE operations, the associated application module, a free-text activity description, and a created_at timestamp. The corresponding interface exposes chronological records containing user identity, time, action type, activity details, and agency context, with retrieval and search functionality. Functional scenario T09 verifies that chronological activity records can be retrieved and displayed.

The available test records do not include transaction-level checks linking every specific create, update, or delete operation to its exact resulting audit-log row. The results confirm that an audit mechanism was implemented and its records retrieved, but not complete provenance verification for every database transaction. Table 2 summarizes the implemented integrity and provenance controls together with the claim boundary associated with each control.

Together, these controls provide several complementary layers of data governance. Authentication and authorization regulate who can interact with particular functions; relational constraints organize how records are connected; controlled master data support consistency across modules; application validation governs data entry before storage; and activity logging provides an attributable history of recorded actions. The architecture therefore embeds data governance and administrative accountability into routine system interaction. The empirical evidence in this study establishes the implementation and selected functional verification of these mechanisms, while stronger claims regarding security resilience, complete transaction provenance, data accuracy, or production-scale reliability would require dedicated evaluation beyond the present study.

2.4 Functional Conformance Evaluation

Functional conformance was assessed through 25 requirements-based black-box test scenarios. Each scenario specified a module/requirement, authorized user role, input or action, expected output, and recorded pass/fail result. The test matrix includes a negative authentication case (T02: incorrect password or empty required login field). It does not document a systematic boundary-value suite across every form; this is therefore not claimed. The complete matrix is reported in Appendix A (Table A1) rather than only as aggregate domain counts.

The test matrix comes from the first author’s software-development project record. The archive does not identify a separate independent tester; tester independence is therefore not claimed, and the Black Box results are treated as functional verification associated with the development process. A scenario was classified as passed when its recorded behavior matched the expected result. The pass rate is the number of passing scenarios divided by the 25 executed scenarios. Because the set is requirement-based rather than a random sample of software states, 100% conformance describes only those executed cases.

2.5 Perceived Usability: Participants, Administration Record, and Statistical Analysis

Perceived usability was measured with the standard 10-item System Usability Scale (SUS), which provides a global rating of perceived system usability [18], [19]. The retained development report indicates that the questionnaire was distributed to 15 prospective users representing administrative, operational, supervisory, leadership, and waste-bank-related functions. However, only 10 complete participant-level SUS scoring records were retained in the study archive. The analytical sample was therefore restricted to these 10 complete records.

The complete records represented a range of organizational responsibilities, including operational staff, a unit head, supervisory and control functions, administrative personnel, and the agency secretary. Table 3 reports the organizational role and participant-level SUS score for each complete record. No aggregate result was reported for all 15 prospective participants because the remaining five questionnaires or item-level scoring records are unavailable.

The retained study record does not preserve sufficient procedural metadata to characterize the usability administration as a standardized task-based experiment. Specifically, it does not document a recruitment procedure, participants’ prior experience with comparable digital systems, duration of SIPEDAS exposure or training, completion of a common task script before the questionnaire, the interval between system use and SUS administration, whether assistance was provided during questionnaire completion, or a formal translation/adaptation record for the questionnaire wording. These undocumented factors were not used to explain differences among respondents.

These omissions do not change the descriptive statistics calculated from the 10 available SUS scores, but they limit interpretation of the usability context, comparability across participants, and any attempt to attribute score variation to specific user or administration characteristics. The available data provide evidence of perceived usability among the 10 documented participants under the study conditions; they do not establish first-use learnability, routine-use experience, training effectiveness, or role-dependent usability.

SUS scores were calculated using the standard scoring procedure [19]. For each odd-numbered item, 1 was subtracted from the response; for each even-numbered item, the response was subtracted from 5. The adjusted item contributions were summed and multiplied by 2.5 to yield a conventional 0–100 score.

Statistical analysis was conducted at the participant level. Descriptive statistics included the arithmetic mean, sample standard deviation, standard error, median, first and third quartiles, minimum, maximum, and observed range. An exploratory two-sided 95% t interval was calculated for the sample mean. Because the retained documentation does not establish probability-based sampling, the interval is interpreted as a description of uncertainty around the observed sample mean rather than as population-level inference.

SUS results were interpreted against a reference benchmark rather than assigned categorical labels. Scores were considered relative to the widely cited historical SUS benchmark of approximately 68 [18], while adjective classifications were treated cautiously because they can overstate the precision and substantive meaning of a single score [20]. Institutional operational permission and informed consent are documented in the retained record; however, no preserved formal ethics-committee approval, exemption, or waiver determination is available, and institutional permission is not treated as equivalent to research-ethics review.

2.6 Claim-Evidence Calibration

The evaluation distinguished system implementation, functional verification, perceived usability, actual use, and organizational outcomes as different levels of evidence. Conclusions were limited to the outcomes directly measured.

Requirement-derived Black Box testing was used to determine whether executed scenarios produced their predefined expected outputs. These results support claims about functional conformance under the documented test conditions, but do not establish the absence of software defects or validate characteristics not specifically tested.

The SUS assessment was used exclusively to characterize participants’ perceived usability of SIPEDAS. SUS scores were not interpreted as direct measures of task performance, productivity, learnability, adoption, organizational effectiveness, or public-service quality. Variation in participant scores was not causally attributed to role, digital literacy, exposure duration, or workflow experience because the corresponding explanatory variables were not retained.

No pre/post measurements were available for reporting time, data-entry accuracy, staff productivity, decision quality, data completeness, organizational efficiency, or other service-level outcomes. Technical evaluation also did not include dedicated load/performance benchmarking, penetration-security testing, reliability testing, recovery testing, or scalability assessment. No benefits were inferred for these unmeasured outcomes.

The resulting evidence hierarchy is as follows: implemented mechanisms indicate what the system was designed to provide; functional tests establish how selected workflows behaved under executed conditions; SUS scores characterize perceived usability among documented participants; and actual use or organizational net benefits require additional behavioral, longitudinal, or comparative evidence.

3.2 Functional Conformance Results (RQ2)

All 25 requirement-derived functional scenarios produced the expected outputs (25/25), corresponding to a 100% pass rate for the executed cases. Coverage included authentication and session handling, administrator and user management, operational dashboard and master data, waste-management operations, waste-bank functions, and reporting/filtering/notification/export workflows. This finding addresses the functional-testing component of RQ2. These findings establish conformance for the executed cases but not the absence of defects or broader software reliability, security, or production readiness. Table 4 summarizes the executed scenarios and pass rates by functional domain.

3.3 Perceived Usability Results (RQ2)

The 10 participant-level SUS scores were 62.5, 75.0, 75.0, 50.0, 67.5, 50.0, 80.0, 65.0, 80.0, and 77.5. The mean was 68.25 (68.3 when rounded to one decimal place), with a sample standard deviation of 11.37 and standard error of 3.59. The median was 71.25, the first quartile was 63.13, and the third quartile was 76.88; scores ranged from 50 to 80. An exploratory 95% t interval for the mean was 60.12–76.38. The 30-point observed range and the width of the interval make the heterogeneity and limited precision of this small-sample usability estimate explicit. Table 6 reports the descriptive statistics supporting this interpretation.

The mean is close to the commonly cited SUS benchmark, but the 30-point range shows that experience was not uniform. Role labels alone do not provide a consistent explanation: both lower and higher scores occur among staff/supervisory positions. Because prior digital experience, task frequency, exposure time, and administration conditions were not retained, the observed heterogeneity cannot be causally attributed to those factors. It instead identifies a concrete need for task-based follow-up that observes navigation, terminology, feedback, data-entry sequence, and reporting interactions.

4.2 Traceability, Accountability, and Public-Service Workflow

Digital transformation is not merely the conversion of paper into electronic records; it involves changes to processes, responsibilities, and service arrangements [5]. In SIPEDAS, moving from individual files to a shared platform changes where records are stored, who can modify them, how actions are attributed, and how reports are assembled. Role-based permissions and audit logging therefore function as administrative controls rather than decorative security features. This interpretation is consistent with municipal-waste platform research linking digital information exchange with reduced fragmentation [12] and with a plastic-recycling case showing how a digital platform can support community engagement and social impact [24].

Public-administration research further characterizes public-sector digital transformation as an ongoing organizational-change process involving managers and frontline workers rather than a one-time software installation [25]. An ICT-enabled reclaimer case from Cape Town similarly illustrates how digital systems can reshape interactions within informal waste-recycling arrangements [26]. SIPEDAS did not directly measure accountability or organizational-change outcomes, so these features are interpreted as enabling mechanisms rather than proven governance improvements.

Centralization also does not guarantee data quality. The contribution of the SIPEDAS architecture lies in making data governance more manageable through referential structure, controlled master data, validation, role-based access, and activity logging. Factual accuracy, completeness, semantic duplication, and full source-level provenance remain separate quality dimensions requiring additional controls and auditing. This distinction is particularly important because the motivating case itself included divergent waste-generation estimates from different administrative sources.

4.3 Functional Conformance and Human Experience Are Distinct Outcomes

The combination of 25 passing functional scenarios and a 50–80 SUS score range is the most informative human-centered finding. The two measures answer different questions. Black Box testing establishes whether predefined workflows produced their expected observable outcomes under recorded conditions; SUS captures participants’ overall perception of the system. The coexistence of 25/25 functional conformance with a broad usability distribution therefore shows that implementation correctness coexisted with varied user experiences.

The mean SUS score of 68.25 is close to the broad historical benchmark reported in SUS research [18], while the exploratory 95% interval (60.12–76.38) and observed range (50–80) show that the estimate is imprecise and user experience was uneven. Bangor et al. [20] demonstrate that adjective interpretations vary across the score continuum and should be used cautiously. The most defensible interpretation is therefore perceived usability close to the benchmark among the respondents, with meaningful room for refinement, not uniformly 'good' or 'excellent' usability.

The participant role labels do not provide a simple explanation for this variation. Both lower and higher scores occur among staff and supervisory functions. Because prior digital experience, task frequency, exposure duration, training, and standardized task performance were not retained, the present data cannot identify why individual experiences differed. A useful next step is task-based evaluation of navigation paths, terminology comprehension, form-entry sequence, feedback visibility, report filtering, task success, time on task, errors, and assistance needs.

This distinction matters for routine administrative systems. A technically conformant platform can still create friction when navigation, terminology, feedback, or task sequence conflicts with work practices. Triangulating SUS with observed task performance and structured qualitative feedback would help explain differences in reported usability and guide interaction-design changes.

4.4 Transferable Design Implications

The case suggests three design implications, which require testing in other settings. First, foundational data integration should precede advanced automation when a public agency still relies on fragmented records: predictive analytics, IoT, or AI can only be as useful as the data and governance structures beneath them. Second, accountability should be designed into routine workflow through role assignment, traceable actions, controlled identifiers, and report provenance rather than added after deployment. Third, technical conformance, human experience, actual use, and organizational net benefits should be evaluated as distinct outcomes because a system can satisfy every executed functional scenario while remaining difficult for some users or producing no demonstrated service improvement.

These implications extend the case beyond Padang Pariaman by framing traceable public-service workflow design as a human-centered computing problem without claiming universal effectiveness. A practical approach for similar systems is to establish a traceable data backbone, embed governance controls in routine interaction, verify requirement-derived behavior, and then evaluate user experience and organizational outcomes with methods suited to those distinct levels of evidence.

4.5 Limitations and Future Research

Several limitations constrain interpretation. The study was conducted in one local-government agency. The requirements archive does not preserve a complete interview-participant roster or formal validation sign-off. The 25 Black Box scenarios were developer-associated requirement checks rather than documented independent verification, and systematic boundary testing was not preserved. The SUS analysis uses only 10 complete records and lacks prior-experience, exposure-duration, standardized-task, timing, assistance, and formal translation metadata. Formal ethics approval/exemption/waiver documentation is not preserved, although institutional operational permission and informed consent are documented. The study contains no pre/post organizational outcomes or dedicated technical security, performance, reliability, recovery, or scalability benchmarks.

Future research should move from implementation evidence toward comparative, task-based, and longitudinal evidence. Priority extensions include larger multi-role samples; moderated usability sessions; accessibility evaluation; measurement of task success, time, and errors; performance and security testing; backup-and-recovery validation; and prospective assessment of reporting effort, data completeness, and decision-support use. Multi-site replication should test whether the workflow architecture and traceability mechanisms transfer across agencies with different staffing, infrastructure, governance maturity, and data practices. The existing RESTful API also provides a basis for mobile clients, external-system integration, and GIS functionality for spatial monitoring.