CS2 Smart Replay Platform — Requirement Analysis (Assignment 3)

A team requirement-analysis deliverable for the Software Engineering course. This post provides the Software Requirements Specification (SRS) and the presentation links, summarizes the functional requirements, domain model, class diagrams and interface prototypes, and documents the team division of labor, the 16-week schedule, collaboration, and the key points and challenges encountered.

Basic Information

Table of Contents

• 1. Software Requirements Specification and Document Links
  • 1.1 Functional requirements overview
  • 1.2 Domain model and UML class diagrams
  • 1.3 Interface prototypes
• 2. Team Division of Labor and Contribution
• 3. Team Organization and Schedule
  • 3.1 Team Organization Method
  • 3.2 Approximate 16-Week Project Schedule
• 4. Team Collaboration and Progress Management
  • 4.1 Task allocation
  • 4.2 Communication methods
  • 4.3 Document collaboration
  • 4.4 Progress tracking
  • 4.5 Review and integration
• 5. Project Key Points and Challenges

1. Software Requirements Specification and Document Links

The complete SRS and the requirement-analysis presentation are hosted on our GitHub repository and are provided below.

• Software Requirements Specification (SRS): https://github.com/2310209788-del/cs2-intelligent-review-platform/blob/main/docs/CS2-Smart-Replay-Platform-SRS-V1.1.docx
• Requirements Analysis Presentation (PPT, exported as PDF): CS2 Smart Replay Platform — Requirement Analysis Report.pdf
• Repository: https://github.com/2310209788-del/cs2-intelligent-review-platform

The SRS (V1.1) follows the recommended national-standard structure and covers every item on the SRS checklist: the Introduction, user scenarios / personas, functional and non-functional requirements, the domain model and UML class diagrams, the interface prototypes, the functional description with use cases, and the acceptance and verification criteria. Terms and abbreviations are defined on first use, and the figures, tables, and writing style are kept consistent throughout. The most important contents are summarized below.

1.1 Functional requirements overview

The platform is divided into four core functional modules, with the high-priority requirements focused on the first three.

The non-functional requirements cover performance (one match parsed in 2–3 minutes, first screen within 3 seconds), concurrency (rate-limited parsing queue), compatibility (mainstream browsers and 1280+ resolutions), security (encrypted passwords, least privilege), and privacy/compliance (official interfaces only, no game-memory reading or cheating features).

1.2 Domain model and UML class diagrams

To keep the model readable, the domain is split into two package diagrams. The first covers the demo-review domain: a Replay is parsed into a Match, which contains Rounds and PlayerMatchStats and is associated with a ReviewReport; the report aggregates the HeatMap, EconomyAnalysis, and GrenadeAnalysis value objects.

Figure 1. UML class diagram of the demo-review domain (replay → match → rounds/stats → report → analysis).

The second covers the account, squad, and training domain: a User owns a PlayerProfile and plays AimTrainingSessions; a User posts a Squad, and each Squad receives SquadApplications from applicants, which the poster approves.

Figure 2. UML class diagram of the account, squad, and aim-training domain (user → profile, squads/applications, and training sessions).

1.3 Interface prototypes

The SRS includes low-fidelity wireframes for the four core pages to show the information architecture and the main interaction flow.

The review report page (Figure 3) uses a left navigation bar that switches between the match overview, radar/heat-map, economy, combat data, grenade analysis and weakness diagnosis, with a match header, per-round timeline, key metrics, and a weakness-diagnosis panel.

Figure 3. Interface prototype — intelligent review report.

The squad lobby (Figure 4) provides a "post a squad" button and a filter panel (role, rank, map pool); each squad card shows the missing roles, ranks, maps, start time, current members and an apply button.

Figure 4. Interface prototype — campus squad lobby.

The aim training page (Figure 5) has a mode-selection bar (Gridshot, Reaction, Spidershot, Microshot, Tracking) and a full-screen game canvas with a crosshair, targets, and a score/time/hit-rate HUD.

Figure 5. Interface prototype — web aim training.

The personal center (Figure 6) shows the player profile card (rank, roles, total matches), tabs for match history, review reports and aim scores, and an aim-score trend chart.

Figure 6. Interface prototype — personal center.

The full SRS does not need to be presented in the PPT; the presentation focuses on the project background, the core requirements, the class diagrams, and the interface prototypes.

2. Team Division of Labor and Contribution

The table below lists each member's student ID, task description, and contribution percentage for this assignment. The total contribution sums to 100%.

3. Team Organization and Schedule

3.1 Team Organization Method

The team is organized by role ownership, with every deliverable having a clear owner. The work is divided into three workstreams:

1. Development & Architecture: the back-end lead set up the Node.js skeleton, the Git repository, and the core APIs; the front-end lead built the web framework and pages.
2. Coordination & Integration: the Product Manager controlled the direction, made the PPT, and presented; the documentation specialist integrated the final blog draft.
3. Content Writing: designated members wrote the task breakdown, collaboration mechanisms, and key-challenge analysis for the blog.

3.2 Approximate 16-Week Project Schedule

The course runs over 16 weeks. The rough, phase-based schedule is shown below; the exact dates follow the course schedule and are synchronized with each successive assignment.

4. Team Collaboration and Progress Management

4.1 Task allocation

This assignment adopts a role-based division of labor, splitting the work into three areas so that every deliverable has a clear owner:

1. Development & Architecture: the back-end lead set up the Node.js skeleton, Git repo, and APIs; the front-end lead built the web framework and wrote the core requirements-analysis document.
2. Coordination & Integration: the PM controlled the direction, made the PPT, and presented; the documentation specialist integrated the final blog draft.
3. Content Writing: designated members wrote the task breakdown and collaboration mechanisms for the blog.

4.2 Communication methods

Daily communication relies mainly on the WeChat group, where members synchronize task progress and raise questions at any time. Important conclusions are confirmed in writing within the group to avoid omissions after verbal discussion.

4.3 Document collaboration

The content written by each member is consolidated by the documentation specialist. Revisions to the blog and the SRS are kept up to date through group synchronization and version updates, ensuring everyone sees the same version. The SRS and the presentation are versioned and hosted on GitHub, so all changes are traceable.

4.4 Progress tracking

The team tracks progress through "role ownership + group synchronization": each role owner paces their part against the assignment deadline and synchronizes current progress and blockers in the WeChat group. The PM oversees the overall direction and, when a part falls behind, coordinates additional support in time to ensure all deliverables are completed before the deadline.

4.5 Review and integration

The review and integration phase proceeds through "cross-checking + unified consolidation": the front-end lead checked whether the back-end APIs met the page requirements to ensure front-end/back-end consistency, while the content writers cross-checked the logic and consistency of the blog content. The PM then finalized the PPT, and the documentation specialist integrated all documents, charts, and links into the final blog post for publication, confirming before publication that both the SRS and PPT links open correctly.

5. Project Key Points and Challenges

(1) Bandwidth trade-offs in large-file uploads

When multiple users upload replays of 50–150 MB (often over 100 MB) simultaneously, bandwidth is consumed and uploads slow down during peak hours. This is a physical limitation that can only be mitigated through upload progress indicators and limits on concurrent uploads per user. Requirements must specify not only "can upload" but also "how the system behaves under heavy upload load."

(2) Early identification of resource-intensive features

A single replay is 50–150 MB, and parsing is a CPU- and memory-intensive operation that may compete with other tasks. We required an asynchronous parsing queue and rate-limited queuing according to server configuration to prevent crashes, moving resource constraints forward into the requirements layer. The challenge is balancing fast parsing against preventing concurrent loads from crashing the server, which can only be achieved through queue scheduling.

(3) Volatility of unlogged-in data

When not logged in, aim-training scores are stored only locally in the browser, and clearing the cache causes score loss; logged-in users can save scores to their personal curve. The challenge lies in the trade-off between zero-barrier access and data retention.

(4) Compliance and engineering ethics constraints

The project uses only official open interfaces and post-match replays; it does not inject into the game process, does not read or write game memory, and does not provide any feature that undermines match fairness (such as displaying enemy positions). This directly rules out solutions that read match memory in real time — compliance is a design prerequisite, not an after-the-fact check.

(5) Conducting real user research

Our plan combines four steps: questionnaires, in-depth interviews, card sorting, and rapid prototyping, with questionnaires distributed to classes, dormitories, and the esports club. The questionnaires and interviews are still in progress, and some conclusions will be added to the document in later iterations; we have marked this as to be improved in the document and will explain the updates in a subsequent assignment blog post.