CodeStrike - Group 5 - Assignment 3: Requirements Analysis

Contents

1. Team Division of Labor and Contribution Percentages

1.1 Members and Initial Division of Labor

The following table describes the team’s overall project responsibilities. Its percentages are planned workload allocations for the whole project. Contributions to Assignment 3 are reported separately in Section 1.2.

1.2 Specific Division of Labor for This Assignment

This section accounts for the requirements analysis and material preparation work undertaken for Assignment 3, including SRS refinement, class diagrams, interface prototypes, the PPT, and the blog.

2. Software Requirements Specification

2.1 Documents and Attachments

The user scenarios, prototypes, and acceptance cases in the SRS describe expected behavior. The deliverables completed for this assignment are requirements analysis materials; actual functionality and test results will be recorded during subsequent development and verification.

2.2 Project Background, Purpose, and Scope

This project primarily serves first- to third-year students at Fuzhou University. It addresses scattered competition information, fragmented teammate recruitment, difficulty retaining and sharing competition preparation experience, and dispersed personal study plans. The requirements are based on team discussions, members' experiences during their first two university years, and informal feedback from junior students. Formal user interviews have not yet been conducted.

The student-facing clients include an H5 web client and a WeChat Mini Program, sharing accounts, business data, and permission rules. A separate web administration portal supports competition and skill maintenance, content moderation, and violation handling. The product uses the "Competition Hub + competition-specific communities" as the entry point for competition exchanges, while also providing an independent personal planner.

The current scope includes three main user workflows:

Competition Team Formation

Discover a competition → view its details and complete a personal profile → apply to a team with published recruitment → captain review → admission and member management. Students who wish to become captains may also create a team directly when eligible and submit recruitment for review.

Community Exchanges

Enter a competition-specific community → submit a post or comment → publish after administrator approval → browse, like, favorite, and view processing results.

Personal Planning

Sign in → manually enter courses, timed plans, or to-dos → view them by day or week → set a finite weekly recurrence and handle individual occurrences independently.

All modules above are within the current delivery scope. A broader campus activity catalog, complex recommendations, WeChat push notifications, personal plan reminders, user banning/unbanning, team task boards, milestones, deliverable files, and internal chat are outside this scope. Experience sharing uses text, images, and external links; uploading arbitrary resource-file attachments is not provided.

Figure 1. System Context and Logical Modules. The H5 client, WeChat Mini Program, and administration portal share business services and data. The server enforces permissions and business rules according to roles. Specific frameworks, databases, and deployment methods will be determined during the subsequent design stage.

2.3 Class Diagrams

Figures 2–4 present the conceptual domain models for team formation, community content and moderation, personal scheduling, and in-app notifications. They show the main classes and their relationships. Detailed business rules and access permissions are defined in Section 2.5.

Figure 2. Account, Competition, and Team Formation Domain Classes. JoinApplication records five states: Pending, Approved, Rejected, Withdrawn, and Invalidated. ActiveMembership represents current membership separately from application history. A student may have at most one active membership per competition. Each active team has exactly one captain, who counts toward team capacity. Profile-access rules are defined in Section 2.5.1.

Figure 3. Community Content, Revisions, Moderation, and Interactions. ContentRevision represents submitted content versions, while ModerationRecord records their review decisions. When an ordinary post or comment is edited, the approved public version remains visible while the revision is under review. Submitting a recruitment revision delists the recruitment until the new version is approved. Detailed rules are defined in Section 2.5.3.

Figure 4. Personal Planner and In-App Notification Domain Classes. CourseItem, TimedPlan, and TodoItem specialize ScheduleItem. Bounded weekly recurrence generates occurrences with distinct actual dates. Editing or deleting one occurrence does not affect others, and completion is independent for each to-do occurrence. Planner records are private to their owner, and notifications belong to their recipients.

2.4 Interface Prototypes

Figure 5. Competition Discovery and Dedicated Community (P01, P02). Visitors may browse published content, while personal actions require sign-in. The registration deadline does not close community discussions. Category filters and keyword prompts in the diagram are interface illustrations; search acceptance for the current scope follows the SRS requirement to search by competition name.

Figure 6. Recruitment Details and My Team (P03, P04). Public recruitment does not expose private contact information, and team management is authorized according to the current role. Once a recruitment revision is submitted, the recruitment is removed from public listings while awaiting review of the new revision.

Figure 7. Captain Review and Personal Daily View (P05, P06). Before admission, the captain can view only the applicant's name, college, sex, skill tags, and brief written CV. After approval and while membership remains active, the current captain may additionally view that member's contact information. Overlapping entries are allowed in the personal planner.

Figure 8. Manual Course Entry and Single-Occurrence Actions (P07, P08). Weekly recurrence has a finite occurrence count, and each occurrence is stored by its actual date. Editing or completing one occurrence does not affect other dates.

Figure 9. In-App Notifications and Personal Center (P09, P10). Public content identifies authors by username, and users maintain their own complete profiles. Historical notifications cannot bypass current profile access permissions.

Figure 10. Independent Web Administration Portal (P11). Administrators manage competitions, skills, and pending content. Administrator status alone does not grant access to private schedules or arbitrary complete student profiles.

Figure 11. Wide-Screen H5 (P12). The layout may adapt to screen size, while accounts, applications, membership, and planner results remain consistent. Maintenance and moderation operations are available only to administrators under FR-15.

Figure 12. Personal Profile and Team Creation. The profile form collects the mandatory information defined in Section 2.5.1 and uses the administrator-maintained skill catalog. Team creation specifies the team name, summary, capacity including the captain, and required skills. The creator becomes the team’s captain and first member. Recruitment requires administrator approval before public display and external applications.

Figure 13. Team Application and Captain Review. Students may apply without a skill match. For a valid Pending application, only the current captain of the target team may view the applicant’s name, college, sex, skill tags, and brief CV. Approval rechecks the application and membership states, capacity, deadline, and team status. The current captain may additionally view contact information while the applicant is an active member of the team.

Figure 14. Application Results and Full-Team Feedback. Joining or creating a team invalidates the student’s other Pending applications in the same competition. When a team reaches capacity, its remaining Pending applications are invalidated. Affected applicants receive notifications explaining the invalidation reason. A full team displays “This team is full.” and accepts no further applications or admissions.

2.5 Core Functions and Business Rules

2.5.1 Accounts, Profiles, and Access Permissions

Students register and sign in with a unique username and password and bind an email address. Password recovery uses a verification code sent to the bound email address. Administrator accounts are provisioned by the team and are not open to public registration. Students are not required to submit student-status documents. Visitors may browse approved competitions, discussions, and recruitment; personal actions require sign-in.

Mandatory profile fields are name, college, major, academic year, sex, at least one predefined skill tag, a brief written CV, and at least one contact method: WeChat ID or QQ ID. MBTI personality type and hobbies are optional. Profile completeness is checked before team creation, application, and posting, with missing fields identified. The private planner is available after sign-in regardless of whether the competition profile is complete.

Skills come from the same predefined catalog maintained by administrators; students cannot create their own tags. Catalog maintenance must preserve existing skill references and readable labels in profiles and recruitment. Public posts, comments, and recruitment use usernames; ordinary students cannot browse arbitrary complete profiles belonging to others. For a valid Pending application, only the current captain of the target team may view the applicant’s name, college, sex, skill tags, and brief written CV. During active membership, the current captain may additionally view the member’s contact information. Rejection, withdrawal, or invalidation ends access granted by the application. Departure, removal, or dissolution ends access granted by membership. Captain transfer updates privileges immediately. Historical applications, former roles, and old notification links do not grant continuing access.

2.5.2 Team Applications, Capacity, and Member Management

The team formation workflow is as follows:

1. Before the registration deadline, a student with a complete profile and no current team in that competition may create a team by entering its name, summary, capacity, and required skills, and becomes its captain-member. The captain may submit recruitment for administrator review. Before initial approval, the team is visible only in "My Team" and does not accept external applications.

2. New applications require a complete profile, published recruitment, an enabled recruitment switch, an active team with available capacity, an unexpired registration deadline, and no current membership in the same competition. Students may apply to different teams in that competition simultaneously, but may have at most one Pending application to any one team.

3. Skill matching follows the rule "at least one required skill overlaps" and is advisory only. Students may apply without a match, and their names are highlighted during review. Sex and MBTI do not influence matching, and matching does not automatically approve or reject applications.

4. Only the current captain may approve or reject valid Pending applications to their team. Approval rechecks the application and membership states, capacity, deadline, and active-team conditions. Approval creates active membership and invalidates the student’s other Pending applications in the same competition. Creating a team also invalidates the creator’s other Pending applications in that competition. Other competitions are unaffected.

5. Team capacity includes the captain, cannot exceed the competition limit, and cannot fall below the current member count. When a team reaches capacity, it stops accepting new applications and further admissions. That team’s remaining Pending applications are invalidated, affected applicants are notified, and the message “This team is full.” is displayed.

Application states and their meanings are as follows:

Reapplication creates a new record while preserving historical decisions. Manually closing recruitment blocks only new applications; existing valid applications may still be reviewed when capacity, deadline, and team conditions allow. While a recruitment revision is pending review, existing applications are also reviewed against the currently effective conditions. The registration deadline blocks team creation, new applications, and approvals and invalidates Pending applications, while existing teams and community discussions remain available. Invalidated applications are not automatically restored by an extended deadline or changes in capacity conditions.

Members may leave voluntarily. The captain may remove members, transfer captaincy to a current member, or dissolve the team. Before leaving, the captain must transfer captaincy or dissolve the team. Transfer changes permissions immediately, and the former captain becomes an ordinary member. After leaving or being removed, students may reapply when eligible; historical approval does not represent current membership. Dissolution invalidates Pending applications, sends notifications, and retains only concise personal history. A vacancy or an increased capacity requires the captain to reopen recruitment manually when legally allowed. Concurrent review or team creation must not exceed capacity or violate the rule of one current team per competition.

Figure 15. Team Application and Captain Review Workflow. New applications require published and open recruitment and must satisfy the eligibility conditions in Section 2.5.2. Approving an eligible Pending application creates active membership and invalidates the applicant’s other Pending applications in the same competition. Reaching capacity also invalidates the team’s remaining Pending applications and notifies affected users. Existing valid applications may still be approved while recruitment is manually closed or a revision is under review, provided the application, membership, capacity, deadline, and team-state checks pass. Applicant-profile visibility follows Section 2.5.1.

2.5.3 Competition Maintenance, Community Moderation, and In-App Notifications

Each competition must include a name, introduction, category, registration deadline, eligibility requirements, team size limit, and official source link; the cover image is optional. Administrators create and maintain competitions, and students may also submit competitions for publication after approval. Reducing a competition's team size limit must not make any existing active team's configured capacity or actual membership invalid. Deadline changes apply to subsequent operations. Extending a deadline does not automatically restore Invalidated applications or reopen recruitment.

Each competition has one dedicated community. Signed-in students may create posts and comments, like or favorite posts, and undo likes and favorites. Posts support text, images, and external links, with up to nine JPG/PNG images, each no larger than 5 MB. Authors may edit and delete their own posts and comments.

Student-submitted competitions, posts, comments, and recruitment require approval before their first publication. When ordinary posts or comments are edited, the old approved version remains public while the revision is pending. Approval replaces it with the new version, while rejection retains the old version. Submitting a recruitment revision immediately delists the recruitment; the new conditions become effective after approval, while rejection keeps it delisted and permits resubmission. Moderation applies to specific revisions. Before recruitment approval, current membership and competition capacity constraints must also be checked. Deleted content or content removed for violations cannot be republished through an outdated moderation decision.

In-app notifications cover new applications, approvals, rejections, invalidations, membership changes, captain transfers, dissolution, and moderation results. They provide a list and read status and refresh on page entry or when the application returns to the foreground. Notifications and their historical links remain subject to current permissions. WeChat push notifications, instant messaging, and personal planner reminders are not provided in the current scope.

2.5.4 Private Courses, Plans, and To-Dos

The personal planner is independent of competition team formation. Students manually enter courses, timed plans, and to-dos, and also add competition tasks themselves. Courses are entered using the actual starting week, weekday, and start/end periods, with an optional classroom, and are converted to actual times using the school's period configuration. Duplicate course records with the same name, actual date, and start/end time are skipped with feedback, without affecting other records.

Timed plans require start and end times. To-dos require a title, while the description and deadline are optional; a to-do without a deadline still appears on its assigned date. Courses, plans, and to-dos are displayed together in day/week views. Time overlaps are allowed, and overlapping records remain individually accessible.

All three record types may repeat weekly for a specified finite number of occurrences. The starting week counts as the first occurrence, and each occurrence has an independent actual date. Editing or deleting one occurrence, or completing a single to-do occurrence, does not affect other dates. Planner records are visible only to their owner. Screenshot recognition, automatic whole-semester import, odd/even-week patterns, infinite recurrence, automatic scheduling, reminders, and automatic team-task generation are not provided.

2.5.5 Mapping Functions to Acceptance Cases

The SRS contains nine user scenarios, nineteen functional requirements, twelve business rules, six non-functional requirements, and sixty-seven acceptance cases. Subsequent verification will follow the mapping below, with applicable workflows verified separately on the H5 client, Mini Program, and administration portal.

Non-functional requirements include data consistency across clients, permission checks for both interfaces and direct data requests, concurrent business constraints, and clear feedback. The performance objective is a response time of no more than three seconds per operation in a recorded acceptance environment, with twenty concurrent users performing common read, save, application, and moderation operations. The exact workload composition and measurement method remain to be determined, and no measured performance results have been reported. Actual verification records the version, environment, prepared data, steps, expected and actual results, and evidence. Cases that have not been executed are not marked as passed.

2.6 Requirements Revision and Confirmation Records for This Assignment

Building on the competition discovery, skill matching, and captain review requirements from Assignment 2, this assignment refines the delivery scope, business rules, prototypes, and acceptance descriptions according to the current SRS. "Current Confirmation" in the following table means that the relevant rules have been defined in the requirements document; actual functionality still requires subsequent development and verification.

3. Team Organization and Schedule

3.1 Team Organization

The following table carries over the organizational structure from Assignment 2: 13 members, 5 working groups, and 17 group positions. Members serving in more than one group are counted only once in the headcount. Project coordinator Zhaoyan Wang (王昭衍) separately undertakes overall coordination. The leaders of the five working groups synchronize progress and review results.

3.2 Overall Project Stages

The project milestones from Assignment 2 are retained: M0 Team Formation and Topic Selection → M1 Requirements Confirmation → M2 Design and Task Breakdown → M3 P0 Core Version → M4 P1 Refinement and Verification → M5 Final Delivery.

Each stage begins after the preceding milestone is completed, with specific dates determined by the course schedule and team progress. The requirements analysis materials for this assignment are prepared in the sequence "requirements review → class diagrams and interface prototypes → SRS integration and review → presentation and submission material preparation," providing a basis for subsequent design and development.

These milestones organize the development sequence, while the team will further specify the functional allocation for each stage. Final delivery will be assessed against the complete mandatory scope of the current SRS, including the H5 client, WeChat Mini Program, independent administration portal, community interactions, moderation, in-app notifications, team formation, and personal planning.

3.3 Work Plan Between Assignments 3 and 4

This stage runs from the end of the Assignment 3 requirements analysis presentation until the next assignment begins. Based on presentation feedback, the team plans to refine the requirements materials, specify the implementation parameters listed in the SRS, and prepare for design and development.

These are proposed arrangements for the next stage. Working-group leaders will synchronize progress and review stage deliverables, and the Documentation and Presentation Group will consolidate and archive the materials.

4. Team Collaboration

The team uses a Feishu group for daily communication. Group leaders allocate tasks, and members co-edit documents through WPS collaboration. The leaders of the five working groups synchronize progress and review results. The final documents are planned to be consolidated and uploaded to GitHub.

Figure 16. Team Collaboration and Archiving Plan. This illustration shows group leaders allocating tasks, members completing materials, WPS document collaboration, the leaders of the five working groups synchronizing progress and reviewing results, and subsequent consolidation and archiving.

5. Key Issues and Challenges in This Assignment

No actual difficulties encountered during this assignment have been recorded so far. The following analysis examines key issues in the current requirements and the handling principles specified in the SRS, providing a basis for subsequent design and verification.