Tongyan: Requirement Analysis and Team Collaboration

Contents

• Project Overview and Requirements Evidence
• Team Division of Labor and Contribution
• Team Organization and Collaboration
• Schedule
• Software Requirements Specification
• Key Issues and Challenges
• SRS Checklist

Project Overview and Requirements Evidence

Tongyan serves students within our university who want to participate in competitions, undergraduate innovation projects, research projects, and course projects. It provides project recruitment, capability matching, application and confirmation, and team collaboration. We focus on students joining projects for the first time. Before applying, they should be able to understand whether beginners are accepted, what prerequisites are required, what they will do after joining, and how many hours they need to commit each week. Competition clubs and experience shared by senior students provide preparation support. Artificial Intelligence (AI) assists with recommendation explanations and answers grounded in reference materials.

Using the Survey to Set First-Release Priorities

The survey contained 15 questions and received 66 valid responses, including 64 from first-year students. All percentages in the following table use these 64 first-year responses as the denominator. Multiple-choice percentages must not be added together. The findings describe this first-year sample and do not directly represent all year groups across the university.

Only 18.8% selected “information scattered across different groups.” We therefore identify unclear recruitment conditions and insufficient preparation guidance as the primary problems. For first-release features, 59.4% selected recruitment and filtering, 51.6% selected information aggregation, and 48.4% selected matching recommendations. A standalone intelligent Q&A assistant and team collaboration each received 23.4%. Accordingly, our first priority is a complete recruitment-to-application flow, with AI embedded in recommendation explanations and preparation guidance.

One open-ended response captures the situation we want to address (translated from Chinese):

“I may have limited skills and be a beginner, but I am willing to start with small tasks and grow step by step.”

First-Release Functions and the Role of AI

AI provides advice. Publishing, applications, invitations, joining a team, and task changes require user confirmation and renewed permission and business-rule checks by the backend. When supporting materials are insufficient, the answer must state that limitation.

The first release is a Web platform supporting desktop and mobile browsers for a single-university trial. University single sign-on, cross-university identity recognition, large-file hosting, and autonomous administrative actions by the model are outside this release.

Team Division of Labor and Contribution

The team consists of one project coordinator and six working groups, with 13 members in total. Objectives and deliverables are assigned at group level. Each group leader coordinates the group, manages handovers, and checks quality, while members jointly complete the group's work.

The following percentages represent planned effort for requirement analysis and documentation: 10% for the project coordinator, 8% for each group leader, and 7% for each group member, totaling 100%. Actual contributions will be assessed against subsequent submissions, reviews, and delivery records. Personal names are retained in Chinese to match the official team roster.

Member Responsibilities

Group Objectives and Deliverables

These objectives are shared within each group. Interviews, walkthroughs, and evaluations are planned activities whose completion will be checked against actual records.

Team Organization and Collaboration

Team Organization

Feishu Organization and Communication

We have established the “同研 Tongyan” organization and department groups in Feishu, which serves as our team communication hub. The following is an original screenshot of the administration console; the Chinese interface is retained as evidence.

Responsibilities remain divided among six working groups. Feishu provides four departmental communication spaces: Product and User Research; Interaction and Frontend; Business and Modeling + Testing; and AI Recommendation + Clubs. Business and testing share a space to align state rules and acceptance issues. AI and clubs share a space to align knowledge structures, sources, and citation rules. Shared communication spaces do not change group leadership or contribution percentages. The official 13-member roster above defines the project team; the additional account visible in the screenshot is excluded from project headcounts and contributions.

Collaboration Workflow

The Feishu organization is in place. The following arrangements govern this assignment; completion is evidenced by actual task records, document revisions, and repository history.

The repository has been created. The branching, review, and archiving rules above are working arrangements and are not presented as completed commits or reviews.

Schedule

Requirement Analysis Delivery

Overall Development Plan

The project retains the eight-week development plan following topic confirmation. The Gantt chart uses Project Coordination and the six working groups as its vertical axis, showing parallel activities, planned timing, and group deliverables. It does not imply that development activities have been completed. Trial feedback and measured effects will be recorded without assuming improvements in advance.

Software Requirements Specification

Building on the earlier proposal, the SRS covers Introduction, User Scenarios, Class Diagram, Interface Prototype, Functional Description, and Acceptance and Verification Criteria. It uses five chapters, with FR identifying functional requirements, UI identifying interface prototype groups, and AC identifying functional acceptance cases.

Chinese submission version V1.1 is available in Word and PDF formats. Online attachments have not yet been uploaded.

Document Structure and Requirements Coverage

Class Diagram and Business Constraints

The model is divided into four domains: accounts, clubs, and project recruitment; application confirmation and task collaboration; knowledge contributions and material versions; and agent sessions, drafts, and auditing. The following diagram shows accounts, clubs, projects, recruitment roles, and bookmarks. The remaining diagrams are included in the full SRS.

Recruitment conditions belong to individual roles. Team membership is created only after an invitation is accepted, and confirmation of the last vacancy requires a database transaction. Bookmarks belong to the authenticated user, persist across sessions, and allow only one saved relationship per user–project pair. Knowledge articles are managed by version and publication status; withdrawn content must not remain eligible for citations in new answers.

Interface Prototype and User Scenarios

The following screenshots demonstrate the main functions of the updated interactive prototype. Projects, recommendations, Q&A, and application results use demonstration data and do not represent real AI calls or formal application records.

Homepage and Natural-Language Project Discovery

The homepage provides natural-language input and two modes: finding projects and asking about experience. Project recruitment, recommended clubs, and experience articles remain accessible below.

Project Filtering and Bookmarks

Students can filter by beginner eligibility, subject, and weekly time commitment. The screenshot retains example projects matching a maximum of four hours per week and shows the prototype's session-level bookmark state, which resets on refresh. The formal product requirement is account-based bookmark storage across sessions, with removal supported. Unavailable projects must be marked as invalid and must not accept applications through saved entries.

Recommendation Explanations and Preparation Advice

After the user enters basic Python skills and six available hours per week, the result explains how skills and time relate to the role and lists prerequisites to check and suggested preparation.

Project Details and Application Confirmation

From left to right: project details, application confirmation, and result feedback. Students inspect prerequisites, responsibilities, time, and vacancies before explicitly confirming an application. The result indicates that team review is required. AI neither submits applications automatically nor decides admission. All actions shown are simulated.

Knowledge Q&A and Source Verification

Users can submit preparation questions directly. Answers associate project facts with project sources and learning advice with experience sources, supporting individual verification.

The Q&A page also presents suggested steps and a source list with source types, titles, versions, and update times.

Opening a citation reveals its publisher, original source, version, usage notes, and cited content. Current vacancies are determined by the project details page.

Club and Partner Support

The club page distinguishes partners from demonstration clubs. It presents the Fuzhou University 206 Smart Car Team's introduction, beginner pathways, learning support, and original-source entry points.

Experience Articles and Source Information

The full article view shows the author, version, update time, original source, authorization terms, and applicability guidance. The current article is an original prototype example and does not quote an actual student submission.

Recruitment publishing, team boards, and content moderation are specified in the corresponding SRS sections.

Main Technology Stack

Language and embedding models are accessed through cloud APIs. The backend validates identity, resource permissions, and business states. Agents retrieve data through restricted query tools; formal business writes use regular application interfaces after user confirmation.

Verifiable Requirements

Acceptance criteria cover successful outcomes, failures, and unauthorized actions. For example:

• Accepting an invitation creates team membership only once. A full role cannot admit extra members, and repeated confirmation cannot consume another vacancy.
• Recommendations display relevant prerequisites, time commitments, and preparation guidance. The model must not describe a project as eligible when mandatory conditions are unmet.
• Q&A displays published sources the user is authorized to access. New answers must not cite materials that have been withdrawn or become inaccessible.
• AI-generated recruitment or task drafts must not create formal publications, invitations, or tasks before user confirmation.
• Bookmarks persist across authenticated sessions, remain isolated between users, and support removal. An unavailable bookmarked project cannot be used to bypass application restrictions.

Traceability follows “User Scenario → Functional Requirement → Interface Prototype → Acceptance Case.” SRS performance requirements and the 50 AI scenarios describe subsequent verification work, not completed test results. AI evaluation uses 30 fixed recommendation queries and 20 questions supported by reference materials. Top-three recommendation agreement and citation accuracy for key facts are comparison metrics without numerical pass thresholds. All safety and business constraints must pass, including prevention of unauthorized access, fabricated sources, and business writes without user confirmation.

Key Issues and Challenges

SRS Checklist