Assignment 2 | Team Formation and Topic Selection: MoodSky**

Item	Content
Which course does this assignment belong to?	EE308FZ
Where are the requirements for this assignment?	Assignment 2: Team Up and Topic Selection
Team Name	MoodSky
The objective of this assignment	Introduce our team and project, set clear milestones, assign responsibilities, and establish a preliminary performance assessment plan

@

Contents

1. Team Introduction

1.1 Team Name: MoodSky

Our team name, MoodSky, combines Mood and Sky. It suggests that everyone has a sky of their own, with changing weather representing different feelings. The name is short and easy to remember, and reflects our project's idea of recording moods through weather symbols and collecting those days in a private Weather Universe.

1.2 Team Member Introductions

Xiang Hong

Item	Introduction
Student ID	FZU：832401205 MU：24125130
CSDN Profile	Xiang Hong
Personality	easygoing
Technical Expertise	Back-end Developer
Hobbies	Football
Desired Software Engineering Role	Project Manager and Back-end Developer
Slogan	study hard

Junhan Huang

Item	Introduction
Student ID	FZU：832401207 MU：24127396
CSDN Profile	Junhan Huang
Personality	Optimistic
Technical Expertise	Front-end development, debugging, and page design
Hobbies	Saxophone
Desired Software Engineering Role	Back-end Developer
Slogan	I can accept failure,but I can't accept not trying.

Jiawei Fang

Item	Introduction
Name	Jiawei Fang
Student ID	FZU: 832401110 MU: 24125075
CSDN Profile	Jiawei Fang
Personality	Teamwork and communication
Technical Expertise	Front-end development, UI design and responsive web design
Hobbies	Playing video games and exploring new tech
Desired Software Engineering Role	Back-end Developer
Slogan	Build together, learn together, and never stop improving.

Linghan Chen

Item	Introduction
Student ID	FZU: 832401201 MU: 24125601
CSDN Profile	Linhan Chen
Personality	Rigorous, responsible, patient, and detail-oriented
Technical Expertise	Strong hands-on ability, practical problem-solving, basic front-end development, and careful debugging
Hobbies	hands-on practice, and exploring new technologies
Desired Software Engineering Role	Front-End Engineer
Slogan	Turn ideas into reality, one careful step at a time.

Yifan Ji

Item	Introduction
Student ID	FZU：832401209 MU：24126411
CSDN Profile	Yifan Ji
Personality	Easygoing and patient
Technical Expertise	Front-end development
Hobbies	Dancing and badminton
Desired Software Engineering Role	Front-end interaction Developer
Slogan	The harder you work, the luckier you will become.

Zhifeng Dai

Item	Introduction
Student ID	FZU：832401203 MU：24127001
CSDN Profile	Zhifeng Dai
Personality	Enthusiastic, easygoing, and eager to learn
Technical Expertise	Front-end interaction development
Hobbies	Discovering delicious food
Desired Software Engineering Role	Front-end interaction Developer
Slogan	Listen to TWICE when you're feeling down.

Qinghan Zhang

Item	Introduction
Student ID	FZU：832401226 MU：24125482
CSDN Profile	Qinghan Zhang
Personality	easygoing & curious
Technical Expertise	Front-end development
Hobbies	Football
Desired Software Engineering Role	Frontend Developer
Slogan	Take it easy

Jiaqi Zhu

Item	Introduction
Student ID	FZU:832401229 MU:24125202
CSDN Profile	Jiaqi Zhu
Personality	Patient, easy-going and inclusive
Technical Expertise	UI design
Hobbies	Playing video games
Desired Software Engineering Role	Front-end development or UI design
Slogan	To strive, to seek, to find, and not to yield.

Yuen Lin

Item	Introduction
Student ID	FZU：832401211 MU：24125491
CSDN Profile	Yuen Lin
Personality	Calm, easygoing
Technical Expertise	Know the basics of HTML, CSS and JavaScript
Hobbies	Musicals
Desired Software Engineering Role	Software Test Engineer
Slogan	I will not throw away my shot.

Xiang Yu

Item	Introduction
Student ID	FZU：832401124 MU：24125661
CSDN Profile	Xiang Yu
Personality	Kind and cheerful
Technical Expertise	Front-end development
Hobbies	Football and basketball
Desired Software Engineering Role	Database Engineer
Slogan	lose yourself to find yourself

Qizhen Chen

Item	Introduction
Student ID	FZU：832401304 MU：24126837
CSDN Profile	Qizhen Chen
Personality	Easy-going & responsible
Technical Expertise	Front-end interaction Developer, good at page layout
Hobbies	Photography
Desired Software Engineering Role	Front-end interaction Developer
Slogan	Learn continuously, code sincerely

Qizhen Cai

Item	Introduction
Student ID	FZU：832401301 MU：24125229
CSDN Profile	Qizhen Cai
Personality	Prudent, cooperative, and patient
Technical Expertise	Finding and solving programming problems and improving code
Hobbies	Listening to music, watching TV
Desired Software Engineering Role	Software Test Engineer
Slogan	Learn constantly and strive for improvement.

1.3 Team Vision

We want MoodSky to make recording a feeling as simple as choosing the weather. Students should be able to save a short entry and revisit it when they want to reflect on a past day.

Our goal for this semester is to complete a usable version and learn to coordinate requirements analysis, design, development, and testing. Each member will have an agreed deliverable, and the team will review complete user journeys during integration.

1.4 Our First Team Photo

2. Team Project Plan

2.1 Team Project Description

Project name: MoodSky

Brief description: We plan to build MoodSky as a WeChat mini program for university students to record feelings through weather symbols and revisit them in a private monthly archive. It will also provide campus place information and optional activities for everyday campus life.

Users choose Sunny, Partly Cloudy, Cloudy, Rainy, or Stormy. Weather alone is enough to save an entry; tags and a short note are optional. Each recorded day can later be found through a calendar, timeline, or monthly weather card.

For example, a student who feels tired after studying could choose Rainy, add the Study tag, and write a sentence about the day. At the weekend, they could revisit that entry in October's archive. If they want a change of surroundings, they could open Campus and browse places for a walk.

The weather is chosen and interpreted by the user. It is a form of personal expression and does not provide psychological diagnoses.

Figure 1. Planned recording and review model. Calendar, timeline, and monthly archive views use the same private entries and update together after edits or deletion.

2.2 Major Functions

Module	Planned Functions
Weather Recording	Choose weather, add optional tags and notes, add missing entries for today or the previous 29 days, edit, and delete
Personal Review	Browse a weather calendar, category distribution, and a timeline arranged by date
Weather Universe	Revisit private monthly archives and weather cards, with a small set of static stickers and backgrounds
Campus Places	Browse lists or maps, filter by activity or setting, check opening information, navigate, save favorites, and submit corrections
Optional Small Tasks	Choose an activity, complete, replace, or skip it, and review personal task history
Personal Settings and Information Management	Manage privacy and display preferences, export entries, delete an account and check cleanup progress, and browse campus support resources

MoodSky has four main tabs: Today, Campus, Weather Universe, and Me. A user can record an entry, review their archive, or go directly to places and tasks.

Figure 2. Low-fidelity concept wireframes for the four main tabs. The entries and places shown are examples, not screenshots of a completed product.

The first Weather Universe will focus on monthly archives and weather cards. It will offer up to six static stickers and two backgrounds, with decoration that users can disable or reset. Edits and deletions will update the calendar, cards, and archives together.

Diaries, favorites, and task history will remain private by default. Campus places will also be available as a list when location access is declined. The first release will include a clearly labeled Campus Weather simulation; it will not collect real campus mood contributions or include a public discussion space.

2.3 Implementation Method

We plan to build the student interface as a native WeChat mini program using JavaScript. WeChat Cloud Development will provide identity, cloud functions, data storage, and the business logic needed for the first release. A separate information administration interface will maintain campus places, task templates, and support resources. Official CloudBase documentation

The front end will use shared components, consistent weather icons, and clear text prompts. Cloud Functions will validate input and check identity and permissions before accessing data. Students will access their own private records, while authorized information operators will maintain campus information without reading private diaries.

Figure 3. Proposed architecture. Student and operator requests go through Cloud Functions, which check identity and permissions before accessing data or storage.

We will test complete user journeys: saving an entry, finding it in different views, editing and deleting it, browsing places, completing or skipping tasks, exporting data, and closing an account. Compatibility checks will cover Android and iOS.

2.4 Reasons for Topic Selection: NABCD Analysis

N — Need

Our target users are university students who want a quick way to record feelings, revisit past days, and find campus places for a break. A long diary entry can be difficult to start, while a plain list of notes can be inconvenient to browse over time. We want to explore whether weather symbols and monthly archives make these actions easier.

In Week 1, we plan to interview 12 students about their recent experiences with recording, revisiting entries, and finding places to rest. Following the requirements analysis approach in 构建之法, we will turn these situations into user stories and acceptance criteria.

One example is: “As a student who does not want to write a long diary entry, I want to save a weather choice so that I can revisit it later.” We will check that an entry can be saved without a note, that the owner can view and edit it, and that the same day does not receive duplicate entries.

A — Approach

We connect three everyday actions: record, revisit, and choose. Weather selection provides a simple starting point, the Weather Universe organizes entries by month, and campus places and small tasks offer optional choices for daily life.

These modules can also be used independently. A student does not need to record a feeling before browsing a place or choosing an activity.

B — Benefit

The intended benefits are quicker recording, easier access to past entries, and more useful information when choosing a campus place. We will assess them through a usability test with 12 participants.

Task	Planned Validation Target
Save a first weather entry	At least 90% success; median completion time no longer than 30 seconds
Identify who can see an entry	At least 90% understand that entries are private
Find a campus place matching a preference	At least 80% find one within three steps
Find a specified archived entry	Reach the month and find the entry within three steps

These figures are targets for testing. Interview findings and actual test results will be recorded after the work takes place.

C — Competition

Alternative	Main Strength	What Our Project Aims to Add
Paper Diary	Flexible personal writing	Quick weather input and browsing by month
Phone Notes or General Diary Tools	Convenient text recording	Weather cards and private monthly archives
Campus Maps or Place Guides	Location and place information	Filters for activities such as resting or walking, alongside optional recording and task functions

The proposed value lies in combining weather expression, a private monthly archive, and campus place information. Prototype feedback will help us judge whether that combination is useful to students.

D — Delivery

We will invite classmates, friends, and other willing campus participants to try the mini program. After essential functional and data access checks pass, we plan a one-week trial with 12 students. We will collect feedback on recording, monthly review, and place discovery, then improve the product before considering a wider trial.

2.5 Project Timeline Plan

Our proposed schedule covers eight weeks after topic preparation. Dates will be adjusted to the course schedule.

Phase	Planned Dates in 2026	Planned Work and Milestone
Topic Preparation	October 10–11	Complete the project proposal, blog, requirements specification, responsibilities, and assessment plan
Week 1: Planning and Design	October 12–18	Conduct interviews, produce a clickable prototype, and check technical and cost feasibility
Week 2: Recording	October 19–25	Complete weather recording, tags, missing entries, editing, and deletion
Week 3: Review and Archives	October 26–November 1	Complete the calendar, category distribution, timeline, monthly archives, and weather cards
Week 4: Campus and Decoration	November 2–8	Add simple decoration, place browsing, favorites, corrections, and information administration; prepare a milestone demo with simulated data
Week 5: Complete User Journeys	November 9–15	Complete tasks and history, support resources, the choice entry point, simulated Campus Weather, export, and account deletion
Week 6: Testing and Trial	November 16–22	Run device and data access tests; begin the voluntary one-week trial after critical checks pass
Week 7: Improvements	November 23–29	Resolve reported issues, retest affected functions, improve interactions, and prepare platform review materials
Week 8: Acceptance and Delivery	November 30–December 6	Prepare a candidate release, test report, user guide, and demonstration; submit for platform review when ready

We will prioritize reliable recording and review, data access controls, export, and account deletion. Export and deletion flows will be designed in Week 1 and developed alongside the core features; Week 5 is their planned integration milestone. We will review the workload at the end of each week. If progress falls behind, static decoration and the simulated Campus Weather page will be deferred first. Any change to the delivery scope will be recorded in the requirements specification and task allocation.

Planning will be coordinated by Xiang Hong, with Jiaqi Zhu preparing the interface prototype and the developers and testers reviewing requirements. During implementation, front-end and back-end members will work together on complete features. Yuen Lin and Qizhen Cai will lead testing, while Qizhen Chen, Xiang Hong, and Xiang Yu will coordinate integration, cloud configuration, and delivery within their respective responsibilities.

The team will hold a weekly progress discussion to review deliverables, resolve issues, and agree on the next week's tasks.

3. Project Division of Labor

3.1 Group Composition

Responsibilities are assigned according to the roles in our member introductions. Xiang Hong combines project management with back-end development. Junhan Huang and Jiawei Fang complete the back-end group. Linhan Chen, Yifan Ji, Zhifeng Dai, Qinghan Zhang, and Qizhen Chen divide the front-end modules; Jiaqi Zhu focuses on UI/UX design; Xiang Yu manages database design; and Yuen Lin and Qizhen Cai handle testing.

Integration and release work will be shared by the relevant front-end, back-end, and database members. Each feature will have development and testing responsibilities, with Xiang Hong coordinating scope and progress.

3.2 Work Distribution and Contribution

The table uses FZU student IDs. The percentages are our initial planned workload ratios, totaling 100%; actual contributions will be reviewed against accepted deliverables.

Student ID	Name	Work Description	Contribution
832401205	Xiang Hong	Project Manager and Back-End Developer: Coordinate requirements, milestones, team tasks, and the opening presentation; implement weather entry and review services, including same-day uniqueness and synchronized views	9%
832401207	Junhan Huang	Back-End Developer: Implement campus place queries and filters, favorites, corrections, support resource services, and authorized information administration	8%
832401110	Jiawei Fang	Back-End Developer: Implement small-task selection and status, personal history, privacy preferences, entry export, and account closure and cleanup workflows	8%
832401201	Linghan Chen	Front-End Engineer: Build the mini program structure, shared components, navigation, personal settings, export and account deletion pages, and the simulated Campus Weather interface	8%
832401209	Yifan Ji	Front-End Interaction Developer: Build weather selection, tags and notes, saving, missing-entry creation, editing, deletion, and the secondary choice entry point	9%
832401203	Zhifeng Dai	Front-End Interaction Developer: Build the calendar, category distribution, timeline, monthly archives, weather cards, and simple decoration interactions	9%
832401226	Qinghan Zhang	Front-End Developer: Build campus place lists and maps, filters, details, navigation, favorites, corrections, and support resource pages	8%
832401229	Jiaqi Zhu	UI/UX Designer: Design the four-tab prototype, shared visual guidelines, five weather icons, weather cards, stickers, and backgrounds; review interface consistency	8%
832401211	Yuen Lin	Software Test Engineer: Prepare and execute functional and integration tests, check normal and exceptional user journeys, test Android/iOS compatibility, and track defects and regression results	8%
832401124	Xiang Yu	Database Engineer: Define collections, fields, indexes, access constraints, uniqueness and deletion rules; prepare campus data and document backup restoration rules	8%
832401304	Qizhen Chen	Front-End Interaction Developer: Build small-task selection, completion, replacement, skipping, and history pages; coordinate front-end integration, interface debugging, and demonstration preparation	9%
832401301	Qizhen Cai	Software Test Engineer: Test account isolation, operator permissions, export and deletion, disabled accounts, and restoration behavior; assess performance and usability	9%

Design, coordination, data verification, testing, and documentation count as workload alongside implementation. Members will agree on deliverables before work starts and review the allocation if the project scope changes.

4. Team Performance Assessment Plan

4.1 Assessment Criteria

We will assess both completed work and the way members work together. Delivery and quality account for 70% of the score; collaboration and documentation account for the remaining 30%.

Dimension	Weight	Assessment Criteria	Application to Our Project
Task Completion	40%	Completeness of agreed deliverables and progress against milestones	Whether an assigned feature, prototype, data definition, or test report is delivered and meets its acceptance criteria
Quality and Testing	30%	Correctness, maintainability, relevant tests, and resolution of defects	Reliable saving and review, consistent views after deletion, correct data access, and documented normal and exceptional cases
Collaboration	20%	Communication, peer review, integration, and support for teammates	Clear front-end/back-end handoffs, timely reporting of issues, and constructive help during integration
Documentation and Demonstration	10%	Clear requirements notes, test records, user guidance, and presentation materials	Traceable changes, understandable test results, and a demonstration that accurately explains the product

Each dimension receives a score from 0 to 100. Reviewers will use the expectations agreed for that dimension: 90–100 means they are fully met with only minor issues; 75–89 means the main expectations are met but some follow-up is needed; 60–74 means they are partly met and substantial improvement is needed; below 60 means key expectations are unmet. Each score must include a brief reason referring to specific deliverables or collaboration records.

Phase performance score = Task Completion × 40% + Quality and Testing × 30% + Collaboration × 20% + Documentation and Demonstration × 10%.

Members will be assessed on their assigned responsibilities. For example, a designer provides prototypes and visual assets, a database engineer provides data definitions and rules, and a tester provides test cases, results, and defect records.

4.2 Assessment Process

1. Before work starts: Agree on the owner, deliverable, deadline, difficulty, and acceptance criteria.
2. At the weekly meeting: Show completed work and discuss blockers, defects, and changes to the plan.
3. At the end of a phase: Each member submits a self-assessment and their deliverables. An assigned peer reviewer proposes scores for the four dimensions and explains the evidence. The reviewer and Xiang Hong review the scores together, and Xiang Hong records the outcome and proposed improvements. Another member coordinates the review of Xiang Hong's work.
4. When a result is disputed: Review the evidence with an uninvolved member. If the project manager is involved, other members coordinate the review.

Peer feedback should refer to specific work, such as an interface review, a resolved integration issue, or a completed test report.

4.3 Actual Workload Contribution

Planned workload percentages and performance scores serve different purposes. The former describe the amount of work assigned; the latter assess completion, quality, and collaboration.

Before a task starts, its owner and reviewer agree on the expected effort and coordination required, then assign difficulty points:

Difficulty Points	Typical Scope
1	A small, self-contained deliverable, such as one icon revision or a focused documentation update
2	A feature or deliverable with several related steps, such as a page prototype, a module's data definition, or its test cases
3	Work spanning several modules or requiring substantial coordination, such as an export/deletion workflow or a cross-module integration review

Acceptance is 0 when no agreed milestone has been accepted, 0.5 when a halfway milestone defined before work starts has been completed and accepted, and 1 when all agreed acceptance criteria are met. The reviewer records the accepted deliverable and the reason for the level.

A task's workload points equal its difficulty multiplied by its acceptance level. A member's actual contribution ratio equals their accepted points divided by the team's total accepted points. No actual ratio will be calculated before work has been accepted.

The team will agree on how shared work is recorded before a task starts, so one deliverable is not counted in full for several members. This preliminary assessment plan will also be included in the opening presentation and refined through phase feedback.

5. Requirements Specification and Expected Deliverables

The companion requirements specifications describe the planned features, data access rules, exceptional cases, and acceptance criteria:

Our planned deliverables are a clickable prototype, the MoodSky WeChat mini program, a campus information administration interface, a test report, a user guide, and demonstration materials. Requirements changes will be reflected in the specification and project plan, with responsibilities reviewed alongside them.