FocusFlow Demand Analysis Assignment

FOCUS_2025_SE 2025-11-09 12:55:37

FocusFlow Demand Analysis Assignment - Engineering Practice of Detailed Requirements under Large Team Collaboration

📖 Overview
👥 Team Division of Labor
🤝 Member Collaboration Methods
1. Communication Structure
2. Collaboration Toolchain
3. Quality Assurance Process
📄 Software Requirements Specification
Core Highlights of the Document
Special Design for Large Teams
🎥 Demand Analysis PPT
⚠️ Analysis of Key Points and Challenges
🤔Class Diagram
🤔Use Case Diagram
🔗 Reference Material Links

📖 Overview

Course	2501_MU_SE_FZU
Assignment Requirement	Third assignment - Demand Analysis
Team Name	Focus_2025
Goal of this assignment	1. Write a "Software Requirements Specification" that complies with national standards. 2. Plan the detailed division of labor and collaboration process for a large 13-person team. 3. Complete the requirements analysis PPT in preparation for the classroom presentation. 4. Practice requirements engineering and team management methods in large projects.
Other references	IEEE Std 830-1998, GB/T 8567-2006

👥 Team Division of Labor

To clearly show the organization of the 13-person team, explanations are grouped by role.

Member	ID	Role	Task Description	Contribution
Jiayao Hu	832301310	Project Manager	Responsible for overall project planning, progress tracking, and risk management. Leads requirements gathering and analysis meetings. Coordinates work across all teams. Chairs the final review and integration of the SRS document.	8%
Hantao Wu	832302129	Backend Team	Lead the detailed requirements definition for the user account system, authentication, and authorization.	7%
Zhihao Liu	832301110	Backend Team	Lead the detailed requirements definition for the user account system, authentication, and authorization.	7%
Yitan Fang	832302110	Backend Team	Responsible for the business logic and data model design for learning task management and the tagging system.	7%
Jiazhuo He	832302130	Backend Team	Responsible for the business logic and data model design for learning task management and the tagging system.	7%
Shengpeng Yang	832301120	Backend Team	Focus on the functional and non-functional requirements (performance, security) for the Pomodoro timer, grade recording, and report generation.	7%
Chenhe Zhu	832301108	Backend Team	Focus on the functional and non-functional requirements (performance, security) for the Pomodoro timer, grade recording, and report generation.	7%
Yuxiang Xie	832301327	Frontend Team	Lead the interface prototype design and define user interaction flows and acceptance criteria.	8%
Pengxiang Hu	832301309	Frontend Team	Lead the interface prototype design and define user interaction flows and acceptance criteria.	8%
Jianyuan Wu	832302126	Frontend Team	Responsible for refining and standardizing user experience requirements such as multi-language support and theme personalization.	8%
Hongzhi He	832302220	Frontend Team	Responsible for refining and standardizing user experience requirements such as multi-language support and theme personalization.	8%
Feijie Zheng	832301306	QA/Test Team	Responsible for the testability of requirements. Involved from the initial stage, they write detailed acceptance verification criteria for each functional requirement, formulate the overall requirements verification plan, and participate in all reviews to ensure requirements are clear, unambiguous, and testable.	9%
Weixiang Zhou	832301303	QA/Test Team	Responsible for the testability of requirements. Involved from the initial stage, they write detailed acceptance verification criteria for each functional requirement, formulate the overall requirements verification plan, and participate in all reviews to ensure requirements are clear, unambiguous, and testable.	9%

🤝 Member Collaboration Methods

Managing a team of 13 people requires precise process design. We adopted an agile model of "Layered Collaboration, Regular Synchronization".

1. Communication Structure

Core Management Group: Composed of the Project Manager and team leads (Backend, Frontend, Test). Holds two Core Stand-up Meetings weekly to resolve cross-team issues and adjust direction.
Within Teams: Backend, Frontend, and Test teams each hold their own Daily Stand-up Meetings (15 minutes) to sync progress and discuss technical details.
Full Team Sync: Holds one All-Hands Meeting weekly to sync overall progress, make major decisions, and share knowledge.

2. Collaboration Toolchain

Document Collaboration: Use Git and GitHub. The SRS document is version-controlled on GitHub, with modifications made through the Pull Request mechanism. Each PR must be Reviewed by at least one team member and one member from another group (e.g., backend changes require frontend review) before merging, ensuring full-stack consistency of requirements.
Design Collaboration: Use Figma for interface prototyping. Design mockup links are embedded in the SRS document, ensuring a one-to-one correspondence between design and requirement descriptions.
Task Management: Use GitHub Projects kanban boards to manage requirement tasks, decompose each functional requirement in the SRS into specific tasks, assign them to individuals, and track status clearly.

3. Quality Assurance Process

Requirement Drafting: Drafted by the responsible member.
Internal Team Review: First round of review within the team.
Cross-Team Review: The core management group organizes cross-team reviews, especially for requirements involving frontend-backend interaction.
Test Review: The QA team reviews all requirements for testability.
Finalization: The Project Manager integrates all feedback and completes the final version.

📄 Software Requirements Specification

We strictly followed the GB/T 8567-2006 national standard to write the "FocusFlow Learning Project Management Platform Software Requirements Specification". For a large team, a clear, unambiguous requirements document is the cornerstone of successful collaboration.

Core Highlights of the Document

Implementation-Oriented Structure: The document structure not only complies with national standards but also considers the development team's composition. For example, the division of the "Specific Requirements" section highly corresponds to the Backend team's division (accounts, tasks, timer), facilitating parallel work by various teams.
Precise Requirement Descriptions: Each functional requirement includes a unique ID, a clear description, input/output formats, pre/post conditions, and detailed acceptance criteria. This greatly reduces ambiguity that might arise during frontend-backend integration.
System Class Diagram and Use Case Diagram: We used Mermaid to draw precise system class diagrams and use case diagrams, providing an authoritative blueprint for the 6-person backend team's database design and API interface planning, and also providing visual guidance for the 4-person frontend team to understand business logic and data flow.
Comprehensive Non-Functional Requirements: Special emphasis was placed on performance, security, and compatibility requirements, providing a clear basis for the test team to formulate performance and security test plans.

Special Design for Large Teams

Interface Contracts: Preliminary definitions of key frontend-backend data interaction interfaces were included in the functional descriptions, laying the foundation for subsequent API design and reducing communication costs.
Glossary: A unified glossary is maintained within the document to ensure all 13 members have a completely consistent understanding of core concepts such as "Task", "Focus Session", and "Grade Record".

🎥 Demand Analysis PPT

We have condensed the core content of the requirements analysis and created a presentation for the classroom narrative.

PPT Content Structure Overview:

Project Origin & Team Introduction: Shows the composition structure and project management approach of the 13-person team.
Pain Point Analysis & Solution: Introduces how FocusFlow integrates three major modules to solve student user pain points.
System Architecture Showcase: Details the system class diagram, showing core entity relationships and design ideas, reflecting the robustness of the backend design.
Function Demonstration & Prototype: Walks through main functions and interface prototypes via user scenario stories, showcasing frontend design results.
Team Collaboration & Planning: Focuses on showcasing how we ensure the quality and efficiency of requirements engineering through processes and tools under a team size of 13.

⚠️ Analysis of Key Points and Challenges

During this requirements analysis, as a large team, we faced and successfully addressed the following unique challenges:

Challenge 1: Ensuring Consistent Understanding of Requirements
- Problem: 13 people might have 13 different interpretations of the same requirement text, especially at interface boundaries.
- Solution:
  - Implemented a "Three-Party Review" System: Any requirement modification or addition must be reviewed jointly by the proposing party (e.g., backend), the related party (e.g., frontend), and the verification party (test).
  - Strengthened Use Cases and Acceptance Criteria: Required that each major function must be accompanied by use case descriptions and verifiable acceptance criteria, using concrete examples to unify everyone's understanding.
Challenge 2: Managing Requirement Dependencies and Changes
- Problem: Complex dependencies exist between requirements (e.g., "Learning Reports" depend on data from "Tasks" and "Focus Timer"). A change in one requirement can cause a ripple effect.
- Solution:
  - Established a Requirements Traceability Matrix: Maintained a table in the SRS appendix clearly recording dependencies between requirements.
  - Strict Change Control Process: Any change must be proposed via a GitHub Issue, assessed for impact by the core management group, and all affected team leads must be notified.
Challenge 3: Coordinating Parallel Work and Integration
- Problem: 6 backend and 4 frontend developers need to work in parallel. How to ensure their designed modules connect seamlessly?
- Solution:
  - Defined "Interface Contracts" Early: During the requirements phase, backend and frontend leads participated together to preliminarily define key data interaction formats, which were written into the SRS.
  - Cultivated a "Contract First" Culture: Required backend to publish formal interface documentation (based on OpenAPI) before implementing APIs, based on which frontend could proceed with mock development.
Challenge 4: Maintaining a Single Source of Truth for Documentation
- Problem: With many people, inconsistent requirement descriptions could easily appear in different places like WeChat groups, meeting notes, etc.
- Solution: Mandated that all formal requirement discussions and conclusions must be updated into the SRS document on GitHub. WeChat groups were only used for daily communication and notifications; the SRS document was the single authoritative source for requirements.