Gamers2 拾光 FindBack — Assignment 3: Requirement Analysis

Item	Content
Course	EE308FZ Software Engineering 2026 Fall — course community
Assignment requirement	Third assignment — Requirement Analysis
Team name	Gamers2, group 4 of the course
Project name	拾光 FindBack — a campus lost-and-found platform with image-based candidate matching
Team account	Gamers_2
Previous assignment	Second assignment — team formation and topic selection
Goal of this assignment	Build on the previous requirements draft to complete user scenarios, a UML class model, interface prototypes and verifiable requirements, delivering the SRS, the requirement-analysis presentation and this blog post
Current SRS	v1.3, FB-SRS-2026-V1.3, 18 October 2026; cross-reviewed within the team, awaiting course review
References	Chapter 8 of The Method of Construction (Zou Xin), GB/T 9385-2008, GB/T 8567-2006, IEEE 830-1998, the assignment-2 materials and the frontend feasibility assessment

We want a lost item on campus to move from "someone posted about it" to "the item actually went back". This requirement analysis follows the loop of publishing, candidate matching, evidence verification, offline handover and two-sided confirmation, and states who performs each step, how exceptions are handled, and what evidence finally counts as acceptance.

This round produced a nine-chapter SRS and a 25-slide presentation (15 spoken slides, 3 appendix slides, 7 backup slides), covering 8 user scenarios, 14 core classes, 12 interface prototypes, and the acceptance and traceability links for 42 functional requirements. Product development, real user research and pilot validation proceed on the following plan; the items, scores and statistics shown in the prototypes are illustrative only.

Contents

目录

1 Team division of labour and contribution

1.1 Role groups

The team has 14 members and keeps the six role groups defined in the second assignment (the membership has been adjusted since then). Item owners and finders are product user roles and are managed separately from the development groups below.

Group	Members (count)	Scope of responsibility
Project management	Sun Zikun, Zhou Shengdong (2)	Project scope, schedule and delivery coordination, consistency checks across the three deliverables
Product requirements	Zhou Debin, Zheng Ziyang (2)	User research, scenarios, SRS body, acceptance criteria
Frontend and UI	Wu Junjia, Zheng Zongyuan, Zuo Xiangrong, Li Jianhang (4)	Prototypes, page interaction, H5 and mini-program differences, upload and messaging experience
Backend and operations	Luo Yuhan, Liu Peikun, Wang Qiushi, Xiao Zhengyu (4)	Domain model, interfaces, identity and permissions, storage, transactions and deployment
Algorithm	Liu Junye (1)	Image candidate retrieval, re-ranking and match-quality assessment
Testing	Xu Yichao (1)	Requirement testability, exception paths, compatibility and acceptance design

1.2 Work and actual contribution for this assignment

The table below is the actual division of labour and contribution for this assignment, confirmed by all 14 members on the basis of document revisions and review records, and totalling 100%. The percentages are weighted by task difficulty and effort; they are not distributed evenly, nor carried over from the second assignment.

Student ID	Name and work description for this assignment	Contribution
832401315	Sun Zikun: coordinated scope and schedule; merged and final-reviewed the SRS; wrote the requirement traceability matrix (9.1) and the open-items list (9.2); organised the internal cross-review	8%
832401313	Luo Yuhan: set up the document repository and folder conventions; unified the Word template and figure/table numbering; exported the PDF; maintained the blog and attachment links; wrote section 2.4 (deployment and resource constraints) and section 7.6 (maintainability)	12%
832401329	Zhou Debin: designed and ran the user research (questionnaire and interviews); wrote the main body of Chapter 3 user scenarios (3.1–3.10)	5%
832401327	Zheng Ziyang: wrote the eight detailed scenario descriptions (3.2–3.9) and the use-case overview (3.1); wrote the terminology and abbreviations table (1.3); completed the data dictionary (6.3); presented this report	10%
832401223	Wu Junjia: led Chapter 5 interface prototypes, including the design rules (5.1) and the 12 key interface wireframes (5.2–5.13)	6%
832401328	Zheng Zongyuan: drew the page map (5.1, Figure 5-1) and the four page flows (5.1.1); wrote the prototype-to-acceptance mapping table	5%
832401230	Zuo Xiangrong: designed the publishing and image-upload interface chain (UI-02/03/05/12), including the interaction notes for automatic masking of ID documents	5%
832401210	Li Jianhang: designed the search and candidate-matching interfaces (UI-01/UI-04) and how match reasons are presented	6%
832401213	Liu Peikun: led the Chapter 4 class model, covering the attributes, operations and multiplicities of the 14 core classes (4.1–4.3); drew the ER view (4.5)	6%
832401317	Wang Qiushi: drew the two state machines (4.4); wrote the 10 business rules (6.4); wrote the security, privacy and compliance requirements (7.2, 7.7)	8%
832401318	Xiao Zhengyu: wrote the performance and capacity targets (7.1), reliability and idempotency (7.4) and maintainability (7.6)	6%
832401212	Liu Junye: designed the matching-related classes and the candidate scoring model; defined Hit@5 and the match-quality evaluation criteria (8.4)	6%
832401319	Xu Yichao: wrote the Chapter 8 acceptance and verification criteria (8.2–8.4, 8.7); test coverage and traceability	6%
832401330	Zhou Shengdong: tracked progress and delivery checks; compiled the device-compatibility matrix and test samples (7.5, 8.6); checked the consistency of the SRS, the presentation and this blog	11%
Total	14 members	100%

Contribution review follows the principle proposed last time — "assess by task quality, collaboration and review records" — rather than counting files or commits. The actual share for this assignment and the projected share for the semester are recorded separately.

2 Team organisation and collaboration

2.1 Connecting roles through user scenarios

Collaboration in this round was organised around user scenarios. A single requirement change has to be checked against the business rules, the classes, the pages and the acceptance criteria at the same time. For example, "one-sided confirmation must not close a case" affects the case state, the uniqueness constraint on confirmations, the button feedback in UI-06, and the duplicate-request and concurrency tests — it cannot be handled by editing one sentence of text.

The requirements group explains why users act and what they expect; the frontend turns inputs, feedback and exceptions into pages; the backend reviews permissions, state and data consistency; the algorithm group explains what a candidate means and when matching degrades; the testing group rewrites requirements into executable checks; the team lead consolidates scope and open items.

2.2 Integrating and reviewing the deliverables

The version changes actually recorded in the files are: v1.0 added the model and prototypes; v1.1 reorganised the document into nine chapters and unified the business rules; v1.2 aligned the runtime environment and the pilot configuration in NFR-02 to 8 CPU cores and 16 GB of memory; v1.3 changed the business backend stack from Java 17 / Spring Boot 3 to C# / .NET + ASP.NET Core (Web API). The presentation and this blog cite the same identifiers, counts and metrics.

Subsequent reviews follow the process below, with the records archived alongside the tasks:

1. Every task names an owner, the related requirements, a planned completion date and a reviewer.
2. Progress, blockers and requirement changes are synchronised in the team's existing channels, and conclusions are written into the shared change log.
3. Scenarios, model, pages and acceptance criteria are cross-reviewed between roles, and the traceability matrix is re-checked after any change.
4. Differences between the SRS, the presentation and the blog are reconciled so that one consistent set of attachments can be submitted.
5. The actual reviewers, dates, decisions and open issues are recorded before an approved baseline is established.

The actual record of this review:

Item	Content
Review time	2026-10-18 18:30–19:30
Participants	Sun Zikun, Luo Yuhan, Zheng Ziyang, Zhou Shengdong, Liu Peikun, Wang Qiushi
Communication tool	WeChat group
Review conclusions	Contribution shares confirmed; backend stack changed to C#; presentation re-organised for an 8-minute slot
Open issues	Real user-research data, service-point cooperation, and others

3 Software Requirements Specification

3.1 Document download

• Word version of the SRS: [Software Requirements Specification v1.3] (https://github.com/shizhong2333/FindBack_srs)
• Requirement analysis presentation: Assignment 3 requirement-analysis presentation

The files are 需求规格说明书-拾光FindBack-v1.3-后端技术栈调整版.docx and 拾光FindBack-第三次作业-需求分析汇报-v1.3-交付版.pptx. The attachments must be uploaded and the two links above replaced before publishing, so that readers who are not logged in to a team account can access them under the platform's permissions.

3.2 Nine-chapter structure

SRS stands for Software Requirements Specification: the document that fixes the behaviour, constraints and acceptance basis of the system to be built.

Chapter	Main content
1 Introduction	Purpose, the four pain points, terminology and abbreviations, references
2 Overall description	Product positioning, functional structure, user characteristics, runtime environment, constraints and dependencies
3 User scenarios	Descriptions of the four roles, 8 full scenarios, the use-case overview and the state of research evidence
4 Class model and domain model	14 core classes, attributes and operations, multiplicity, composition and aggregation, two state machines and the ER view
5 Interface prototypes	Page structure, 12 prototypes, control descriptions, inputs and outputs, exception feedback and page flows
6 Functional requirements	18 modules, 42 FRs, priorities, iterations, inputs and outputs, data dictionary and business rules
7 Non-functional requirements	Performance, privacy, usability, reliability, compatibility, maintainability and platform constraints
8 Acceptance and verification criteria	Verification methods and pass criteria for interface, function, non-functional, match quality and pilot
9 Requirement traceability matrix	Five-way links between scenario, function, class, interface and verification, plus the TBD list and review status

External interface requirements are kept in Appendix E as input for later API design. The interface tables, the data entity tables and the interface prototypes describe different concerns and none of them can substitute for another.

4 User scenarios and business flow

4.1 Users and scope

The product serves item owners, finders, service-point staff and administrators. An owner and a finder may be the same user taking different roles in different cases. If the campus authorities only receive anonymised statistics, they are treated as a stakeholder and do not automatically gain access to private evidence.

The scope for this semester is a controlled pilot on a single campus: no payments, no custody guarantee, no cross-campus interoperability and no automatic ownership adjudication. Only service points with confirmed cooperation and authorisation can enter the receiving or verification flow.

4.2 The eight scenarios

Scenario	Main task	Key exceptions
SC-01 Login and campus authentication	Establish a session and verify campus identity	Verification code failure, name not on the list, authorisation refused
SC-02 Owner publishes and searches	Publish a lost-item post and search found-item posts with combined filters	Missing fields, image failure, no results
SC-03 Finder publishes, candidates generated	Publish a found-item post, process images, generate candidates	Masking or moderation failure, algorithm unavailable
SC-04 Claim evidence review	Submit private details and supporting proof, reviewed by a human	Insufficient evidence, duplicate requests, disputes
SC-05 Handover confirmation and disputes	Agree a handover, both sides confirm separately	One-sided confirmation, timeout, concurrent retries
SC-06 Content moderation and reports	Moderate content under authorisation, handle reports and dictionaries	Privilege escalation, missing reason, insufficient evidence
SC-07 Message preferences and optional aids	View pending items, control preferences and optional subscriptions	WeChat message failure, target no longer available
SC-08 Metrics and pilot retrospective	Recompute statistics over a fixed window	Zero denominator, insufficient sample

4.3 Main flow illustrated with a folding umbrella

An owner realises a folding umbrella is missing, completes campus authentication, and publishes a photo, time, place and public description. A finder publishes a found-item post and states where the item is actually kept. After processing the images, the system returns candidates, and the user can look further using the similarity score and the real match reasons.

Once both sides accept, the claimant fills in details that are not visible in the public photo and may provide an old photo or other proof. The finder, or an authorised staff member, reviews the evidence by hand and records the decision and the reason. After approval the two sides agree an offline handover, confirm separately that the item was received or handed over, and the system closes the case and updates the statistics exactly once.

If the algorithm fails, publishing and manual search still work; if evidence is insufficient, it is sent back for completion; if only one side confirms, the case stays pending; if a dispute arises, it goes to manual handling. Real questionnaire and interview results from M1 are still outstanding, and the concrete item in the scenario is not treated as a survey sample.

5 Class model and domain model

5.1 The fourteen core classes

Beyond the entity descriptions, this round adds a UML class model with the key attributes, operations and relationships between classes.

Class ID	Class name	Responsibility
C01	User	Account, campus identity and participation permission
C02	Item	A lost or found post and its state
C03	ItemPhoto	Original image, masked derivative and processing state
C04	MatchCandidate	Candidate link between posts of opposite type, with reasons and feedback
C05	Case	Claim, verification, handover and dispute case
C06	VerificationChallenge	Non-public claim question configured by the finder
C07	VerificationEvidence	Private evidence and review record submitted in the current case
C08	HandoverConfirmation	One handover confirmation by a single participant
C09	CreditRecord	Confirmed credit event and its appeal status
C10	Notification	In-app notification and channel delivery state
C11	Subscription	A user's optional subscription condition and on/off state
C12	Report	Reported object, reason and handling result
C13	AuditLog	Audit record carrying the target type and the operator
C14	ServicePoint	Service point with confirmed cooperation and authorised operations

A post owns 1–6 images and may configure 0–3 non-public questions. A case links one found-item post and optionally one lost-item post, and the two parties must be different users. A case may have several pieces of evidence, but a normal handover has at most two confirmations, enforced by UNIQUE(caseId, userId) so that one person cannot occupy both sides.

Service points are in an aggregation relationship with items. Retiring a service point must not delete the history of items and cases. Reports and audit logs record both the target type and the target identifier, so no object can be read merely by passing a client-side ID.

5.2 Two state machines

The item state describes whether a post is still matchable, has been returned, or has been archived; the case state describes acceptance by both sides, evidence review, handover arrangement, confirmation and dispute handling. An ordinary closure, a cancellation or an expiry-based archive must never be counted as a successful return.

5.3 Persistence view

The ER view continues to express the main tables and foreign-key relationships, and works with the class model to explain how data is stored. Operations on a class are not equivalent to database columns.

6 Interface prototypes

6.1 Page structure

The prototypes cover both the student side and the administration side. Visitors may browse; publishing redirects to authentication; an unverified user cannot enter the handover flow; the administrator entry point is permission-checked on the server.

Prototype	Page	Key requirement
UI-01	Home and search	Keyword plus category, place and date filters; loading, empty result and error states are distinguished
UI-02	Publish lost / found item	Required-field checks, 1–6 images, custody location, input preserved on failure
UI-03	Item detail	Publicly masked information only; available actions depend on identity and state
UI-04	Candidate matching	Real ranking reasons, relevance feedback and the acceptance state of both sides
UI-05	Submit claim evidence	Private answers and optional proof; the reference answer is never shown
UI-06	Handover confirmation	Both sides' states shown separately; one side cannot close the case
UI-07	Messages and cases	The user's own pending items, case timeline and authorised conversation
UI-08	Profile and preferences	Verification state, my posts, message preferences and appeals
UI-09	Administrator moderation	Moderation queue, necessary evidence, mandatory reason and operation log
UI-10	Statistics and pilot dashboard	Statistics window, sample size, numerator and denominator, and the no-data state
UI-11	H5 login and campus verification	Campus e-mail and student ID verification, with an authorised manual path
UI-12	Configure questions and review evidence	Non-public questions, current case material, manual decision and reason

6.2 Prototype showcase

The four showcase figures below together contain all 12 prototypes. Because the class session allows less than 8 minutes, the presentation only walks through the first two groups (slides 10–11, UI-01/02/03 and UI-04/05/12); the other six interfaces are on backup slides (19–20). Chapter 5 of the SRS gives the controls A–E, inputs and outputs, linked FRs and exception feedback for each page.

This version completes the basic requirement prototypes. High-fidelity design, walkthroughs with real users, and verification of the differences between H5 and the mini program continue in M2; the figures are not presented as finished interfaces.

7 Functional requirements and traceability

7.1 Requirement list and priorities

The original 42 FR identifiers are kept and classified with MoSCoW as 21 Must, 16 Should and 5 Could, grouped into 18 modules. Must items have to be satisfied, Should items allow a reasonable substitute, and Could items are implemented according to time and resources.

The core modules are account and campus identity, publishing lost and found items, browsing and search, image processing, candidate generation and re-ranking, messaging, evidence review, handover, credit and appeals, administration and statistics. Each FR records its inputs, outputs, source scenario, iteration and acceptance conditions in Chapter 6 of the SRS.

Automatic tagging is an optional aid, but FR-18.3, the tag privacy boundary, remains a Must. Turning the suggestion feature off does not lift the privacy requirements on public content.

7.2 Five-way traceability example

User scenario	Functional requirement	Core classes	Interface	Functional verification
SC-02 Owner publishes	FR-02.1	C02, C03	UI-02	FT-02.1
SC-04 Claim review	FR-11.1	C05, C06, C07 and others	UI-05, UI-12	FT-11.1
SC-05 Handover confirmation	FR-12.1	C05, C08 and others	UI-06	FT-12.1
SC-07 In-app reminder	FR-09.1	C10 and others	UI-07 and others	FT-09.1

The complete matrix covers all 42 FRs. The original 41 use cases are retained as a use-case index; scenarios, use cases and functional requirements are allowed to map many-to-many, so their counts do not have to match. This round filled in the traceability gaps for FR-07.1, FR-07.2 and FR-18.3.

8 Non-functional requirements and acceptance

8.1 Performance and capacity targets

Item	Target and test conditions
Pilot resources	8 CPU cores, 16 GB memory
User scale	300 registered users, recorded separately from concurrency
Concurrency test	50 concurrent virtual users running for 10 minutes
Item pool	10,000 items
Response targets	List or detail P95 under 1 s, search under 800 ms, candidates under 1.5 s
Image processing	CPU single-image embedding under 2 s; 3 compressed images transferred in under 3 s under the agreed 4G conditions
Test record	Hardware, network, sample, request mix, error rate, throughput and resource peaks; cold start reported separately

All of the above are targets still to be verified. P95 is the 95th percentile of the latency distribution and cannot be replaced by an average. Image transfer time is measured separately from user input and embedding generation.

Security requirements include HTTPS, role-based and object-level permissions, task-based authorisation for original images and private answers, masking of public images, and a clear statement of deactivation, deletion and retention scope. When the algorithm service is unavailable, legitimate publishing and basic search must still work; repeated confirmations must not close a case twice, add credit twice or double-count statistics.

8.2 Five acceptance categories

Category	Method	Pass criteria
Interface	Prototype walkthrough with at least 5 first-time users performing tasks	Entries, controls and exceptions are consistent; the standard publish task after authentication takes no more than 30 s
Function	42 FTs mapped to FRs, including positive, privilege-escalation, retry and state counter-examples	Inputs, outputs and per-item acceptance conditions are satisfied
Non-functional	Load, permission, failure, dual-platform and backup-recovery verification	The corresponding NFRs are met and checkable records are retained
Match quality	Frozen independent labelled set, checked query by query	Hit@5 is reproducible and reaches the threshold and latency confirmed in M2
Controlled pilot	30–50 students planned over two weeks on the H5 pilot	No serious privacy, permission or case-closure blocking defect; actual sample and results reported

8.3 Definitions of the three metrics

Recovery rate: with a fixed publication cohort and observation cut-off, N is the number of valid lost-item posts and R the number confirmed as recovered; the recovery rate is R / N × 100%. When N is zero the display reads "no data". Re-confirming the same case must not increase R again.

Median time to return: for the recovered posts in that cohort, compute "final confirmation time minus publication time of the lost-item post", and report the median together with the number of recovered samples and the number still unresolved. When there is no recovered sample, 0 hours must not be shown.

Hit@5: Q is the number of queries in the independent test set that have a known true counterpart, and H the number of queries where at least one of the top five candidates is a true counterpart; the value is H / Q × 100%. A query using several images still counts once, and photos of the same physical item must not be split across the tuning and test sets. Online relevance feedback is counted separately.

The quality threshold, minimum sample size and false-reminder threshold of Hit@5 are recorded as TBD-07 and will be confirmed in the M2 review. This section explains the evaluation method; it does not report accuracy or recovery improvement that has not been measured.

9 Delivery form and technology choices

9.1 H5 as the primary delivery, mini program for demonstration

Following the frontend feasibility assessment, this semester uses uni-app, Vue 3 and TypeScript: one shared codebase compiled to a mobile H5 site served over HTTPS as the primary controlled pilot, with the WeChat mini program used as the development and demonstration form. The administration side is a role-authorised web console.

Compiling from the same source does not remove the need to adapt each platform: login, camera upload, routing, background behaviour and notifications must still be implemented and verified separately. WeChat login cannot by itself prove campus identity, so the rules for campus e-mail, student ID and the authorised pilot list still need to be confirmed in practice.

Core messages are kept in the in-app list and badge. WeChat subscription messages depend on user authorisation, templates and the platform environment; a refusal or a failed delivery must not block the business flow. The platform entity, domain name, package size and quotas will be verified in M2, and earlier estimates are not presented as current platform commitments.

9.2 Backend and algorithm service

SRS v1.3 has fixed the business backend stack as C# / .NET + ASP.NET Core (Web API); the database MySQL 8, cache Redis 7, object storage, Nginx and Docker are unchanged. The decision was proposed by the team's technical lead and confirmed within the team; section 2.4 of the SRS, the revision record and slide 12 of the presentation have been updated and state the same thing.

The change affects only the implementation layer and alters no user behaviour, permission, state or acceptance requirement in this document: the entity fields in Appendix D and the REST endpoints in Appendix E are independent of programming language, so the conclusions of Chapters 3–8 remain valid. The .NET runtime version, the data-access approach and the re-work of the interface contract are recorded as TBD-13 and will be confirmed in M2 (19 October – 1 November); until that item is closed we do not claim the backend is ready.

The algorithm service remains an independent Python service; CLIP, ResNet, FAISS and similar options will be compared in M2. The frontend reaches it through the business API and never connects directly to the algorithm intranet or holds object-storage keys.

10 Key difficulties and consistency revisions

10.1 Entity tables cannot fully express the business model

The raw material already contained data entities and interface information, but it still had to explain what operations an object has and how objects constrain each other. This round added class attributes and operations, multiplicity, composition and aggregation, and used Case to connect verification, handover and credit events. The ER view continues to express the persistence relationships.

10.2 Similar images cannot prove ownership

Similarity is good for generating candidates but cannot carry an ownership decision. Reference answers to claim questions are not disclosed, private evidence is isolated per case, and a manual review conclusion must record the operator, the time and the reason. Insufficient evidence can be completed or escalated to manual handling, and there is no rule under which "identical free text means automatic approval".

10.3 External notification and campus identity depend on platforms

Making mini-program publication or WeChat message delivery a prerequisite of the main flow would tie business availability to platform conditions that have not been verified. We therefore use H5 as the primary delivery and in-app messages as the core channel, and keep platform verification as a separate task. Service points and the pilot list likewise require real cooperation and authorisation.

10.4 Case closure and metrics must stay consistent

Archiving an item does not mean it was returned, and one-sided confirmation does not mean the handover is complete. State conditions, checks that the participants are different, unique constraints and idempotent handling prevent a repeated confirmation from closing a case and incrementing statistics more than once. Credit records are appended only for genuine completions or events confirmed by investigation; failed verification and unverified reports cannot lead directly to a penalty.

10.5 Unified baseline across the three deliverables

Item	Unified result in this round
Requirement count	42 FRs: 21 Must, 16 Should, 5 Could
Scenarios and model	8 scenarios, 14 core classes, two state machines
Prototypes	12 basic prototypes; high fidelity and user walkthroughs continue in M2
Student-side delivery	H5 is the primary controlled pilot; the mini program is for development and demonstration
Verification and messaging	Private evidence reviewed by a human; in-app messages as the core channel
Backend stack	C# / .NET + ASP.NET Core (Web API); the algorithm service remains an independent Python service
Host resources	The runtime environment, NFR-02 and the presentation all use 8 CPU cores and 16 GB memory
Acceptance conclusion	Targets are kept separate from measured results; real research, tests and review records are still to be completed

10.6 The technology change and synchronising three deliverables

The most time-consuming rework of this round happened on the day of submission: the team's technical lead asked for the business backend to be switched to C#, while the SRS, the presentation and this blog had already been finalised on the Java stack and referenced each other.

The difficulty was not in changing a few words but in the number of places each document referenced: the stack row in section 2.4 of the SRS, the revision record, the open items in 9.2; the "current requirement and solution" row on slide 12 of the presentation, the pending-decisions list on slide 13, and the version reference in every slide's speaker notes; and, in this blog, the version history, the attachment file names and the page references. Any one of them left behind would be enough for a reviewer comparing two files to spot a contradiction.

The order we worked in was: first raise the SRS to v1.3 and record the source of the change in the revision history; then change the two statements in the presentation and the pending-decision item; finally rewrite the version references in the blog against v1.3. At the same time we added TBD-13 to register "runtime version, data-access approach and interface-contract rework" as an item to be closed in M2, rather than hiding unfinished work behind a single sentence saying "already switched".

The rework also confirmed one thing: as long as a requirements document does not couple implementation details into its body, switching language is a one-line change to the stack row — the data tables in Appendix D and the interfaces in Appendix E were never language-specific, so not a word of Chapters 3–8 had to change.

11 Project plan and open items

11.1 Planned schedule

The dates below are planned; results will be updated against actual records.

Phase	Dates	Main acceptance content
M1 Requirement analysis	12–18 October	Requirements, model and prototypes produced; if the real research record is not closed, evidence is added in the next version
M2 Design and feasibility	19 October – 1 November	High fidelity, identity and platform verification, .NET landing validation, algorithm and sample thresholds confirmed
It.1 Publish and search	2–9 November	One side publishes, the other finds it by category, place and keyword
It.2 Candidates and reminders	10–19 November	Candidates are traceable, in-app pending items are visible, manual search survives an algorithm failure
It.3 Verification and handover	20–29 November	Manual review, independent confirmation, idempotent closure and dispute handling
Controlled H5 beta	30 November – 13 December	30–50 people planned for two weeks; actual participation, problems and metrics recorded
Wrap-up and showcase	14–27 December	Result analysis, document archive and final showcase, adjusted to the course arrangement

11.2 Open items

Item	Responsible role	Planned closure
Real questionnaire, interviews, valid sample and requirement adjustments	Requirements group	M1; evidence added in the next version if missing
Service-point cooperation and the actual transfer flow	Team lead, requirements group	M1; the path stays closed if unconfirmed
Campus identity rules, H5 address and deployment resources	Requirements, front and back end, operations	M2, no later than 1 November
Algorithm, independent labelled set, Hit@5 threshold and minimum sample	Algorithm, testing, requirements	M2, frozen before the pilot
Mini-program platform conditions, dual-platform differences and end-to-end messaging	Frontend, backend, testing	Verified in M2, complete by It.2
Actual contribution shares, review sign-off and public attachment links	Team lead and all members	Before the assignment-3 submission
Credit scoring and whether it affects candidate display	Requirements, algorithm, administration	Confirmed before It.3 is enabled

The SRS keeps a complete list of 13 TBD items. Document modelling that is finished and research, development and testing that are still outstanding are tracked separately: the planned number of pilot invitees is not treated as an actual sample, and existing prototypes are not treated as a completed beta.

12 Requirement analysis presentation

The presentation has 25 slides — 15 spoken, 3 appendix and 7 backup — each with speaker notes. The class requires a presentation of less than 8 minutes, so the spoken part is paced at about 7 minutes 15 seconds, leaving roughly 45 seconds of buffer; the remaining slides are kept as backup and can be called up during questions.

Slide	Topic
1	Cover and presenter
2–3	The four problems; user roles and project scope
4–5	The eight user scenarios; the business flow from publishing to return
6	Functional requirements and priorities (21 Must / 16 Should / 5 Could)
7–9	Three core class diagrams: publishing and matching, verification and handover, administration and service points
10–11	Six core interface prototypes: search and publish, candidates and evidence review
12	Delivery form and system boundary
13	Iteration plan and pending decisions
14	Team division of labour and workload share
15	Summary: problem, MVP and verification
16–18	Appendix: users and use-case overview; the complete 42 functional requirements
19–25	Backup: the other six interface prototypes → performance and security → five acceptance categories → two state machines → three metric definitions and the five-way traceability matrix

To fit the 8-minute limit, a division-of-labour slide was first added to the completed 24-slide version (making 25), and then four kinds of adjustment were made: the "page structure navigation" slide, which duplicated the prototype slides, was removed; the two state machines, the three metric definitions and the five-way traceability matrix were moved to backup; performance and security, and the five acceptance categories, were also moved to backup; and the interface prototypes were reduced from 4 slides to 2, walking through only the six interfaces that carry the main line (UI-01/02/03 and UI-04/05/12), with the other six interfaces on backup slides. A closing slide, "Summary: problem, MVP and verification", was added at the end.

The presentation explains how the system works using the model, the flow and the prototypes; per-item inputs and outputs, detailed business constraints and the full traceability matrix are in the SRS. The division of labour and contribution shares are on slide 14 and match section 1.2 of this blog.

13 References

1. Third assignment — Requirement Analysis.
2. Gamers2 second assignment — team formation and topic selection.
3. Software Requirements Specification — 拾光 FindBack, v1.3, attachment to this submission.
4. 拾光 FindBack Assignment 3 — Requirement Analysis Presentation, attachment to this submission.
5. Frontend Technology Feasibility Assessment — WeChat Mini Program, project technical assessment material.
6. GB/T 9385-2008 Specification for computer software requirements specifications, GB/T 8567-2006 Specification for computer software documentation, IEEE 830-1998 — references for the document structure.
7. Zou Xin, The Method of Construction, Chapter 8 — reference for requirement analysis.
8. DCloud conditional compilation documentation.
9. Microsoft ASP.NET Core Web API documentation — technical reference for the backend stack.