CodeStrike - Group 5 - Assignment 3: Requirements Analysis

Item	Content
Course	EE308FZ Software Engineering Class Community
Assignment Requirements	Third assignment -- Requirement Analysis
Team Name	CodeStrike (Group 5)
Project Name	Campus Competition & Activity Community
Assignment Goal	Refine the requirements analysis based on the initial requirements from Assignment 2; specify user scenarios, class diagrams, interface prototypes, functional requirements, and acceptance criteria; and organize the team's division of labor, collaboration methods, and requirements analysis presentation materials.
Project Coordinator	Zhaoyan Wang (王昭衍, 832402220)
GitHub Organization	26-SoftwareEngineering-CodeStrike
Other References	Assignment 2 Blog, Chapter 8 of 构建之法: 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.

Student ID	Task Description	Contribution
832402220	Zhaoyan Wang (王昭衍): Project coordinator; Backend Development Group member; Documentation and Presentation Group leader. Coordinates the overall project, documentation, and presentation materials, and participates in backend development and integration.	10%
832402221	Maoping Wu (吴茂平): Frontend Development Group member; Product Design and Testing Group leader. Responsible for requirements analysis, product prototypes, and functional acceptance, and participates in personal profile page development.	10%
832402223	Zhengyang Wu (吴正杨): Product Design and Testing Group member. Responsible for requirements, test cases, and acceptance records related to the Competition Hub and competition-specific communities.	6%
832402218	Quanyan Tan (谈权焰): Frontend Development Group leader; Documentation and Presentation Group member. Coordinates frontend pages and components, develops competition pages, and assists with PPT visuals and presentation materials.	10%
832402215	Zihan Lin (林子涵): Documentation and Presentation Group member. Organizes the requirements specification, blog, and project documentation, and assists with the README, PPT, and version maintenance.	6%
832402216	Jianhao Liu (刘鉴浩): Frontend Development Group member. Responsible for team creation, recruitment details, and team application pages, and participates in API integration and frontend self-testing.	8%
832402211	Guanxin Lai (赖观新): Backend Development Group leader; Engineering Operations and Testing Group member. Responsible for API and data design, team creation and application review logic, and assists with backend deployment and integration.	10%
832402212	Yu Lei (雷彧): Backend Development Group member. Responsible for user, permission, and skill profile APIs, as well as related API documentation, self-testing, and integration.	8%
832402209	Haogang Huang (黄浩罡): Engineering Operations and Testing Group leader. Responsible for Git collaboration, environment and deployment workflows, and system and API integration testing.	8%
832402208	Haochen Huang (黄浩宸): Engineering Operations and Testing Group member. Responsible for test environments, API and workflow testing, and defect, log, and deployment verification records.	6%
832402224	Zhiqiang Wu (吴誌强): Frontend Development Group member. Responsible for competition-specific community and experience-sharing pages, interaction issue resolution, and scenario test records.	6%
832402227	Zhaoyuan Zhang (张钊源): Product Design and Testing Group member. Responsible for team formation and skill matching rules, application review and capacity limit test cases, and regression and acceptance records.	6%
832401308	He Huang (黄和): Backend Development Group member. Responsible for data APIs, data models, and business validation related to competitions, competition-specific communities, and experience resources.	6%
Total	13 members; responsibilities across groups are included in each person's percentage and are not counted twice.	100%

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.

Student ID	Specific Tasks for This Assignment	Workload Percentage for This Assignment
832402220	Zhaoyan Wang (王昭衍): Responsible for drafting the blog and SRS.	25%
832402218	Quanyan Tan (谈权焰): Responsible for reviewing the SRS and blog.	25%
832402211	Guanxin Lai (赖观新): Responsible for preparing the PPT and giving the presentation.	25%
832402221	Maoping Wu (吴茂平): Responsible for creating the class diagrams.	25%

2. Software Requirements Specification

2.1 Documents and Attachments

Material	Access Link
SRS Word document for this assignment: CodeStrike_Group5_SRS.docx	CodeStrike_Group5_SRS

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.

Mandatory Module in the Current Scope	Defined Scope	Corresponding SRS Requirements
Accounts and Personal Profiles	Username/password sign-in, password recovery through a bound email address, profile completeness checks, and predefined skill tags maintained by administrators.	FR-01–FR-03
Competitions and Dedicated Communities	Competition maintenance and student submissions, search by name, and access to official sources; each competition has one dedicated community supporting posts, comments, likes, favorites, and publication review.	FR-04–FR-06, FR-14
Team Formation and "My Team"	Advisory skill matching, team creation and recruitment, applications and captain review, capacity and deadline limits, member departure and removal, captain transfer, dissolution, and limited personal history.	FR-07–FR-12
In-App Notifications	Notifications for applications, decisions, invalidations, membership changes, captain transfers, dissolution, and content moderation results, with read/unread status.	FR-13
Web Administration Portal	Competition and skill tag maintenance, pending-content previews, approval and rejection, and removal of violating content.	FR-14–FR-15
Personal Planner	Manual course entry, timed plans, to-dos, day/week views, finite weekly recurrence, and single-occurrence operations; records are visible only to their owner.	FR-16–FR-19

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

Page ID	Page	Corresponding Figure	Main Interactions
P01	Competition Hub	Left side of Figure 5	Search published competitions by name and open their details.
P02	Competition Details and Dedicated Community	Right side of Figure 5	View the introduction, eligibility, deadline, team size limit, and official source; browse discussions, recruitment, and experience resources.
P03	Recruitment Details	Left side of Figure 6	View team size and skill indicators; apply when recruitment conditions are met, even without a skill match.
P04	My Team	Right side of Figure 6	View current members and perform management actions according to the member or captain role; recruitment awaiting revision review remains visible within the team.
P05	Captain Review	Left side of Figure 7	The current captain views the five allowed categories of information for valid Pending applicants to their team and approves or rejects applications.
P06	Personal Daily View	Right side of Figure 7	View courses, timed plans, and to-dos together; overlapping entries can still be opened separately.
P07	Manual Course Entry	Left side of Figure 8	Select the actual starting week, weekday, and start/end periods, with times converted using the school's period configuration.
P08	Single-Occurrence Actions for Repeating Items	Right side of Figure 8	Edit or delete only the record on the selected date, or complete a single to-do occurrence independently.
P09	In-App Notification Center	Left side of Figure 9	View business messages and read status; historical links recheck current permissions when opened.
P10	Personal Center	Right side of Figure 9	Manage one's own profile and access personal applications, teams, posts, and favorites.
P11	Independent Web Administration Portal	Figure 10	Maintain competitions and skills; preview specific content revisions and approve, reject, or remove violating content.
P12	Wide-Screen H5 Competition Hub	Figure 11	Display competition search and listings in a wide-screen layout, sharing accounts, data, and business rules with the Mini Program.

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:

State	Chinese Meaning	Processing Result
Pending	待审核 (Pending Review)	May be approved or rejected by the current captain, or withdrawn by the applicant.
Approved	已批准 (Approved)	Results in admission; whether the student is still in the team is determined by the membership relationship.
Rejected	已拒绝 (Rejected)	The captain explicitly rejects the application; no member is added, and the student may reapply when eligible.
Withdrawn	已撤回 (Withdrawn)	The applicant terminates this application, and the associated applicant-profile access ends.
Invalidated	已失效 (Invalidated)	Invalidated because of full capacity, the deadline, dissolution, or the applicant joining/creating another team in the same competition; the reason is recorded and notifications are sent. This is distinct from rejection by the captain.

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.

Verification Area	SRS Requirements	Acceptance Cases
Accounts, Personal Profiles, and Skill Catalog	FR-01–FR-03	AC-01–AC-08
Competition Maintenance, Discovery, and Dedicated Communities	FR-04–FR-05	AC-09–AC-14
Posts, Interactions, and Content Moderation	FR-06, FR-14	AC-15–AC-18, AC-46–AC-49
Team Creation, Applications, Captain Review, and Member Management	FR-07–FR-12	AC-19–AC-42
In-App Notifications	FR-13	AC-43–AC-45
Independent Administration Portal	FR-15	AC-50–AC-51
Private Courses, Plans, To-Dos, and Weekly Recurrence	FR-16–FR-19	AC-52–AC-61
Cross-Client Consistency, Permissions, Concurrency, Performance, Feedback, and Verification Records	NFR-01–NFR-06	AC-62–AC-67

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.

Related Requirements or Sections	Refinements in This Assignment	Current Confirmation
Delivery Scope: SRS §2, §5.9	Specify the H5 client, WeChat Mini Program, and independent web administration portal; include community interactions, moderation, notifications, and personal planning in the current scope.	The current scope is defined, and all FR-01–FR-19 requirements are mandatory for this delivery.
Accounts and Profiles: FR-01–FR-03, FR-10	Specify username/password access, bound-email password recovery, complete profile fields, predefined skills, and the information visible to captains before and after admission.	Student-status documents are not required; visitors may browse published content; current captains access permitted information according to valid applications or memberships.
Competitions and Communities: FR-04–FR-06, FR-14	Specify administrator maintenance, student submissions, official sources, community interactions, image limits, and publication review.	Publication and moderation rules are defined; ordinary content revisions and recruitment revisions use different publication behavior.
Applications and Member Management: FR-07–FR-12, BR-01–BR-11	Specify five application states, applications to multiple teams and the one-team-per-competition rule, withdrawal and reapplication, invalidation at full capacity, deadlines, the recruitment switch, captain transfer, and dissolution.	Pending applications are invalidated with notifications when capacity is reached; closing recruitment permits continued processing of valid applications; concurrency and recruitment reopening rules are defined.
Notifications and Administration: FR-13–FR-15	Specify in-app business messages, read status, administrator permissions, and the independent administration portal.	In-app notifications are within the current scope; WeChat push notifications, banning/unbanning, and arbitrary access to private schedules are outside it.
Personal Planner: FR-16–FR-19, BR-12	Complete manual course entry, plans, to-dos, day/week views, finite weekly recurrence, and single-occurrence actions.	Planner data is private to its owner; overlaps are allowed; competition tasks are added manually; changing one occurrence does not affect other dates.
Class Diagrams, Prototypes, and Acceptance: SRS §3–§5	Update Figures 2–4 and 12–15 to reflect the SRS rules for application states, active membership, profile access, capacity handling, moderation, and personal scheduling.	The revised figures describe the defined requirements and business rules. The sixty-seven acceptance cases remain planned verification criteria; execution results will be recorded during development and testing.
Implementation Parameters: SRS §3.5	Further specify email-code validity and retry limits, semester and period-to-date mappings, content revision retention, and the workload for performance measurement.	These implementation parameters await design decisions; the defined functional scope and business rules continue to follow the current SRS.

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.

Working Group	Leader	Other Members	Existing Responsibilities
Frontend Development	Quanyan Tan (谈权焰)	Jianhao Liu (刘鉴浩), Zhiqiang Wu (吴誌强), Maoping Wu (吴茂平)	UI/UX, pages and components, interaction logic, and frontend/backend integration.
Backend Development	Guanxin Lai (赖观新)	Yu Lei (雷彧), He Huang (黄和), Zhaoyan Wang (王昭衍)	Business logic, APIs, data design, and frontend/backend integration.
Product Design and Testing	Maoping Wu (吴茂平)	Zhengyang Wu (吴正杨), Zhaoyuan Zhang (张钊源)	Requirements analysis, product prototypes, test cases, and functional acceptance.
Engineering Operations and Testing	Haogang Huang (黄浩罡)	Haochen Huang (黄浩宸), Guanxin Lai (赖观新)	Environments, deployment, system maintenance, and integration testing.
Documentation and Presentation	Zhaoyan Wang (王昭衍)	Zihan Lin (林子涵), Quanyan Tan (谈权焰)	SRS, CSDN blog, README, project documentation, and PPT.

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.

Work Item	Responsible Person or Group	Expected Deliverables
Presentation Feedback and Material Revision: Collect comments from the instructor, teaching assistants, and other groups, then review and revise the SRS, class diagrams, and interface prototypes item by item.	Led by the Documentation and Presentation Group, with support from all working groups.	Presentation feedback list and revised requirements materials.
User Research and Requirements Coverage Review: Consult junior students about their actual needs for competition information, team formation, experience sharing, and personal planning; compare these needs with the current SRS and record full, partial, and missing coverage, identifying additions or changes requiring review.	Led by the Product Design and Testing Group, with support from all working groups.	User research records, a requirements coverage comparison, and a list of requirements awaiting review.
Implementation Parameter Refinement: Following SRS §3.5, determine email-code validity and retry limits, semester and period-to-date mappings, content revision retention, and the workload composition and measurement method for twenty-user concurrent performance verification.	Led by the Product Design and Testing Group, with support from the Frontend Development, Backend Development, and Engineering Operations and Testing Groups.	Defined implementation parameters and a performance measurement plan.
Design Preparation: Review H5, Mini Program, and administration pages and data against the defined rules for application invalidation, contact information access, recruitment revision review, and planner single-occurrence actions; draft database tables and an API list.	Frontend and Backend Development Groups, with support from the Product Design and Testing Group.	Initial page workflows, data tables, and API list.
Development Preparation and Task Breakdown: Confirm the technical approach, organize development environments and repository structure for the three clients, verify that the base project runs locally, and specify module owners, estimated time, and acceptance cases.	The Engineering Operations and Testing Group and Frontend and Backend Development Groups prepare the environments; the project coordinator and working-group leaders coordinate task allocation.	Technical approach, a locally runnable base project, module tasks, and a time plan.

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.

Collaboration Activity	Method or Arrangement Used for This Assignment
Task Allocation	Tasks are allocated by group leaders.
Daily Communication	Feishu group.
Progress Synchronization	The leaders of the five working groups are responsible.
Collaborative Document Maintenance	WPS collaboration.
Result Review	The leaders of the five working groups are responsible.
Final Document Archiving	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.

Key Requirements Analysis Issue	Analysis and Handling Principles
Boundary Between Matching and Admission	Skill matching is advisory only; students without a match may still apply. Sex and MBTI do not influence matching, and the current captain makes the admission decision.
Application History Versus Current Membership	The five application states must be distinguished from active membership. Joining or creating a team invalidates other Pending applications in the same competition; after leaving, a student may reapply when eligible.
Capacity, Deadlines, and Concurrency	The captain counts toward capacity, and capacity and eligibility are rechecked before approval. Full capacity or the deadline invalidates Pending applications with notifications. Concurrent operations must not cause overcapacity or active membership in multiple teams within the same competition.
Profile Permissions Change with Relationships	During Pending review, only the relevant current captain may view the five allowed categories of information. After admission, current members' contact information becomes additionally available. Permissions are adjusted promptly after withdrawal, invalidation, departure, or captain transfer.
Different Handling of Ordinary Content and Recruitment Revisions	The old approved version of an ordinary post or comment remains public while a revision is pending. Recruitment is first delisted and becomes public again after approval. Deleted content or content removed for violations cannot be republished through an outdated moderation decision.
Private Planning and Weekly Recurrence	A finite number of independent records are generated by actual date. Time overlaps are permitted, and editing or completing one occurrence does not affect other dates. Planner records are visible only to their owner, and competition tasks are added manually.
Consistency Across Clients and Requirements Materials	The H5 client and Mini Program share accounts, data, and business rules. The blog, class diagrams, prototypes, functional descriptions, and acceptance criteria use the scope and terminology of the current SRS.