Organized by user journeys. Each journey has a mandatory base (MUST) derived from the project's Functional and Non-Functional Requirements, plus opt-in modules that add acceptance criteria when selected. All cited text comes directly from the project subject PDF.
Each user journey has two layers:
-
MUST — Mandatory requirements from the PDF (NFRs + FRs). Non-negotiable. Failure on any of these = project rejection regardless of module points.
-
OPT-IN — Optional modules the team selects. When a module is opted in, its criteria become MUST for that module's points to count during evaluation. The PDF evaluation rule (p.11 §IV): "Only fully functional and properly implemented modules will be counted toward your final score."
feat/FR-<id>-<slug> # Feature work on a user journey
fix/FR-<id>-<slug> # Bug fix on an existing journey
chore/<slug> # Non-functional (deps, configs, linting)
devops/<slug> # Docker, CI, deployment
docs/<slug> # Documentation only
These mandatory requirements apply to every screen and interaction in the application. They are not repeated per journey — they are always part of the Definition of Done.
Every feature branch must satisfy these before merging:
| NFR | Requirement | Cited Text (PDF) |
|---|---|---|
| NFR-5 | No console warnings or errors | "No warnings or errors should appear in the browser console." (p.8 §III.2) |
| NFR-6 | Multi-user concurrency, no race conditions | "No data corruption or race conditions occur with simultaneous user actions." (p.8 §III.2) |
| NFR-7 | Real-time updates across connected users | "Real-time updates are reflected across all connected users when applicable." (p.8 §III.2) |
| NFR-8 | Clear, responsive, accessible frontend | "A frontend that is clear, responsive, and accessible across all devices." (p.9 §III.3) |
| NFR-12 | All forms validated frontend + backend | "All forms and user inputs must be properly validated in both the frontend and backend." (p.9 §III.3) |
These are verified once at the project level, not per feature:
| NFR | Requirement | Cited Text (PDF) |
|---|---|---|
| NFR-1 | Web app with frontend, backend, and database | "The project must be a web application, and requires a frontend, backend, and a database." (p.8 §III.2) |
| NFR-2 | Git: clear commits from all team members | "Git must be used with clear and meaningful commit messages. The repository must show: Commits from all team members. Clear commit messages describing the changes. Proper work distribution across the team." (p.8 §III.2) |
| NFR-3 | Containerization, runs with single command | "Deployment must use a containerization solution (Docker, Podman, or equivalent) and run with a single command." (p.8 §III.2) |
| NFR-4 | Compatible with latest stable Chrome | "Your website must be compatible with the latest stable version of Google Chrome." (p.8 §III.2) |
| NFR-9 | CSS framework or styling solution | "Use a CSS framework or styling solution of your choice." (p.9 §III.3) |
| NFR-10 | Credentials in .env (gitignored), provide .env.example |
"Store credentials in a local .env file that is ignored by Git, and provide an .env.example file." (p.9 §III.3) |
| NFR-11 | Database with clear schema and well-defined relations | "The database must have a clear schema and well-defined relations." (p.9 §III.3) |
| NFR-13 | HTTPS everywhere (backend) | "For the backend, HTTPS must be used everywhere." (p.9 §III.3) |
| NFR-14 | Must use a framework | "A framework is defined as a comprehensive tool that provides: A structured architecture and conventions for organizing code." (p.9 §III.3) |
Branch: feat/FR-01-user-signs-up-and-sets-up-profile
Description: A new user discovers the app, creates an account, logs in, and personalizes their profile before engaging with other features.
| Source | Criteria | Cited Text (PDF) |
|---|---|---|
| FR-1 | Privacy Policy page is accessible with relevant content | "The project must include accessible Privacy Policy and Terms of Service pages with relevant content. Missing or inadequate Privacy Policy/Terms of Service pages will result in project rejection." (p.8 §III.2) |
| FR-2 | Terms of Service page is accessible with relevant content | "Be easily accessible from the application (e.g., footer links). Contain relevant and appropriate content for your project. Not be placeholder or empty pages." (p.8 §III.2) |
| FR-3 | User can sign up with email and password | "Users must be able to sign up and log in securely." (p.9 §III.3) |
| FR-4 | Passwords are hashed and salted | "At minimum: email and password authentication with proper security (hashed passwords, salted, etc.)." (p.9 §III.3) |
| FR-5 | Multiple users can be logged in simultaneously | "Users should be able to interact with the application at the same time without conflicts or performance issues." (p.8 §III.2) |
Source: p.14 §IV.3
| Criteria | Cited Text (PDF) |
|---|---|
| Users can update their profile information | "Users can update their profile information." |
| Users can upload an avatar (with a default avatar if none provided) | "Users can upload an avatar (with a default avatar if none provided)." |
| Users have a profile page displaying their information | "Users have a profile page displaying their information." |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| Screens in this journey use design system components | "Custom-made design system with reusable components." |
| Proper color palette, typography, and icons applied | "Including a proper color palette, typography, and icons." |
Source: p.13 §IV.2
| Criteria | Cited Text (PDF) |
|---|---|
| All user-facing text on screens in this journey is translatable | "All user-facing text must be translatable." |
| Language switcher is available in the UI | "Language switcher in the UI." |
| At least 3 complete language translations cover this journey | "At least 3 complete language translations." |
Branch: feat/FR-02-user-finds-and-adds-friends
Description: A logged-in user searches for other users, sends friend requests, accepts or declines incoming requests, and sees their friends' online status.
| Source | Criteria | Cited Text (PDF) |
|---|---|---|
| FR-5 | Multiple users interacting simultaneously without conflicts | "Users should be able to interact with the application at the same time without conflicts or performance issues." (p.8 §III.2) |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| A friends system (add/remove friends, see friends list) | "A friends system (add/remove friends, see friends list)." |
Source: p.14 §IV.3
| Criteria | Cited Text (PDF) |
|---|---|
| Users can add other users as friends and see their online status | "Users can add other users as friends and see their online status." |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| Real-time updates across clients (friend requests, online status) | "Real-time updates across clients." |
| Handle connection/disconnection gracefully | "Handle connection/disconnection gracefully." |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| Screens in this journey use design system components | "Custom-made design system with reusable components." |
| Proper color palette, typography, and icons applied | "Including a proper color palette, typography, and icons." |
Source: p.13 §IV.2
| Criteria | Cited Text (PDF) |
|---|---|
| All user-facing text on screens in this journey is translatable | "All user-facing text must be translatable." |
Branch: feat/FR-03-user-chats-with-friends
Description: A user opens a conversation with a friend and sends and receives messages.
| Source | Criteria | Cited Text (PDF) |
|---|---|---|
| FR-5 | Multiple users interacting simultaneously without conflicts | "Users should be able to interact with the application at the same time without conflicts or performance issues." (p.8 §III.2) |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| A basic chat system (send/receive messages between users) | "A basic chat system (send/receive messages between users)." |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| Implement real-time features using WebSockets or similar technology | "Implement real-time features using WebSockets or similar technology." |
| Real-time updates across clients | "Real-time updates across clients." |
| Efficient message broadcasting | "Efficient message broadcasting." |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| Screens in this journey use design system components | "Custom-made design system with reusable components." |
| Proper color palette, typography, and icons applied | "Including a proper color palette, typography, and icons." |
Source: p.13 §IV.2
| Criteria | Cited Text (PDF) |
|---|---|
| All user-facing text on screens in this journey is translatable | "All user-facing text must be translatable." |
Branch: feat/FR-04-user-plays-online-match
Description: A user finds an opponent, plays a real-time Pong match on a separate computer, and sees the result when the game ends.
| Source | Criteria | Cited Text (PDF) |
|---|---|---|
| FR-5 | Multiple users interacting simultaneously without conflicts | "Users should be able to interact with the application at the same time without conflicts or performance issues." (p.8 §III.2) |
Source: p.16 §IV.6
| Criteria | Cited Text (PDF) |
|---|---|
| A complete web-based game where users can play against each other | "Implement a complete web-based game where users can play against each other." |
| Players must be able to play live matches | "Players must be able to play live matches." |
| The game must have clear rules and win/loss conditions | "The game must have clear rules and win/loss conditions." |
Source: p.16 §IV.6 Dependency: Requires GAME-01
| Criteria | Cited Text (PDF) |
|---|---|
| Two players on separate computers play the same game in real-time | "Enable two players on separate computers to play the same game in real-time." |
| Handle network latency and disconnections gracefully | "Handle network latency and disconnections gracefully." |
| Smooth user experience for remote gameplay | "Provide a smooth user experience for remote gameplay." |
| Reconnection logic implemented | "Implement reconnection logic." |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| Implement real-time features using WebSockets or similar technology | "Implement real-time features using WebSockets or similar technology." |
| Handle connection/disconnection gracefully | "Handle connection/disconnection gracefully." |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| Screens in this journey use design system components | "Custom-made design system with reusable components." |
| Proper color palette, typography, and icons applied | "Including a proper color palette, typography, and icons." |
Source: p.13 §IV.2
| Criteria | Cited Text (PDF) |
|---|---|
| All user-facing text on screens in this journey is translatable | "All user-facing text must be translatable." |
Branch: feat/FR-05-user-tracks-progress-and-stats
Description: After playing matches, a user views their game statistics, match history, achievements, and standing on the leaderboard.
| Source | Criteria | Cited Text (PDF) |
|---|---|---|
| FR-5 | Multiple users interacting simultaneously without conflicts | "Users should be able to interact with the application at the same time without conflicts or performance issues." (p.8 §III.2) |
Source: p.14 §IV.3 Dependency: Requires at least one game module (GAME-01)
| Criteria | Cited Text (PDF) |
|---|---|
| Track user game statistics (wins, losses, ranking, level, etc.) | "Track user game statistics (wins, losses, ranking, level, etc.)." |
| Display match history (1v1 games, dates, results, opponents) | "Display match history (1v1 games, dates, results, opponents)." |
| Show achievements and progression | "Show achievements and progression." |
| Leaderboard integration | "Leaderboard integration." |
Source: p.17 §IV.6 Dependency: Requires at least one game module (GAME-01)
| Criteria | Cited Text (PDF) |
|---|---|
| Implement at least 3 of: achievements, badges, leaderboards, XP/level system, daily challenges, rewards | "Implement at least 3 of the following: achievements, badges, leaderboards, XP/level system, daily challenges, rewards." |
| System must be persistent (stored in database) | "System must be persistent (stored in database)." |
| Visual feedback for users (notifications, progress bars, etc.) | "Visual feedback for users (notifications, progress bars, etc.)." |
| Clear rules and progression mechanics | "Clear rules and progression mechanics." |
Source: p.12 §IV.1
| Criteria | Cited Text (PDF) |
|---|---|
| Screens in this journey use design system components | "Custom-made design system with reusable components." |
| Proper color palette, typography, and icons applied | "Including a proper color palette, typography, and icons." |
Source: p.13 §IV.2
| Criteria | Cited Text (PDF) |
|---|---|
| All user-facing text on screens in this journey is translatable | "All user-facing text must be translatable." |
This table shows which journeys each optional module touches. When a module is selected, its criteria become MUST in all journeys marked with ●.
| Module | Points | J1: Sign Up | J2: Friends | J3: Chat | J4: Play | J5: Stats |
|---|---|---|---|---|---|---|
| WEB-01: FE+BE Framework | 2 | ● | ● | ● | ● | ● |
| WEB-02: Real-Time Features | 2 | ● | ● | ● | ||
| WEB-03: User Interaction | 2 | ● | ● | |||
| WEB-05: ORM | 1 | ● | ● | ● | ● | ● |
| WEB-07: Design System | 1 | ● | ● | ● | ● | ● |
| A11N-01: i18n | 1 | ● | ● | ● | ● | ● |
| USR-01: User Management | 2 | ● | ● | |||
| USR-02: Game Stats | 1 | ● | ||||
| GAME-01: Complete Game | 2 | ● | ||||
| GAME-02: Remote Players | 2 | ● | ||||
| GAME-03: Gamification | 1 | ● |
From the PDF — some modules require others to be selected:
GAME-01: Complete Web Game ◄─── REQUIRED FIRST
│
├──► GAME-02: Remote Players (p.16 §IV.6)
├──► GAME-03: Gamification (p.17 §IV.6)
└──► USR-02: Game Stats & Match History (p.14 §IV.3)
These are verified at the project level. Failure on any = project rejection.
Branch: chore/mandatory-compliance
| ID | Criteria | Cited Text (PDF) | Verification |
|---|---|---|---|
| NFR-3 | Single-command deployment | "Deployment must use a containerization solution and run with a single command." (p.8 §III.2) | docker compose up from fresh clone |
| NFR-4 | Chrome compatibility | "Compatible with the latest stable version of Google Chrome." (p.8 §III.2) | Full walkthrough in Chrome |
| NFR-10 | .env.example provided |
"Store credentials in a local .env file that is ignored by Git, and provide an .env.example file." (p.9 §III.3) | File exists and is complete |
| NFR-13 | HTTPS everywhere | "For the backend, HTTPS must be used everywhere." (p.9 §III.3) | Verify SSL in deployment |
| FR-1 | Privacy Policy page | "Accessible Privacy Policy with relevant content. Not be placeholder or empty pages." (p.8 §III.2) | Navigate to page, verify real content |
| FR-2 | Terms of Service page | "Accessible Terms of Service with relevant content. Not be placeholder or empty pages." (p.8 §III.2) | Navigate to page, verify real content |
"Missing or inadequate Privacy Policy/Terms of Service pages will result in project rejection."
Target: 14 points minimum (p.10 §IV)
Currently selected modules (from scorecard):
| Module | Points | Status |
|---|---|---|
| WEB-01: FE+BE Framework | 2 | DONE |
| WEB-02: Real-Time Features | 2 | IN PROGRESS |
| WEB-03: User Interaction | 2 | IN PROGRESS |
| WEB-05: ORM | 1 | DONE |
| WEB-07: Design System | 1 | IN PROGRESS |
| A11N-01: i18n | 1 | IN PROGRESS |
| USR-01: User Management | 2 | IN PROGRESS |
| USR-02: Game Stats | 1 | IN PROGRESS |
| GAME-01: Complete Game | 2 | DONE |
| GAME-02: Remote Players | 2 | DONE |
| GAME-03: Gamification | 1 | IN PROGRESS |
| Total | 17 |
Buffer: 3 points above the 14-point target.
Worst case: If any IN PROGRESS module fails evaluation, it scores 0. The team can lose up to 3 points worth of modules and still pass.
Authoritative resources on user journey mapping as a practice:
-
Journey Mapping 101 — Nielsen Norman Group The foundational reference from NN/g. Defines what a journey map is, its key components (actor, scenario, phases, actions, thoughts, emotions, opportunities), and when to use one. NN/g is the leading authority on evidence-based UX research.
-
User Journeys vs. User Flows — Nielsen Norman Group Clarifies the distinction between journey maps (high-level, experience-focused, captures emotions and pain points) and user flows (granular, task-focused, captures specific UI steps). Important for understanding why this document uses journeys rather than flows — we care about end-to-end outcomes, not click-by-click paths.
-
How to Create Actionable User Journey Maps — Interaction Design Foundation Practical guidance from IxDF on making journey maps actionable rather than decorative — mapping user goals to acceptance criteria, identifying pain points, and using the map as a living document that drives development priorities.