Assignment 3 | MoodSky Requirements Analysis

Contents

1. Project Background and Goals

MoodSky is a WeChat mini program for university students to record their moods. We want users to be able to leave a brief record even when they do not feel like writing a diary. Selecting a weather symbol is enough; tags and a short note are optional.

Two groups of features build on these entries. Personal review lets users revisit their records through a calendar, weather distribution, and timeline. Campus places and small optional tasks help users find somewhere suitable to go or choose something they feel like doing.

Entries are private by default. Weather symbols are a way to express feelings, not a mental health assessment. The campus weather display currently uses fixed simulated data and does not aggregate private entries. Anonymous discussion boards, public comments, messages from strangers, and mood rankings are outside the first release.

This assignment addresses three questions: when users would need each feature, how the system should handle normal and exceptional situations, and how the team will determine whether the implementation meets the requirements.

2. Team Responsibilities and Contribution Shares

The team has 12 members. Responsibilities follow the team allocation document. The table uses FZU student IDs.

2.1 Project Responsibilities and Planned Shares

The planned shares total 100%. We use the same allocation for the requirements document in this assignment.

Individual contribution share = points allocated to the member / total project points × 100%. Tasks are estimated by difficulty. Points for shared work are divided among contributors before being counted, so the same deliverable is not counted more than once. Actual contributions should be reviewed against deliverables, review records, and acceptance results.

2.2 Responsibilities for This Requirements Document

The document workload uses the same allocation as the project plan, totaling 100%. We review each member’s work through document revisions, deliverables, and review records.

3. Software Requirements Specification

3.1 Requirements Document and Presentation

The Software Requirements Specification (SRS) develops our earlier requirements into a shared reference for design, implementation, and testing. Its structure follows GB/T 9385—2008 and GB/T 8567—2006, the national standards for software requirements specifications and software documentation.

The SRS online version, Word/PDF copies, and presentation are linked in the information table at the beginning of this post.

The online version presents the complete SRS directly on GitHub, with a linked table of contents, readable text, tables, and embedded figures. The SRS is maintained in the assignment3 documentation directory of our GitHub repository. The Word document is the formal SRS submission; the PDF contains the same document for convenient reading. Both files retain their original Chinese content. On GitHub, use the download button if a file cannot be previewed.

The document covers the project background and scope, user roles and scenarios, architecture and class diagrams, interface prototypes, and the 24 functional requirements. It also defines input limits, permission rules, exceptional situations, and acceptance criteria. Each requirement retains its original ID so that developers and testers can refer to the same item. Chapter 3 explains the core objects and their relationships, Chapter 4 presents the interface designs, and Chapter 5 connects functions with acceptance and verification criteria.

Requirements Analysis Presentation
The 19-slide English presentation covers user scenarios, interface prototypes, business flows, the class model, system architecture, acceptance criteria, validation evidence, team responsibilities, and the implementation schedule. It supports the classroom presentation, while the SRS provides the detailed requirements and acceptance rules. The presentation retains the original Chinese interface screenshots; its titles, explanations, tables, and diagram labels are in English. The SRS Word and PDF files remain in Chinese.

Selected interface designs appear in Section 3.5. The front-end source directory contains the mini program code, which runs through WeChat Developer Tools. Development evidence is recorded in the October 15 integration report and Week 1 materials.

3.2 User Roles and Typical Scenarios

The requirements distinguish visitors, active student accounts, disabled accounts, and data operators. Visitors can browse permitted public content. Active students can manage their own entries and preferences. Disabled accounts have access only to necessary public content and restricted cleanup progress. Operators maintain campus information but cannot read private journals or WeChat identity mappings.

The server must determine identity and data ownership. For example, changing an entry ID in a request must not allow a user to read or delete another person's entry. Export and cleanup jobs require the same ownership checks.

Scenario 1: Leaving a quick record. A user opens Today, selects a weather symbol, and saves. Tags and text can remain empty. After a successful save, the page states that the entry is private. If the request fails, the page keeps the input and offers a retry.

Scenario 2: Editing or deleting an earlier entry. A user selects a date and edits the existing entry. Deletion requires confirmation. Once an entry is deleted, the calendar, statistics, timeline, and affected exports must also be updated. Each account may have at most one entry per date.

Scenario 3: Reviewing a month. A user opens Weather Universe to view the calendar, weather distribution, and entry details. Dates without entries remain blank rather than being filled as sunny. The system does not draw trend conclusions from too few records.

Scenario 4: Finding a suitable campus place. A user browses the place list before choosing filters, opening details, or starting navigation. Location is requested only when the user asks for it. Refusing permission must not prevent list browsing.

Scenario 5: Choosing a small activity without pressure. The system offers at most three tasks. Users can complete, replace, or skip them. Photos, location proof, and daily streaks are not required. Place and task pages remain accessible without first saving a journal entry.

These scenarios describe expected behavior. Formal acceptance still requires test records from the intended environment.

3.3 Functional Scope and Diagrams

The first release retains 24 requirements, UW3-F01 through UW3-F24, abbreviated below as F01–F24.

The class diagram shows relationships among accounts, entries, personal reviews, places, task history, and data management jobs. The architecture diagram shows the mini program, shared request entry point, cloud function domain services, and database. Both appear in Chapter 3 of the SRS.

Figure 1. MoodSky architecture and validation scope. Reported checks do not establish that all production services have been implemented.

Figure 2. Core objects and relationships in the first-release design. The diagram does not establish that every object has cloud persistence.

3.4 Functional and Interface Acceptance

Each functional requirement has a corresponding test ID, such as F01 and T01. A test record must include preconditions, input, steps, expected and actual results, version, environment, evidence, and reviewer.

Interface acceptance also covers empty data, loading failures, permission refusal, and processing states. For example, Campus should explain what the user can still do when there are no matching places or the map is unavailable.

3.5 Actual Mini Program Screenshots

The following screenshots show the implemented MoodSky mini program running in the WeChat Developer Tools simulator, captured on October 17, 2026. They retain the original Chinese interface labels. These are actual application screenshots in local demonstration mode; displayed records and campus places are demonstration or synthetic data. They do not establish production cloud persistence, real account integration, or verified campus service information.

Figure 3(a). Today: weather selection, private recording, and the entry to optional tags and text.

Figure 3(b). Campus: the place list in synthetic demonstration mode. Place details and opening information remain unverified.

Figure 3(c). Weather Universe: the personal calendar and review entry points in the local demonstration.

Figure 3(d). Me: preferences, saved places, task history, privacy and data, and help entry points. The screen identifies the account as a local demonstration account.

Figure 4. The implemented private record form: weather selection, optional tags, an optional note, and the save action in local demonstration mode.

4. Implementation Progress and Validation

The actual screenshots in Section 3.5 show the local simulator interface captured on October 17, 2026. The implementation summary below retains the earlier report scope. Existing development work includes the four-page structure, shared validation and request handling, the Today in-memory demonstration, and parts of the data management design. Production account integration, cloud journal operations, and complete workflows still need development.

The results below summarize the October 15, 2026 integration report and refer to the environments recorded there.

See the integration report. The relevant PR determines whether an individual branch has been merged. Simulated exports and cleanup do not establish that real account data can be exported or deleted.

User interview samples, original records, and findings still need to be consolidated. Usability goals, including time to create a first entry and clarity of navigation, require testing with actual users.

5. Team Organization and Collaboration

5.1 Task Allocation and Handoffs

Responsibilities are divided across journal, review, campus, tasks, and data management. Work affecting multiple modules requires joint review. Deleting an entry, for example, affects Today, review results, database state, and existing exports, so front-end, back-end, database, and testing members need to check it together.

Week 1 handoff materials are organized by member and list inputs, tasks, expected deliverables, and review conditions. Preparing a handoff is different from completing the assigned work. Progress is checked against task records, files, and review results. Decisions about requirements and interfaces should be recorded in the relevant tasks and documents after discussion.

5.2 Collaborative Maintenance

Code changes use Issues, task branches, and Pull Requests (PRs). Changes are reviewed and automated checks must pass before merging into the main branch. Changes to shared interfaces, the database, navigation, or access control require review by the relevant owners.

Documents use consistent requirement IDs, field names, and status terms. When an interface or responsibility changes, the SRS, team allocation, data dictionary, and test tables need to be checked together.

5.3 An Integration Example

During Week 1 integration, Xiang Yu's new work was on a feature branch and consisted of five documents covering database, export, cleanup, and recovery. Integration included aligning fields, error codes, access rules, and version conventions with the existing contracts while retaining the original PR's contribution and review history.

The process also revealed an ordering problem. The workflow was revised to review and resolve member PRs first, then update the main branch and integrate a release. Designs that have not been deployed remain labeled as designs. H03 failures remain in the report for subsequent fixes and verification. Details are recorded in the integration report.

6. Main Requirements Analysis Challenges

6.1 Turning Feature Names into Testable Requirements

“Support mood recording” is too broad to guide implementation or testing. We break it down into questions: Is weather mandatory? Can text be empty? How are repeated submissions handled? Is input retained after a failed save? Each answer needs a corresponding test condition.

Review statistics also need precise rules. If a user records ten days in a month, those ten days should be the denominator for weather distribution. That rule is more useful to developers than simply requiring a statistics chart.

6.2 Separating Private Entries from Campus Displays

Weather symbols appear in both private entries and the campus display, which could suggest that private records are public. The first release therefore uses fixed simulated campus weather information and labels it accordingly. Private entries are not published or included in public statistics, and maintaining campus data does not grant operators access to journals.

6.3 Handling the Consequences of Deletion

A success message on the page does not show that every related result has been updated. Calendars, distributions, timelines, and exports may still contain old information. The SRS therefore requires related views to update and affected old exports to become invalid after deletion.

Repeated submissions, version conflicts, and cleanup retries also require coordination between services and the database. H03 has recorded failures, so these behaviors still need verification in the actual cloud environment.

6.4 Distinguishing Prototypes from Working Features

High-fidelity screenshots explain layouts and entry points, but they cannot establish cloud persistence, access isolation, or account closure. The blog and SRS distinguish design prototypes, local demonstrations, and cloud test results, with the relevant environments identified.

6.5 Keeping the First Release Manageable

Starting all 24 requirements at once could leave many visible entry points without working core operations. The next priority is real account integration and cloud saving, editing, and deletion. Review, campus, and task features follow, while export and account cleanup continue under the agreed constraints. Public comments and interactions with strangers remain outside scope to limit development and moderation work.

7. Schedule and Next Steps

Future dates depend on development and acceptance results. The immediate priority is cloud journal operations and account permissions. Interview materials also need to be completed so usability judgments can be based on user feedback.