Falcons — Assignment 3: Requirement Analysis

Contents

• Deliverables at a Glance

1. Team Division of Labor
2. Software Requirements Specification
3. Team Organization and Schedule
4. Team Collaboration
5. Key Points and Challenges
6. References

Deliverables at a Glance

1. Team Division of Labor

1.1 Team Organization

Falcons has 13 members and one team leader. The team is organised into six functional groups — Project Management, Product Requirements, Frontend Development, Backend Development, Algorithm, and Testing — so that every member owns a clear part of the requirements analysis work.

1.2 Division of Labor and Contribution

All 13 members share an equal estimated contribution for this assignment — about 7.7% each, totaling 100%. The rating is an estimate; the final proportion is adjusted by the team performance assessment.

2. Software Requirements Specification

Sports Buddy is a sports matchmaking platform for university students: it helps people who want to exercise find partners who match in time, skill level and location, and who can be relied on. The SRS in this assignment defines the student-facing web client, the backend service and the admin backend, and covers the complete flow of creating an activity, signing up, checking in and reviewing.

2.1 Document Links

The SRS was further improved from the previous assignment (V2.2 → V3.1). Both the required Word version and a PDF for easier reading are available in the team repository:

• Word (required): 需求规格说明书V3.1.docx
  

  需求规格说明书V3.1.docx 8.17M

• PDF (recommended): 需求规格说明书V3.1.pdf
  

  需求规格说明书V3.1.pdf 6.56M

• Requirements-analysis presentation: PPTX · PDF
  

  Falcons-Assignment3-Requirements-Analysis.pptx 1.35M

2.2 Document Structure and Coverage

The document follows the reference structure required by the assignment and the national SRS guide:

2.3 Key Artifacts

• Domain class diagram: 领域类图 (also provided as a version suited for document insertion)
• Interface prototypes (12 screens): assignment3/prototypes
• Implementation prototype / source code: src/

The full SRS is not repeated in the presentation; the presentation focuses on the project background, the development content (including the class diagram) and the plan execution.

Domain Class Diagram

Figure 1. Domain class diagram of Sports Buddy (User, Activity, Sign-up, Review, Reliability, etc.).

Interface Prototype Gallery

The 12 high-fidelity screens below cover the complete user journey: login → discovery → activity detail → creation → check-in → management → review → profile.

Figure 2. Overview of the 12 interface prototypes.

Figure 3. Login and registration.

Figure 4. Discovery home.

Figure 5. Activity list.

Figure 6. Activity detail (participant view).

Figure 7. Activity detail (organizer view).

Figure 8. Create an activity.

Figure 9. Check-in.

Figure 10. Manage an activity.

Figure 11. My activities.

Figure 12. My profile.

Figure 13. Another user's profile.

Figure 14. Review partners after an activity.

3. Team Organization and Schedule

3.1 Organization

The team uses a lightweight matrix structure: the team lead coordinates schedules and integration, while each functional group owns its deliverables. Tasks are tracked in folders of the shared GitHub repository and on the group task board.

3.2 Schedule

Each stage follows a one-week cycle; specific dates are adjusted according to the course arrangement and the teacher's instructions.

3.3 Responsibilities and Workload

Each member's specific responsibility is listed in the division-of-labor table in Section 1.2, and the workload proportion for this document task is 7.7% per member (equal share, adjusted later by the team performance assessment).

4. Team Collaboration

4.1 Task Allocation

At the start of the assignment, the team lead split the SRS into chapters and mapped them to the six functional groups. Every task had one owner and one reviewer, which avoided duplicated work and unclear responsibility.

4.2 Progress Synchronization

• A short online meeting at the beginning of each week confirmed the current progress and the next milestone.
• Completed items were marked on the task board; blockers were raised immediately in the group chat.
• The team lead tracked the critical path (SRS body → class diagram → prototypes → review) and re-assigned work when a part fell behind.

4.3 Document Collaboration

• The SRS was written chapter by chapter and merged by the product group, which kept one unified style and terminology.
• The Word document is the single source of truth; the PDF is exported from it for reading.
• All deliverables are stored in the shared GitHub repository under clear folders (assignment3/srs, assignment3/diagrams, assignment3/prototypes, assignment3/slides, assignment3/blog).
• Every member has write access to the organisation, so files can be uploaded directly, while the folder structure and the contribution guide (CONTRIBUTING.md) prevent files from being mixed up.

4.4 Communication

Daily coordination happens in the team chat group (QQ/WeChat); technical and document issues are discussed in the GitHub repository and in short online meetings. Questions that affect the whole team are decided in the group rather than in private chats.

4.5 Integration and Review

• Each chapter was reviewed by at least one member outside its authoring group.
• The testing member checked the SRS checklist (introduction, user scenarios, class diagram, prototypes, functional description, acceptance criteria, figures, formatting, style).
• The team lead performed the final integration: consistent product name, consistent figure numbering, and a final export of both Word and PDF.

5. Key Points and Challenges

5.1 Key Points

1. Traceability: every functional requirement is linked to a use case and to acceptance criteria, so the document can be checked item by item.
2. Consistency: the class diagram, the interface prototypes and the functional descriptions must describe the same system; terminology and figure numbering are therefore unified across chapters.
3. Reader perspective: the document was reviewed by members who did not write a chapter, to confirm that someone unfamiliar with the project can still understand what the software does.

5.2 Challenges and Solutions

6. References

1. Zou Xin. The Method of Construction.
2. GB/T 8567-2006 Computer Software Documentation Guide.
3. Assignment 3 reference SRS example (DES-RSA hybrid encryption), provided in the assignment post.
4. Team repository: Falcons-FZU-MU-SE-GROUP12/SportsBuddy