Item	Information
Course	EE308FZ — Software Engineering
Assignment title	Fourth Assignment — Prototype Design
Team name	GOAT_666
Project name	Shanhai‑Travel Platform（山海行在线旅行平台）
Assignment requirement	Teaching assistant's Fourth Assignment — Prototype Design notice, published October 19, 2026
Assignment objective	Translate the approved SRS v1.4 into a complete high‑fidelity interface prototype, document core interaction paths, record design problems and present the whole design process and outcomes.
Interactive prototype URL	https://stirring‑profiterole‑dbfeb1.netlify.app
GitHub supporting assets & Prototype presentation (PPT/PDF)	GitHub supporting assets & Prototype presentation (PPT/PDF)
Earlier SRS	GOAT_666 Online Travel PlatformSoftware Requirements Specification (SRS)

Assignment Grading Checklist

Grading item	Points	Where it is addressed
Table of contents, format description and published prototype link	5	Section 1; Figma prototype URL included
Markdown blog layout	5	Headings, tables, screenshots and links throughout
Key points and challenges that may arise during the assignment	4	Sections 4 and 9
Division of labor among team members and the proportion of work done	6	Section 5; contributions total 100%
Specialized prototype design tool used and mentioned	5	Section 6; Figma interactive‑prototype link
Prototype design process and results	25	Sections 6‑8 and live prototype
Accurate text, clear style, clear design concepts	15	Section 7 and interface annotations
Difficulties encountered, solution attempts, solved status and lessons gained	15	Section 9
Non‑posed team discussion photos and team feelings & peer evaluations	8	Section 10.1 and 10.3
Team plan execution status and workload distribution	4	Sections 5 and 10.2
PPT presentation with accessible prototype link & live prototype demonstration	4	Section 11 and classroom presentation
Classroom report performance	4	Sections 1‑11 and presentation deliverable
Total	100	Blog + prototype + presentation

2. Project Overview and Design Objectives

2.1 Background and Problem Statement

Shanhai‑Travel Platform is a Web‑oriented travel‑service platform for travel‑loving ordinary users, inherited from our Assignment 2 and Assignment3 results.

Travel‑related resources are scattered across many different websites. Users spend plenty of time searching destinations, attractions, travel guides, hotel and ticket resources. Most existing booking platforms require real‑world payment, which makes students hard to experience complete booking workflow without actual money loss. There is also lack of convenient community space for publishing travel‑notes, comments, ratings and favorites.

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

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

Real‑world payment, native mobile APP and third‑party OTA system integration are explicitly excluded from initial‑release scope.

Our SRS v1.4 has defined P0 core mandatory functions and P1/P2 extension functions. This prototype task converts those textual requirements into visible high‑fidelity Web pages and interactive flows.

2.2 Main Users and User Goals

Three core user‑roles defined in SRS: Visitor, Registered User, Administrator.

Visitor: Browse destination information, travel guides, commodity introduction without login; cannot place orders, publish notes or comment.
Registered User: Browse information, complete simulated booking, query/cancel orders, publish travel‑notes, comment, rate and collect favorite content, manage personal profile and private data.
Administrator: Maintain attraction, guide and commodity resource; audit and manage user‑generated travel‑note & comment content.

Core interface goals:

Keep page navigation simple and consistent for different user roles.
Make information hierarchy clear: destination inspiration first, then commodity details and operation entry.
Clearly distinguish visitor‑only view and logged‑in‑user operation entry.
Make simulated booking process easy to understand, explicitly mark that it is simulated without real money transaction.

2.3 From Requirements to Interface Evidence

SRS requirement group	Intended user‑facing experience	Interface evidence location
FR‑AUTH	Account register‑login‑logout‑profile‑edit	Section7.8 Personal‑Center Page
FR‑INFO	Destination, attraction & guide browse & search	Section7.1‑7.3
FR‑BOOK	Hotel‑ticket commodity display, simulated booking, order query & cancel, simulated refund	Section7.4‑7.6
FR‑SOC	Travel‑note publish, comment‑rating‑favorite community interaction	Section7.7
FR‑ADMIN	Administrator resource & content maintenance	Section7.9
FR‑EXT	Personalized Recommendation, AI Trip‑Assistant(extension)	Partial entry reserved in home page, detailed panel is not fully implemented in current prototype

3. Assignment Scope, Design Boundaries and Key Points

This stage focuses on high‑fidelity interface prototype design and explanation, not complete backend deployment. All screenshots show intended UI components, example mock content and clickable entry points.

Features including commodity price, user review content, order amount, inventory number are marked as simulated demo data, not real‑world online service data.

Key design challenges:

Keep visual style unified across more than 9 core pages (home, destination detail, guide, commodity, booking, order, community note, personal‑center, admin page).
Clearly separate permission‑related UI elements: hide order‑submit / publish‑note buttons for anonymous visitors, show them only for logged‑in users.
Guarantee simulated booking flow consistency: date selection, quantity input, inventory deduction prompt, simulated‑refund prompt correspond to business rules defined inside SRS.
Distinguish mandatory P0 pages and P2 extension‑function reserved entries; avoid scope creep in prototype design.
Balance rich travel‑picture display and readable text information on Web pages.

Visual style of our prototype: fresh travel‑oriented design style; large high‑quality destination photograph blocks; card‑style layout for guides & commodities; obvious primary‑action buttons for booking / publish / submit operations; unified navigation bar on top of every page.

4. Project Division of Labor and Contributions

4.1 Team Organization

GOAT_666 team contains total 13 members, inherited grouping structure from Assignment2 and Assignment3.

Project‑coordinator: Zihan Zhao, responsible for overall progress‑tracking, cross‑group communication, requirement alignment between SRS and prototype.
Frontend‑development group: Liucheng Wang, Zexin Zhang, Hongfu Zhao, Wenjie‑Yan. Responsible for high‑fidelity page layout, visual style unification, interaction path design inside Figma prototype.
Backend‑development & database group: Ruizhi Liu, Haomin Lin, Xinyang Zhang, Zerui Xie, Longzhe Lin, Qihang Peng. Responsible for checking prototype against business‑logic rules inside SRS, verifying inventory, booking‑refund, permission‑control related interface rationality.
Test‑group: Minghao Zhang, Zhihua He. Responsible for prototype page cross‑check, inspect missing requirements, record defects found in prototype.
Document‑&‑presentation‑sub‑group: members selected from each group, responsible for blog writing, sorting screenshots, organizing PPT materials, assembling deliverable links.

Group‑leaders organize synchronous meetings to synchronize progress, review prototype pages and resolve understanding divergence.

4.2 Member Responsibilities and Contribution Table

Student ID	Member	Prototype‑stage responsibility aligned with module assignment	Contribution
832401129	Zihan Zhao	Team lead; requirements alignment between SRS‑v1.4 and prototype, overall progress coordination, blog & presentation review	9%
832401218	Liucheng Wang	Frontend group coordinator; home page & destination series page high‑fidelity layout, visual style unification	9%
832401114	Ruizhi Liu	Backend check for simulated booking & order‑cancel flow, verify business‑rule consistency of prototype	9%
832401217	Qihang Peng	Prototype environment check, deliverable file organization, cross‑page navigation jump inspection	8%
832401116	Haomin Lin	Document integration; mapping SRS user‑scenarios to each prototype page, blog format review	8%
832401125	Minghao Zhang	Test group; prototype page requirement coverage inspection, record prototype defects	7%
832401127	Zexin Zhang	Booking, order‑confirm & my‑orders page UI layout and interaction design	6%
832401128	Hongfu Zhao	Community travel‑note publish page, comment‑rating module interface design	6%
832401118	Longzhe Lin	Check prototype page against domain class‑diagram; verify data display rationality	8%
832401123	Wenjie Yan	UI / UX Designer; unify component style, make card, button, form component specification for whole prototype	9%
832401111	Zhihua He	Auxiliary prototype review; inspect visitor / logged‑in‑user permission display difference	6%
832401121	Zerui Xie	Travel‑note & comment‑related interface business‑logic review	8%
832401126	Xinyang Zhang	Commodity product page, simulated‑refund prompt interface check	7%
Total	13 members		100%

5. Prototype Design Tools and Process

5.1 Specialized Tool and Prototype Deliverable

We select Figma as our specialized high‑fidelity prototype design tool.

Online interactive prototype link: https://stirring‑profiterole‑dbfeb1.netlify.app

Figma supports us to draw high‑fidelity Web‑oriented pages, define click‑hotspot areas, configure page jump transitions, and share the whole prototype as public web link for team review and classroom demonstration.

Distinction: Figma prototype is used for interface visualization & navigation demonstration; our SRS document describes the later‑to‑implement React / Spring Boot / MySQL system architecture. Prototype cannot replace real backend development.

5.2 Design Stages

Stage1 — Requirement baseline review Team members read SRS v1.4 carefully, sort P0/P1/P2 requirement priority, compare original low‑fidelity wireframes (UI‑01~UI‑08), confirm which user scenarios and pages must be covered inside this high‑fidelity prototype.

Stage2 — Information architecture definition Confirm top‑level navigation structure: Home / Destination / Travel‑Guide / Commodity / Community / Personal‑Center / Administrator entry. Define global header navigation, footer information, unified component library including button, input form, destination‑card, commodity‑card, note‑card.

Stage3 — High‑fidelity visual drawing Front‑end & UI members draw each core page one‑by‑one according to scenario requirements, import travel‑related picture resources, fill in mock demo data for destination, guide, commodity, order and community content.

Stage4 — Interaction scenario mapping Configure click hotspots and page jumps for core user journeys: visitor browse destination → registered‑user simulated booking → order query & cancel → publish travel note → administrator content management.

Stage5 — Cross‑team review against SRS Backend and test group check each page against SRS user‑scenarios(SC‑01~SC‑06), functional‑requirements FR series, permission rules; record inconsistencies and defects for revision. This blog records review findings and improvement suggestions.

5.3 Visual and Interaction Conventions

Global top navigation bar exists on every page; navigation entries change slightly according to whether current user is logged‑in.
Card‑style component reuse: destination card, travel‑guide card, hotel‑ticket commodity card, travel‑note community card follow unified margin, picture size and text layout specification.
Primary operation buttons (Book Now, Submit Note, Confirm‑Cancel‑Order) use obvious highlight color.
For visitor users: operation buttons requiring login will pop‑up login prompt instead of executing function directly.
All simulated‑booking related pages have small prompt text: "This is simulated booking, no real‑world payment will happen".
Form input area has placeholder text and error hint state reserved for later development phase.

6. Interface Prototype Design and Results

6.1 Home & Destination Overview Page

Home page is the first entry for all users. It includes site slogan, time‑&‑person selector for travel plan, hot‑recommended destination blocks, edited travel‑guide entries, popular travel‑note community content, quick‑access button for starting travel‑plan.

Visitors can scroll to view all public destination and guide content. Login / register button is placed in top‑right corner. Extension‑function AI travel‑assistant entry is reserved on home page.

6.2 Destination Detail Page

After user clicks destination card on home page, jump to destination detail page. Page contains destination introduction, weather hint, scenic‑spot list, local food recommendation, related travel‑guides, nearby accommodation commodity list.

Users can collect this destination (login required). Each sub‑item card supports jump to corresponding detail page.

6.3 Travel Guide Detail Page

Travel‑guide page shows complete editor‑made travel route, day‑by‑day schedule, scenic‑spot arrangement, dining suggestion, estimated budget, suitable travel season. Supports collect, comment operations.

6.4 Accommodation & Product Detail Page

Commodity page shows hotel / scenic‑spot‑ticket information: picture carousel, price, location, service tag, user mock review list, date‑selection component, number selector and "Simulated Booking" primary button.

Click simulated‑booking button will jump to order‑confirmation page. For visitors, clicking booking button triggers login popup prompt.

6.5 Simulated Booking & Order Confirmation Page

This page corresponds to user scenario SC‑02 User Makes a Simulated Booking. It shows selected commodity, check‑in / usage date, purchase quantity, calculated total simulated amount. User can submit simulated order. After submit, system generates a new order record and deduct mock inventory number according to business rule defined in SRS.

6.6 My Orders Page

Correspond to SC‑02 and SC‑05 User Cancels an Order and Views a Simulated Refund. Lists all user’s simulated orders, display different status tags: Pending, Completed, Cancelled‑With‑Simulated‑Refund. Each order item contains “Cancel Order” button. After canceling, page displays simulated‑refund result according to tiered‑refund rule defined in SRS. Empty‑state prompt shows “You do not have any orders yet” when there is no order record.

6.7 Travel‑note Publish & Community Page

Community page displays public user‑published travel‑note list, supports filtering by destination / publish‑time. Registered‑user can click publish button to open travel‑note publish modal, fill title, text content, upload pictures and submit notes. Each note supports comment, rating and favorite operation. Visitors can browse notes but cannot publish or interact.

6.8 Personal‑Center Page

Personal‑center shows user nickname, avatar, basic profile; tab groups for My Orders, My Published Travel‑notes, My Collection, Account Setting. Login‑only page; visitors will be redirected to login page when accessing this url directly.

6.9 Administrator Maintenance Page

Administrator exclusive page. Provide functions: maintain destination & attraction resource, manage travel‑guide content, audit user‑published travel‑notes & comments, hide inappropriate community content. Normal registered users cannot enter this page, will see permission‑denied prompt.

7. Interaction Scenarios and Evidence‑Based Verification

7.1 User Journeys Represented in the Prototype

Journey A — Visitor browses travel content Open home → click hot destination card → browse destination detail → view related travel guide. Visual path exists inside prototype; real click‑jump transition needs live prototype demonstration.

Journey B — Registered‑user completes simulated booking whole‑flow Login → open commodity detail page → select date & quantity → click simulated booking → submit order → jump to my‑orders page → view newly‑created order → click cancel order → view simulated‑refund feedback.

Journey C — Community content publish and interaction Registered‑user enter community page → open publish‑note modal → fill content and submit → view self‑published note inside community list → make comment & rating.

Journey D — Administrator content maintenance Login as administrator identity → enter admin page → edit destination information; audit & operate user travel‑note content.

Journey E — Personal‑center data management Enter personal‑center → switch tab between orders / notes / collections, modify basic account information.

7.2 Verification Matrix: What Is Visible and What Still Requires Clicking

Scenario	Evidence in prototype screenshots	Verification status
T01 Global top navigation & page switch	Home / Destination / Guide / Community / Personal‑Center entry are visible	Visible ; full click transitions need live test
T02 Visitor public‑content browsing flow	Destination, guide, commodity community‑note pages are available	Visible ; login‑popup trigger effect needs live‑click verification
T03 Simulated booking page components	Date‑selector, quantity selector, simulated‑booking button exist	Visible ; submit‑order mock‑inventory‑deduct effect not proved by static screenshots
T04 My‑orders & cancel‑order operation	Order‑status tag, cancel‑order button, empty‑state prompt exist	Visible ; simulated‑refund calculation result needs interactive verification
T05 Travel‑note publish modal	Title, text‑input box, picture‑upload area, submit & cancel button	Visible ; form submit effect not proved by screenshots
T06 Administrator maintenance interface	Resource‑edit entry and content‑audit panel exist	Visible ; permission interception effect needs verification
T07 Personal‑center multi‑tab switching	My‑Orders / My‑Notes / My‑Collection tab group	Visible ; tab‑content switching needs live‑click
T08 AI‑travel‑assistant entrance	Button entry reserved on home page	Entry visible ; dedicated dialogue panel not implemented

Interpretation: At prototype‑design phase, we finished visual coverage for all P0 core pages. Static screenshots can show UI layout, but cannot prove form submission, state change, permission interception and data calculation. In‑class demonstration must open Figma live prototype and perform real clicking navigation.

8. Difficulties, Solutions, Current Status and Lessons

8.1 Mapping SRS text‑based scenarios to high‑fidelity interface pages

Difficulty: Our Assignment‑3 SRS records user‑scenarios, functional‑requirements and low‑fidelity wire‑frames in text format. When upgrading to high‑fidelity prototype, it is easy to miss some tiny requirement details, for example empty‑state prompt, exception hint, permission‑control prompt text.

Solution approach: Build requirement‑traceability checklist. Map each SC‑xx scenario and FR‑xx functional‑requirement to corresponding Figma page. During review, go through checklist item‑by‑item to check whether related UI elements and prompt texts exist.

Status / evidence: We have built the trace‑check table; partial minor prompt texts still need supplement. Partially completed, follow‑up revision needed.

What we learned: Prototype design is not purely drawing pretty pictures; it is the visual translation of requirement documents. Requirement trace‑ability work should run through the whole prototype‑making process.

8.2 Separating demo mock data from real business data

Difficulty: The prototype uses a large amount of mock destination name, commodity price, review content, order amount data. Without clear marks, reviewers may mistake demo mock data for real‑service data.

Solution approach: Add unified small prompt for simulated‑booking related pages; mark mock‑data hint for commodity price, review block inside prototype notes. Explicitly write inside blog: all displayed numbers and user‑generated‑content are demo examples for prototype demonstration only.

Status / evidence: Simulated‑booking page already has prompt text; partial community‑review blocks lack explicit marks. Partially addressed, need further improvement.

What we learned: Early‑stage prototype should clearly distinguish "design intention" and "real‑running service". Explanation text and prompt inside blog and prototype both are important.

8.3 Consistency between booking flow and inventory deduction & simulated‑refund business‑rules

Difficulty: SRS has defined inventory‑deduct rule when submitting simulated order, and tiered simulated‑refund percentage according to advance‑cancel days. It is easy for UI designer to draw booking‑related pages without fully matching these backend business rules.

Solution approach: Backend group members participate in prototype review, check booking‑confirm page, cancel‑order popup, refund‑result prompt against business rules defined in SRS. Record inconsistency points and feed back to UI designer for modification.

Status / evidence: Page layout matches overall flow; mock calculation result of refund popup has not been fully verified by interactive click. Documented review suggestion, needs live‑prototype test.

What we learned: Interface prototype design cannot be separated from backend business‑logic review. Cross‑role team review is critical for avoiding requirement deviation.

8.4 Permission boundary for Visitor / Registered User / Administrator

Difficulty: Multiple user‑roles exist. Some buttons and pages should be hidden or show login‑prompt for visitors; administrator‑only pages must block normal‑user access. It is easy to ignore permission‑related UI difference when drawing pages.

Solution approach: For every page, think over: what will visitor see? What will logged‑in‑ordinary‑user see? What will administrator see? Mark permission‑related element inside prototype comment.

Status / evidence: Main permission‑control UI entry is finished; some pop‑up prompt texts still need polishing. Partially solved.

What we learned: User‑permission logic is not only backend code work; it must be reflected in interface display and prompt information.

9. Team Collaboration, Schedule and Reflections

9.1 Team Discussion Evidence

These photos record our face‑to‑face / online collaborative review process as assignment requires. They capture team members jointly examining prototype design.

9.2 Planning Framework and Evidence of Progress

After Assignment‑3 requirement‑analysis presentation, our team carried out prototype‑design work following this timeline:

Period	Workstream	Output / evidence available in this report
Baseline phase (before Oct‑20)	Review SRS v1.4, sort P0/P1/P2 requirement priority, inherit low‑fi wireframe result	SRS‑v1.4 document, requirement‑traceability draft
Oct‑20 ~ Oct‑24	Define prototype information‑architecture, build unified Figma component library	Reusable button / card / form components inside Figma file
Oct‑24 ~ Oct‑28	Draw high‑fidelity core pages one‑by‑one, fill mock demo data	Complete all P0 core page visual design
Oct‑28 ~ Oct‑30	Configure click hot‑spot and page‑jump interaction path	Interactive jump between core user‑journey pages
Oct‑30 ~ Nov‑01	Cross‑team review against SRS, record defects, write CSDN blog and prepare presentation PPT	This blog article; prototype link; to‑be‑filled PPT assets

The deliverable logic: SRS provides requirement baseline, Figma provides visual interactive prototype, this blog connects prototype pages with requirement documents, records design problems and review findings.

9.3 Collaboration Mechanism and Peer Evaluation

Our team keeps the collaboration mode inherited from previous assignments: WeChat group for daily instant communication; online collaborative document for requirement‑checklist editing; regular synchronous short meetings for progress synchronization.

Workflow for this assignment:

Project coordinator assigns prototype sub‑task to frontend‑UI group according to module division.
After UI members finish drawing pages, deliver to backend & test‑group for cross‑check.
Review‑comments are collected and fed back for prototype revision.
Document‑group assembles screenshots, writes blog content, organizes all deliverable links.

Peer evaluation based on assigned responsibilities: Front‑end & UI members bear the core workload for visual drawing and interaction configuration. Backend members are critical for checking business‑rule consistency between prototype and SRS. Test‑group’s requirement‑coverage inspection helps us avoid missing requirement details. Document members integrate all outputs into standard assignment blog.

Team reflection: Prototype design is a collaborative result of UI designer, backend thinker and tester. Many design defects (data inconsistency, permission‑prompt omission, business‑rule mismatch) can only be discovered through multi‑role cross‑review. Static screenshots can show appearance, but real interactive clicking test is irreplaceable for verifying user‑journey experience. We also realize that we should reserve enough revision time for prototype after first‑version drawing, not only draw pages but also review and iterate.

10. Presentation and Deliverables

10.1 Deliverable Links

Figma interactive Web prototype: https://stirring‑profiterole‑dbfeb1.netlify.app
GitHub assets and Assignment‑4 PPT/PDF: GitHub supporting assets & Prototype presentation (PPT/PDF)
Previous Software Requirements Specification SRS v1.4 PDF: GOAT_666 Online Travel PlatformSoftware Requirements Specification (SRS)

10.2 Classroom Demonstration Script

Open the Figma prototype link in browser; introduce our Shanhai‑Travel Platform project, show top‑level navigation structure.
Demonstrate visitor‑side journey: show home page, jump to destination detail page and travel‑guide page, explain browsing experience for anonymous visitors.
Demonstrate simulated‑booking whole‑flow: enter commodity product page, show date‑selection and simulated‑booking button, show login‑prompt for visitor; switch to logged‑in‑user view, complete simulated‑booking and show order‑confirm page, then enter my‑orders page, demonstrate cancel‑order and simulated‑refund result.
Demonstrate community module: enter community page, open travel‑note publish modal, introduce publish‑note and comment‑rating interaction.
Show personal‑center multi‑tab interface and administrator‑maintenance page, explain three‑role permission boundary.
Point out AI‑assistant reserved entry, explain current prototype boundary (the dedicated dialogue panel is extension function not fully implemented now).
Summarize difficulties and review‑findings in section 8 of this blog; clearly distinguish visual prototype demonstration effect and future backend‑implementation functions.
Remind audience: screenshots inside blog cannot replace real click‑navigation; the classroom demonstration depends entirely on opening live prototype link.

11. Conclusion

GOAT_666 team’s fourth‑assignment high‑fidelity prototype builds concrete visual interface for Shanhai‑Travel online travel platform based on our SRS v1.4 requirement document.

This prototype covers all P0 core function pages: home & destination overview, destination detail, travel‑guide, hotel‑ticket commodity page, simulated‑booking & order‑management flow, travel‑note community publish & interaction, personal‑center and administrator resource‑maintenance page.

Compared with previous low‑fidelity wire‑frames in Assignment‑3, this prototype defines unified visual specification, complete page layout and click‑jump interaction path, converts textual functional‑requirements into visible user‑interface. Meanwhile, prototype review exposed several improvement points: requirement‑trace detail supplement, mock‑data explicit marking, booking‑refund business‑rule verification, permission‑prompt text polishing. These problems should be iteratively optimized before formal development phase.

The AI travel‑assistant only keeps entrance button as P2 extension requirement, complete dialogue panel has not been finished in current prototype. Static screenshots in this blog cannot verify submit‑form, data‑calculation, permission‑interception real‑runtime behavior. All those interactions must be verified by opening live Figma prototype and performing actual clicking in classroom demonstration.

Our team has finished member‑contribution statistics, collected team‑discussion evidence photos, assembled all deliverable links. We will continue to revise prototype according to review findings, prepare for the classroom presentation of this assignment.

Reference documents

Fourth assignment requirement document: <https://bbs.csdn.net/topics/620556488>
Assignment 2 blog of GOAT_666: <https://bbs.csdn.net/topics/620546966>
Assignment 3 blog of GOAT_666: <https://bbs.csdn.net/topics/620556448>
《The Art of Construction》
GB/T 9385‑2008 Specification for Computer Software Requirements
GB/T 45802‑2025 Systems and Software Engineering‑‑Life Cycle Processes‑‑Requirements Engineering

...全文