group 4——gamer 2——assignmment2

Gamers_2 2026-10-11 23:58:11

Gamers2 · 拾光 FindBack — Assignment 2: Team Formation and Topic Selection

Item	Content
Course	EE308FZ Software Engineering (2026 Fall)
Where are the assignment requirements	Second assignment — Team up and Topic selection
Team Name	Gamers2
Project Name	拾光 FindBack — a campus lost-and-found platform with image-based smart matching
CSDN Team Account	Gamers_2 (already added to the class community)
GitHub Organization	To be created — the team repository will be set up in milestone M2 (Oct 19 – Nov 1)
Assignment Objective	Form the team and lock the semester topic; deliver a milestone-based project plan, a clear division of labor with workload ratios, a team performance-assessment scheme, an NABCD topic analysis, and the Requirements Specification Document as an attachment
Other References	The Method of Construction (Zou Xin), Chapter 8 "Requirements"; the NABCD requirement-analysis model; IEEE 830 / GB/T 8567 (software requirements specification)

1. Team Introduction

1.1 Team Name & Project Name

Team Name: Gamers2 — our CSDN team account is Gamers_2.

Gamers2 is the name our team has used since we started working together. It carries the "player" mindset we bring to the semester: we treat the project as a long game rather than a sprint — read the map first, keep playing after a lost round, and win by coordination instead of by one lucky move. It is short, easy to remember, and it is also the nickname of our CSDN team account.

Project Name: 拾光 FindBack — a campus lost-and-found platform with image-based smart matching.

The project name carries the idea we actually care about. The Chinese name 拾光 is a deliberate play on words on 时光 ("time"): 拾 means "to pick up (what was lost)", and 光 means "light" — the light that shows an item the way home. Put together, 拾光 means picking up what was lost and lighting its way back. FindBack says the same thing in one word: our product does not stop at finding, it goes all the way to back to its owner.

That is exactly what our project is about. On campus, things are lost every day — campus cards, keys, earphones, umbrellas, water bottles, USB drives. The items are usually found; what is missing is a channel that actually connects the loser and the finder and then proves who the real owner is. Group chats bury the message in five minutes; the pile of unclaimed items at the service desk just keeps growing.

Project Slogan:

Pick up what was lost. Light the way back.
拾起遗失，光照归途

Team CSDN account: our team account is Gamers_2. CSDN generated the URL slug 2603_97191685 automatically, and the account nickname Gamers_2 matches our team name. The account has been registered and added to the class CSDN community, and the teaching assistant has been notified in the group chat so the team can be admitted.

1.2 Team Members

14 members in total, with 1 team leader. We are organised into six role groups: Project Management, Product Requirements, Frontend Development (incl. UI/UX design), Backend Development, Algorithm, and Testing.

Roster (names, student IDs and CSDN profiles):

#	Name	Student ID	Role Group	CSDN
01	Sun Zikun (Team Lead)	832401315	Project Management	bluejay33
02	Luo Yuhan	832401313	Backend Development / DevOps	Zarvik188
03	Zhou Debin	832401329	Product Requirements	832401329周德斌
04	Zheng Ziyang	832401327	Product Requirements	832401327 郑子阳
05	Wu Junjia	832401223	Frontend Development (UI/UX)	832401223吴浚嘉
06	Zheng Zongyuan	832401328	Frontend Development	shizhong233
07	Zuo Xiangrong	832401230	Frontend Development	XXXz602
08	Li Jianhang	832401210	Frontend Development	832401210_李健航
09	Liu Peikun	832401213	Backend Development	832401213 刘培坤
10	Wang Qiushi	832401317	Backend Development	832401317王秋实
11	Xiao Zhengyu	832401318	Backend Development	8324018 肖正宇
12	Liu Junye	832401212	Algorithm	832401212 刘君烨
13	Xu Yichao	832401319	Testing	832401319徐一超
14	Zhou Shengdong	832401330	Testing	shade-afk

Member 01 | Sun Zikun — Team Lead

Student ID: 832401315
CSDN: bluejay33
Personality: Responsible, well organised and calm under pressure; good at communication and coordination, focused on keeping a steady pace and following tasks through to the end
Technical Expertise: Scheduling and progress control, project management; JavaWeb backend development and MySQL database design
Hobbies: Basketball, running, board games
Role: Project Management (Team Lead)
Slogan: Never stop.

Member 02 | Luo Yuhan

Student ID: 832401313
CSDN: Zarvik188
Personality: Well organised and punctual; the team's gatekeeper of process and configuration
Technical Expertise: Object storage and image pipelines, Git / GitHub Actions, Docker and Nginx deployment, documentation and configuration management
Hobbies: Mechanical keyboards, hiking, tidying things up
Role: Backend Development / DevOps
Slogan: If it can be automated, do not rely on memory.

Member 03 | Zhou Debin

Student ID: 832401329
CSDN: 832401329周德斌
Personality: Empathetic and patient in interviews; keeps asking "why" until the real need shows up behind the stated one
Technical Expertise: Axure / Figma prototyping, use-case and activity modelling, SQL data analysis
Hobbies: Podcasts, mystery novels, campus research
Role: Product Requirements
Slogan: Ask why before how.

Member 04 | Zheng Ziyang

Student ID: 832401327
CSDN: 832401327 郑子阳
Personality: Optimistic and eager to learn, proactive and enterprising
Technical Expertise: Questionnaire design and data analysis, page layout, functional and competitor research
Hobbies: Computer games, photography
Role: Product Requirements
Slogan: Curiosity first, conclusions later.

Member 05 | Wu Junjia

Student ID: 832401223
CSDN: 832401223吴浚嘉
Personality: Detail-oriented, with a healthy obsession about pixel-level alignment; communicates directly and can hold the line against "just ship it"
Technical Expertise: UI/UX design, Figma component libraries and design systems, usability testing
Hobbies: Photography, exhibitions, collecting typefaces
Role: Frontend Development (UI/UX design)
Slogan: Usable first, beautiful always.

Member 06 | Zheng Zongyuan

Student ID: 832401328
CSDN: shizhong233
Personality: Action-oriented — turns an idea into a clickable page the same day; enjoys writing technical notes
Technical Expertise: Vue 3 / TypeScript / Vite, WeChat mini program, frontend engineering and performance optimisation
Hobbies: Baking, street dance, writing on CSDN
Role: Frontend Development
Slogan: Ship it first, then make it elegant.

Member 07 | Zuo Xiangrong

Student ID: 832401230
CSDN: XXXz602
Personality: Patient and meticulous; willing to take on the edge cases and compatibility problems nobody else wants
Technical Expertise: Component encapsulation, image cropping/compression and upload, responsive layout and accessibility
Hobbies: Pour-over coffee, cycling, indie games
Role: Frontend Development
Slogan: Every edge case is somebody's real day.

Member 08 | Li Jianhang

Student ID: 832401210
CSDN: 832401210_李健航
Personality: Outgoing and curious, the one in the team most willing to raise a problem early instead of sitting on it
Technical Expertise: Mini-program development, ECharts data visualisation, WebSocket messaging
Hobbies: Badminton, board games, video editing
Role: Frontend Development
Slogan: Blocked? Say it out loud.

Member 09 | Liu Peikun

Student ID: 832401213
CSDN: 832401213 刘培坤
Personality: Rational and calm; prefers to draw the data model before writing code and insists on "API contract first"
Technical Expertise: Spring Boot / MyBatis-Plus, MySQL indexing and transactions, RESTful API design
Hobbies: Go, hiking, watching conference talks
Role: Backend Development
Slogan: Data consistency is the ground floor of trust.

Member 10 | Wang Qiushi

Student ID: 832401317
CSDN: 832401317王秋实
Personality: Quiet but dependable; rarely needs a second reminder, and writes things down so others do not have to remember them
Technical Expertise: Authentication and authorisation (JWT / RBAC), logging and monitoring, admin-side APIs
Hobbies: Calligraphy, night running, note-taking
Role: Backend Development
Slogan: Write it clearly, not just plenty.

Member 11 | Xiao Zhengyu

Student ID: 832401318
CSDN: 8324018 肖正宇
Personality: Pragmatic and performance-minded; measures before guessing
Technical Expertise: Redis caching and distributed locks, message queues, scheduled tasks, full-text search
Hobbies: Music, gaming
Role: Backend Development
Slogan: Make it fast, make it stable.

Member 12 | Liu Junye

Student ID: 832401212
CSDN: 832401212 刘君烨
Personality: Curious and evidence-driven; prefers to verify an intuition with real data rather than argue about it
Technical Expertise: Python, image feature extraction and vector retrieval (CLIP / ResNet + FAISS), text similarity and ranking, offline evaluation of match quality
Hobbies: Astronomy, Kaggle, sudoku
Role: Algorithm
Slogan: Make the match explainable, not lucky.

Member 13 | Xu Yichao

Student ID: 832401319
CSDN: 832401319徐一超
Personality: Rigorous and detail-driven; zero tolerance for "it works on my machine"
Technical Expertise: Functional testing and test-case design, Postman / JMeter, defect lifecycle management, release acceptance
Hobbies: Sports, listening to music, detective novels
Role: Testing
Slogan: Quality is not an act, it is a habit.

Member 14 | Zhou Shengdong

Student ID: 832401330
CSDN: shade-afk
Personality: Practical and calm under pressure; enjoys breaking things on purpose to see how they fail
Technical Expertise: Regression testing, test-data preparation, device compatibility matrix, bug reporting and triage
Hobbies: Basketball, films, tinkering with gadgets
Role: Testing
Slogan: If nobody can break it, we have not finished testing.

1.3 Team Vision

Why we chose this topic. Campus lost-and-found today has a strange property: the finding is rarely the problem — the returning is. Group chats have no search, no matching and no persistence, so a "found" post and a "lost" post about the same pair of earphones can sit in the same group for a week without ever meeting. Service-desk piles are authoritative but passive: nobody notifies you, nobody can search by photo, and eventually unclaimed items are thrown away. We want to close that loop with software, and image matching is the piece that makes the loop actually close — because the most natural way to describe a lost item is a picture, not a paragraph.

Our vision in three moves: 不沉底 · 讲凭据 · 留痕迹.

Nothing gets buried (不沉底): publishing takes about 30 seconds, and the post lands in one structured pool with a photo, a category, a time and a place. It can still be searched weeks later, instead of sinking down a chat you cannot search.
Proof, not promises (讲凭据): image retrieval, text similarity and time-and-place filtering produce a ranked candidate list; hidden feature questions and a proof photo then decide who really owns the item. Whoever asks first is not automatically the winner.
A return you can see (留痕迹): both sides confirm the handover, the case closes with a timeline, and the finder's credit is recorded. Doing the right thing costs almost nothing, and it does not go unnoticed.

How far we intend to get. We do not aim to be big and all-inclusive. By the end of this semester we want one campus to be genuinely usable: a runnable MVP (publish, browse, search, smart matching, notification, ownership verification, handover confirmation, credit, admin console) validated by a real beta test with 30–50 students, with the recovery rate measured before and after. If time allows, we add subscription alerts, a "where things get lost" hotspot map for campus service improvement, and anonymous handover via service points.

Where it can be used. The same mechanism transfers well beyond one campus: other universities, parks and scenic spots, shopping malls, railway stations and airports, and any property-management or community scenario where "someone lost it, someone picked it up" happens every day. Inside the campus itself it can plug into the security office (保卫处) and logistics service points, turning an offline pile of unclaimed items into a searchable, notifiable, verifiable service.

1.4 Team Photo

1.5 Team Logo

The crest is a shield, and that is the first thing we want it to say: from the moment a found item is posted until it is handed back, we take custody of the case and we do not drop it. Inside the shield stands a hooded figure — the everyday helper on campus, the person who picks something up and does the right thing without expecting anything in return, and who usually stays anonymous. A magnifier is held over the figure's eye: the search itself, plus the promise that a case is looked at again and again rather than filed away. Inside the lens burns a sharp red eye: attention that never blinks, on every single item, however small.

2. Project Introduction

2.1 Background & Reasons

Almost every student has experienced this sequence at least once: you realise your campus card / keys / earphones / umbrella / water bottle / USB drive is gone; you retrace your steps; you post "寻物启事" in three class groups and two club groups; the message is buried within minutes; you refresh the lost-and-found pile at the teaching-building service desk and find a stack of items with no photos and no dates; a week later you give up and buy a replacement — while the person who picked your item up has already stopped checking.

The pain has four distinct parts, and they need different fixes:

Information cannot be searched: chat messages are a stream, not a database. There is no category, no place filter, no "show me everything found near the canteen last Tuesday".
Lost posts and found posts never meet: the two sides describe the same object in different words, and nobody cross-checks them. Automated image/text matching is exactly what is missing.
No way to verify ownership: "that's mine" is unfalsifiable, so finders either hand items to the wrong person or stop bothering; genuine owners get asked to "prove it" with no mechanism.
No closure and no incentive: nothing records that the item was returned, so a helpful finder gets no credit and a no-show costs nothing.

[To be filled with real data in M1] We deliberately do not invent survey numbers here. In milestone M1 (Oct 12 – Oct 18) we will run a campus survey and short interviews (target: 120 valid responses plus 8–10 in-depth interviews) to quantify how often students lose items, how long they search, how they currently get them back, and how much they trust a "found item" post. The Requirements Specification Document will be updated with those real numbers.

2.2 Project Description

拾光 FindBack is a campus lost-and-found platform with image-based smart matching. It helps the person who lost something and the person who found it meet each other automatically, verifies that the item goes to its real owner, and records the handover so that the loop closes.

Core features:

Feature	Description
Publish Lost / Found Item	Post a lost or found item in ~30 seconds: photo(s), category, short description, time and place
Smart Matching	Image feature retrieval + text similarity + time/place filtering rank candidate matches between a new post and the existing pool
Match Feed & Notification	Both sides are notified of new candidates; the match list shows a score and the reasons behind it
Ownership Verification	Hidden feature questions (colour, marks, serial, contents) plus a proof photo; optional service-desk check for high-value items
Handover Confirmation	Two-way confirmation of handover, suggested pickup points on a map, and a timeline record of the whole case
Credit & Reputation	Honest posting, no-shows and false claims are recorded and affect visibility and matching priority
Search & Browse	Filter by category, place, date and status; a campus hotspot map shows where items are most often lost
Subscription & Alerts	Subscribe to categories or places and get notified when a new post matches
Privacy Protection	Automatic masking of ID photos and card numbers, contacts hidden until a match is accepted, in-app messaging instead of exposing phone numbers
Admin Console & Dashboard	Moderation, category management, abuse reports, and metrics such as recovery rate and median time-to-return

Tech stack (initial, to be confirmed in the design phase): Vue 3 + TypeScript + Vite and a WeChat mini program for the client; Spring Boot + MyBatis-Plus + MySQL + Redis for the backend; object storage for photos; a Python (FastAPI) algorithm service using CLIP/ResNet image embeddings with FAISS vector retrieval, plus text similarity for descriptions; GitHub + GitHub Actions for CI/CD and Docker + Nginx for deployment.

2.3 NABCD Analysis

N — Need

Students lose things often and get them back rarely. The channels that exist cannot do the job: group chats bury posts, service-desk piles are passive and unsearchable, and nothing cross-checks a "lost" post against a "found" post. The cost is concrete — replacement money, a re-issued campus card, a week of anxiety, and unclaimed items that end up in the bin. What is needed is a lightweight, searchable, image-aware, verifiable channel that both sides actually use.

A — Approach

Build a campus lost-and-found platform whose core loop is: publish → automatic match → ownership verification → handover confirmation → credit. We stabilise the basic loop first (publish/browse/search/match/notify/handover) and only then upgrade "can find something similar" into "can find the right item and prove it": image feature retrieval plus text similarity for matching, hidden feature questions plus proof-photo flow for verification, and a credit record for durable participation. A pilot campus and cooperation with service points keep the product anchored in real offline handover behaviour instead of being an online-only bulletin board.

B — Benefit

For the person who lost something: a much higher chance of getting it back, in hours instead of weeks, with zero cost. For the person who found something: one post instead of chasing five group chats, a clear way to hand it over, and credit for doing the right thing. For the campus: fewer unclaimed items thrown away, less re-issuing and replacement waste, cleaner information than chat spam, and — through the hotspot map and recovery-rate metrics — actual evidence about where things get lost that the logistics and security departments can act on.

C — Competitors

Competitor	Strength	Our Difference
WeChat / QQ group chats	Zero barrier; everyone already uses them	Posts sink within minutes; no search, no categories, no matching, no verification. We provide a structured, searchable, image-matched pool
Campus forums / confession walls	Wide reach, casual traffic	Messy information; no structured fields, no sign-up/claim status, no closed loop. We track a case from post to handover
Offline lost-and-found desks / piles (服务台, 保卫处)	Authoritative; physical custody is trustworthy	Passive: no notification, no photo search, no way to reach the owner; items expire. We make the pile searchable and push matches to both sides
Generic second-hand / campus marketplace apps	Large user base, mature chat and payment	Money-oriented; no lost-and-found flow, no ownership verification, no handover record
Existing lost-and-found mini programs	Solve "posting"	Mostly electronic bulletin boards: keyword search only, no image matching, no verification, no credit. Image-based matching plus verification plus handover closure is our differentiator

D — Delivery

Phase 1 (this semester): a runnable MVP on one pilot campus — publish, browse/search, image-and-text matching, notification, ownership verification, handover confirmation, credit and admin console — validated with a 30–50 student beta test and measured by recovery rate and median time-to-return. Phase 2: subscription alerts, hotspot map, service-point collaboration, mini-program release and push notifications. Phase 3: extend to neighbouring universities, parks and transit hubs, generalising the matching service into a reusable "lost-and-found" component. Start from the everyday campus cases — campus cards, keys, earphones, umbrellas, water bottles, USB drives — then extend to high-value items with a stricter verification and custody flow.

The full topic-selection presentation is attached as 《选题汇报-NABCD-拾光FindBack.pptx》 (8-minute talk, presenter: Zhou Debin).

3. Team Project Plan

3.1 Development Milestones (6 Phases)

We follow the standard software-engineering process and split the semester into six phases, each with explicit deliverables and an exit criterion. Dates are planned and will be adjusted dynamically against the course schedule and the teacher's arrangements.

Phase	Time (planned)	Main Tasks	Milestone / Deliverable
0 Team Formation & Topic	By Oct 11	Team up (14 members), name the team, choose the topic, NABCD analysis, draft the performance-assessment scheme, register the CSDN team account and join the class community	Team blog, topic PPT, Requirements Specification Document v0.9
1 Requirements Analysis	Oct 12 – Oct 18	Campus survey and interviews (target 120 responses + 8–10 interviews), walk through existing channels, use-case analysis, scope the MVP, freeze the requirement list with priorities	Requirements Specification Document v1.0, survey report
2 Design	Oct 19 – Nov 1	High-fidelity prototyping, tech selection, architecture and database design, API documentation, repository and collaboration rules, feasibility spike on image matching	Prototype, architecture design document, API document
3 Iterative Development	Nov 2 – Nov 29	Three iterations — It.1 (Nov 2–9): login, profile, publish lost/found, browse and search; It.2 (Nov 10–19): image upload pipeline, matching service, match feed and notifications; It.3 (Nov 20–29): ownership verification, handover confirmation, credit, hotspot map, admin console	A runnable, demoable version at the end of every iteration
4 Testing & Beta	Nov 30 – Dec 13	Integration testing, performance and security checks, bug fixing, invite 30–50 students to a beta test, collect and triage feedback	Test report, beta feedback summary
5 Wrap-up & Showcase	Dec 14 – Dec 27	Pilot run, data analysis (recovery rate, time-to-return, match accuracy), documentation archive, final demo preparation	Final version, project summary, showcase materials

3.2 Rhythm Principles

MVP first, intelligence later. Matching quality is improved iteratively; the publish → match → verify → handover loop must be usable before any algorithm tuning starts.
Every iteration is demoable. A review meeting is held at the end of each iteration, where completion is checked against the exit criteria and unfinished items are carried over openly.
Keep buffer time. The plan reserves buffer for requirement changes, image-matching uncertainty (a genuine technical risk) and unexpected delays, especially in phase 3.

3.3 Iteration & Collaboration Routine

Weekly stand-up: Monday 20:00, 25 minutes — what was finished, what is planned, what is blocking; minutes are archived.
Iteration review (at the end of every iteration): demo the running build, accept or carry over against the exit criteria, publish the performance record.
Task board: GitHub Projects; tasks estimated in story points (1/2/3/5/8); an owner and a due date for every task.
Docs in the same repository: all deliverables are committed with the code; every push triggers a build and check through GitHub Actions.

4. Project Division of Labor

4.1 Group Overview

Group	Members	Main Responsibilities
Project Management	Sun Zikun (Team Lead)	Scheduling, coordination, risk and progress tracking, external communication with the teacher and TA
Product Requirements	Zhou Debin, Zheng Ziyang	User research, use cases and requirements specification, prototyping, acceptance criteria
Frontend Development	Wu Junjia, Zheng Zongyuan, Zuo Xiangrong, Li Jianhang	UI/UX design, pages and interaction implementation, mini program, visualisation and messaging client
Backend Development	Luo Yuhan, Liu Peikun, Wang Qiushi, Xiao Zhengyu	APIs, database, caching and search, image storage pipeline, authentication, deployment and CI/CD
Algorithm	Liu Junye	Image feature retrieval, text similarity and ranking, match-quality evaluation
Testing	Xu Yichao, Zhou Shengdong	Test cases, defect management, release acceptance, regression and beta-test coordination

4.2 Division of Labor for Assignment 2 (this assignment)

Student ID	Work Description	Contribution
832401315	Formed the team and led role assignment; wrote the milestone plan and the collaboration routine; hosted the topic-selection review; reviewed and merged this blog	9%
832401313	Set up the GitHub organisation, repository structure and documentation templates; registered the CSDN team account and applied to join the class community	7%
832401329	Led the NABCD analysis and the 8-minute topic presentation; drafted the Requirements Specification Document outline; prepared the on-stage script	8%
832401327	Ran the preliminary desk research on campus lost-and-found channels; collected competitor screenshots; designed the survey to be launched in M1	7%
832401223	Set the visual style of the topic slides and of the product prototype; produced the layout and icon set for the blog	7%
832401328	Frontend feasibility check (Vue 3 + mini program); built the clickable demo pages used during the presentation	7%
832401230	Evaluated the image upload/cropping/compression path in the mini program; verified the 30-second publishing flow on real devices	7%
832401210	Built the presentation demo for the match feed and notification; produced the visual charts used in the slides	7%
832401213	Drew the initial architecture and database concept model; wrote the "data requirements" part of the SRS draft	8%
832401317	Designed the account, role and privacy scheme (masking of ID photos and card numbers); wrote the "non-functional requirements – security and privacy" part of the SRS draft	7%
832401318	Studied the image storage, caching and search approach; estimated the cost and performance envelope for the matching service	7%
832401212	Ran the feasibility spike on image feature retrieval and text similarity; defined the match-quality metrics; wrote the matching chapter of the SRS draft	8%
832401319	Reviewed the requirement list for testability; wrote the acceptance criteria and test points; checked the slides and blog for consistency	6%
832401330	Prepared the test data set and device-compatibility matrix; ran the regression pass on the presentation demos and the blog tables	5%
Total	—	100%

4.3 Semester Contribution Ratio (Estimated)

The ratios above are also our estimated semester contribution ratio. They are estimates, not final grades: the actual ratio is recalculated after each iteration from the performance-assessment results described in Section 5 and published to the whole team, so that whoever contributes more is credited more.

5. Performance Assessment

Goal: make contribution visible, measurable and appealable, so that neither "free riding" nor "quiet contribution nobody notices" survives in this team. The full assessment sheet is embedded in the topic-selection presentation (Slide 13).

5.1 Objective

Align contribution with responsibility, and encourage collaboration rather than internal competition. The assessment is not a ranking exercise; it exists to correct unfair distribution and to make late-stage contribution ratios defensible with evidence.

5.2 Dimensions & Weights

Dimension	Weight	Basis of Evaluation	Data Source
Task Completion & Quality	40%	Whether board tasks are completed on time, on scope and accepted by the reviewer	Task board completion rate, iteration review records
Code / Document Quality	20%	Code review conclusions, documentation review, rework and defect density	Merge-request reviews, test defect records, doc reviews
Collaboration & Communication	15%	Meeting participation, response timeliness, willingness to unblock others, quality of hand-off	Meeting sign-ins, weekly report timestamps, peer feedback
Attendance & Punctuality	10%	Stand-up and review attendance, on-time delivery, advance notice when unavailable	Sign-in sheets, task due-date records
Peer Review	15%	Anonymous mutual rating at the end of each iteration	Peer review form (highest and lowest dropped)

Assessment cycle: once at the end of each iteration (three iterations in phase 3); the final individual contribution ratio is based on the cumulative results across all iterations.

5.3 Scoring Method

Individual score = Σ (dimension score × weight), out of 100. Tiers:

90 and above — Excellent (A)
75–89 — Good (B)
60–74 — Pass (C)
Below 60 — Needs Improvement (D)

Contribution ratio: contributionᵢ = scoreᵢ ÷ Σ score × 100%, rounded to one decimal place and published by the team lead within 48 hours after each iteration review.

5.4 Fairness & Anti-Gaming Mechanisms

Commit count is never used as a standalone metric, so nobody splits commits to inflate the number.
Tasks are weighted by difficulty and effort, not compared by sheer quantity — a hard two-hour algorithm spike is not worth less than four trivial page tweaks. Workload differs across roles and the weighting reflects that.
Peer review is anonymous, and the average is taken after dropping the highest and lowest scores, to reduce both favouritism and personal grudges.
Evidence over memory: every score must point to a record (a merge request, a document, a meeting minute); unsupported scores are not accepted.
Red lines — an automatic zero for the iteration: disappearing without notice (7 consecutive days of no response to tasks or meetings without prior leave); falsifying workload (staged commits unrelated to the task, claiming someone else's work, ghost-writing); academic misconduct (plagiarised code or documents, fabricated research data). A red-line case is reported to the teacher and the TA.

5.5 Feedback & Appeal

A member who disagrees with an assessment may appeal to the team lead within three days of the announcement; the whole team discusses and re-evaluates if necessary, and the conclusion is recorded in writing.
A member rated "Needs Improvement" for two consecutive iterations has a one-to-one talk organised by the team lead to analyse the causes together and adjust the task arrangement; if there is still no improvement, the division of labor is revisited with the teacher informed.
Every weekly report, meeting minute, review record and appeal conclusion is archived in docs/ and is the only basis for the final contribution ratio.

5.6 Application of Results

The performance record is the primary basis for the final individual contribution ratio of the course project, and an important reference for the final course grade. It is also used to decide who presents which part at the final showcase, so that the people who built a feature are the ones who explain it.

6. Requirements Specification Document

The Requirements Specification Document is submitted as an attachment to this blog: 《需求规格说明书-拾光FindBack-v1.0.docx》 (to be updated to v1.1 after the M1 survey).

Document number: FB-SRS-2026-V1.0 · Version: v0.9 draft attached here (dated 2026-10-11), superseded by v1.0 at the end of M1.

Contents of the document:

Introduction — purpose, scope, definitions and acronyms, references, overview.
Overall Description — product perspective, product functions, user characteristics (loser / finder / service-point staff / administrator), operating environment (mini program + web admin), design constraints and assumptions.
Functional Requirements — 42 requirements at feature level with MoSCoW priorities (21 Must, 16 Should, 5 Could) and acceptance criteria, covering publishing, matching, verification, handover, credit, search, subscription, privacy and administration.
Non-functional Requirements — performance (match response P95 < 1.5 s for a 10k-item pool; image upload < 3 s on 4G), security and privacy (masking of ID photos and card numbers, contacts hidden until a match is accepted, encrypted transport), availability, compatibility (iOS/Android WeChat mini program, Chrome/Edge web admin), maintainability and compliance.
Business Rules — verification before handover, high-value item custody flow, no-show and false-claim handling, data retention for unclaimed items.
Data Requirements — entity-relationship model (user, item, photo, match, verification, case, credit record, notification), key attributes and relationships.
Interface Requirements — REST API overview (OpenAPI), object-storage photo pipeline, matching-service interface.
Traceability Matrix — bidirectional mapping between the 41 use cases and the functional requirements.

Feature overview (details in the attachment):

ID	Feature	Priority	Milestone
FR-01	Account registration, login and campus identity	M (Must)	It.1
FR-02	Publish lost item	M (Must)	It.1
FR-03	Publish found item	M (Must)	It.1
FR-04	Browse, filter and keyword search	M (Must)	It.1
FR-05	Image upload pipeline (crop / compress / mask)	M (Must)	It.2
FR-06	Image-based candidate matching	M (Must)	It.2
FR-07	Text similarity and time/place re-ranking	M (Must)	It.2
FR-08	Match feed with score and explanation	M (Must)	It.2
FR-09	Match notification (in-app / subscription message)	M (Must)	It.2
FR-10	In-app messaging between the two sides	S (Should)	It.2
FR-11	Ownership verification (feature questions + proof photo)	M (Must)	It.3
FR-12	Handover confirmation and case timeline	M (Must)	It.3
FR-13	Credit and reputation record	S (Should)	It.3
FR-14	Admin console, moderation and abuse reports	S (Should)	It.3
FR-15	Dashboard: recovery rate, median time-to-return, match accuracy	S (Should)	It.3
FR-16	Lost-item hotspot map	C (Could)	It.3
FR-17	Category/place subscription alerts	C (Could)	It.3
FR-18	Auto-tagging suggestions from the description (LLM-assisted)	C (Could)	It.3