Assignment 3: Requirements Analysis | GOAT_666

目录

Assignment 3: Requirements Analysis | GOAT_666

1. Team Division of Labor and Contribution Percentages

1.1 Members and Initial Long‑term Division of Labor

2. Software Requirements Specification

2.1 Documents and Attachments

2.2 Project Background, Purpose and Scope

2.3 User Roles & User Scenarios

2.4 Overall Class Diagram

2.5 Interface Prototypes

2.6 Functional Requirements & Acceptance‑Verification Criteria

2.7 Requirements Revision & Unfinished‑item Record

3. Team Organization and Schedule

3.1 Team Organization

3.2 Overall Project Milestones

3.3 Work Plan Between Assignment‑3 and Assignment‑4

4. Team Collaboration

5. Key Issues and Challenges in This Assignment

6. Requirements Analysis PPT and Presentation Arrangements

1. Team Division of Labor and Contribution Percentages

The team contains 13 members. The table below inherits member information from Assignment 2. The first table shows general long‑term responsibilities of each member; the second table focuses on workload for this Assignment 3 (SRS revision, class diagram, interface wireframes, blog, presentation PPT).

1.1 Members and Initial Long‑term Division of Labor

2. Software Requirements Specification

2.1 Documents and Attachments

2.2 Project Background, Purpose and Scope

Project Name: GOAT_666 Online Travel Platform.

This Web‑based travel‑service platform targets travel‑loving ordinary users. Current real‑world pain‑points: travel‑related information is scattered on many websites; users spend much time searching destinations, attractions, guides, hotel‑and‑ticket resources. Existing platforms require real‑payment during booking; students cannot experience the complete booking workflow without actual money loss. Meanwhile there lacks a community for publishing travel‑notes, comments, ratings and favorites.

Our platform provides a full‑flow from information‑browsing to travel‑experience sharing:

• Visitors can browse and search destinations, attractions, travel guides, hotel and ticket commodities.
• After registration & login, registered users can select dates and finish simulated booking, query / cancel orders and view simulated‑refund results. They can also publish travel‑notes, make comments, ratings and collect favorite contents.
• Administrators maintain platform‑side attraction‑guide‑product resources and manage user‑generated content.
• Extension‑phase functions: personalized recommendation, content moderation & usage statistics, AI travel assistant for generating reference itineraries.

2.3 User Roles & User Scenarios

Three core user‑roles are defined: Visitor, Registered User, Administrator. We define six complete user‑scenarios (SC‑01 ~ SC‑06), each follows the fixed template: role‑and‑goal‑trigger‑pre‑condition‑normal‑flow‑exception‑branch‑outcome‑related‑requirements.

• SC‑01 Visitor Searches for Attraction Guides
• SC‑02 User Makes a Simulated Booking
• SC‑03 Publish a Travel Note and Interact
• SC‑04 Administrator Maintenance
• SC‑05 User Cancels an Order and Views a Simulated Refund
• SC‑06 Registered users use the AI travel assistant [Extension]

Each scenario corresponds to functional‑requirements, class‑diagram objects, UI‑prototype pages and acceptance‑test cases.

2.4 Overall Class Diagram

The overall class‑diagram covers core domain‑objects: User, Destination, Attraction, Guide, Product, Inventory, Order, OrderItem, TravelNote, Comment, Rating, Favorite.

Key relationships:

1. User has zero‑to‑many orders, travel‑notes, comments, ratings and favorites.
2. Destination aggregates multiple Attraction and Guide. Hotel‑type products associate to destination; ticket‑type products associate to attraction.
3. Product relates multiple Inventory records distinguished by date; Inventory.availableCount represents bookable stock quantity on that day. When placing simulated‑booking order, system deducts availableCount; when canceling order, availableCount gets restored.
4. One Order contains ≥1 OrderItem. OrderItem records product, usage‑date, buying‑quantity, unit‑price and subtotal amount.
5. Polymorphic association: Comment / Rating / Favorite use targetType + targetID to point to different targets (attraction / guide / travel‑note / product).

2.5 Interface Prototypes

We finish key‑page wire‑frame prototypes (UI‑01 ~ UI‑08):

Wire‑frames define page‑layout, control‑buttons, input‑items, empty‑state prompt text, error‑hint text and navigation‑jump relations. For example, Product‑Detail page contains date‑selector, quantity‑selector and “Simulated Booking” button; My‑Orders page shows order‑status label, “Cancel Order” button and empty‑state prompt “No orders yet”.

Some high‑fidelity visual‑effects are pending; current deliverables are low‑fidelity wire‑frames satisfying requirement‑analysis assignment criteria.

2.6 Functional Requirements & Acceptance‑Verification Criteria

We define 12 functional‑requirements FR‑01 ~ FR‑12, covering account‑management, information‑browsing, search, commodity query, simulated‑booking, order‑management, travel‑note publishing, comment‑rating‑favorite, administrator‑platform‑maintenance and three extension‑functions.

Non‑functional requirements (NFR‑U series for usability; NFR‑S series for security‑access; NFR‑O series for other quality‑constraints) specify:

• Form‑input error feedback rules; empty‑page prompt rules; maximum response‑time constraints; multi‑viewport adaptability.
• Permission‑access control: regular‑users cannot access administrator pages; users can only operate their‑own orders.
• Server‑side input‑validation; password salt‑hash storage.
• Data‑consistency guarantee for order‑placing / order‑canceling to prevent overselling; audit‑log for order‑status‑change.

Acceptance‑test cases AT‑UIxx (interface acceptance) and AT‑Fxx (functional acceptance) are given. Each test‑case lists pre‑conditions, operation‑steps and expected‑results, providing test‑baseline for later development & testing phase.

2.7 Requirements Revision & Unfinished‑item Record

Chapter 6 inside SRS records:

1. Design‑decisions, encountered‑issues and adopted‑solutions (ISS‑01 ~ ISS‑05): e.g. tiered‑simulated‑refund rules, inventory‑deduction transaction‑strategy, server‑side idempotency solving repeated‑submit‑duplicate‑orders.
2. User‑validation record: formal real‑user interviews are planned but not yet completed; will be supplemented before deadline.
3. Unfinished‑items table: lists items such as partial wire‑frames, some detailed acceptance‑cases waiting for supplement, to‑be‑review class‑diagram. After completion in follow‑up work, we will update SRS and explain revisions in Assignment‑4 blog.
4. Requirement‑traceability‑matrix: mapping between each user‑scenario, FR‑functional‑requirement, class‑diagram object, UI‑prototype and acceptance‑test case.

3. Team Organization and Schedule

3.1 Team Organization

Our team keeps the grouping structure inherited from Assignment 2:

• Project‑coordinator: Zihan Zhao, responsible for overall progress‑tracking and cross‑group communication.
• Frontend‑development group: Liucheng Wang, Zexin Zhang, Hongfu Zhao, Wenjie‑Yan.
• Backend‑development & database group: Ruizhi Liu, Haomin Lin, Xinyang Zhang, Zerui Xie, Longzhe Lin, Qihang Peng.
• Test‑group: Minghao Zhang, Zhihua He.
• Document‑&‑presentation‑sub‑group: members selected from above groups, responsible for SRS‑writing, blog‑editing and PPT‑making.

Group‑leaders hold regular online meetings, synchronize progress, review deliverables and resolve divergence of understanding on requirements.

3.2 Overall Project Milestones

Keep the milestone sequence defined in Assignment 2:

For Assignment 3 internal workflow: Requirement‑discussion & sorting → write‑user‑scenarios → draw‑class‑diagram → draw‑interface‑wire‑frames → integrate‑&‑revise‑full‑SRS → internal‑team‑review → compile‑CSDN‑blog → make‑presentation‑PPT → upload‑documents to GitHub repository → final‑submit.

3.3 Work Plan Between Assignment‑3 and Assignment‑4

After requirement‑analysis presentation of Assignment‑3, we will move to system‑design phase, main work items as follows:

4. Team Collaboration

Our team uses WeChat group as daily instant‑communication channel. We adopt online collaborative‑document tool for jointly editing SRS‑draft. Group‑leaders organize short synchronous‑meetings 2‑3 times each week for progress‑sync and requirement‑review. After each member finishes his own part, document‑integrator merges content and performs format‑unification. Finally we upload final‑docx, pdf and PPT files to GitHub repository.

表格

5. Key Issues and Challenges in This Assignment

During SRS‑compilation our team met several key challenges of requirement‑analysis:

1. Boundary‑distinction between initial‑release‑functions and extension‑phase‑functions We need to strictly distinguish which features must be finished in initial‑Web‑version and which can be delayed to extension‑iteration. Real‑payment, native‑mobile‑APP are explicitly excluded out‑of‑scope; AI‑travel‑assistant and personalized‑recommendation are marked as extension‑items, clearly written in scope‑table and SRS‑chapters. Avoid scope‑creep.
2. Simulated‑booking & simulated‑refund business‑rule definition Since it is simulated without real‑money, we need to explicitly define inventory‑deduct / inventory‑restore timing, tiered‑refund‑percentage rule based on how‑many‑days‑before‑usage‑date. We also need to handle repeated‑click‑submit‑order problem by combining frontend‑button‑disable and server‑side idempotency mechanism, prevent inventory overselling. These rules are reflected in scenarios, functional‑requirements and acceptance‑cases.
3. Consistency‑maintenance across multi‑artifacts The SRS contains user‑scenarios, class‑diagram, UI‑wire‑frames, FR‑functional‑requirements and AT‑acceptance‑cases. Different members are responsible for different artifacts. We spend a lot of time doing cross‑check to ensure terminology, identifier prefix(SC‑xx / FR‑xx / UI‑xx / AT‑Fxx) keep unified; scenario‑steps can map to corresponding‑functions, class‑objects and test‑cases. We build requirement‑traceability‑matrix to help inspection.
4. Visitor / Registered‑User / Administrator permission‑boundary clarification Visitor can only browse public content, cannot place‑order or publish‑notes; registered‑user can only modify / cancel his‑own‑orders and his‑own‑published‑content; administrator has content‑maintenance authority but cannot arbitrarily tamper normal‑user private‑data. All permission‑restrictions are written in scenarios, non‑functional‑security‑requirements and acceptance‑test‑cases.
5. User‑validation limitation Due to time‑limit before assignment‑deadline, formal real‑user interviews are only planned and have not been finished. We record this point clearly in SRS chapter 6 “unfinished‑items”, promise to supplement user‑feedback before next‑stage work and revise requirements accordingly.

6. Requirements Analysis PPT and Presentation Arrangements

• Requirement‑analysis PPT covers project‑background & goal, user‑roles & scenarios, overall class‑diagram, key‑interface‑wire‑frames, core‑functional‑requirements & acceptance‑criteria, team‑division‑of‑labor and next‑phase‑work‑plan.
• PPT file is uploaded to our GitHub repository. Link for PPT: 软件需求规格说明书汇报PPT
• In‑class presentation will be assigned according to course‑arrangement; presentation‑members will be selected from our team.

Reference documents:

1. Third assignment requirement document: https://bbs.csdn.net/topics/620549144
2. Assignment2 blog of GOAT_666: https://bbs.csdn.net/topics/620546966
3. 《The Art of Construction》
4. GB/T 9385‑2008 Specification for Computer Software Requirements
5. GB/T 45802‑2025 Systems and Software Engineering‑‑Life Cycle Processes‑‑Requirements Engineering