企业官网建设流程全解析

需求分析这件事，干过几年项目的人都有一肚子话想说。我见过太多团队在需求阶段埋雷，然后在开发和验收阶段花三倍精力去排雷。有意思的是，几乎所有人都认同“需求分析很重要”，但真正愿意在需求环节花时间打磨的团队少之又少。大多数人把需求文档当成一个“走流程的交付物”——写完了往共享盘一扔，开发照着做，做完发现不对再改，改完再对不上再吵。这个循环我经历过不止一次，后来才慢慢想明白一件事：需求分析的核心不是“写一份文档”，而是“把一群人脑子里各自以为一致的东西，变成真正一致的东西”。这篇内容就是围绕这个认知展开的，从怎么提需求、怎么写需求两个角度，把需求分析这件事拆开揉碎讲清楚。不管你是刚入行的产品新人、被需求文档折磨过的开发，还是带团队的项目负责人，下面这些从实际项目里摔打出来的经验，应该都能帮你少走一些弯路。

1. 需求分析到底在解决什么问题

很多人对需求分析的理解停留在“把用户想要的东西记下来”这个层面。如果真是这样，那需求分析就太简单了——找用户聊聊天，记个笔记，整理成文档，完事。但实际项目里你会发现，用户说的“我想要一个报表功能”和开发理解的“做一个数据导出按钮”之间，隔着一条巨大的鸿沟。需求分析真正要解决的，是这条鸿沟。

1.1 需求不是“收集”来的，是“翻译”出来的

我刚开始做项目的时候，习惯性地把需求分析等同于“需求收集”。用户说什么我就记什么，生怕漏掉任何一条。结果呢？需求列表越拉越长，开发看了直摇头，做出来的东西用户又不认。后来我才意识到问题出在哪：用户表达的是“他以为他需要的东西”，而不是“他真正需要解决的问题”。

举个很典型的例子。某次做一个内部审批系统的改造，业务方提的需求原话是“审批流程要支持会签”。如果直接照搬，开发就会去做一个“多人同时审批”的功能。但深聊之后发现，业务方真正的痛点是“有些审批需要多个部门确认后才能通过，现在只能一个个串行审批，太慢了”。你看，“会签”是业务方给出的解决方案，而“多部门并行确认”才是真实需求。这两者对应的技术方案完全不同——前者可能只需要加一个审批人字段，后者需要重新设计审批节点的流转逻辑。

所以需求分析的第一层工作，是把用户嘴里的“解决方案”翻译回“问题本身”。这个翻译过程需要反复追问：你现在是怎么做的？哪里觉得不舒服？如果这个功能上了，你第一步会怎么操作？这些问题看起来简单，但能逼着用户从“我想要什么功能”切换到“我在什么场景下遇到了什么障碍”。

1.2 需求文档的本质是“共识载体”

另一个常见的误解是把需求文档当成“给开发看的说明书”。这个定位不能说错，但不够准确。需求文档更重要的角色是“共识载体”——它要让业务方、产品、开发、测试这几拨人在同一个页面上理解同一件事。

我踩过最典型的一个坑是：需求文档里写了一句“系统应支持灵活的角色权限配置”。我觉得这句话很清楚了，开发也觉得没问题。结果做出来之后，业务方说“这不是我要的灵活”，开发说“你当时没说清楚灵活到什么程度”。问题出在哪？“灵活”这个词在每个人脑子里的画面是不一样的。业务方想的是“我能自己拖拽配置每个按钮的权限”，开发理解的是“后台有一个角色管理页面可以增删角色”。

后来我养成了一个习惯：凡是需求文档里出现“灵活”“高效”“友好”“合理”这类形容词，一律替换成具体的场景描述或验收标准。比如“灵活的角色权限配置”改成“管理员可以在不联系开发的情况下，为新增角色勾选其可访问的菜单项和操作按钮，配置生效时间不超过一分钟”。这样写虽然啰嗦，但没有人会产生歧义。

1.3 需求分析的产出不只是文档

很多人以为需求分析的终点就是一份需求规格说明书。但从实际项目来看，需求分析阶段真正有价值的产出至少包括四样东西：一份明确的需求清单（做什么、不做什么）、一组可验证的验收标准（怎么判断做完了）、一张关键流程的梳理图（业务怎么流转）、以及一份风险与假设清单（哪些地方还不确定、依赖什么前提）。

这四样东西里，最容易被忽略的是“不做什么”和“风险假设”。我见过太多需求文档只写“要做什么”，不写“不做什么”，结果开发做着做着就开始自由发挥，加了一堆没人要的功能。至于风险假设，更是很少有人主动写——大家都倾向于表现得“一切尽在掌握”，但实际项目里，需求阶段的不确定性是最高的，把假设和风险显性化，反而能让后续的变更管理有据可依。

2. 提需求的正确姿势：从场景出发而不是从功能出发

“提需求”这个动作，大多数人以为是业务方的事，跟技术团队关系不大。但实际项目里，技术团队往往需要引导业务方把需求提清楚。如果业务方提需求的方式不对，后面写需求文档的人就要花大量时间去补窟窿。所以这一章既写给提需求的人看，也写给接需求的人看——知道对方应该怎么提，你才知道怎么接。

2.1 用“场景-障碍-期望”三段式把需求说清楚

我总结了一个很土但很好用的方法，叫“场景-障碍-期望”三段式。任何一条需求，如果能用这三段话说清楚，基本就不会跑偏。

第一段是场景：什么人在什么情况下会用到这个功能？比如“仓库管理员在每天下班前需要核对当天所有出库单的状态”。第二段是障碍：现在这个场景下有什么问题？比如“目前需要逐条点开每个出库单查看状态，一百多条单子要花将近一个小时”。第三段是期望：希望达到什么效果？比如“希望能在一个页面上看到所有未完成出库单的汇总状态，并且能按状态筛选”。

这个三段式的价值在于，它强迫提需求的人把“功能”放回到“场景”里去描述。你会发现，很多需求一旦用这个框架过一遍，要么变得非常清晰，要么直接暴露出“其实没有这个场景”的问题。我遇到过好几次，业务方兴冲冲提了一个功能需求，结果在描述场景那一步就卡住了——说不清楚谁会用、什么时候用。这种需求大概率是“伪需求”，要么是看到别人有所以自己也想要，要么是某个人的个人偏好。

提示：如果一条需求没法用“场景-障碍-期望”说清楚，先别急着写进需求池，大概率是还没想明白。

2.2 区分“想要”和“需要”：优先级判断的实操方法

需求池里永远堆满了“想要”的东西，但资源永远有限。怎么判断哪些是“需要”、哪些只是“想要”？我常用的方法是问三个问题。

第一个问题：如果不做这个需求，当前业务会不会出问题？如果答案是“不会，只是不太方便”，那这条需求的优先级就应该往后放。第二个问题：这个需求影响多少人？是所有人都受影响，还是只有个别岗位？影响面越大优先级越高。第三个问题：有没有替代方案？比如用户想要一个自动导出功能，但现有系统其实支持手动复制粘贴，只是操作麻烦一点——这种情况下，自动导出是“想要”，不是“需要”。

这三个问题问下来，大部分需求都能被归到四个象限里：高影响+无替代方案的，优先做；高影响+有替代方案的，排期做；低影响+无替代方案的，看资源做；低影响+有替代方案的，先不做。这个判断逻辑听起来简单，但实际用起来非常有效，因为它把“谁嗓门大谁的需求先做”变成了一个可以讨论的判断框架。

2.3 需求提报时最容易漏掉的三类信息

即使需求本身说清楚了，提报的时候还是经常漏东西。根据我的经验，最容易漏的是三类信息：边界条件、异常流程、以及非功能约束。

边界条件是指“这个功能在什么范围内有效”。比如“支持批量导入”这个需求，边界条件包括：一次最多导入多少条？支持什么格式的文件？字段缺失怎么处理？这些不写清楚，开发做出来的东西大概率跟预期不符。

异常流程是指“正常流程走不通的时候怎么办”。大部分人在提需求的时候只描述“一切顺利”的情况，但实际使用中异常才是常态。比如审批流程，正常情况是“提交-审批-通过”，但异常情况包括：审批人离职了怎么办？审批超时了怎么办？提交后想撤回怎么办？这些不提前想清楚，上线后就是一堆工单。

非功能约束是指性能、安全、兼容性这些“不是功能但影响功能”的要求。比如“页面加载时间不超过两秒”“支持主流浏览器”“敏感数据需要脱敏展示”。这些约束如果不提前写进需求，开发默认不会主动做，等到验收的时候再提就来不及了。

3. 写需求文档的骨架：一份能落地的需求规格该长什么样

写需求文档最怕两种极端：一种是写得太简略，几页纸全是“系统应支持XX”的句式，开发看了等于没看；另一种是写得太啰嗦，把每个按钮的颜色都规定死，开发看了觉得被冒犯。好的需求文档应该像一份菜谱——食材、步骤、火候都写清楚，但具体怎么切菜、怎么翻锅，留给做菜的人发挥。

3.1 需求文档的最小可用结构

我经过多个项目迭代，最后沉淀下来的需求文档结构大概是这样的：概述、干系人与角色、业务流程说明、功能需求清单、非功能需求、验收标准、假设与依赖、附录。这个结构不是死的，小项目可以合并章节，但核心要素不能少。

概述部分要写清楚这个需求解决什么问题、涉及哪些模块、预期上线时间。干系人与角色部分要列出所有跟这个需求有关的人和系统，以及他们各自的诉求。业务流程说明用文字加流程图的方式把核心流程走一遍，重点是标出异常分支。功能需求清单是主体，每条需求要有编号、描述、优先级、验收标准。非功能需求单独列一节，把性能、安全、兼容性要求写清楚。假设与依赖部分把“我们假设XX成立”“这个需求依赖XX系统先上线”这类信息显性化。附录放参考资料、术语表、变更记录。

这个结构里，我认为最重要的是“验收标准”这一项。很多需求文档写了功能描述但不写验收标准，结果开发和测试对“做完了”的理解不一致。验收标准要写成可验证的句子，比如“当用户输入超过50个字符时，输入框下方显示红色提示文字‘最多输入50个字符’，且提交按钮置灰”。这种写法虽然细，但能省掉大量扯皮。

3.2 功能需求怎么写才不产生歧义

功能需求是需求文档里最容易出问题的部分。我总结了几条实操规则，都是被坑出来的。

第一条：一条需求只描述一件事。不要把“用户可以创建订单并查看订单状态”写成一条，拆成两条——“用户可以创建订单”和“用户可以查看订单状态”。拆开之后，优先级可以分别设定，验收也可以分别做。

第二条：用主动语态，明确主语。写“管理员可以删除用户”，不要写“用户可以被删除”。后者没说是谁删的，是管理员删的、系统自动删的、还是用户自己注销的？主语不明确，开发就得猜。

第三条：避免使用“等”“之类”“相关”这种模糊词。“支持按名称、日期等条件筛选”里的“等”字，开发看了会问“到底还有哪些”。要么列全，要么明确写“支持按名称和日期筛选，其他筛选条件不在本期范围内”。

第四条：每条需求都要有唯一编号。这个编号后面在测试用例、变更记录、缺陷跟踪里都要用，没有编号就没法追溯。编号规则可以简单一点，比如“FR-模块缩写-序号”，FR-ORDER-001这种。

第五条：需求描述后面紧跟验收标准。格式可以是“需求描述：……；验收标准：1.……2.……”。验收标准要覆盖正常流程和关键异常流程，不用覆盖所有异常，但主要的几条要有。

3.3 非功能需求：最容易被跳过但最不该跳过的部分

非功能需求在需求文档里经常被一笔带过，甚至直接不写。但我可以很负责任地说，上线后最难改的问题，大部分都跟非功能需求有关。功能做错了可以改，架构层面的性能问题、安全问题改起来伤筋动骨。

非功能需求至少要覆盖这几个维度：性能（响应时间、并发量、数据量级）、安全（权限控制、数据脱敏、操作审计）、兼容性（浏览器版本、分辨率、操作系统）、可用性（错误提示是否清晰、操作是否有确认机制）、可维护性（日志记录、配置项管理）。

写非功能需求的时候，尽量量化。不要写“系统应快速响应”，写“在1000条数据量级下，列表页加载时间不超过2秒”。不要写“系统应保证数据安全”，写“用户手机号在列表页展示时中间四位用星号代替，导出时需二次确认并记录操作日志”。量化的指标不一定都能达到，但至少给了开发和测试一个明确的靶子。

注意：非功能需求的指标要在需求评审时跟开发和测试对齐，确认在当前技术架构下是否可行。我见过需求文档里写“支持一万并发”，结果开发看了说“当前架构最多撑两千”，这种指标写了等于没写，还会引发不必要的争论。

4. 需求评审：把分歧消灭在开发动手之前

需求评审是需求分析阶段最后一道关口，也是分歧最集中的地方。我参加过效率极高的评审会，也参加过开了三个小时什么都没定下来的评审会。差别在哪？不在于参会人的水平，而在于评审会之前有没有做足准备，以及评审的流程设计是否合理。

4.1 评审会之前必须做的三件事

第一件事：提前发材料。需求文档至少在评审会前一天发给所有参会人，并明确要求“请提前阅读，会上直接讨论问题”。我见过太多评审会是当场发文档当场读，读完一半时间就过去了。提前发材料这个动作看起来简单，但能筛掉一半“其实没什么意见只是来听听”的参会人。

第二件事：明确评审目标。评审会到底是评审“需求要不要做”还是“需求怎么做”？这两个目标的参会人和讨论方式完全不同。如果混在一起，就会出现业务方在讨论技术方案、开发在质疑业务价值的混乱场面。我的做法是分两次评审：第一次评审需求价值和范围（业务方、产品参加），第二次评审需求细节和可行性（产品、开发、测试参加）。

第三件事：指定记录人和决策人。评审会上一定会产生各种意见和待办事项，没有记录人就会漏掉。决策人则负责在意见不统一的时候拍板，避免会开完了但没有结论。这两个角色最好在会前就指定好，不要会上临时抓人。

4.2 评审会上怎么讨论才不跑偏

评审会跑偏是常态。常见跑偏场景包括：讨论技术实现细节、纠结界面颜色字体、翻旧账讨论上一个项目的问题。控制跑偏的责任在主持人，但参会人也可以主动拉回来。

我的经验是，评审会上只讨论三类问题：需求是否清晰（有没有歧义）、需求是否完整（有没有漏掉关键场景）、需求是否可行（当前资源和技术能不能做）。超出这三类的，一律记入待办，会后单独讨论。比如开发在会上说“这个功能用现有架构实现不了”，主持人应该追问“是完全做不了，还是需要额外工作量”，如果是后者，记下工作量评估待办，不在会上展开技术方案讨论。

另一个实操技巧是：每条需求评审完，当场确认三个信息——优先级、验收标准、责任人。优先级不确认，后面排期就会吵；验收标准不确认，做完就会扯皮；责任人不确认，出了问题就找不到人。这三个信息确认完，这条需求才算评审通过。

4.3 评审之后的变更管理

需求评审通过不代表需求不会再变。实际项目中，需求变更几乎不可避免。关键不是杜绝变更，而是让变更可控。

我的做法是建立一个简单的变更记录表，每次变更记录五个信息：变更内容、变更原因、影响范围（涉及哪些功能模块和排期）、决策人、生效时间。这个表不需要多复杂，一个共享表格就够。它的价值在于，当项目延期的时候，你可以拿出这个表说“延期是因为这三次变更，每次变更增加了多少工作量”，而不是空口扯皮。

另外，变更要走评审。小变更（比如文案调整）可以简化流程，口头确认加记录即可；大变更（比如新增一个功能模块）必须重新走评审，重新评估排期。我见过最离谱的情况是，业务方直接在开发群里说“加个功能”，开发顺手就做了，结果做完发现影响了其他模块，最后谁都不认账。变更没有记录，就等于没发生过。

5. 需求分析中那些没人明说但很重要的经验

前面几章讲的都是方法和流程，这一章聊点更“软”的东西。这些东西在正式的方法论里很少提，但在实际项目中往往决定了需求分析的成败。

5.1 跟业务方沟通时，先听懂“潜台词”

业务方提需求的时候，很少会直接说“我担心XX”。更多时候，他们说的是“这个功能能不能再加一个确认弹窗”。表面上看是加个弹窗，潜台词可能是“上次操作失误导致数据错了，我被领导批了”。如果你只按字面需求做，加了个弹窗，但没解决“操作失误”的根本原因（比如缺少二次确认机制、缺少操作回退功能），下次他还会提别的需求。

听懂潜台词的方法是多问一句“为什么”。用户说“这里要加个提示”，你问“什么情况下会触发这个提示”，他可能会说“上次有人误删了数据”。你再问“误删之后怎么处理的”，他可能会说“找开发从备份恢复的，很麻烦”。到这一步，真实需求就浮出来了：不是加提示，而是加删除前的二次确认和删除后的回收站功能。

5.2 需求文档写完之后，自己先“走”一遍

这个习惯是我从一位前辈那里学来的：需求文档写完之后，不要急着发出去，自己对着文档把核心流程在脑子里走一遍。假设自己就是用户，从打开页面开始，一步步操作，看文档里有没有描述不清楚的地方。

我每次这么走一遍，都能发现几个问题。比如写着“用户提交表单后跳转到列表页”，走一遍就会问：提交失败了跳哪？提交过程中按钮要不要置灰？列表页是跳回第一页还是停留在当前页？这些问题在写的时候很容易漏掉，但走一遍就能发现。走完之后把发现的问题补进文档，文档质量能提升一大截。

5.3 给需求留出“呼吸空间”

最后一条经验可能有点反直觉：需求不要写得太满。我早期写需求文档，恨不得把每个细节都规定死，觉得这样开发就不会做偏。后来发现，写得太满反而容易出问题——因为需求阶段不可能预见所有情况，写得太死会让开发在遇到意外情况时没有调整空间，只能回来找你确认，反而拖慢进度。

更好的做法是：核心流程和验收标准写死，实现细节留出弹性。比如“用户列表支持按姓名搜索”这条需求，搜索框放哪、要不要加搜索按钮、搜索结果是前端过滤还是后端查询，这些可以留给开发根据技术情况决定，你只需要在验收标准里写清楚“输入姓名后，列表展示匹配的结果，无匹配时显示‘暂无数据’”。给开发留出发挥空间，他们反而更愿意在遇到问题时主动想办法，而不是事事回来问你。

6. 从需求到验收：怎么判断需求真的“做完了”

需求分析的终点不是文档写完，而是需求被正确实现并被验收。很多团队在需求文档写完后就撒手不管了，等到验收的时候才发现做出来的东西跟预期不符。这一章讲怎么在需求阶段就为验收铺好路。

6.1 验收标准要写到“可测试”的程度

验收标准是需求文档里最需要花心思的部分。我见过很多验收标准写的是“功能正常”“页面展示正确”“操作流畅”，这种标准等于没写，因为没法测试。

可测试的验收标准长什么样？举个例子。需求是“用户可以修改个人头像”。不可测试的验收标准是“头像上传功能正常”。可测试的验收标准是：1. 点击头像区域弹出文件选择框，支持jpg和png格式；2. 选择文件后显示预览图，预览图尺寸不超过200KB时直接上传，超过200KB时提示“图片过大，请压缩后重试”；3. 上传成功后头像区域显示新头像，刷新页面后仍然显示新头像；4. 上传失败时显示错误提示，头像保持原样。

你看，这样的验收标准，测试人员可以直接照着写测试用例，开发也知道做到什么程度算完。写验收标准的时候有一个简单的判断方法：如果这条标准没法用“是/否”来判断，就说明写得不够具体。

6.2 需求追溯：从需求编号到测试用例的链路

需求追溯听起来很正式，其实做起来可以很简单。核心就是一件事：每条需求都能找到对应的测试用例，每个测试用例都能追溯到对应的需求。这样做的好处是，验收的时候可以对着需求清单逐条确认，不会漏；出了问题也能快速定位是需求没写清楚还是开发做错了。

实操上，可以在需求文档里给每条需求编号（前面提过的FR-XXX-001），然后在测试用例管理工具里关联这个编号。如果团队没有测试用例管理工具，用一个共享表格也能做：一列需求编号，一列需求描述，一列对应的测试用例编号，一列验收结果。这个表格在验收会上过一遍，哪些做完了、哪些没做完、哪些做偏了，一目了然。

6.3 验收不通过时怎么处理

验收不通过是常事，关键是怎么处理。我的原则是：先判断是“需求理解偏差”还是“实现质量问题”。如果是需求理解偏差（开发做的跟需求文档写的不一样），先回头查需求文档——如果文档写清楚了但开发做偏了，那是开发的问题；如果文档本身写得模糊，那是需求的问题，不能全怪开发。

如果是实现质量问题（功能做了但不符合验收标准），那就按缺陷流程走，记录问题、定级、排期修复。这里要注意的是，验收阶段发现的缺陷，修复成本比开发阶段高得多，所以能在前面的环节拦住的问题尽量在前面拦住。需求评审拦住一批，开发自测拦住一批，测试拦住一批，最后到验收阶段的问题应该是个位数，而不是几十个。

7. 不同规模项目下需求分析的裁剪策略

需求分析的方法论很多，但不是每个项目都需要全套流程。三个人两周做完的小项目和三十个人做半年的项目，需求分析的深度和形式应该完全不同。这一章聊聊怎么根据项目规模裁剪需求分析的动作。

7.1 小项目：口头对齐加一页纸需求

小项目最大的特点是沟通链路短，三个人坐在一起就能把事说清楚。这种情况下，不需要写几十页的需求文档，一页纸就够了。一页纸上写清楚：做什么（功能清单）、不做什么（范围边界）、什么时候做完（时间节点）、怎么算做完（验收标准）。这四样写清楚，小项目的需求基本就不会出大问题。

小项目最容易出的问题是“口头说了但没记”。三个人聊的时候都觉得明白了，过两周其中一个人忘了，就开始扯皮。所以即使是小项目，也要有一个简单的记录——可以是一个共享文档，也可以是一个群公告，关键是写下来、发出来、大家确认。这个动作花不了十分钟，但能省掉后面很多麻烦。

7.2 中型项目：标准需求文档加评审

中型项目（比如五到十人团队、两三个月周期）就需要相对正式的需求文档和评审流程了。这个规模下，沟通链路开始变长，光靠口头对齐已经不够了。需求文档按前面说的最小可用结构来写，评审会至少开一次，变更要有记录。

中型项目要特别注意的一点是：需求文档的读者不只是开发和测试，还包括业务方。业务方需要通过需求文档确认“你们理解的就是我要的”。所以文档里要避免太多技术术语，业务流程部分要写得让非技术人员也能看懂。我见过一些需求文档写得技术味很重，业务方看了半天说“我看不懂，你们看着办吧”——这就是需求文档没起到共识作用。

7.3 大型项目：分层次的需求管理

大型项目（比如跨团队、半年以上周期）的需求管理需要分层。最上面一层是业务需求（为什么做这个项目、解决什么业务问题），中间一层是用户需求（哪些角色在什么场景下用什么功能），最下面一层是功能需求（具体的功能点和验收标准）。这三层分别对应不同的文档和不同的评审参与者。

大型项目还要特别注意需求之间的依赖关系。A团队的功能依赖B团队的接口，B团队的接口又依赖C团队的数据——这种依赖如果在需求阶段不梳理清楚，开发阶段就会互相卡脖子。我的做法是在需求文档里单独列一节“依赖与接口”，把跨团队依赖的接口、数据格式、联调时间都写清楚，并且在评审会上让相关团队确认。

8. 需求分析做得好不好，看这几个信号就知道

最后聊一个很实际的问题：怎么判断一个团队的需求分析做得好不好？不用看文档写得多厚，看几个信号就够了。

第一个信号：开发过程中需求变更的频率。如果开发做到一半频繁收到“这里改一下”“那里加一个”的需求，说明需求分析阶段没做透。变更不是不能有，但高频变更说明前面的功课没做够。

第二个信号：验收阶段的争议数量。如果每次验收都要开好几次会、吵好几轮才能通过，说明验收标准没写清楚，或者需求理解有偏差。好的需求分析，验收应该是一次过的比例高，需要返工的少。

第三个信号：业务方的满意度。这个最直接。业务方如果经常说“做出来的不是我想要的”，那需求分析一定有问题。反过来，如果业务方在验收时说“对，就是这个意思”，说明需求分析做到位了。

第四个信号：需求文档的复用率。这个信号比较隐蔽。好的需求文档，后面做类似项目的时候可以直接参考甚至复用；差的需求文档，做完这个项目就再也没人打开过。文档有没有生命力，反映了写文档的时候有没有真正把业务逻辑想清楚。

我在实际项目里的体会是，需求分析这件事，投入产出比最高的动作是“多问一句为什么”和“把验收标准写具体”。这两个动作花不了太多额外时间，但能挡掉后面大量的返工和扯皮。至于文档格式、评审流程这些，根据团队情况灵活调整就好，不必追求大而全。毕竟需求分析的目的是让项目顺利推进，不是让文档看起来漂亮。