Requirements Review & Acceptance Planning

Revisit Requirements

The remaining requirements are given here for Milestone 3, and evaluation is done for them.

Remaining Requirements

Requirement Number	Description
1.1.1.3	Registered users shall be able to reset their passwords.
1.1.3.2	Registered users shall be able to earn points for logging recycling.
1.1.4.3	Moderator shall be able to see reports that are sent by users about a post.
1.1.4.4	Moderator shall be able to delete a post if it includes inappropriate words...
1.1.5.1	Registered users shall be able to view the available badge that they receive...
1.1.5.2	Registered users shall be able to take badges from the forum activities automatically.
1.1.5.3	Users shall submit feedback, suggest improvements...
1.2.3.2	The system shall assign achievement badges when users reach predefined milestones...
1.2.3.3	The system shall provide a badge catalog where each badge is described.
1.2.3.4	The system shall assign achievement badges when users are in the first three places...
1.2.4.2	The system shall send a notification to people for the update of the leaderboard situation.
1.2.5.2	The system shall include tagging and categorization features...
2.2.1	The platform should be designed for horizontal scalability...
2.4.3	The platform shall support at least one screen reader...
2.4.4	The platform shall support text resizing up to 200%...
2.5.1	The platform shall prioritize hosting providers with certified renewable energy usage...

Reset password and Recycling Points (1.1.1.3)

It is a small feature, so we will just put a reset password button and implement its endpoint.

Moderator and Report (1.1.4.3 ,1.1.4.4)

The report and moderator implementation are one of the main features of Milestone 3, we will figure out first before anything else.

Feedback (1.1.5.3)

At the moderator page, there will also be feedback, and users will give feedback about the application, which will have a title, description etc.

Badges (1.1.5.1, 1.1.5.2, 1.2.3.2, 1.2.3.3, 1.2.3.4)

The badges feature was a solid and motivating part of our previous application. We removed it during the redesign, but since we have the know-how from the previous term, we will start developing it from scratch, just as it was.

Tagging and Categorization (1.2.5.2)

We will add this similarly to our Semantic Search feature from last year. The necessary infrastructure is complete, and only the implementation is left.

Notification Addition (1.2.4.2)

The notification feature is done at Milestone 2; we will just add a new type for the leaderboard.

Horizontal Scalability (2.2.1)

Since our system does not require many users for this lecture and we will not need to figure out scaling, our deployment will be just as it is, a Digital Ocean machine and a containerized system with fixed memory, disk, etc.

Additional Accessibility and Sustainability Requirements (2.4.3, 2.4.4 and 2.5.1)

We will meet these requirements by implementing support for screen readers and text resizing in the frontend, and by ensuring our hosting provider utilizes renewable energy.

Acceptance Test Planning

In our overall project plan, backend testing was intentionally prioritized and performed earlier because the smaller, foundational units of the backend functions needed to be stable and available for the frontend to successfully execute its further development and their end-to-end tests.

This strategy includes continued use of Unit Testing for both backend and frontend/mobile components with explicit emphasis on implementing these unit tests within the frontend to assure the correctness of individual component implementations.

Integration and End-to-End (E2E) validation will continue via chained user scenarios executed through Postman collections for the backend. For the frontend, we use the application during development and review to confirm that all acceptance criteria are met from a direct user interaction perspective.

Acceptance Criteria

• Users can use voiceover with full support.
• Users can write feedback messages for the app.
• Users can search other users by their usernames
• Users can filter their posts via waste type
• Display waste savings in real-life equivalent terms for user engagement.
• Users earn points as they recycle within a challenge. Points increase as users participate more, moving them up in leaderboards.
• Reset passwords functionality for the application
• Challenges to be for specific types
• Feature for reporting accounts/posts
• Feature that shows earned badges and makes them visible to others

Current Compliance Status

In this section, we assessed our application's W3C compliance in several aspects through several standards.

W3C ActivityStreams 2.0

Current Status

Our current implementation of the ActivityLogger and NotificationService meets our project's core requirements. We have successfully established a logging format compatible with W3C ActivityStreams standards, ensuring our data is structured correctly for future interoperability. We successfully generate JSON payloads using the standard @context. Standard fields (actor, object, target, type) are mapped correctly for third-party parsers. Moreover, our code is concise, combining serialization and notification triggering to reduce complexity. The NotificationService handles user alerts cleanly, and ObjectMapper ensures reliable JSON output. While the system is operational, we have identified a couple areas where minor adjustments will ensure long-term stability.

Plans to Address Compliance Gaps

Currently, we keep local IDs instead of strict absolute URIs which the Activity Streams 2.0 expects. However, we cannot switch to URL-based IDs because our frontend architecture relies on pop-ups rather than distinct pages for users and posts. Due to tight delivery timelines, a frontend refactor to support URL doesn't seem possible.

Furthermore, the logger currently writes logs and triggers database notifications. If there is any database related errors, we risk losing the log trace. To deal with this potential error, we will separate logging from notifications. This ensures logs are written even if the notification service fails.

Laslty, we currently use the check (targetId instanceof List<?> l) which is a creative solution to handle multiple targets, but it is slightly fragile. We will standardize the input to always expect a list, or separate the method into logAction (single) and logGroupAction (multiple) to prevent runtime casting errors so the targetId will always be a list and therefore the JSONs will all be of the same structure.

WCAG 2.1 AA

Current status

At the start of the first phase of project development, we have enhanced our SRS with new requirements to increase our application's compliance with WCAG 2.1 AA. We have partially competed these requirements. We implemented and manually verified core AA practices on the web such as non-text alternatives, contrast, keyboard operability, visible focus, consistent navigation. On mobile, we implemented non-text alternatives and contrast support, and consistent navigation patterns. Remaining gaps are mainly screen-reader completeness (VoiceOver behavior in dialogs, and formal VoiceOver/TalkBack validation) and in-application text resize implementation (200%/large scaling checks and any needed layout fixes). Detailed analysis of the related requirements/standards and their implementation details are explained in the related section of Milestone 2 Report.

Plan to Address Compliance Gaps

We plan to conduct a complete screen-reader testing on both platforms, either manually or with E2E testing, fix/add any missing aria-label, and achieve a seamless experience with assistive technologies such as VoiceOver. Although text can be resized up to 200% with the browser resizing tools, we plan to implement up to in-application 200% text resizing feature on both web and mobile. These two enhancements/implementation done, all the aimed standards will be achieved and our application will be compliant with WCAG 2.1 AA guidelines to a large extent.

Internationalization (i18n)

Current status

Our application is mostly compliant for core i18n requirements. We support English and Turkish using react-i18next (web) and i18next (mobile), follow BCP 47 locale conventions, and use key-based translation via per-locale JSON resources and alt/aria-label attributes in elements (no hardcoded UI strings in translated areas). We also have a fallback mechanism (fallbackLng: 'en') and unit tests for content internationalization and dynamic content verification. Advanced i18n topics (RTL, locale-aware number/currency/calendar formatting) are intentionally out of scope. Further detail consists in the related section of the Milestone 2 Report.

Plan to close gaps

We plan to perform a final audit to eliminate remaining hardcoded strings, ensure all new UI text (including accessibility labels like alt/aria-label) uses translation keys, and verify language switching across all major flows. Our ultimate goal is to test our whole application with E2E tests to ensure full i18n compliance.

User Experience Assessment

1. Customer Feedback on User Experience

During the Milestone 2 presentation, the customer validated the core functionality of the project. However, specific feedback was provided regarding the clarity and logic of the user interface:

• Contextual Ambiguity in the Activity Stream: The customer identified a usability gap in the notification system. The current format (e.g., "User X liked your post") was deemed insufficient for a positive UX. Users currently lack the context to identify exactly which post triggered the interaction or when it occurred, leading to potential confusion.
• Generic Wastes in Challenges: The customer highlighted a disconnect in the "Challenges" feature, specifically regarding waste entry. The current reliance on free-text input and generic "amount" logs feels inconsistent with the rest of the application. The feedback emphasized that engaging gamification requires precise units and standardized metrics. To fix this, the established UX for "Waste Goals" must be replicated in "Challenges" since it is already sufficient in being precise and it got positive feedback from the customer.
• Impact Visibility: While the Impact Visibility feature functions technically, the UX relies heavily on historical data to be meaningful. Our demo revealed that without a rich dataset, the feature's value is not immediately apparent to the customer. Consequently, we must prioritize precise and comprehensive data population to properly showcase this feature in the Milestone 3 presentation.

2. UX Goals for Final Delivery

Our goal in the UX side for the final delivery is as following:

1. Eliminate Ambiguity in Notifications: Every notification must provide immediate context so the user never has to guess the source of an interaction. We will achieve this by:
   • Including a thumbnail if the post contains a photo.
   • Displaying the first 30 characters of the post body.
   • Replacing absolute timestamps with relative time (e.g., "5 minutes ago") for a smoother, more intuitive experience.
2. Unified Logical Flow in Challenges: The experience between "Logging Waste" and "Participating in Challenges" must feel similar. By standardizing the units and inputs as we did in Waste Goals, we aim to reduce the cognitive load on the user.
3. Data-Rich Visualization: We will ensure the final product is populated with sufficient, realistic demo data. This is essential to ensure that statistical visualizations act as a true showcase of the system's analytical capabilities.