1. Basic Information

Item	Content
Course	EE308FZ
Assignment Requirement	https://bbs.csdn.net/topics/620549144
Team Name	MIN-roamer
Project Name	Travel Planning and Social Platform
Assignment Goal	To further analyze and standardize the software requirements based on the previous project design, clarify system functions, user scenarios, module boundaries, UI prototypes, and acceptance criteria, and organize team responsibilities and collaboration methods to provide a unified basis for subsequent implementation and testing.
Software Requirements Specification (SRS)	https://github.com/EthanChen251/RoamMin_Docs/blob/93aab7ba33f6ded6f9f1c373da89df1141bee1e7/%E6%97%85%E8%A1%8C%E8%A7%84%E5%88%92%E7%A4%BE%E4%BA%A4%E5%B9%B3%E5%8F%B0-%E8%BD%AF%E4%BB%B6%E9%9C%80%E6%B1%82%E8%A7%84%E6%A0%BC%E8%AF%B4%E6%98%8E%E4%B9%A6.md
Requirements Analysis PPT	https://github.com/EthanChen251/RoamMin_Docs/blob/93aab7ba33f6ded6f9f1c373da89df1141bee1e7/RoamMin_Assignment3.pptx

---

2. Table of Contents

• 1. Basic Information
• 2. Table of Contents
• 3. Project Overview
• 4. Team Division of Labor
  • 4.1 Team Organization
  • 4.2 Module Responsibilities
  • 4.3 Individual Contribution
• 5. Software Requirements Specification
  • 5.1 SRS Document
  • 5.2 Main Contents of the Requirements Analysis
• 6. Team Plan and Task Execution
• 7. Team Collaboration
  • 7.1 Task Allocation
  • 7.2 Progress Synchronization
  • 7.3 Documentation and Code Collaboration
  • 7.4 Communication Mechanism
  • 7.5 Review and Integration
• 8. Problems and Challenges
• 9. Requirements Analysis PPT
• 10. Conclusion

---

3. Project Overview

Our project is Travel Planning and Social Platform, which is mainly designed for individual travelers and users traveling together in groups.

In real-world travel planning, users often need to use multiple tools at the same time, such as map applications, travel guide platforms, messaging applications, spreadsheets, and expense-tracking tools. Information about attractions, schedules, opinions from travel companions, and travel expenses may therefore be scattered across different platforms.

This not only increases the cost of organizing information, but also makes collaborative travel planning more difficult.

Therefore, this project aims to build a Web platform that integrates:

• itinerary planning;
• maps and destination information;
• budget management;
• community sharing;
• travel buddy functions;
• AI travel assistance.

The goal is to allow users to complete most major travel-planning tasks within one unified platform.

The current project uses Fuzhou as the primary demonstration city. Basic destination services are built using locally curated attraction and food information, while external services such as maps, weather services, and AI services are integrated to further enhance system capabilities.

In the current SRS, the project is defined as a Web platform combining itinerary planning, destination information, and social sharing. A map together with date-based itinerary cards serves as the core interaction model for travel planning.

The system is currently divided into the following major functional modules:

1. User and Personal Profile;
2. Trip Planning and Map;
3. Destination Information, including attractions, food, weather, and transportation;
4. Budget and Expense Management;
5. Community and Social Features, including public trips, travel buddies, and collaboration;
6. AI Travel Assistant.

These modules are consistent with the functional scope currently defined in the SRS.

---

4. Team Division of Labor

4.1 Team Organization

Our project team consists of 14 members.

Because the project contains multiple types of functionality, the team adopts a structure that divides work by business module while also assigning responsibilities according to frontend development, backend development, UI design, AI integration, and project management.

The current team structure is mainly divided into:

• Group A: User and Personal Profile
• Group B: Trip Planning
• Group C: Destination Information
• Group D: Budget and Expenses
• Group E: Community and Social Features
• AI Group: AI Travel Assistant

Each module has corresponding members responsible for frontend development, backend development, UI work, or related functional tasks.

Chen Hang serves as the Team Lead. In addition to being responsible for authentication-related backend development, he is also responsible for overall project progress control, task coordination, and team management.

Some members participate in more than one related module. For example, Qiu Yuqi participates in both Group A and Group E, while Zhuang Yijun participates in both Group C and the AI module.

This cross-module arrangement helps reduce communication costs between related modules and improves consistency in shared data and functionality.

---

4.2 Module Responsibilities

According to the team’s currently confirmed task allocation, the main responsibilities are as follows.

Module	Main Member(s)	Main Responsibilities
Project Management	Chen Hang	Team Lead, project progress control, task coordination, and overall management
Group A: User and Personal Profile	Chen Hang	User authentication and related backend development
Group A: User and Personal Profile	Qiu Yuqi	User-related frontend development
Group B: Trip Planning	Wang Jingling	UI design for the trip-planning module
Group B: Trip Planning	Zou Jiayu	Trip frontend development
Group B: Trip Planning	Qiyang Chen	Trip backend development
Group C: Destination Information	Wenjie Huang	Places frontend development
Group C: Destination Information	Kang Ciqi	Weather-related frontend development
Group C: Destination Information	Huang Qiwei	POI-related backend development
Group C + AI	Zhuang Yijun	Destination-information backend and AI-related backend work
Group D: Budget and Expenses	Chen Yibing	Budget frontend development
Group D: Budget and Expenses	Chen Kongzhou	Expense backend development
Group E: Community and Social Features	Qiu Yuqi	Community-related frontend collaboration
Group E: Community and Social Features	An Liuzhi	Community frontend development
Group E: Community and Social Features	Zha Shi	Social backend development
AI Group	Yuhe Jiang	AI integration and integration with existing system functions
AI Group	Zhuang Yijun	AI-related backend support

Overall, each member focuses on a relatively clear functional area, while appropriate cross-module collaboration is used for modules with strong business dependencies.

For example, AI functionality needs to use trip and destination data. Therefore, the AI module does not exist completely independently and must integrate with existing business modules at both the API and data levels.

---

4.3 Individual Contribution

Based on the module tasks, development responsibilities, cross-module collaboration, and project management work undertaken by each member during the current stage, the team discussed and confirmed the contribution percentages.

The contribution percentages are not simply divided equally among all team members. Instead, they are determined based on the actual scope of responsibilities undertaken by each member.

The final contribution allocation is as follows:

Member	Student ID	Main Responsibilities	Contribution
Chen Hang	832401103	Group A authentication backend; Team Lead, project progress control, and team coordination	8%
Qiu Yuqi	832401120	Group A + Group E frontend development	8%
Zhuang Yijun	832401130	Group C + AI backend development	8%
Wang Jingling	832402119	Group B UI Design	7%
Zou Jiayu	832402130	Group B Trip Frontend	7%
Qiyang Chen	832401105	Group B Trip Backend	7%
Wenjie Huang	832401206	Group C Places Frontend	7%
Kang Ciqi	832401115	Group C Weather Frontend	7%
Huang Qiwei	832401208	Group C POI Backend	7%
Chen Yibing	832401107	Group D Budget Frontend	7%
Chen Kongzhou	832401104	Group D Expense Backend	7%
An Liuzhi	832401101	Group E Community Frontend	7%
Zha Shi	832401102	Group E Social Backend	7%
Yuhe Jiang	832402107	AI Integration	6%
Total			100%

Most members are responsible for one complete or relatively independent module task, so their contribution percentages are concentrated around 7%.

The contribution percentages above represent the team’s confirmed workload allocation for the current stage, with a total contribution of 100%.

If the actual task scope changes in later development stages, the contribution percentages will be updated according to the work actually completed in subsequent assignments.

---

5. Software Requirements Specification

5.1 SRS Document

Based on the previous project design, this assignment further analyzes and standardizes the software requirements and organizes them into a Software Requirements Specification.

Software Requirements Specification

SRS Online Link:

https://github.com/EthanChen251/RoamMin_Docs/blob/93aab7ba33f6ded6f9f1c373da89df1141bee1e7/%E6%97%85%E8%A1%8C%E8%A7%84%E5%88%92%E7%A4%BE%E4%BA%A4%E5%B9%B3%E5%8F%B0-%E8%BD%AF%E4%BB%B6%E9%9C%80%E6%B1%82%E8%A7%84%E6%A0%BC%E8%AF%B4%E6%98%8E%E4%B9%A6.md

The current SRS version is:

Version 1.0 — Requirements Analysis Draft

The main purpose of the SRS is to define the system’s target users, user scenarios, system boundaries, functional behavior, data constraints, interface expectations, and acceptance methods.

It provides a common requirements reference for frontend development, backend development, API integration, testing, and subsequent presentation work.

---

5.2 Main Contents of the Requirements Analysis

The SRS does not simply list the functions that the system should provide.

Instead, it further refines the project requirements from several perspectives, including user scenarios, system behavior, data relationships, UI interactions, and acceptance testing.

1. User Scenarios

The SRS defines several typical user scenarios based on realistic usage of a travel platform.

These scenarios mainly include:

• creating and planning a personal trip to Fuzhou;
• collaborating with travel companions on a trip;
• browsing and publishing public trips;
• publishing place reviews;
• managing travel budgets and expenses;
• using AI to generate itinerary drafts and answer travel-related questions.

For example, in the personal travel-planning scenario, the user first creates a trip and enters the destination and travel dates.

The user then searches for attractions or restaurants and adds selected places to a specific day of the trip.

The user can further edit activity times and notes, reorder itinerary items, and view corresponding locations on the map.

After that, the user can check weather information and destination recommendations and record the travel budget and expenses.

In collaborative travel scenarios, the Trip Owner can add other members to the trip. Members can jointly edit the itinerary or add expenses within their authorized permissions, while important operations such as deleting the entire Trip remain restricted by role-based permissions.

---

2. Class Diagram and Core Data Objects

To further clarify the relationships among system data, the SRS organizes the major business entities and provides a requirements-stage class diagram.

The main data objects include:

• User
• Trip
• TripMember
• TripDay
• DayItem
• Place
• PlaceReview
• Expense
• BuddyPost

Together, these objects describe the system’s core business data, including users, trips, membership relationships, daily schedules, places, reviews, expenses, and travel-buddy posts.

The class diagram helps clarify the relationships among these objects and also provides a basis for subsequent database design and backend entity design.

---

3. Functional Requirements

To make later development, testing, and requirement tracking easier, the SRS assigns a consistent identifier to the functional requirements of each module.

The main functional requirement groups are:

ID	Functional Module
FR-AUTH	User and Personal Profile
FR-TRIP	Trip Planning
FR-DEST	Destination Information
FR-BUD	Budget and Expenses
FR-SOC	Community, Sharing, and Collaboration
FR-AI	AI Travel Assistant

The requirements are also divided into three priority levels: P0, P1, and P2.

• P0: Core Requirements
• P1: Important Enhancements
• P2: Optional Extensions

P0 functions are implemented first to support the system’s core business workflow.

P1 functions are implemented after the core workflow has been established.

P2 functions may be implemented depending on project progress and available development time.

This approach helps reduce the risk of failing to complete the core workflow because too many features are developed at the same time.

---

4. UI Prototypes

To make the functional requirements easier to understand, the SRS also includes several low-fidelity UI prototypes.

The current prototypes mainly include:

• Trip Planning Page;
• Place Details and Reviews Page;
• Community and Travel-Buddy Page;
• Budget and Expense Management Page;
• AI Travel Assistant Sidebar.

And we will design the website to support both Chinese and English languages.

The main purpose of these prototypes is to illustrate:

• page information structure;
• feature entry points;
• major interaction flows;
• data that users need to see;
• Make it convenient for users of non-Chinese languages to use.

They are requirement-analysis-stage interface illustrations and do not represent the final visual design of the project.

Several representative prototypes can be displayed in the blog.

For example:

 [Trip Planning Page Prototype]

[Community and Travel-Buddy Page Prototype]

 [Budget and Expense Management Page Prototype]

[AI Travel Assistant Page Prototype] 

The complete prototypes and their related interaction requirements are provided in the SRS.

---

5. Acceptance and Verification Criteria

To ensure that the major requirements can be verified after implementation, the SRS also defines corresponding Acceptance and Verification Criteria.

The current acceptance scenarios mainly include:

• user registration and login;
• private-data authorization;
• creating and editing Trips;
• place search and itinerary insertion;
• itinerary drag-and-drop ordering;
• curated Fuzhou place data;
• city switching and weather queries;
• place reviews and likes;
• budget and expense management;
• collaborative member permissions;
• public and private Trips;
• likes and saves;
• Travel Buddy Posts;
• AI itinerary generation and travel Q&A;
• secret and sensitive-data checks;
• Chinese/English interface switching.

This means that a requirement is no longer described only as:

“The system should provide a certain function.”

Instead, it can be further transformed into:

“What operations should be performed to verify whether this function actually satisfies the requirement?”

The current SRS therefore includes relatively concrete acceptance tests for the major business workflows.

---

6. Team Plan and Task Execution

The content of this section is based on the current team task arrangement. Before final submission, it will be checked again against the Requirements Analysis PPT to ensure that the plan, member responsibilities, and contribution percentages are fully consistent.

The main goal of the current stage is not to immediately complete every system function, but to first organize the project scope and requirements systematically.

The overall work is mainly carried out through the following process:

1. Determine the overall project objectives;
2. Divide the system into major functional modules;
3. Assign members according to their development roles;
4. Organize the core requirements of each module;
5. Standardize core objects such as User, Trip, Place, and Expense;
6. Define major user scenarios;
7. Create requirement-stage UI prototypes;
8. Classify requirements into P0 / P1 / P2 priorities;
9. Add Acceptance Criteria for major requirements;
10. Integrate the results into the SRS;
11. Organize the blog;
12. Prepare the Requirements Analysis PPT.

At present, the major business modules, team responsibilities, and core user scenarios have been basically clarified.

However, some implementation details still require further confirmation during subsequent development, including:

• the final map POI service provider;
• the map tile source;
• whether collaboration will require true real-time synchronization;
• how conflicts caused by simultaneous editing will be resolved;
• image upload and storage methods;
• AI request limits and conversation-retention strategies;
• H2 database concurrency and backup strategies;
• the final supported browsers and screen sizes.

For issues that cannot yet be fully determined, the SRS does not assume a specific implementation solution.

Instead, these items are marked as TBD or Proposed.

This avoids locking the project into an implementation solution too early during requirements analysis and allows the team to further improve the system based on actual development conditions.

---

7. Team Collaboration

7.1 Task Allocation

The team first divides the system according to business functionality and then assigns specific tasks according to each member’s technical direction and project responsibilities.

The current types of tasks mainly include:

• Frontend Development;
• Backend Development;
• UI Design;
• AI Integration;
• Project Management.

Each member focuses on one primary responsibility while being allowed to collaborate with other related modules when necessary.

For example:

• Qiu Yuqi participates in both Group A and Group E;
• Zhuang Yijun participates in both Group C and the AI module;
• the AI module needs to integrate with existing modules such as trip planning and destination information.

This organization allows each member to have a relatively clear primary responsibility while still handling unavoidable data and functional dependencies between modules.

---

7.2 Progress Synchronization

Different modules proceed according to the tasks of the current stage.

During team collaboration, the following information needs to be synchronized in a timely manner:

• completed tasks;
• tasks currently in progress;
• requirements that have not yet been confirmed;
• dependencies on other modules;
• changes to data formats or APIs;
• current problems;
• tasks for the next stage.

If changes in one module may affect another module, the relevant information should be communicated promptly rather than being handled only during final integration.

Team Lead Chen Hang is responsible for overall project progress control and assists in coordinating task relationships between different modules.

---

7.3 Documentation and Code Collaboration

During project development, both code and project documentation need to be maintained in a unified manner.

The requirements-analysis stage places particular emphasis on consistency among different project materials.

For example, the team should avoid situations where:

• field names in the SRS are inconsistent with those used in frontend pages;
• backend APIs do not correspond to functional requirements;
• different modules use different names for the same business object;
• UI prototypes contain functions that do not exist in the SRS;
• the blog and PPT describe different team responsibilities;
• the blog and SRS describe different project scopes.

The current SRS assigns unified identifiers to major requirements and requires terminology, requirements, interfaces, and prototypes to remain consistent.

Therefore, the SRS can also serve as a unified requirements reference during later development.

---

7.4 Communication Mechanism

Team communication is mainly divided into three levels.

Internal Module Communication

Members responsible for the same module first confirm:

• what information the frontend needs to display;
• what data the backend needs to provide;
• API inputs and outputs;
• user operation flows;
• error-handling methods;
• permission restrictions.

For example, the Trip Frontend and Trip Backend need to agree on data related to daily schedules, places, dates, and ordering.

---

Cross-Module Communication

Some business objects are shared by multiple modules.

For example:

• User is used by both the personal-profile and community modules;
• Trip is used by trip planning, budgeting, community, and AI modules;
• Place is used by trip planning, destination information, and AI modules;
• Expense is related to both Trips and collaborative members.

Therefore, these shared objects need to be defined consistently through cross-module communication.

---

Overall Coordination

Team Lead Chen Hang is responsible for overall project progress control and cross-module task coordination.

When a change may affect multiple modules, the scope of impact should first be confirmed before making unified adjustments.

This helps reduce new conflicts caused by independent modifications across different modules.

---

7.5 Review and Integration

After members complete their individual tasks, the results still need to go through unified integration and review.

The main review items include:

• whether functional names are consistent;
• whether frontend and backend requirements are consistent;
• whether there are conflicts in the permission model;
• whether prototypes are consistent with the SRS;
• whether the class diagram is consistent with the functional descriptions;
• whether core data objects are defined consistently;
• whether Acceptance Criteria are actually testable;
• whether the Blog, SRS, and PPT describe the same project version;
• whether team responsibilities and contribution percentages are consistent.

For issues that have not yet been confirmed, TBD markers are retained rather than filling in unconfirmed content merely to make the document appear complete.

---

8. Problems and Challenges

During this requirements-analysis assignment, we encountered several major challenges.

8.1 Transforming Feature Ideas into Verifiable Requirements

During the early stages of the project, discussions focused more on:

“What functions should the system have?”

For example:

• maps;
• itinerary planning;
• weather;
• community;
• budget management;
• AI.

However, when these features are formally written into an SRS, simply stating:

“The system should provide a map function.”

is not sufficient.

We also need to consider:

• Who can use the function?
• Under what conditions can it be used?
• What is the input?
• What should the system return?
• What should happen when the operation fails?
• Should the data be persisted?
• How can we test whether the function works correctly?

Therefore, one of the major challenges in this assignment was transforming relatively abstract product ideas into specific, clear, and testable system requirements.

---

8.2 Data Consistency Across Multiple Modules

The project contains multiple business modules, and these modules have strong relationships with each other.

For example:

• trip planning needs to use Place;
• an Expense must be associated with a Trip;
• public trips in the community originate from Trip;
• collaboration depends on User, Trip, and TripMember;
• the AI assistant may need both Trip and Place data.

If different modules are designed completely independently, several problems may occur:

• the same field may use different names;
• different members may interpret the same object differently;
• the backend may not provide the data required by the frontend;
• API structures may not match UI requirements.

Therefore, one important task in the SRS was to standardize the core business objects and their relationships.

---

8.3 Uncertainty of Third-Party Services

The project’s map, POI, weather, and AI functions may all depend on external services.

These services may experience:

• network errors;
• API timeouts;
• request quota limitations;
• API Key configuration issues;
• temporary service unavailability.

Therefore, the requirements cannot describe only the normal successful situation.

For example, even if the weather, map POI, or AI service becomes unavailable, important local data such as Trips and Expenses should still remain accessible, and the system should provide understandable error messages to the user.

Sensitive information such as third-party API Keys must also not be exposed directly in frontend code.

---

8.4 Controlling the Project Scope

During project design, many additional features were considered, including:

• real-time collaboration;
• direct messaging;
• Follow / Follower relationships;
• more complex recommendation systems;
• more complete content management;
• more advanced AI functionality.

However, the development time of a course project is limited.

If all of these functions are defined as mandatory, the project scope may continue to expand and eventually affect the completion of the core system workflow.

Therefore, this requirements analysis uses P0, P1, and P2 priorities to control the functional scope.

The core workflow is implemented first, and other functions can then be expanded gradually.

---

8.5 Team Division and Cross-Module Collaboration

Because different business modules have strong dependencies on each other, team members cannot work in complete isolation.

For example:

• Qiu Yuqi participates in both Group A and Group E;
• Zhuang Yijun participates in both Group C and AI;
• Yuhe Jiang is responsible for AI Integration and therefore needs to coordinate with other business modules.

The team division therefore needs to achieve two goals at the same time:

1. Each member should have a clear primary responsibility;
2. Necessary cross-module collaboration should still be supported.

In addition, the Team Lead is responsible for progress control, task coordination, and team management.

These responsibilities may not directly appear as a specific page or API, but they are still important parts of a team software project.

---

8.6 Consistency Among the Blog, SRS, and PPT

The final assignment requires three major deliverables:

• SRS;
• PPT;
• CSDN Blog.

Although these three materials have different presentation formats, they describe the same project.

Therefore, problems may occur if:

• the SRS marks a feature as TBD while the PPT claims it has already been implemented;
• member responsibilities in the Blog are different from those in the PPT;
• contribution percentages in the Blog and PPT are inconsistent;
• functions shown in the UI Prototype do not match the SRS.

For this reason, a final consistency review among all three materials is an important step before submission.

---

9. Conclusion

The main task of this assignment was to transform the relatively scattered project design from the previous stage into a more structured set of software requirements.

Through this requirements analysis, we reorganized:

• user scenarios;
• core business workflows;
• functional requirements;
• data relationships;
• system boundaries;
• UI prototypes;
• requirement priorities;
• Acceptance and Verification Criteria.

At the same time, by further clarifying team responsibilities, each member can better understand both their own module and its dependencies on other modules.

Compared with simply listing system functions, this requirements analysis places more emphasis on three aspects:

Clarity, Consistency, and Verifiability.

Clarity means that the requirements should clearly describe what the system is expected to do.

Consistency means that the SRS, prototypes, Blog, PPT, and later implementation should use the same definitions as much as possible.

Verifiability means that every core requirement should eventually be testable so that the team can determine whether it has actually been satisfied.

During subsequent development, the team will continue updating the requirements according to the actual implementation status and further refine the items that are still marked as TBD.

Ultimately, we aim to ensure that:

The software implementation, Software Requirements Specification, Requirements Analysis PPT, and Blog remain consistent in their description of the project.

This not only helps reduce repeated modifications caused by different interpretations among team members, but also provides a clearer foundation for subsequent development, testing, and in-class presentation.