企业官网建设流程全解析

开头先聊点实在的。这几年我陆续带过软件工程课程设计，也帮不少毕业设计做过评审，还在企业里跟过从零到一、从一到百的各种项目，见得最多的翻车现场不是编码写崩了，而是需求分析阶段埋的雷。很多人觉得"速成"就是跳过分析、直接撸代码，结果做出来的东西要么不是用户要的，要么改到第十版还在改。软件工程里几乎每个环节都能靠短期突击补上来，唯独需求分析不行——它恰恰是那个最能在后期帮你节省返工时间的环节。

这篇就系统梳理需求分析的核心内容，覆盖基本概念、需求获取手段、建模方法、需求规格说明书写法、需求验证与变更控制，还会带上高校新闻网站、电商购物系统这两个课设和毕设里最常见的实战案例，以及我实际踩过的坑。不管你现在是在准备软件工程期末考试、做课程设计，还是刚入行做开发、产品，这部分内容都能直接用。

1. 先说清楚：需求分析不是在"问用户想要什么"

1.1 需求分析的本质：从"愿望"到"约束"

"需求分析"四个字听起来简单，但绝大多数人对它有误解。很多人以为需求分析就是拿着小本子去问用户"你想要什么功能"，然后记录下来，回去交给开发。这其实是需求收集，不是需求分析。

需求分析的本质，是把用户零散的、模糊的、甚至是自相矛盾的"愿望"，转化成一套无歧义、可验证、可指导设计和开发的"系统行为约束"。它做的是翻译和加工的工作，而不是简单的记录。

每次我给课设小组讲这个概念时，都喜欢用一个点菜的类比。顾客进餐厅说"来点好吃的"，厨师不能直接冲进厨房炒菜，他得确认几个人吃、吃不吃辣、有没有忌口、预算多少、是便饭还是请客。软件需求分析就是这个确认的过程，而且比点菜复杂得多——因为顾客往往不是一个人，你说的和用户以为的经常是两回事。

1.2 三层需求模型：业务需求、用户需求、系统需求

在软件工程导论类教材里，需求一般分三个层次：

业务需求对应的是组织或业务层面上的目标，用户需求描述的是用户与系统的交互过程，而系统需求才是真正交给设计、编码、测试人员的"硬性条款"。系统需求又可以拆成功能需求（系统做什么）和非功能需求（系统做到什么标准）。

做课程设计和毕业设计时，很多学生直接跳到第三层，张嘴就是"我要做个登录注册、新闻CRUD"，但你问他这个系统服务的核心流程是什么、谁在用、希望解决什么痛点，他答不上来。这就会导致一个结果:功能是堆出来了，但整个系统没有灵魂，评审老师随便一问"为什么要有这个角色/状态"就卡壳了。

1.3 为什么"需求收集"和"需求分析"不是一回事

再把这个区别说透一点。需求收集是把用户嘴巴里说出来的话原样记下来，它是素材阶段；需求分析是对素材进行归类、抽象、冲突消解、可行性判断，它是加工阶段。

举一个我实际见过的例子。有次一个项目组做高校新闻网站，收集阶段用户提了这些诉求："发布新闻要快""敏感内容不能放出去""编辑们希望手机上也能审核""最好有个热度排行"。如果只做收集，这些需求就是四句口号，开发根本没法排期。但经过分析之后，它们会变成：

• 新闻编辑提交稿件后，系统自动进入待审状态；
• 审核员可在Web端和移动端查看待审列表，通过或退回并填写理由；
• 已发布新闻支持按浏览量和发布时间进行排行展示；
• 系统需对稿件内容进行敏感词过滤，命中敏感词时禁止发布并提示。

这才是需求分析产生的东西：具体的、可设计的、可测试的约束。这条链路搞清楚了，后面所有的方法论才有意义。

2. 需求获取的五种手段：从访谈、问卷到原型验证

2.1 需求获取不是"聊天"，是"结构化挖掘"

一堂课上我做过一个小实验:让两个小组分别去访谈同一个"用户"，结果两个组拿回来的需求清单相差悬殊。原因很简单——一个组拿着问题清单去追问"为什么"，另一个组纯粹是闲聊。需求获取是有方法论支撑的，常见的五种手段是：访谈、问卷调查、观察法、原型法、文档分析。

• 访谈：有结构化（按事先准备好的问题清单）和半结构化（有主线但允许发散）两种。做ToB项目、课设对接甲方时，半结构化访谈最实用，既要保证不跑题，又不能让用户觉得在被审讯。
• 问卷调查：适合用户基数大、需求差异度高的场景，比如校园类系统可以发问卷收集不同学院学生的使用习惯，量大之后做统计分析。
• 观察法：去用户的工作现场看他们是怎么干活的，注意是"看"不是"听"。很多用户的表述能力和实际行为是有偏差的，观察才能拿到真实流程。
• 原型法：这是目前项目里最有效的手段。做一个低保真或高保真的可点击原型，让用户"用"而不是"想"，用户在看到界面之前真的不知道自己想要什么。
• 文档分析：翻现有系统的操作手册、业务表单、统计报表、旧代码注释，里面藏着大量用户已经说不出来的隐性需求。

2.2 访谈的问题清单怎么设计

访谈如果只问"你想要什么功能"，收获一定很浅。我建议每个访谈一定要覆盖这四类问题：

1. 角色类：你在整个业务流程里承担什么角色？你的上一环是谁，下一环是谁？
2. 任务类：你日常最重要的事务是什么？一周大概处理多少量？现在是怎么做的？
3. 痛点类：现在这个过程最让你难受的地方在哪？你希望什么能更快、更省事？
4. 期望类：如果这个系统只能做好三件事，你希望是哪三件？

第三类问题和第四类问题尤其重要。痛点直接对应需求的价值点，而"只能做好三件事"能逼出真正的优先级，防止后面需求蔓延得不可收拾。

2.3 原型法怎么做才有用：以高校新闻网站为例

原型法是目前需求获取阶段的"核武器"。但很多人做原型容易走极端：要么直接上高保真UI，视觉做得很精致，用户一看到颜色不好看就开始纠结配色，完全忘了评审业务流程；要么画一个只可远观的线框图，用户根本不知道点哪里，提不出有效意见。

我的建议是分两步。第一步做低保真原型，重点是把页面结构、信息架构、核心操作路径表达清楚。以高校新闻网站为例，低保真原型至少要有这些页面：首页（新闻列表+分类导航）、新闻详情页、投稿页、后台审核列表页、审核详情页、用户管理页。第二，在低保证原型确认整体流程没问题后，再用墨刀或Axure把关键页面做成高保真可点击版本，交互流程完整到"编辑可以走完投稿-查看审核状态-收到退回通知"这么细。

很多课设小组直接把原型和UI设计混为一谈，给用户看高保真原型时用户全在聊视觉细节，导致原型评审根本评不到点子上。记住，原型的核心目的是验证流程逻辑，不是验证审美。

2.4 电商购物系统的需求获取要点

电商购物系统是毕设里出现频率最高的题目之一，它的需求获取更有代表性，因为角色多、状态多、边界条件多。做这样的系统时，我的建议是先把用户角色理清楚：游客、注册用户、商家/店铺管理员、平台管理员（有时候还有运营和客服）。

然后围绕每个角色去划核心用例，比如游客可以浏览商品、搜索商品；注册用户可以加入购物车、提交订单、支付、查看订单状态、申请退款；商家可以上架商品、修改库存、处理订单、查看销售数据；平台管理员审核商品、管理用户、处理纠纷。

这个题目最容易被忽视的是订单状态流转和库存扣减时机。我见过太多毕业设计把"订单"做成一个只有"已下单"和"已发货"两态的简单表，评审老师一追问退款流程就答不上来。需求获取阶段就应该把状态流转追问清楚，这在后面建模阶段很重要。

3. 从文字需求到可视化建模：用例图、E-R图、流程图与状态图

3.1 为什么不能只靠文字描述需求

纯文字的需求描述有三个致命问题：冗长、有歧义、难以验证完整性。你写"系统要支持订单管理"，不同人对"订单管理"的想象完全不同——有人想到的是列表+筛选+详情，有人想到的是批量发货+退款+对账。

软件工程的核心方法论之一就是"用图形化模型来降低沟通成本"。需求分析阶段最常用的图包括用例图、E-R图、数据流图、状态图、流程图，它们分别从不同视角描述系统。注意，这些图不是画完交差就完事，它们的核心使命是引导评审、暴露问题。

3.2 用例图：划定系统边界的第一张图

用例图是需求分析阶段最该先画的一张图。它的构成不复杂：参与者（Actor）、用例（Use Case）、系统边界框，以及它们之间的关系。

以高校新闻网站为例，参与者有：游客、新闻编辑、审核员、系统管理员。用例方面，游客有浏览新闻、搜索新闻、查看分类、发表评论（如果需求里有）；新闻编辑有提交新闻稿、查看审核状态、修改稿件、撤回稿件；审核员有待审列表查看、审核通过、审核退回、填写审核意见；系统管理员有用户管理、角色权限分配、新闻分类管理、敏感词管理。

画用例图有几个常见错误：一是把所有功能都塞进一张图，结果密密麻麻根本没法评审，正确的做法是按角色或按子系统拆成多张图；二是把"登录"作为所有参与者的单独用例反复出现，其实登录应该作为公共约束写在系统描述里；三是用例命名用"某某管理"这类模糊词汇，用例一定要以"动宾结构"表达用户可观察的目标，比如"提交新闻稿"比"稿件管理"好得多。

3.3 E-R图：把数据需求落到实体关系上

数据需求是需求分析里绕不开的一环，E-R图（实体-联系图）就是用来表达数据需求的模型。很多学生是在数据库课上第一次见E-R图，但它在需求分析阶段的地位远高于数据库设计阶段——它回答的问题是"系统里有哪些核心概念、它们之间是什么关系"。

以电商购物系统为例，核心实体至少包括：用户、商品、商品分类、购物车项、订单、订单项、支付记录、收货地址、店铺（如果有商家概念）。它们的关系要一条条梳理：

• 用户与订单：一对多；
• 订单与订单项：一对多；
• 商品与订单项：一个商品可以出现在多个订单项中，一个订单项对应一个商品；
• 用户与收货地址：一对多；
• 商品与分类：多对一。

这里有个特别容易踩的坑：购物车要不要单独建实体？答案取决于需求，如果需求只是"临时加购、下单即清空"，那购物车可以设计成依赖用户和商品的中间表；如果需求包含"购物车长期保存、跨会话恢复、过期提醒"，那它就是一个独立实体。E-R图的价值就在于此——逼你先把数据层面的需求边界想清楚，而不是到了数据库设计阶段再做决定。

3.4 数据流图、流程图和状态图：动态视角的补充

用例图和E-R图一个偏行为一个偏静态数据，但需求分析还需要表达"过程"。这时候就要用数据流图（DFD）、流程图和状态图。

数据流图描述的是数据的流动和加工过程，它特别适合用来梳理"新闻稿从投稿到发布经历了哪些处理环节"。DFD是分层的，顶层图（上下文图）把整个系统画成一个加工，外部实体用箭头连进来；0层图才开始展开加工细节。画DFD的时候，最常见的错误是控制流和数据流混在一起画，流程图里"判断"代表的是控制流，数据流转不需要画这种菱形判断。

顺便说一句，热搜词里"软件工程流程图"出现频率很高，很多同学其实想画的是业务流程图。画业务流程图建议用泳道图：横向是角色，纵向是时间或阶段，每个活动落到对应角色的泳道里。比如高校新闻网站的投稿审核流程，编辑在"投稿"泳道发起，系统在"系统处理"泳道自动分词和敏感词过滤，审核员在"审核"泳道操作，每个角色各占一行，流程是否清晰一目了然。这种图更适配需求获取阶段的沟通，是评审会上用户最容易看懂的一种图。

状态图则聚焦某一个对象的生命周期。电商订单状态是最经典的案例：待支付、已支付（待发货）、已发货、已签收、已完成、已取消、售后中。注意这里有个容易被忽略的点——已取消和售后中不是同一个分支下发生的，取消是支付前或发货前的事务，售后是签收后的事务。把这张状态图画清楚，开发阶段才不会把订单状态做成一个无脑的字符串字段。

3.5 建模工具怎么选

建模工具不需要纠结太久，根据团队基础快速定就行：

• 课堂上快速画、交作业：draw.io（免费、网页版、支持导出图片和编辑源文件）
• 更规范一点、要管理大型模型：StarUML、Enterprise Architect
• 团队协作、评审方便：ProcessOn、boardmix
• 喜欢用代码维护模型：PlantUML（写文本就能生成图，适合放Git仓库管理）

我个人建议课设和毕设用draw.io就够了，关键是图的内容，不是图的颜值。评审老师看重的是图中的实体关系、状态流转是否合理，而不是配色。

4. 需求规格说明书（SRS）的结构与撰写方法

4.1 SRS是一份"可验证的合同"

需求分析阶段的产品级交付物，是一份需求规格说明书（Software Requirements Specification，SRS）。它面向的目标读者不是用户，而是设计、开发、测试人员，所以在写法上和要求上，与需求获取阶段那些口语化记录完全两回事。

SRS的本质是"契约"。开发按它写代码，测试按它做用例，验收按它做检查，所以里面的每一条描述都必须是可验证的。可验证的最低标准是：任何人读这句话，都能判断系统当前状态是否满足它。反例是"系统应运行流畅"，正例是"在1000并发用户条件下，首页响应时间不超过2秒"。

4.2 SRS的标准结构，以IEEE 830为基础

目前主流的SRS结构多参考IEEE 830 / ISO/IEC/IEEE 29148，一般包含：

1. 引言：目的、范围、定义、参考文献
2. 总体描述：产品视角、用户特征、运行环境、约束、假设与依赖
3. 外部接口需求：用户界面、硬件接口、软件接口、通信接口
4. 系统功能需求：按功能模块组织，每个模块下列具体需求条目
5. 非功能需求：性能、安全、可用性、兼容性、可维护性、可移植性
6. 其他需求：法规、标准、文化或政策相关约束

课设和毕设的SRS不需要写上百页，但结构要完整。我见过不少同学一到"总体描述"就写"本系统是一个基于B/S结构的管理系统"，一句话就没了。实际上，总体描述的核心是用户特征和产品视角：谁来用？他们有什么特征？系统要解决什么问题？这直接决定了功能列表有没有偏离方向。

4.3 功能需求的编写：统一模板 + 编号 + 可测试

功能需求的写法最推荐"用户故事+验收标准"的组合模式。用户故事的经典模板是：

作为（某个角色），我希望（系统做什么），以便（达成什么价值）。

比如高校新闻网站的投稿功能，可以写成：

• FR-1.1 作为新闻编辑，我希望在稿件提交时上传正文和封面图，以便新闻在审核通过后直接展示完整内容。
• FR-1.2 编辑提交后，系统应自动将稿件状态置为"待审核"，并通知审核员。
• FR-1.3 审核退回时，系统应记录退回理由并通知编辑，编辑可修改后重新提交。

每一条还要带验收标准。验收标准描述的就是"怎么测试它"。例如FR-1.2的验收标准是：编辑在投稿页面提交稿件后，后台稿件列表中该稿件状态显示为"待审核"，同时审核员账号在待办列表能看到这条记录。

需求编号极其重要，它是后面需求跟踪矩阵的锚点。我一般用模块前缀+流水号，比如FR开头表示功能需求，NFR表示非功能需求，UI开头则表示界面需求。编号一旦确定不要随意改，否则后面管理和追溯都会乱套。

4.4 非功能需求为什么是需求分析里的"隐形杀手"

功能需求人人都知道要写，非功能需求却常常被忽略。但真实项目里，非功能需求往往是上线后暴露问题最多的部分。

以电商购物系统为例，非功能需求至少包括：性能（首页在并发500时响应时间不超过3秒）、安全（密码必须加密存储、接口要防SQL注入）、可用性（核心操作在故障恢复后5分钟内可用）、兼容性（支持Chrome、Edge、Safari三款浏览器的最新两个版本）、可维护性（日志记录关键操作、代码注释覆盖率）。

写非功能需求同样要遵守"可验证"原则。"密码要加密"就不合格，"密码存储必须使用BCrypt算法进行加盐哈希"才合格。对课设而言，评审老师特别喜欢问"你的性能指标是怎么来的"，如果你写"支持高并发"却拿不出任何依据，那就变成过度设计了。合理的做法是根据使用场景去推算，校园新闻网站峰值并发可能只有几十，那性能指标就按这个量级去定，这才叫分析。

4.5 需求条目的优先级：MoSCoW法怎么用

需求优先级是SRS里很容易被忽视的内容。没有优先级，开发团队不知道先做哪个后做哪个，只能凭感觉排期，最后必出问题。我自己在项目里最常用的是MoSCoW法：

• Must Have（必须有）：系统没有它就无法运转，比如电商的"提交订单""支付"；
• Should Have（应该有）：重要但可以暂时降级，比如"订单批量导出"；
• Could Have（可以有）：锦上添花，比如"商品收藏列表排序"；
• Won't Have（这次不做）：明确告知不在本次范围，比如"多语言支持"。

特别注意"Won't Have"的价值。很多需求蔓延之所以控制不住，是因为没人明确说"这个功能不做"。把Won't Have写进文档，相当于给需求边界画了一条硬线，用户再提的时候可以直接拿文档出来说"这块已经在范围外了"。

5. 需求验证与变更管理：让需求真正"定下来"

5.1 需求评审：不止是"开个会"

需求分析完成后不能直接交给开发，必须经过验证。需求评审是最常见的验证手段，但很多项目的评审会开成了"走过场"。一份需求文档能不能过评审，要提这几个问题：

• 完整性：角色有没有遗漏？异常流程（取消订单、审核退回、支付超时）有没有覆盖？
• 一致性：FR-1.2说"自动通知审核员"，UI需求里有没有对应的通知列表入口？
• 可验证性：有没有出现"快速""友好""强大"这种无法测试的词汇？
• 可行性：技术团队能不能做？工期够不够？数据量撑不撑得起？

评审会一定要让用户代表、开发、测试、项目经理四方到场。测试角色尤其不能缺，因为测试人员是SRS最忠实的用户，他们拿到需求文档第一件事就是琢磨"这个功能怎么测"，如果测试提不出测试思路，这个需求大概率是模糊的。

5.2 原型走查：比评审会更能发现问题

比文档评审更有效的是原型走查。让用户代表"假装完成一个真实任务"，比如电商系统里"作为买家，我要完成从搜索商品到提交订单的全流程"。走查过程中他每卡一下，就说明这里有一个交互或流程问题。

走查的记录方式建议用表格，逐条记录：走查编号、操作步骤、实际结果、期望结果、问题严重程度（高/中/低）、建议改进。这样产出的走查报告可以直接作为SRS的修订依据，也方便追踪每条问题有没有闭环。

5.3 需求跟踪矩阵：从需求到测试用例的一条线

热搜词里有一条"从需求分析到测试报告：AI自动生成测试用例的完整实践指南"，这条思路的前提就是需求条目足够清晰，而且建立了需求跟踪矩阵（RTM）。

需求跟踪矩阵就是一个表，每行是一条需求条目，列是它的落点：对应设计模块、对应代码模块、对应测试用例、测试结果、是否通过。它的意义是确保每一条需求都能从"提出"追溯到"实现"与"验证"，没有孤儿需求，也没有无人认领的测试项。

更现实的意义在于，当需求变更发生时，RTM让你可以快速评估"这个需求改了会影响哪些设计和测试用例"。没有RTM的项目，需求变更就像往湖里扔石头，你不知道涟漪会荡到哪里。

现在的实践里，如果你把SRS里每一条功能需求写成标准的用户故事+验收标准，喂给AI工具去生成测试用例，效果比直接扔一段描述强得多。AI生成测试用例的前提是需求本身够结构化和无歧义。这不是AI的魔法，是需求分析质量的外溢。

5.4 需求变更：防的不是变更，是"无记录的变更"

需求变更是软件工程里绕不开的常态，用户今天说"加个功能"，明天说"改个状态"，如果没有一套变更管理机制，项目会被拖死。

规范的变更流程是：

1. 提出变更：任何人提出，填写变更申请（描述变更内容、原因、期望时间）；
2. 影响分析：分析变更对范围、进度、成本、质量的影响，更新RTM；
3. 审批：由变更控制委员会（CCB）决定接受、拒绝、还是暂缓；
4. 实施与验证：批准后更新SRS和相关模型，开发实施并补充测试；
5. 归档：记录变更记录，确保文档和代码同步。

这里有个务实建议：课设和毕设里不必搞严格的CCB，但至少要有一个"需求变更记录表"，每次变更都登记：变更日期、变更内容、原因、影响模块、是否已修改SRS、是否已补充测试用例。有了这张表，答辩时评审老师问"你遇到需求变更怎么处理"，你就能拿出实际材料来讲，而不是空口说理论。

5.5 需求蔓延的日常防御

需求蔓延（Scope Creep）的本质，是范围没立好边界，变更又没有节制。日常防御手段很朴素，但很管用：

• 一个功能如果不在Must Have里，默认不进本期开发；
• 用户口头提的需求，必须经过邮件或文档确认才生效，不确认就当没提过；
• 每次评审会结束发一份会议纪要，写明"本次确定做什么、不做什么、谁负责什么"；
• 需求文档改版，要有版本号，有改动说明，不能悄无声息地替换。

这些动作都不难，但真的坚持做下来的人不多。需求分析工作做得好不好，最终看的就是这套流程纪律有没有被遵守。

6. 那些年我们一起踩过的需求坑：真实案例复盘

6.1 "做一个简单的后台"：需求边界不清的典型翻车

有个项目组接了一个任务，甲方说"我们就想要一个简单的后台，把文章管起来"。项目组默认就是文章CRUD，没追问，没建模，直接开干。做完了交付，甲方说"不对啊，我们主任只能看自己部门文章，副主任要能审稿，还有两种角色的管理员权限不一样"。

这就是典型的没有做角色分析和权限需求分析。口头上"简单"的CRUD，实际落地要的是多角色RBAC权限模型、部门数据隔离、审核流。如果一开始画一张用例图、理一下角色，这个结果完全可以在两周前暴露出来，而不是到交付验收时才炸掉。对策很简单：用户说"简单"的时候，你要反问"简单是指功能数量，还是使用人数？谁来用？他们在组织里是什么位置？"

6.2 "删除订单"到底是物理删除还是逻辑删除

这个问题我在点评毕设时至少遇到过五次。需求文档里写着"用户可以删除已完成的订单"，开发直接执行DELETE语句把记录删了，用户后来投诉说"我看不到历史订单了"。

"删除订单"就是一个二义性需求。用户语境里的删除，大概率意思是"从我的订单列表里隐藏"，而不是"彻底销毁交易记录"。正确做法是在需求分析阶段就明确删除语义：

• 物理删除：管理员删除违规商品数据，底层表记录一并清除；
• 逻辑删除：订单添加"已删除"标记，用户列表不再展示，但数据保留用于统计和追溯。

我建议在SRS里增加一条术语表，把所有"删除""禁用""停用""注销"这类近义词都定义清楚。这个细节不花多少时间，但能省下后期无数扯皮。

6.3 高并发需求是怎么变成一场灾难的

课设里最容易被抓的过度设计，就是没有依据的"高并发"。有个学生做校园二手交易平台，SRS里写了"系统支持高并发访问"，我问他高是几十还是几万，他说不知道，看网上都这么写。

高并发本身不是需求，是基于业务预测的性能指标。校园二手平台，同时在线可能就一两百人，真正同时提交订单的并发可能只有几十。你按这个量级设计，单机应用配个稳定的关系型数据库完全够用。如果你没有预测数据却按照"秒杀场景"去设计，引入消息队列、分布式缓存、分库分表，结果就是把简单系统做复杂，开发和维护成本全上去了。

需求分析阶段写非功能需求时，一定要问三个问题：当前业务量是多少？未来一年预计增长多少？极端峰值场景是什么？数据跑出来是几十，就按几十设计；数据跑出来是几万，再考虑分布式方案。

6.4 需求文档写得很厚，开发却做错了优先级

有个项目组在SRS里写了五十多条功能需求，但没有标优先级。开发团队从第一条开始做，做到第四十天才发现，最重要的"审核流"反而排在后面，而用户最关心的投诉处理功能（Won't Have）被反复追问"怎么还没做"。

这就是没有提前用MoSCoW法做优先级排序的结果。五十条需求全部是Must，就等于没有Must。后来我帮他们重新梳理：核心的投稿-审核-发布闭环是Must，数据统计分析是Should，个性化推荐是Could，多语言是Won't。重排之后，开发计划立刻清晰了。

这个坑的教训是：优先级不是产品经理一个人的事，它必须写进SRS里，并且在每次评审时都要口头确认。用户嘴上说"这个功能很关键"，和你在SRS里把它标成Must Have，是两回事。

6.5 原型给用户看晚了，等于白做

最后一个案例是关于原型的时机。有个小组花三周做了一个很漂亮的高保真原型，觉得"等全部细节都设计好再找用户确认"，结果用户一看就蒙了："你们怎么没有首页轮播图？我们官网必须有轮播图，这是惯例。"而他们因为前期没确认这个信息，整个首页改版花了一周。

原型最重要的作用不是展示设计成果，而是尽早暴露认知偏差。正确做法是第一周就把低保真原型拿给用户走查，哪怕只有线框图和页面结构，用户也能立刻告诉你"这里少了什么环节、那个流程不对"。越是粗糙的原型，用户越敢提意见；越是看起来完成度高的原型，用户越容易被视觉带偏，反而漏掉流程问题。画原型要快、要便宜、要早。

关于需求分析，我这些年的核心体会是：它在整个软件工程里看起来最不"技术"，但最考验沟通能力和结构化思维能力。需求分析做得扎实，后面设计、编码、测试全部顺风顺水；需求分析糊弄过去，后面每一步都会拿时间和返工来还债。所谓"速成"，不是跳过这个阶段，而是用一套系统方法快速把它做深做透。如果你现在手里正好有个课设或毕设项目，建议别急着建工程写代码，先花一到两天把角色、用例图、E-R图、核心流程图和一页纸的需求清单整理出来，拿给同学或老师走查一遍，你会回来感谢这个习惯的。