CodeStrike - Assignment 2 - Team Formation and Topic Selection

[CodeStrike]

Assignment 2: Team Formation and Topic Selection | CodeStrike

This post records CodeStrike's team formation, topic selection, project plan, and preliminary performance assessment scheme. Workload proportions are estimated allocations; product details and assessment implementation rules will be further refined at later milestones.

Item	Content
Course	EE308FZ Software Engineering Class Community
Assignment Requirements	Second assignment-- Team up and Topic selection
Team Name	CodeStrike
Assignment Objectives	Complete team formation and project topic selection, clarify user needs, team vision, member responsibilities, and the semester plan, develop a performance assessment scheme, and prepare the Requirements Specification Document (SRS) and topic selection presentation.
Other References	Official Companion Repository for 构建之法 (The Method of Construction), Fourth Edition, Chapter 8: Requirements Analysis
GitHub Organization	26-SoftwareEngineering-Group6
CSDN Team Account	CodeStrike Team Account
Project Name	Campus Competition & Activity Community (provisional English name)

目录

• Assignment 2: Team Formation and Topic Selection | CodeStrike
• 1. Team Introduction
• 1.1 Basic Team Information
• 1.2 Member Introductions
• 1.2.1 Zhaoyan Wang (王昭衍)
• 1.2.2 Maoping Wu (吴茂平)
• 1.2.3 Zhengyang Wu (吴正杨)
• 1.2.4 Quanyan Tan (谈权焰)
• 1.2.5 Zihan Lin (林子涵)
• 1.2.6 Jianhao Liu (刘鉴浩)
• 1.2.7 Guanxin Lai (赖观新)
• 1.2.8 Yu Lei (雷彧)
• 1.2.9 Haogang Huang (黄浩罡)
• 1.2.10 Haochen Huang (黄浩宸)
• 1.2.11 Zhiqiang Wu (吴誌强)
• 1.2.12 Zhaoyuan Zhang (张钊源)
• 1.2.13 He Huang (黄和)
• 1.3 Team Logo
• 2. Team Vision and First Group Photo
• 2.1 Motivation for Forming the Team and Team Vision
• 2.2 Expected Outcomes and Implementation Scope
• 2.3 Usage Scenarios
• 2.4 First Team Group Photo
• 3. Team Project Plan
• 3.1 Project Overview and Product Positioning
• 3.2 NABCD Topic Selection Analysis
• N — Need: User Needs
• A — Approach: Proposed Solution
• B — Benefit: Expected User Benefits
• C — Competitors: Existing Products and Alternative Solutions
• D — Delivery: Product Delivery and Promotion
• 3.3 Core Features and Business Rules
• 3.3.1 Student Skill Profiles
• 3.3.2 Skill Matching Rules
• 3.3.3 Team Creation and Capacity Limits
• 3.3.4 Team Applications and Review
• 3.3.5 Competition-Specific Communities
• 3.3.6 Team Workspace and Campus Activities
• 3.4 System Page Architecture
• 3.5 User Workflows
• 3.6 Feature Development Priorities [Proposed Draft]
• 3.7 Semester Project Plan and Milestones
• 3.8 Arrangements for This Topic Selection Presentation
• 4. Project Work Allocation
• 4.1 Organizational Structure and Workgroup Responsibilities
• 4.2 Member Responsibilities and Planned Workload Shares
• 4.3 Principles for Managing Work Allocation
• 4.4 Work Directions for This Project
• 4.5 Collaboration and Task Acceptance
• 5. Team Performance Assessment Scheme
• 5.1 Assessment Objectives and Basic Principles
• 5.2 Five Assessment Criteria and the Overall Formula
• 5.3 Task Points and Workload Scores
• 5.3.1 Three Task-Point Tiers
• 5.3.2 Workload Scores
• 5.4 Assessors
• 5.5 Dual-Role Performance Calculation
• 5.5.1 Use the Higher Workload Score
• 5.5.2 Apply 7:3 Weighting to the Other Four Criteria
• 5.5.3 Calculate Overall Performance
• 5.6 Handling Late Task Completion
• 5.7 Handling Additional Tasks
• 5.8 Calculate Actual Contribution Shares and Performance Separately
• 5.9 Assessment Cycles and Process
• 5.10 Assessment Evidence and Record Keeping
• 5.11 Appeals and Review
• 6. Summary of Members' Planned Workload
• 7. Requirements Specification Document and Related Materials
• 7.1 Contents of the Requirements Specification Draft
• 8. References

(Table of Contents)

1. Team Introduction

1.1 Basic Team Information

Item	Content
Official Team Name	CodeStrike (Group 6)
Team Size	13 members
Team Leader / Overall Project Lead	Zhaoyan Wang (832402220)
Topic Selection Presenter	Guanxin Lai (832402211)
Team Slogan	Build dreams with code; create value through collaboration.
Team GitHub Organization	26-SoftwareEngineering-Group6
CSDN Team Account	CodeStrike Team Account
Course Registration	Joined the class community and completed the Team Formation Table in the Tencent shared document in the QQ group (confirmed by the Team Leader).

1.2 Member Introductions

CodeStrike is Group 6, with 13 members in total. The following personal information was provided by the members. Desired roles retain each member's personal preferences; confirmed working-group appointments are listed below, and detailed responsibilities and cross-group arrangements are provided in Section 4.

No.	Student ID	Name	Confirmed Team Responsibilities
01	832402220	Zhaoyan Wang (王昭衍)	Overall Project Lead; member of the Backend Development Group; lead of the Documentation and Presentation Group
02	832402221	Maoping Wu (吴茂平)	Member of the Frontend Development Group; lead of the Product Design and Testing Group
03	832402223	Zhengyang Wu (吴正杨)	Member of the Product Design and Testing Group
04	832402218	Quanyan Tan (谈权焰)	Lead of the Frontend Development Group; member of the Documentation and Presentation Group
05	832402215	Zihan Lin (林子涵)	Member of the Documentation and Presentation Group
06	832402216	Jianhao Liu (刘鉴浩)	Member of the Frontend Development Group
07	832402211	Guanxin Lai (赖观新)	Lead of the Backend Development Group; member of the Engineering Operations and Testing Group
08	832402212	Yu Lei (雷彧)	Member of the Backend Development Group
09	832402209	Haogang Huang (黄浩罡)	Lead of the Engineering Operations and Testing Group
10	832402208	Haochen Huang (黄浩宸)	Member of the Engineering Operations and Testing Group
11	832402224	Zhiqiang Wu (吴誌强)	Member of the Frontend Development Group
12	832402227	Zhaoyuan Zhang (张钊源)	Member of the Product Design and Testing Group
13	832401308	He Huang (黄和)	Member of the Backend Development Group

1.2.1 Zhaoyan Wang (王昭衍)

Student ID: 832402220

Name / Nickname: Zhaoyan Wang (王昭衍)

CSDN Profile: Zhaoyan Wang's CSDN Profile

Personality: Careful and detail-oriented, with clear goals and an emphasis on planning and verifying results; willing to learn proactively and patient when solving problems.

Technical Strengths: Has foundational knowledge of Python and Web development, has worked with Vue 3, FastAPI, and PostgreSQL, and has practical experience in AI-assisted development and frontend-backend integration. Also capable of organizing and writing project documentation, writing technical blog posts, preparing presentation slides, and writing and maintaining project documentation such as GitHub READMEs.

Interests: Exploring AI tools, sports, and making game-assistance plugins independently.

Desired Software Engineering Role: Backend developer, also supporting frontend-backend integration and testing, and organizing project documentation and presentation materials.

Personal Motto: Seek truth through rigor; reach further through steadfast action.

1.2.2 Maoping Wu (吴茂平)

Student ID: 832402221

Name / Nickname: Maoping Wu (吴茂平)

CSDN Profile: Maoping Wu's CSDN Profile

Personality: Conscientious and responsible, with good communication skills.

Technical Strengths: Proficient in using C and Java for basic program development, with skills in reading code, implementing features, and debugging problems; continuously learning frontend and backend development.

Interests: Sports.

Desired Software Engineering Role: Backend / frontend development, participating in the design and implementation of project feature modules.

Personal Motto: Focus on coding; unite our efforts to tackle challenges.

1.2.3 Zhengyang Wu (吴正杨)

Student ID: 832402223

Name / Nickname: Zhengyang Wu (吴正杨)

CSDN Profile: Zhengyang Wu's CSDN Profile

Personality: Careful and responsible, with good communication skills.

Technical Strengths: Requirements analysis, software testing, GitHub project management, and project deployment and operations.

Interests: Programming and reading.

Desired Software Engineering Role: Product design and testing, and engineering operations.

Personal Motto: Test carefully; operate systematically.

1.2.4 Quanyan Tan (谈权焰)

Student ID: 832402218

Name / Nickname: Quanyan Tan (谈权焰)

CSDN Profile: Quanyan Tan's CSDN Profile

Personality: Rigorous and careful at work, skilled at requirements analysis, willing to communicate and coordinate, and patient in continuing to debug bugs.

Technical Strengths: Frontend development, using HTML, CSS, and JavaScript and working with the Vue framework; UI/UX design, using Figma for prototyping, page color schemes, and interaction logic design, with the ability to independently encapsulate page components and develop responsive layouts.

Interests: Travel and photography.

Desired Software Engineering Role: Frontend development and UI design, responsible for product prototyping, implementing page visuals, developing frontend components, and writing user interaction logic.

Personal Motto: Shape interfaces through design; build experiences through code.

1.2.5 Zihan Lin (林子涵)

Student ID: 832402215

Name / Nickname: Zihan Lin (林子涵)

CSDN Profile: Zihan Lin's CSDN Profile

Personality: Steady and practical, a strong learner who is good at organizing ideas, able both to support documentation and presentations and to write basic code.

Technical Strengths: Has basic Java programming skills, is familiar with simple backend syntax and basic logic, and has skills in API development, business logic implementation, and frontend-backend integration; familiar with preparing PowerPoint presentations, able to organize project materials and create presentation slides using code screenshots and running demonstrations.

Interests: Hiking, photography, and programming.

Desired Software Engineering Role: Backend development support + PowerPoint support, responsible for writing basic code and debugging simple features, while assisting with PowerPoint preparation and incorporating running code demonstrations into project presentations.

Personal Motto: Demonstrate working code; present achievements through PowerPoint.

1.2.6 Jianhao Liu (刘鉴浩)

Student ID: 832402216

Name / Nickname: Jianhao Liu (刘鉴浩)

CSDN Profile: Jianhao Liu's CSDN Profile

Personality: Steady and calm, practical and rigorous at work, with careful logical thinking; remains composed and is good at finding clarity in complex code.

Technical Strengths: Frontend development (familiar with HTML/CSS/JavaScript and frameworks such as Vue/React), and UI/UX design (with a good sense of aesthetics and interaction logic).

Interests: Gaming and sports.

Desired Software Engineering Role: Frontend developer.

Personal Motto: Make steady progress; code the future.

1.2.7 Guanxin Lai (赖观新)

Student ID: 832402211

Name / Nickname: Guanxin Lai (赖观新)

CSDN Profile: Guanxin Lai's CSDN Profile

Personality: Rigorous and grounded in facts, conscientious and responsible, careful, and easy to communicate with.

Technical Strengths: Familiar with backend development, Java, C++, and database-related knowledge.

Interests: Sports.

Desired Software Engineering Role: Backend developer, developing business modules.

Personal Motto: Seek truth from facts; work with rigor and practicality.

1.2.8 Yu Lei (雷彧)

Student ID: 832402212

Name / Nickname: Yu Lei (雷彧)

CSDN Profile: Yu Lei's CSDN Profile

Personality: Conscientious, responsible, and steady.

Technical Strengths: Backend development, proficiency in Java, skills in API development and API documentation, and the ability to integrate with the frontend to exchange data.

Interests: Sports and reading.

Desired Software Engineering Role: Backend developer, developing business modules.

Personal Motto: Overcome every difficulty; put plans into practice.

1.2.9 Haogang Huang (黄浩罡)

Student ID: 832402209

Name / Nickname: Haogang Huang (黄浩罡)

CSDN Profile: Haogang Huang's CSDN Profile

Personality: Composed and calm, conscientious and responsible, factual, and rigorous.

Technical Strengths: Capable of developing backend business functionality in Java, analyzing business requirements, coding modules, troubleshooting problems, and iterating on features.

Interests: Basketball.

Desired Software Engineering Role: Frontend / backend developer.

Personal Motto: Build on the backend, connect through APIs, collaborate efficiently, and deliver reliably.

1.2.10 Haochen Huang (黄浩宸)

Student ID: 832402208

Name / Nickname: Haochen Huang (黄浩宸)

CSDN Profile: Haochen Huang's CSDN Profile

Personality: Patient and rigorous, with an organized approach to work.

Technical Strengths: Familiar with various skills, including JS interaction logic, DOM manipulation, and Java/SpringBoot.

Interests: Mountain climbing, photography, and reading.

Desired Software Engineering Role: Frontend or backend development, responsible for product design.

Personal Motto: Keep logic in the backend; serve the user.

1.2.11 Zhiqiang Wu (吴誌强)

Student ID: 832402224

Name / Nickname: Zhiqiang Wu (吴誌强)

CSDN Profile: Zhiqiang Wu's CSDN Profile

Personality: Gentle and reserved, careful and patient, eager to learn, observant, and skilled at debugging programs.

Technical Strengths: Frontend development, familiarity with browser debugging tools, and skills in troubleshooting interaction bugs and identifying page abnormalities; UI/UX design, with the ability to experience products from a user's perspective, identify usage pain points, and continuously iterate to improve interaction experiences.

Interests: Reading, sports, and programming.

Desired Software Engineering Role: Frontend developer and UX interaction designer, responsible for identifying and fixing interaction bugs, debugging page interactions, testing user scenarios, and improving the experience to ensure stable and usable feature interactions.

Personal Motto: Focus on how users feel; build a solid foundation for interaction.

1.2.12 Zhaoyuan Zhang (张钊源)

Student ID: 832402227

Name / Nickname: Zhaoyuan Zhang (张钊源)

CSDN Profile: Zhaoyuan Zhang's CSDN Profile

Personality: Calm and patient, skilled at finding and investigating problems.

Technical Strengths: Has foundational frontend and backend knowledge, can perform requirements analysis, and is familiar with functional testing, writing test cases, and troubleshooting bugs.

Interests: Programming and drawing.

Desired Software Engineering Role: Frontend or backend developer, requirements analysis, and engineering operations.

Personal Motto: Refine with dedication; improve the product.

1.2.13 He Huang (黄和)

Student ID: 832401308

Name / Nickname: He Huang (黄和)

CSDN Profile: He Huang's CSDN Profile

Personality: Careful and conscientious, practical at work, emotionally steady, and able to identify vulnerabilities.

Technical Strengths: Backend development, proficiency in service monitoring and troubleshooting methods, and skills in handling API errors and identifying concurrency anomalies; data model design, creating storage solutions based on business requirements, identifying system weaknesses, and continuously improving throughput and data consistency.

Interests: Sports, reading, and gaming.

Desired Software Engineering Role: Backend developer.

Personal Motto: Attend to detail; pursue stability and practicality.

1.3 Team Logo

2. Team Vision and First Group Photo

2.1 Motivation for Forming the Team and Team Vision

CodeStrike aims to complete a campus WeChat Mini Program that can actually run, addressing university students' needs for competition information, teammate recruitment, and experience sharing. With the team slogan "Build dreams with code; create value through collaboration.", we connect requirements analysis, product design, development, testing, deployment, and documentation delivery through division of responsibilities and cross-group collaboration.

Our product vision is to help students discover competition opportunities more easily, find teammates with complementary skills, and accumulate preparation experience and materials in a discussion space dedicated to the same competition. This vision describes the project's intended goals; the requirements hypotheses still need to be validated through research with real users.

2.2 Expected Outcomes and Implementation Scope

This semester, we plan to complete Campus Competition & Activity Community as a runnable WeChat Mini Program, positioned with academic competitions at its core and campus activities as a supplement.

The system uses a two-level structure of "Competition Hub + competition-specific communities," supported by student skill profiles, rule-based matching, team recruitment, and team application review, to gradually establish the following core workflow:

Discover a competition → View its competition-specific community → Find or create a team → Match skills → Apply to join → Team Captain review → Complete team formation.

Competition discussions, the team workspace, and campus activities will be developed incrementally according to priorities. Team tasks, milestones, competition progress, and organizing deliverable files are part of the overall plan; they are not all required to enter the first minimum viable product. The first version uses fixed skill tags and rule-based matching and does not introduce complex AI models, machine learning, complex matching percentages, custom skill tags, or an instant messaging system.

The specific feature scope of the first version and the deliverable targets for each stage are provided in Section 3; the technology stack, specific dates, and some product rules still need refinement.

2.3 Usage Scenarios

Students looking for a team: Want to enter a competition but lack teammates, learn about their target competition through the Competition Hub, enter its competition-specific community to view recruitment information, select a team based on their skills, and apply to join.

Team Captains recruiting members: Already have a competition direction and some teammates, create a team under a specified competition, enter the required skills and team capacity, view applicant information, and approve or reject applications.

Students preparing for competitions and sharing experience: Discuss problems, share experience, and find learning resources in a community dedicated to the same competition, reducing the scattering of information across different group chats.

Students participating in campus activities: Browse activities, view details, register or bookmark them, and view personal activity records in a later campus activity module.

These are the usage scenarios we plan to support; they do not mean that the features have already been developed or their effects on users have been validated.

2.4 First Team Group Photo

Photo Note: CodeStrike has 13 members in total. Two students were on leave and had not yet returned to campus, so 11 members appear in this first team group photo.

3. Team Project Plan

3.1 Project Overview and Product Positioning

Item	Content
Project Name	Campus Competition & Activity Community
Provisional English Name	Campus Competition & Activity Community
Product Form	WeChat Mini Program
Product Positioning	A student discussion and collaboration platform with academic competitions at its core and campus activities as a supplement
Overall Structure	Competition Hub + competition-specific communities, supported by skill profiles, rule-based matching, team applications, and Team Captain review
Semester Goal	Complete a runnable core business workflow and gradually improve competition discussions, team collaboration, and campus activities
Technical Approach	To be determined by the team; the technologies members know do not directly constitute the project's technology selection
Current Status	Project planning and requirements organization stage; this does not mean that system development or acceptance has been completed

This section is based on the Summary of Team Project and Performance Assessment Discussions V1.0. "Confirmed" means that a direction or rule has been agreed upon in discussions. Feature development priorities, implementation rules that have not yet been refined, and actual research results retain their respective statuses and are not treated as completed outcomes.

3.2 NABCD Topic Selection Analysis

The NABCD model is used to analyze the project's user needs, proposed approach, expected benefits, existing alternatives, and delivery plan. The analysis is based on preliminary team discussions and will be refined through subsequent requirements research and project reviews.

N — Need: User Needs

Illustrative User Scenario

Consider a student at Fuzhou University who wants to participate in a mathematical modeling competition but has not yet found suitable teammates. The student may need partners with programming, mathematical modeling, or academic writing skills. However, recruitment information may be distributed across different QQ groups, WeChat groups, and university announcements, making it difficult to compare team requirements or determine whether a team is still recruiting.

Meanwhile, a Team Captain may struggle to describe recruitment requirements consistently and identify applicants with suitable skills.

This hypothetical scenario illustrates the problems the project intends to address. It is not presented as a finding from completed user research.

Preliminary Requirements Analysis

Current discussions have identified five categories of requirements hypotheses:

Requirements Hypothesis	Possible Scenario	Priority	Questions to Validate
Scattered competition information	Information is distributed across university notices, QQ groups, WeChat groups, and competition websites	P0: Core	Which information sources students use, what information they need most, and whether finding it is difficult
Inefficient team formation	Students want to compete but struggle to find teammates with complementary skills	P0: Core	How students currently find teammates and which skill requirements matter most
Inconsistent recruitment information	Recruitment messages lack standardized descriptions, making teams difficult to compare	P0: Core	Which recruitment fields and application statuses are most useful to applicants and Team Captains
Scattered competition experience	Preparation experience, learning materials, and discussions are difficult to retrieve over time	P0: Basic community access; later improvements	What types of experience and resources students need and how they prefer to organize them
Fragmented collaboration tools	Teams use multiple tools to organize tasks, documents, and competition progress	P1: Planned	Which collaboration functions are most valuable after team formation

Target Users

User Category	Users	Main Tasks
Primary users	University students who want to compete but have not yet found a team	Discover competitions, complete skill profiles, find suitable teams, and submit applications
Primary users	Team Captains recruiting additional members	Publish recruitment requirements, review applicants, and manage team membership
Primary users	Students interested in competition discussions and preparation	Exchange experience, discuss problems, and find relevant learning resources
Secondary users	Previous competition participants	Share competition experience and preparation materials
Secondary users	Students interested in campus activities	Browse activities, register, and bookmark relevant information
Supporting users	Platform administrators	Maintain competition information, manage community content, and support platform operations

Requirements Validation Plan

During the M1 requirements review stage, the team plans to collect feedback from students interested in competitions, students who have participated in competitions, and students with team recruitment experience.

Interviews, questionnaires, or task-based observations may be used to investigate existing information channels, team formation difficulties, recruitment expectations, and the usefulness of proposed features.

Actual research methods, participant information, findings, and resulting requirement changes will be documented after the research takes place.

Current Status: These needs are preliminary hypotheses. No completed user interview, questionnaire, or observation results are claimed at this stage.

A — Approach: Proposed Solution

The project proposes a student communication and collaboration platform built as a WeChat Mini Program, with academic competitions as its core focus and campus activities as a supplementary service.

The overall product adopts a two-level structure:

Competition Hub + Competition-Specific Communities

The Competition Hub provides centralized competition discovery, keyword search, filtering, and access to competition details. Each competition has a dedicated community that organizes competition information, team recruitment, discussions, experience, and related resources.

The proposed solution focuses on three directions:

1. Rule-Based Team Formation Using Skill Profiles [P0 Core]

Students maintain personal skill profiles using predefined skill tags, while Team Captains create teams and specify recruitment requirements.

The system uses rule-based skill matching: a student is considered a match when at least one of their skill tags overlaps with the team's required skills. Students without matching skills may still apply, and the Team Captain makes the final admission decision.

A complete team-formation workflow includes:

Competition Discovery → Team Recruitment → Skill Matching → Application Submission → Team Captain Review → Team Formation

The first version also considers duplicate applications, recruitment capacity, and applicant privacy. These business rules are described in detail in Section 3.3 and the Requirements Specification Document.

2. Competition-Specific Knowledge Exchange [Core Direction Confirmed]

Each competition is associated with a dedicated communication space, allowing competition information, discussions, recruitment, experience, and learning resources to be organized around the same topic.

This structure is intended to make competition-related information easier to find and retrieve. Specific posting permissions, content categories, and management rules will be refined during requirements review.

3. Collaboration Throughout the Competition Lifecycle [Planned Improvement]

After team formation, the platform may gradually support member management, task allocation, project milestones, competition progress, and deliverable organization.

These collaboration capabilities belong mainly to later development stages. Their final scope will depend on project progress, user feedback, and the priority of completing the core team-formation workflow.

Implementation Boundary

The first version focuses on predefined skill tags and rule-based matching. It does not require complex AI recommendation models, machine learning, custom skill tags, or a built-in instant messaging system.

The team will prioritize a complete and testable P0 workflow before introducing additional collaboration and campus activity features.

B — Benefit: Expected User Benefits

The proposed platform aims to improve how students discover competitions, understand recruitment requirements, find teammates, and exchange competition-related knowledge.

Expected Benefit	Corresponding Product Design	Proposed Validation Method
Easier discovery of competition information	Competition Hub, keyword search, filtering, and access to official information sources	Ask participants to locate a specified competition and record task completion, steps, time, and feedback
Clearer team recruitment information	Standardized recruitment fields, skill requirements, and team capacity	Check whether participants can correctly identify required skills, available places, and application procedures
More targeted team formation	Student skill profiles, rule-based matching, and Team Captain review	Test matching and non-matching application scenarios and collect feedback from applicants and Team Captains
Easier retrieval and accumulation of competition experience	Competition-specific discussions and organized resources	Evaluate whether participants can locate relevant experience or materials within the supported version
Better support for collaboration after team formation	Planned team workspace, task management, milestones, and deliverable organization	Evaluate task and progress management workflows when the corresponding features are implemented

Benefit Validation Boundary

These benefits represent expected outcomes rather than verified improvements.

During later milestones, the team will use functional testing, user task observations, and feedback to evaluate whether the product helps address the identified problems.

No specific efficiency improvement, time-saving percentage, or user satisfaction result is claimed before supporting evidence is available.

C — Competitors: Existing Products and Alternative Solutions

Students already use different channels to discover competitions, recruit teammates, and coordinate project work.

Rather than assuming that existing products lack particular features, the team will investigate representative alternatives and compare them against the project's core user needs.

Existing Alternative	Current or Potential Usage	Aspects to Investigate	Proposed Difference in CodeStrike
University announcements and competition information websites	Finding competition notices, schedules, rules, and official information	Ease of information discovery, search functions, and connections to team recruitment	Connect competition discovery with dedicated communities and structured team recruitment
QQ groups, WeChat groups, and campus competition discussion groups	Sharing competition information, recruiting teammates, and communicating	Consistency of recruitment descriptions, visibility of available positions, and organization of historical messages	Provide standardized recruitment fields, predefined skill tags, and explicit application statuses
General project collaboration tools, such as Feishu or Trello	Organizing tasks, documents, and team progress	Relevant collaboration features and their relationship to competition discovery and recruitment	Prioritize competition discovery and team formation, with selected collaboration features planned for later stages

Preliminary Competitive Positioning

CodeStrike does not aim to replace all existing communication or project management tools.

Its proposed value lies in connecting several competition-related activities within one workflow: discovering a competition, understanding recruitment requirements, matching skills, applying to a team, and completing Team Captain review.

Competition-specific discussions and later collaboration functions may further support the preparation process.

Competitive Research Status

The table identifies categories and candidate products for investigation. It does not establish that any specific product lacks a feature or that students prefer CodeStrike over existing alternatives.

During M1, the team plans to examine representative platforms or recruitment channels, record verified features and information sources, and update the comparison based on actual findings.

D — Delivery: Product Delivery and Promotion

1. Initial Target Users

The initial trial will focus on Fuzhou University students who are interested in academic competitions, including students looking for teammates and students with team recruitment experience.

The team will first validate the core competition discovery and team-formation workflow with a limited group of trial users before considering wider promotion.

2. Product Delivery

The intended product is a runnable WeChat Mini Program supported by the necessary backend services and project documentation.

During development, the team plans to provide a testable version through an appropriate development or testing environment. Public release will depend on the platform's applicable requirements and the final deployment arrangements.

The semester deliverables are expected to include the confirmed functional version, source code, requirements and design documentation, testing records, usage instructions, and presentation materials.

3. User Testing and Feedback

Once the core workflow is available, trial participants will be invited to complete representative tasks, such as:

• Finding a specified academic competition;
• Viewing a team's recruitment requirements and skill-matching result;
• Submitting an application to join a team;
• Reviewing an application using a Team Captain test account;
• Checking the application result and team membership.

The team will record task outcomes, operational difficulties, defects, and suggestions, then use the findings to guide subsequent improvements.

4. Promotion and Iteration

Potential promotion channels include campus competition discussion groups, relevant student organizations, and recommendations among students.

Specific promotional arrangements will be determined according to the availability of trial users, permission to use relevant channels, and feedback from the initial testing stage.

The project will follow the milestones in Section 3.7. Requirements, development priorities, and delivery plans will be updated based on confirmed findings and project progress.

Current Status: Product testing, public release, and promotional activities described above are planned activities. They are not presented as completed work.

3.3 Core Features and Business Rules

3.3.1 Student Skill Profiles

Profiles use a form similar to a resume or an ordinary app's personal profile.

Information Category	Specific Fields	Current Notes
Basic identity information	Name, student ID, college, major	Name and college are required and visible to the Team Captain during application review; student ID and major are not shown to the Team Captain, and whether they are required remains to be refined
Personal information	Gender, MBTI	Not used in default skill matching and not shown to the Team Captain; whether they are required remains to be refined
Interests	Personal hobbies	Not shown to the Team Captain; whether this field is required remains to be refined
Technical information	Areas of expertise, skill tags	Skill tags are predefined by the system, selected through multiple choices, and visible to the Team Captain during application review; the separate areas-of-expertise field is not shown to the Team Captain
Supplementary information	Short textual resume; self-introduction and relevant competition experience may be included in the resume	The textual resume is confirmed to be visible to the Team Captain during application review; whether it is required and its length limit remain to be refined

Users can maintain and view their own profiles. Other students cannot view them. The corresponding Team Captain may view only an applicant's name, college, skills (predefined skill tags), and short textual resume when reviewing an application to their own team; other profile fields, such as student ID, major, gender, MBTI, and hobbies, are not shown to the Team Captain. Name and college are required; required status for other fields and the textual resume, the resume length limit, and permissions after application review still need refinement.

The first version uses fixed skill Tags predefined by the system and does not support user-defined tags, to prevent different expressions of the same skill from affecting matching. Tag examples discussed are: Python, Java, C++, MATLAB, Data Analysis, Mathematical Modeling, Algorithm Design, UI/UX, Frontend Development, Backend Development, Copywriting, PPT Preparation. The final tag list may be refined during requirements confirmation.

Caption: Users maintain their own profiles; the corresponding Team Captain can view only the name, college, skill tags, and short textual resume while reviewing applications to their own team. Other students cannot view the profiles.

3.3.2 Skill Matching Rules

A student and a team are considered a match when the student's skills and the team's required skills share at least one skill, supporting further communication between the two sides. Simple skill matching is included in the first version's P0 scope. Displaying matching results must not make other students' profiles public; formally joining a team still requires Team Captain approval.

Rule Example: A Mathematical Modeling Team Requires Python	Student Skills	Matching Result in This Example
Student A	Python, MATLAB	Meets the Python requirement
Student B	Python, C++	Meets the Python requirement
Student C	Java, UI/UX	Does not meet the current Python requirement

This is a rule example, not real student data. The first version does not introduce complex matching percentages, machine learning, or AI recommendation algorithms; information such as MBTI and gender is not used in default skill matching. Multiple required skills use a "match any one skill" rule. Students who do not match can still apply; their names are highlighted in the Team Captain's application review list, and the Team Captain still approves or rejects them, without automatic rejection. Sorting of matching results, the communication entry point, and the timing of contact information exchange still need refinement.

3.3.3 Team Creation and Capacity Limits

The Team Captain creates a team under a specified competition and enters the team name, associated competition, recruitment capacity, required skill tags, team introduction, and recruitment notes. Multiple teams may exist under the same competition.

Recruitment capacity consistently means the maximum total number of team members, including the Team Captain. It is set by the Team Captain and must not exceed the limit specified by the competition. For example, with a limit of 3 members, the Team Captain takes 1 place and at most 2 additional members may join. Once the team is full, it stops accepting new applications and approving membership, and provides the fixed reply "This team is full." ("该队伍已满员。") to users attempting to apply and to existing applicants awaiting review. This reply is basic feedback in the application workflow; the final status transitions of existing pending applications, concurrent capacity protection, and rules for reopening recruitment still need refinement.

3.3.4 Team Applications and Review

1. Applicants browse competitions and teams and view the skill matching results displayed by the system.

2. Applicants read the recruitment requirements and proactively submit an application to a team that is not full; applicants whose skills do not match are also allowed to apply.

3. The Team Captain views only the applicant's name, college, skills, and short textual resume. Names of applicants who do not match are highlighted, and the Team Captain can still approve or reject applications while the team is not full.

4. After approval, the applicant officially becomes a team member.

5. Members contact each other privately through contact information voluntarily provided by both sides and collaborate in the competition.

Application Status	Meaning
Pending review	The application has been submitted and is awaiting handling by the Team Captain
Approved	The Team Captain agrees to admit the applicant
Rejected	The Team Captain does not agree to admit the applicant

The same user must not submit duplicate, unprocessed applications to the same team. The full-team reply "This team is full." does not automatically equal the application status "Rejected"; specific status transitions still need refinement. The first version will not develop an instant messaging system; rules for displaying and exchanging contact information still need refinement.

3.3.5 Competition-Specific Communities

Each competition has an independent discussion space linked to its introduction, schedule, participation requirements, and official information sources, as well as discussions, recruitment, experience sharing, and material sharing.

Proposed Post Type	Purpose
Discussion posts	Ask questions, discuss technical topics, and share experience
Recruitment posts	Publish team formation needs and link to the team application feature
Resource posts	Share learning materials, preparation experience, and results

These three post types are the current content category proposal. Detailed categories, posting permissions, moderation rules, and how recruitment posts are linked to teams have not been finalized. The data sources and maintenance method for competition information also need confirmation; they must not be described as already connected to or scraping official data.

3.3.6 Team Workspace and Campus Activities

After team formation, we plan to gradually support member management, task allocation, milestone management, competition progress records, and organizing deliverable files. The campus activity module is a supplement, with planned support for activity lists, details, registration, bookmarking, and personal activity records. Specific version scopes are given in the proposed development priorities; not all planned features are commitments for the first version.

3.4 System Page Architecture

The overall page structure has been confirmed, while specific features within the pages will be delivered in stages. The table below presents the overall plan; it does not mean that all features have been implemented or will be included in the first version.

Module	Main Pages / Features
A. Competition Hub	Competition list, keyword search, categories and filtering, competition bookmarks, and access to details
B. Competition Details and Competition-Specific Communities	Competition introduction, schedule and participation requirements, official information sources, discussions, team recruitment, and experience and material sharing
C. Intelligent Team Formation	Student skill profiles, team creation, recruitment requirements, skill matching, team applications, Team Captain approval, and recruitment capacity management
D. My Teams	Joined teams, member lists, basic task management, milestones, and team deliverables
E. Campus Activities	Activity lists, details, registration, and bookmarking
F. Personal Center	Basic personal information, skill profile, personal introduction, competition experience, My Bookmarks, My Applications and Teams
G. Notification Center	Team application notifications, review result notifications, and task reminders
H. Administration Backend	Competition information maintenance, community content moderation, user management, and data statistics

3.5 User Workflows

Scenario	Planned Workflow
Finding a competition team	Register → Complete skill profile → Enter Competition Hub → Search for competition → Enter competition-specific community → View recruitment information → Select a team based on skill matching → Submit application → Await review → Receive approval → Contact privately
Creating a team and recruiting members	Team Captain logs in → Select competition → Create team → Set capacity and skill requirements → Publish recruitment information → Receive applications → View applicant profiles → Approve or reject → Complete team formation
Participating in competition discussions	Enter Competition Hub → Select target competition → Enter competition-specific community → Browse discussions and experience → Publish posts or comments → Bookmark needed content
Participating in campus activities	Enter campus activity page → Browse activities → View introduction → Register or bookmark → View personal activity records

Caption: Students apply proactively, the platform checks for duplicate applications and capacity, and the Team Captain decides admission. Students who do not match may still apply, and full-team feedback does not automatically mean rejection.

3.6 Feature Development Priorities [Proposed Draft]

P0 prioritizes a complete, testable team-formation workflow, rather than a large collection of unfinished pages. The table below is the proposed release plan; its final boundaries will be reviewed during M1.

Stage	Proposed Feature Scope	Delivery Goal
P0: Minimum Viable Product	User accounts and student profiles; predefined skill tags; Competition Hub, competition details, and competition-specific community entry points; team creation and recruitment; rule-based skill matching; team applications; Team Captain approval/rejection; membership and capacity management	Complete an end-to-end flow from discovering a competition to joining a team, including privacy and application rules
P1: Core Improvements	Selected team-workspace functions, notifications, and administration capabilities, subject to review	Improve team collaboration and operational usability after a stable P0 is available
P2: Optional Extensions	Campus activities, improved experience/resource management, and data statistics	Extend supplementary services if time and validation justify the additional scope

Confirmed core rules: Simple matching is included in P0; one overlapping required skill is sufficient, and non-matching students may still apply. The Team Captain decides admission. The team-size limit includes the Team Captain, and full teams cannot accept new applications or admissions.

Scope control: The full P0 requirements and acceptance baseline will be confirmed at M1. If development time becomes constrained, the team will first preserve the core discovery → application → review → admission workflow. P1 and P2 functions are conditional goals, not promises that all planned features will be completed this semester.

Caption: The proposed P0 scope covers competition discovery, rule-based matching, team creation, application review, and admission; later improvements are reviewed separately.

3.7 Semester Project Plan and Milestones

The project progresses through the following milestones in sequence, using deliverables and completion criteria as the basis for stage acceptance. Except for the official deadline of this assignment, specific dates will be set according to the course schedule and team progress. A performance assessment is conducted after each milestone is completed.

Milestone	Stage Sequence / Deadline	Main Work	Stage Deliverables	Completion Criteria
M0: Team Formation and Topic Selection	2026-10-11 23:59	Confirm members, project direction, and organizational structure; complete the team formation table, blog post, and topic selection materials	Team blog post, Requirements Specification Document (SRS), NABCD PPT, and team formation table record	Complete content and attachments, submitted on time through the class assignment page
M1: Requirements Confirmation	After M0 is completed	Conduct user research and competitor analysis; confirm the P0 feature scope, competition information sources, team formation rules, and privacy boundaries	Team-reviewed Requirements Specification Document (SRS), user research and competitor analysis records, and priority and acceptance checklist	Core requirements have supporting evidence, and rules affecting P0 implementation and acceptance are resolved
M2: Design and Task Breakdown	After M1 requirements confirmation	Design core pages and business workflows; determine technology and deployment plans; break down tasks and prepare the stage schedule	Product prototype, necessary design descriptions, API and task lists, and stage schedule	Identify task owners, dependencies, points, deadlines, and acceptance criteria
M3: P0 Core Version	After M2 design and task breakdown	Implement the confirmed minimum viable scope and complete frontend-backend integration	Runnable basic version for competition discovery and team formation	Can complete simple skill matching, team creation, application, review, and joining workflows; details are accepted according to the conclusions of M1
M4: P1 Improvements and Validation	After acceptance of the M3 core version	Improve features such as the team workspace, notifications, and administration as planned; conduct testing and address defects and user feedback	Improved version, testing records, and feedback records	Complete the team-confirmed P1 scope and address major defects
M5: Final Delivery	After M4 improvements and validation, according to the course's final delivery schedule	Organize the product, source code, documentation, and demonstrations; determine the deliverable scope of P2 according to progress	Final product, source code, usage instructions, presentation, and review	Meet the course's final delivery requirements; outputs are accessible or runnable, and differences between plans and actual outcomes are documented

Caption: The project progresses through M0—M5, with an assessment after each milestone is completed. The weights of the five basic indicators total 100%; dates for M1—M5 remain to be confirmed.

3.8 Arrangements for This Topic Selection Presentation

Presenter: Guanxin Lai (832402211)

Presentation Duration: No more than 8 minutes

Content Arrangement: NABCD topic selection analysis, with the team performance assessment scheme embedded in the PPT

PPT Status: Completed for the classroom topic selection presentation

Consistency Check: Before publication, check the team name, members, product positioning, feature boundaries, milestones, and the performance assessment scheme simplified in this revision, keeping the blog post and PPT consistent.

4. Project Work Allocation

4.1 Organizational Structure and Workgroup Responsibilities

CodeStrike has 13 members, 5 workgroups, and 17 role seats (including cross-group roles). Role seats count appointments within the five workgroups; the Overall Project Lead is listed separately, and members with multiple roles are counted only once in the team headcount. This update adds 4 cross-group appointments while retaining the original five workgroups and their leads.

Overall Project Lead: Zhaoyan Wang

Responsible for overall project coordination, task allocation, progress management, and acceptance of deliverables.

Workgroup	Number of Members (Including the Lead)	Lead	Members	Responsibilities
Frontend Development Group	4 members	Quanyan Tan	Jianhao Liu, Zhiqiang Wu, Maoping Wu	UI/UX design, page development, interaction logic, and component maintenance
Backend Development Group	4 members	Guanxin Lai	Yu Lei, He Huang, Zhaoyan Wang	Business logic, API interfaces, database design, and frontend-backend integration
Product Design and Testing Group	3 members	Maoping Wu	Zhengyang Wu, Zhaoyuan Zhang	Requirements analysis, product prototypes, test cases, and functional acceptance
Engineering Operations and Testing Group	3 members	Haogang Huang	Haochen Huang, Guanxin Lai	Environment setup, project deployment, system maintenance, and integration testing
Documentation and Presentation Group	3 members	Zhaoyan Wang	Zihan Lin, Quanyan Tan	Project documentation, CSDN blogs, README, and presentation PPT

4.2 Member Responsibilities and Planned Workload Shares

The following preliminary allocation for the entire semester is based on the current division of responsibilities. Planned workload is allocated across three tiers, totaling 100%. The allocation considers overall project coordination, workgroup coordination, module delivery, and cross-group tasks; each member's share already includes the planned work of all their roles, with no double counting for additional appointments. The allocation may be updated as the requirements scope and tasks change, with the reasons for adjustments recorded.

Tier	Members	Number of Members	Planned Workload Share per Member	Tier Total
Tier 1	Zhaoyan Wang, Maoping Wu, Quanyan Tan, Guanxin Lai	4 members	10%	40%
Tier 2	Haogang Huang, Yu Lei, Jianhao Liu	3 members	8%	24%
Tier 3	Zhengyang Wu, Zihan Lin, Haochen Huang, Zhiqiang Wu, Zhaoyuan Zhang, He Huang	6 members	6%	36%
Total		13 members		100%

These percentages represent planned workload, rather than actual contribution shares for completed work or performance scores; specific tasks will be broken down further and their acceptance criteria defined before the corresponding milestone begins.

No.	Student ID	Member	Confirmed Responsibilities	Planned Tasks / Deliverables	Planned Workload Share
01	832402220	Zhaoyan Wang	Overall Project Lead; member of the Backend Development Group; lead of the Documentation and Presentation Group	Develop the schedule and coordinate the groups; coordinate the Requirements Specification Document (SRS), CSDN blog, README, and presentation PPT; participate in developing skill-matching interfaces and frontend-backend integration	10%
02	832402221	Maoping Wu	Member of the Frontend Development Group; lead of the Product Design and Testing Group	Organize user research, requirements analysis, product prototyping, and functional acceptance; deliver the requirements list, prototypes, and acceptance records; develop the student skill profile and personal center pages	10%
03	832402223	Zhengyang Wu	Member of the Product Design and Testing Group	Define requirements for the Competition Hub and competition-specific communities; write and execute test cases for the corresponding functions, and compile defect and acceptance records	6%
04	832402218	Quanyan Tan	Lead of the Frontend Development Group; member of the Documentation and Presentation Group	Coordinate frontend pages, shared components, and frontend-backend integration; develop the Competition Hub and competition detail pages; assist with PPT visual design and organizing demonstration materials	10%
05	832402215	Zihan Lin	Member of the Documentation and Presentation Group	Compile the Requirements Specification Document (SRS), project documentation, and blog materials; assist with writing the README and PPT, and maintain document versions and presentation materials	6%
06	832402216	Jianhao Liu	Member of the Frontend Development Group	Develop team creation, recruitment detail, and team application pages; complete API integration, interaction implementation, and frontend self-testing	8%
07	832402211	Guanxin Lai	Lead of the Backend Development Group; member of the Engineering Operations and Testing Group	Coordinate API and database design; develop interfaces for team creation, membership limits, and team application review; assist with backend deployment and troubleshooting integration issues	10%
08	832402212	Yu Lei	Member of the Backend Development Group	Develop interfaces for users, permissions, and student skill profiles; maintain the corresponding API documentation, and complete API self-testing and frontend-backend integration	8%
09	832402209	Haogang Huang	Lead of the Engineering Operations and Testing Group	Coordinate Git collaboration, environment setup, and deployment processes; organize system and API integration testing; deliver deployment instructions and a system test report	8%
10	832402208	Haochen Huang	Member of the Engineering Operations and Testing Group	Set up and maintain the test environment; execute API, deployment, and business workflow tests; compile defects, runtime logs, and deployment verification records	6%
11	832402224	Zhiqiang Wu	Member of the Frontend Development Group	Develop competition-specific community and experience-sharing pages; investigate and fix interaction issues, and compile interaction improvement and user-scenario test records	6%
12	832402227	Zhaoyuan Zhang	Member of the Product Design and Testing Group	Define team formation and skill-matching rules; write test cases for application, review, and membership-limit workflows; execute regression tests and compile acceptance records	6%
13	832401308	He Huang	Member of the Backend Development Group	Develop data interfaces for competitions, competition-specific communities, and experience-sharing resources; refine the corresponding data models and business validation, and complete API self-testing and exception troubleshooting	6%

Caption: 13 members belong to 5 workgroups, with 17 roles including cross-group appointments; individual planned workload shares total 100% and do not represent actual contribution shares.

4.3 Principles for Managing Work Allocation

Members with cross-group roles have formal tasks in both groups, but their performance assessment aggregates their actual deliverables to avoid double counting. Each group retains its original lead, who is responsible for assigning and accepting tasks.

4.4 Work Directions for This Project

The table below summarizes each group's project work directions and corresponds to the preliminary individual allocation in Section 4.2; detailed tasks, deadlines, and acceptance criteria will be defined when milestone tasks are broken down.

Workgroup	Project Work Directions
Frontend Development Group	Pages for the Competition Hub, competition-specific communities, student skill profiles, and team formation; interaction logic, UI/UX, visualization, and frontend-backend integration
Backend Development Group	User and permission management, competition and community data, team and application business logic, skill-matching rules, API and database design
Product Design and Testing Group	User research, requirements analysis and prioritization, product prototypes, test cases, and functional acceptance
Engineering Operations and Testing Group	Git management, environment setup, continuous integration, deployment, system maintenance, and system and API testing
Documentation and Presentation Group	CSDN blogs, Requirements Specification Document (SRS), README, project documentation, presentation PPT, and presentation of outcomes

4.5 Collaboration and Task Acceptance

• Record the person responsible, work content, deadline, deliverables, acceptance criteria, and task difficulty and points agreed in advance for each task.

• Retain corresponding records for code, design, testing, documentation, and presentation materials; use GitHub commit counts and lines of code as supporting evidence.

• Promptly communicate task dependencies, requirements changes, or blockers; after confirmation, update tasks and plans, and record the basis for deadline-extension approvals or exemptions.

• Workgroup leads confirm task completion against the deliverables and acceptance criteria; only tasks that pass acceptance earn valid points.

• Conduct performance assessments under the scheme in Section 5 at the end of each project milestone, without double counting cross-group deliverables.

A single task and assessment sheet records work allocation, task points, acceptance results, and performance scores. Matters affecting delivery are communicated promptly.

5. Team Performance Assessment Scheme

This scheme uses project milestones as assessment cycles. Before each milestone begins, the team agrees on task allocation, points, the workload scoring benchmark, and acceptance criteria. Scores are then based on actual deliverables at the end of the milestone. The five assessment criteria and their weights, three task-point tiers, assessors, dual-role calculation rules, and late-completion rules follow the team's confirmed scheme. Additional tasks earn only normal task points, while performance and contribution shares are calculated separately. The topic selection PPT must remain consistent with this scheme; actual scores and contribution data are derived from task acceptance records.

5.1 Assessment Objectives and Basic Principles

The assessment aims to clarify the responsibilities of workgroups and members, reasonably measure task scale and difficulty, encourage timely delivery of high-quality outcomes, recognize members who proactively undertake additional tasks, improve collaboration efficiency, and provide a basis for contribution statistics.

Assessment is based on actual tasks and deliverables, rather than solely on lines of code, commit counts, or subjective impressions. Members with cross-group roles undertake formal tasks in both workgroups, assigned and accepted by each group's original lead; individual performance is aggregated from actual outcomes, and the same outcome is not counted twice because of cross-group appointments. Performance scores and actual contribution shares are calculated separately.

5.2 Five Assessment Criteria and the Overall Formula

Assessment Dimension	Symbol	Weight	Assessment Content
Workload and Task Responsibility	W	25%	Task scale, complexity, and actual completed workload
Task Completion	D	25%	Proportion of committed tasks completed
Work Quality	Q	25%	Correctness, completeness, and maintainability of outcomes
Progress Management	T	15%	Timely delivery and prompt communication of risks
Team Collaboration	C	10%	Communication, cooperation, and cross-module collaboration
Total		100%

Each criterion is scored on a 0–100 scale. An individual's overall performance score is calculated using the following formula:

P = 0.25 × W + 0.25 × D + 0.25 × Q + 0.15 × T + 0.10 × C

Here, P is the individual's overall performance score, ranging from 0 to 100. For members with dual roles, first calculate the final scores for the five criteria, then substitute them into this formula.

5.3 Task Points and Workload Scores

5.3.1 Three Task-Point Tiers

Task Level	Points	Examples
Simple Task	1 point	Simple page changes, minor bug fixes, and documentation updates
Medium Task	3 points	A complete page, a standard API interface, a UI prototype, or a testing module
Complex Task	5 points	Core business development, complex architecture, or cross-module integration

Task points are awarded under the following rules:

1. Before a task begins, the lead and member confirm its difficulty and points.

2. Each task must have defined deliverables and acceptance criteria.

3. Valid task points are awarded only after completion and acceptance.

4. Incomplete tasks or tasks that fail acceptance earn no valid points.

5. For tasks completed by multiple members, points are allocated according to the work proportions agreed in advance.

6. Additional tasks also earn normal task points according to their difficulty.

5.3.2 Workload Scores

The score is calculated from the valid task points earned by a member during the assessment cycle:

W = min(100, E / E_target × 100)

E: Valid task points earned during the current assessment cycle.

E_target: A positive workload scoring benchmark agreed by the team according to the task plan before the current milestone begins.

W: The workload score, capped at 100 points.

Task points, acceptance criteria, and E_target are entered in the task and assessment sheet before the milestone begins. Members with dual roles calculate workload scores separately for their lead role and member role, then take the higher score under Section 5.5.

5.4 Assessors

Member Type	Assessor(s)	Procedure
Regular Group Member	Lead of the member's workgroup	Assess the member's task completion and performance in each criterion within that group
Workgroup Lead	The other 4 workgroup leads	Score the lead role and take the arithmetic mean; members may not participate in scoring themselves
Member Who Is Both a Lead and a Member of Another Group	The other 4 leads score the lead role; the lead of the additional group scores the member role	Obtain separate scores for the two roles, then apply the dual-role calculation rules in Section 5.5

The current five workgroup leads are Quanyan Tan, Guanxin Lai, Maoping Wu, Haogang Huang, and Zhaoyan Wang. Haogang Huang currently serves only as the lead of the Engineering Operations and Testing Group, so the other 4 leads assess him under the lead rules, without the dual-role 7:3 weighting.

5.5 Dual-Role Performance Calculation

The 4 members currently covered by this rule and their two roles are listed below:

Member	Lead Role	Member Role	Assessor for the Member Role
Zhaoyan Wang	Lead of the Documentation and Presentation Group	Member of the Backend Development Group	Guanxin Lai
Guanxin Lai	Lead of the Backend Development Group	Member of the Engineering Operations and Testing Group	Haogang Huang
Quanyan Tan	Lead of the Frontend Development Group	Member of the Documentation and Presentation Group	Zhaoyan Wang
Maoping Wu	Lead of the Product Design and Testing Group	Member of the Frontend Development Group	Quanyan Tan

Each member's lead role is scored by the other 4 workgroup leads, and the arithmetic mean is used, excluding self-assessment. The role or group responsible for project coordination and cross-group tasks, together with the task points, is also agreed before the milestone begins. Each outcome is counted only once.

5.5.1 Use the Higher Workload Score

W_final = max(W_leader, W_member)

W_leader is the workload score for the lead role, and W_member is the workload score for the member role in the additional group.

Rule example: If the lead role has a workload score of 90 and the member role has a score of 80, the final workload score is 90 points. This example only explains the formula and is not an actual score for any member.

5.5.2 Apply 7:3 Weighting to the Other Four Criteria

Task completion, work quality, progress management, and team collaboration are each calculated with a 70% weight for the lead role and a 30% weight for the member role:

S_final = 0.70 × S_leader + 0.30 × S_member

Here, S represents D, Q, T, or C; S_leader is the arithmetic mean of the other 4 leads' scores for the corresponding criterion in the lead role, and S_member is the additional group's lead's score for the corresponding criterion in the member role.

Rule example: If work quality is scored at 90 for the lead role and 80 for the member role:

Q_final = 0.70 × 90 + 0.30 × 80 = 87

The final work quality score is 87 points. This example likewise does not represent an actual assessment.

5.5.3 Calculate Overall Performance

First calculate W_final, D_final, Q_final, T_final, and C_final, then substitute them into the five-dimensional formula:

P = 0.25 × W_final + 0.25 × D_final + 0.25 × Q_final + 0.15 × T_final + 0.10 × C_final

Regular group members and members who serve only as leads do not use the above 7:3 weighting. This rule applies to members who lead one workgroup and are members of one other workgroup. If role arrangements change, the team will review the assessment rules again.

5.6 Handling Late Task Completion

If a task is not completed by the agreed deadline and no extension has been approved in advance, 50% of that task's points are deducted. This penalty applies to the task points; it does not directly halve the individual's overall performance score.

Task Level	Original Points	Points after Late Completion
Simple Task	1	0.5
Medium Task	3	1.5
Complex Task	5	2.5

The rules are as follows:

1. A task is considered late if it exceeds the agreed deadline without an approved extension.

2. A late task earns the halved valid points only after it eventually passes acceptance.

3. Tasks that are not delivered or fail acceptance earn no points.

4. Delays caused by factors beyond the member's control, such as blockers from another workgroup or requirements changes, may be exempted after confirmation by the lead.

5. Retain records of late completion, extension approvals, and exemptions for later review.

5.7 Handling Additional Tasks

When members proactively undertake additional work, they first agree with the lead on the task content, points, and acceptance criteria. Once completed and accepted, the task earns valid points under the 1 / 3 / 5 task-point tiers and is included in workload and contribution statistics, without separate performance reward points. The same task or outcome must not be counted twice.

5.8 Calculate Actual Contribution Shares and Performance Separately

Performance reflects how well a member completes their assigned work and how they perform; the contribution share reflects the member's actual proportion of contributions to the team's outcomes. Neither individual performance scores nor the planned workload shares in Section 4 may be used directly as actual contribution shares.

Contribution shares are calculated from valid task points at each milestone. Total contribution shares for the semester use the cumulative valid task points earned throughout the semester:

Contribution_i = E_i / ΣE × 100%

E_i: The cumulative valid task points earned by member i across all workgroups during the period being measured.

ΣE: The sum of valid task points for all members within the same calculation scope.

• When ΣE is greater than 0, all members' contribution shares total 100%.

For members with dual roles, the workload score used in performance calculation is the higher of the two role scores; actual contribution shares instead accumulate points for distinct tasks completed and accepted in each group. Cross-group appointments cannot result in double counting the same task or outcome, and points for collaborative tasks are still divided according to the proportions agreed in advance. Points for accepted additional tasks are also included in E_i.

When the team's total valid task points ΣE equals 0, record "No data available for calculation" and do not calculate contribution shares yet. Section 6 presents planned workload allocation; actual contribution shares are calculated separately from real points after tasks pass acceptance.

5.9 Assessment Cycles and Process

Assessment follows project milestones, with one performance assessment conducted upon completion of each project milestone; specific dates will remain consistent with the project plan in Section 3.

1. Each workgroup lead confirms task completion.

2. Calculate valid task points from acceptance results.

3. Workgroup leads score their group members.

4. The other 4 workgroup leads score the lead role, and the arithmetic mean is used; self-assessment is excluded.

5. Calculate the overall performance scores for regular members, members who serve only as leads, and members with dual roles, and calculate contribution shares for the current stage.

6. Publish the assessment results and provide an opportunity for review.

7. Confirm and save the task and assessment sheet for the current stage.

5.10 Assessment Evidence and Record Keeping

A single task and assessment sheet records members, workgroup membership, task content, points, deadlines, acceptance results, and scores for the five criteria. Links or records of code, designs, tests, documentation, and other deliverables serve as acceptance evidence. Late completion and deadline-extension approvals are recorded as well.

GitHub commit counts and lines of code are only supporting evidence and do not directly represent the size of a contribution. The same outcome is not counted twice because of cross-group appointments.

5.11 Appeals and Review

1. Members have the right to view the scores and task records related to their own performance.

2. Members who disagree with a score may submit corresponding work evidence.

3. Other workgroup leads who are not directly involved in the dispute jointly conduct the review.

4. If a score needs correction, record the reason for the change.

5. Archive the final assessment results after confirmation for the current stage.

6. Summary of Members' Planned Workload

For this assignment, the planned workload allocation in Section 4.2 is initially used and summarized by “Student ID, Work Content, Share.” The work content below consists of planned tasks for the semester project, and the shares represent planned workload; actual contributions will be calculated at later milestones from real deliveries and acceptance records.

Student ID	Work Description	Contribution
832402220	Develop the schedule and coordinate the groups; coordinate the Requirements Specification Document (SRS), CSDN blog, and README; participate in developing skill-matching interfaces and frontend-backend integration; take turns presenting the PPT	10%
832402221	Organize user research, requirements analysis, product prototyping, and functional acceptance; deliver the requirements list, prototypes, and acceptance records; develop the student skill profile and personal center pages	10%
832402223	Define requirements for the Competition Hub and competition-specific communities; write and execute test cases for the corresponding functions, and compile defect and acceptance records	6%
832402218	Coordinate frontend pages, shared components, and frontend-backend integration; develop the Competition Hub and competition detail pages; assist with PPT visual design and organizing demonstration materials; take turns presenting the PPT	10%
832402215	Compile the Requirements Specification Document (SRS), project documentation, and blog materials; assist with writing the README and PPT, and maintain document versions and presentation materials	6%
832402216	Develop team creation, recruitment detail, and team application pages; complete API integration, interaction implementation, and frontend self-testing	8%
832402211	Coordinate API and database design; serve as presenter for the first presentation; develop interfaces for team creation, membership limits, and team application review; assist with backend deployment and troubleshooting integration issues; take turns presenting the PPT	10%
832402212	Develop interfaces for users, permissions, and student skill profiles; maintain the corresponding API documentation, and complete API self-testing and frontend-backend integration	8%
832402209	Coordinate Git collaboration, environment setup, and deployment processes; organize system and API integration testing; deliver deployment instructions and a system test report	8%
832402208	Set up and maintain the test environment; execute API, deployment, and business workflow tests; compile defects, runtime logs, and deployment verification records	6%
832402224	Develop competition-specific community and experience-sharing pages; investigate and fix interaction issues, and compile interaction improvement and user-scenario test records	6%
832402227	Define team formation and skill-matching rules; write test cases for application, review, and membership-limit workflows; execute regression tests and compile acceptance records	6%
832401308	Develop data interfaces for competitions, competition-specific communities, and experience-sharing resources; refine the corresponding data models and business validation, and complete API self-testing and exception troubleshooting	6%

The 13 members' planned workload shares total 100%. Shares for members with cross-group roles already include tasks from all their roles and are not counted twice.

7. Requirements Specification Document and Related Materials

Material	Current Status	Access Point
Requirements Specification Document (SRS)	Initial requirements draft prepared and exported to PDF; requirements will be reviewed and refined during M1	PDF attachment provided below
NABCD Project Topic PPT	Prepared for the October 12, 2026 topic-selection presentation; presenter: Guanxin Lai	Classroom presentation

7.1 Contents of the Requirements Specification Draft

The standalone document has been prepared as a requirements draft for this project, including function IDs, business rules, suggested non-functional requirements, and acceptance criteria. Its specific contents include:

• Project background, competition-focused product positioning, objectives, and version scope;

• Target users, stakeholders, requirements assumptions, and real requirements sources and validation records still to be added;

• Functional requirements for the Competition Hub and competition-specific communities, student skill profiles, team creation, team applications, and review;

• Business rules for fixed skill tags, application statuses, membership limits, and information visibility;

• Main usage scenarios, pages, and core business workflows;

• Necessary non-functional requirements, constraints, dependencies, and data sources;

• P0 / P1 / P2 priorities, delivery boundaries, and verifiable acceptance criteria;

• Unresolved requirements review records, confirmation results, and requirements versions.

The Requirements Specification Document has been prepared as an initial requirements draft and exported to PDF for Assignment 2. Unresolved requirements affecting functionality and acceptance are recorded in Appendix A. The team will review these items during M1 and update the specification as requirements are confirmed.

The original assignment requires an SRS attachment but does not prescribe a specific file format, page count, or dedicated template.

8. References

1. Assignment 2: Team Formation and Topic Selection

2. EE308FZ Software Engineering Class Community

3. Official Companion GitHub Repository for The Method of Construction, Fourth Edition

4. Chapter 8: Requirements Analysis in the Official Companion Materials

CodeStrike - Assignment 2 - Requirements Specification.pdf 1.80M