1. 需求分析到底在分析什么EE308FZ 这门课国内很多软件工程专业的同学应该都不陌生课程名一般是软件工程实践或者软件需求工程。第三份作业直接叫 Demand Analysis摆明了就是让你写一份完整的需求分析文档。我见过太多人拿到这个题目上来就画用例图结果被老师批了一堆“需求不明确”“边界模糊”的评语核心问题其实是没想明白需求分析到底在分析什么。需求分析不是让你当产品经理去编功能清单也不是让你当程序员直接想数据库表结构。它做的是一件“翻译”的事把用户脑子里的模糊想法翻译成技术人员能照着开发的明确方案。这里面有两层关键动作——先搞清楚用户真正要什么再把这个“要什么”结构化地描述出来让团队里每个人看到的都是同一幅画面。很多同学把精力全花在画图、写格式上反而把最核心的部分忽略了。要知道EE308FZ 这种课程的作业考察的重点从来不是文档多厚、图多漂亮而是你有没有建立起一套“从模糊到清晰”的需求分析思路。这篇博客我就从项目拆解、过程设计、实操方法到避坑经验把一份能拿高分的需求分析作业完整地盘一遍。先说结论一份好的需求分析文档应该让随便一个没参与过前期讨论的开发人员拿到之后都能清楚地知道“系统要做什么”“边界在哪里”“哪些功能优先级最高”。如果达不到这个效果那这份文档就是自嗨。2. 拿到题目后的第一件事拆解需求边界2.1 不要急着写文档先做需求抽取我见过最普遍的错误是拿到题目就打开 Word 开始写“引言”“项目背景”。这东西不是这么弄的。正确做法是先做需求抽取把题目里给的信息全部“榨干”。EE308FZ 第三份作业的题目通常会给一个场景描述比如设计一个课程管理系统、图书馆预约系统或者实验室设备管理系统。不管具体题目是什么你都需要从这段描述里抽取三类信息功能性需求系统要能做什么。比如“学生可以预约实验室”“教师可以审批预约申请”。非功能性需求系统做到什么程度。比如“系统需要支持 100 人同时使用”“响应时间不超过 3 秒”。约束条件有什么限制。比如“只能在校园网内访问”“需要支持移动端”。这三类信息在题目里往往混在一起甚至被藏在一些叙事性的描述里。比如题目写“管理员每天需要查看实验设备的使用情况”这句话背后就藏着两个需求一个是一个管理端的统计报表功能一个是面向上层的使用率数据可视化需求。你要做的是把这些“埋着”的需求全部挖出来。实操上我建议用便签纸或者在线白板一条需求一张卡片先不管分类和优先级把能想到的都写出来。这个阶段的准则就是“宁滥勿缺”需求多不可怕后面可以砍但一开始就漏掉关键需求等设计评审时被老师点名“这里没考虑到”那才麻烦。2.2 从需求抽取到需求分析建立需求金字塔抽取出原始需求后下一步是把这些零散的需求组织成一个有层次的骨架。我习惯用“需求金字塔”的方式来做这件事简单说就是三层结构顶层是业务目标回答“这个系统为什么存在”中间层是用户需求回答“用户通过系统完成什么任务”底层是功能需求回答“系统提供什么功能来支撑用户完成任务”。举个例子如果题目是做图书馆预约系统那么业务目标就是“提升图书馆座位利用率减少占座现象”用户需求是“学生能实时查看空位并预约座位”功能需求则是“展示座位状态地图”“预约/取消预约”“预约超时释放”等等。你可能会问这不就是很普通的“愿景到功能”的拆解吗对道理不复杂但很多人不这么做。他们直接从题目跳到一个具体功能上比如先想到“要做一个二维码签到功能”然后整篇文档都围绕着这个功能写。结果是什么需求文档变成了功能说明书完全没有体现需求分析的思维过程。这是要扣分的。明确了这三层结构你其实就已经有了文档的骨架。章节目录不用去网上抄模板按照“业务目标—用户画像—功能需求—非功能需求—优先级”这条主线走就非常顺了。3. 核心步骤拆解用结构化方法做需求分析3.1 构建用户画像与使用场景很多学生写的需求文档里用户只有两个普通用户和管理员。但你仔细想想一个系统里真的只有这两种角色吗我考过 EE308FZ 的作业要求里往往特别强调了“用户分析”这一项。以课程管理系统为例“学生”看起来是一个角色但大一新生和即将毕业的大四学生对系统的使用需求完全不同——新生要用选课指引毕业生要用成绩单打印“老师”也可以拆成“授课教师”和“教学管理人员”前者关心作业管理后者关心排课数据。这就是用用户画像来做细分的意义。画像要写清楚用户的背景、使用频率、技能水平、核心诉求。比如角色名称本科生低年级使用场景每学期初进行选课、查看培养方案、提交课程作业能力水平能操作手机 App不习惯复杂界面核心诉求快速找到自己要的课程操作流程越短越好用户画像做完之后紧接着要做的是使用场景描述。场景描述的是“谁在什么情况下想完成什么事”它让需求分析从“抽象功能列表”变成“具体的生活片段”。比如大三学生小张周三上午 10 点想预约当天下午的实验室但发现下午时段已被约满于是系统自动帮他加入候补队列并在有人取消预约后推送通知。这样的场景能检测你抽取的需求是否覆盖真实情况。比如此时就需要一个“候补排队”功能这个需求如果你不用场景推演很容易漏掉。3.2 功能性需求和非功能性需求怎么区分功能性需求很好理解就是“系统做什么”一般可以用用例来描述。非功能性需求则经常被大家忽略或者写得太空泛。我来列举一些 EE308FZ 作业里考官最看重的非功能性需求维度你在文档里一定要有对应描述性能需求具体数值比如“查询空闲实验室的响应时间不超过 2 秒”不要写“系统要快”那等于没写。可用性需求比如“支持 7×24 小时运行”“允许 500 名用户同时在线系统不崩溃”。易用性需求比如“系统应支持用户 5 分钟内完成预约流程”“不需要培训即可上手”。安全需求比如“用户密码需要加密存储”“不同角色有不同的数据访问权限”。可维护性需求比如“系统需要支持模块化扩展后续能添加新的实验室类型”。为什么非功能性需求这么重要因为同一套功能需求在不同非功能约束下技术实现方案可能完全不同。比如说“查询实验室空闲状态”这个功能如果是给 30 人的课题组用直接简单查数据库就行如果是要给全校几万人实时查询那可能就需要缓存、读写分离这些设计了。非功能性需求直接决定了后端的架构怎么做如果你在需求阶段不提开发阶段就会翻车。实操建议非功能需求必须数字化。能用数字表述的绝不用形容词。“快速”改成“2 秒内”“安全”改成“密码经 SHA-256 算法加密传输”“大并发”改成“支持 1000 并发请求”。这是一个很多资深分析师都会反复强调并执行的细节你要是能把这些写清楚文档的专业度直接上一个台阶。4. 从需求到模型画图背后的建模思路4.1 用例建模实战别为了画图而画图需求分析中最常用到的建模工具就是 UML 用例图。但很多同学画用例图画成了“功能气泡图”这是误区。用例图的核心价值是表达“参与者”与“系统”之间的交互目标而不是表达系统内部功能模块。一个用例必须代表用户的一个完整目标比如“提交作业”是一个用例但“上传附件”“填写评语”就不算用例它们只是完成“提交作业”这个目标过程中的步骤。EE308FZ 作业里用例图建议包含以下几层内容参与者从角色画像里来。用例一个参与者要完成的一个目标。关系用例之间的include包含和extend扩展。边界用矩形框标出系统边界哪些操作在系统内、哪些不在。举个例子。对于课程管理系统“教师批改作业”这个用例通常包含“下载作业附件”和“填写成绩”这两个子步骤那这两步就是 include 关系“上传作业”这个用例可能要处理“超过截止日期提交”的特殊情况这就可以画成 extend。我在实操中会特别留意 include 和 extend 的使用因为这两个关系最能体现学生的建模水平。include 是必需的、每次都执行的extend 是可选的、有条件的。搞不清这两者用例图就会变成一张蜘蛛网评审看起来就乱。4.2 活动图、状态图、领域模型怎么选EE308FZ 作业一般不会要求所有 UML 图都画一遍但要求会针对重点场景选择性地使用。这里有一个选择逻辑活动图适合描述业务流程特别是“预约→审批→使用→释放”这种有多步骤、多分支的流程。活动图要体现出泳道也就是不同角色各自做了什么。状态图适合描述单个对象的状态流转。比如“实验设备”这个对象可以有“空闲”“已预约”“使用中”“维修中”四种状态状态之间的转换条件和触发事件要写清楚。领域模型类图用于表达业务实体和它们之间的关系。对需求分析来说类图不需要深入到属性和方法重点是找出业务概念。我见过一个反面教材学生花了很多力气画了一张特别详细的类图连每个类的数据库字段类型都标了出来。结果老师评价说这不是需求分析这是详细设计了。记住需求阶段画类图是为了找“业务概念”和“关联关系”不是让你提前设计表结构。表结构是设计阶段的事。4.3 需求规格说明中的用例描述表光有用例图还不够。用例图只解决“有哪些用例”的问题用例描述表才解决“这个用例具体怎么运作”的问题。我建议对优先级最高的 5—8 个用例每个都写一份完整的用例描述表。用例描述表一般包含用例名称、参与者、前置条件、后置条件、主事件流、备选事件流、业务规则。这里重点说主事件流和备选事件流。主事件流就是“一切正常时系统怎么走”。以“学生预约实验室”为例学生登录系统。系统显示当前可预约的实验室列表。学生选择目标实验室和时段。系统校验该时段是否空闲。系统创建预约记录并发送确认消息。用例结束。备选事件流就要写“异常或者分支情况”。比如第 4 步如果校验失败系统要提示“该时段已被预约”并让学生选择其他时段。很多同学只写主事件流备选事件流不写然后系统设计阶段一堆边界情况没考虑到。备选事件流是让你提前暴露问题的好工具这部分最值得花时间。5. 实操过程实录从空白文档到完整需求报告5.1 需求获取与用户访谈的思路EE308FZ 作业毕竟是课程作业你可能没有真实的用户去访谈。但老师通常会在题目里给出“客户描述”还有一些隐含的调研要求。你可以基于题目信息配合“模拟访谈提纲”来完成需求获取这一部分这样既有过程感又接地气。访谈提纲要注意两点一是不问“是或否”的问题二是不诱导用户。错误提问你需要一个二维码签到功能吗——这是诱导式提问。正确提问你目前在安排学生出勤时最耗时的是哪个环节——这是开放式的需求挖掘提问。就算你只能模拟访谈也要把访谈过程、访谈结论、需求增量这三段写清楚。所谓需求增量就是从这次访谈中你新发现了哪些原本没注意到的需求。这能向阅卷老师展示你的需求分析是一个动态完善的过程而不是一次性生成的。5.2 需求优先级排序的方法需求全列出来了但你不可能让所有需求同等重要。在文档中要对需求做优先级排序推荐用 MoSCoW 法则Must have必须有系统存在的基石。没有这些功能系统完全不可用。Should have应该有很重要但短期缺失也能凑合。Could have可以有锦上添花的功能。Won‘t have这次不做明确排除以免范围蔓延。这个排序不能只看直觉要结合客户的核心目标来排。课程管理系统里“选课”是 Must have“课程论坛讨论”很大概率是 Could have 甚至 Won’t have。你得能解释每个排序的理由这个功能支撑了哪个业务目标如果砍掉会怎样这些问题在需求评审时几乎是必问的。一个背靠背制订优先级的技巧是从“用户完成核心任务必需的路径”出发排查。比如学生要在系统里完成选课系统必须有课程列表、选课操作、冲突检测这三块它们是核心链路必然 Must have。至于“选课后给课程打分”这种链路之外的、服务于另一目标的功能可以往下放。5.3 输出验收标准需求怎么算“完成”这块一定要在正文或附录中写清楚否则会失真。一份需求文档的验收标准可以这样界定需求覆盖率题目描述中提到的所有功能点是否都有对应需求条目和用例。一致性功能需求、用例描述、术语表之间无矛盾。可测试性每条需求是否都有可验证的验收条件。优先级合理性每个优先级排序是否都有理由说明。另外很多同学在文档最后没有加术语表。不同角色对同一个词的理解可能不同比如“预约”和“订座”看起来差不多但在某个具体系统里可能代表不同的流程。术语表能保证团队沟通时大家说的是一回事写上一个不亏。6. 常见问题与排查技巧实录6.1 需求分析中踩过的那些坑我自己在辅导 EE308FZ 作业时发现学生犯的问题高度集中我总结成一张表典型问题表现根因对应解法功能性需求写成功能列表没有用户视角全是“增删改查”没用用户场景驱动需求抽取用事件驱动的用户故事替代功能列表用例图画成功能树把“上传附件”“保存”都当成用例混淆了任务目标和系统操作回归“用户级目标”判断标准非功能需求全是形容词性能写“快”、安全写“高”缺乏可度量的意识所有非功能需求必须数字化需求排序没有依据凭感觉把喜欢的放前面没有关联业务目标用 MoSCoW 并写排序理由备选事件流缺失只写正常路径不写异常情况思维停留在理想流程没模拟异常分支逐个步骤追问“如果这一步失败了怎么办”用户画像太粗糙所有用户统称“普通用户”没做角色细分按使用目标和使用频率拆分角色6.2 好的需求文档长什么样这里我给几个可以“抄作业”的快速检查项写完之后对着过一遍猎头式阅读测试把文档给一个完全没了解过背景的同学看他能否说出系统的核心业务目标十万个为什么测试随机挑一条需求追问“为什么需要它”能否在文档里找到依据裁剪测试如果把文中的“Could have”需求全删掉系统是否还能正常运作如果能说明优先级排序是合理的。TRACE 测试从任一功能需求是否能追踪到对应的用户需求、用例描述和验收标准6.3 用最少的时间把文档质量再提一档最后分享一个短时间内提升文档质感的小技巧。写完后把每一条功能性需求用“作为XX我希望能够XX以便XX”的句式改写一遍。看到区别了吗第一版是“系统支持文件上传”第二版是“作为学生我希望能够上传作业附件以便老师在线查看和批改”。后者把“功能”变成了“价值”让需求从“系统要做什么”走向“用户能获得什么”。这个视角的转变在需求分析里是最值钱的技能。这种改写之后你再去看整个文档就会发现自己哪些需求其实根本不值得做——因为你说不出它对用户有什么价值。这就达到了需求分析的一个隐藏目的帮你砍掉不重要的需求而不是制造一个臃肿的系统。7. 经验之谈与最后的小建议EE308FZ 的这份作业说实话难度不算大但它逼着你走完一遍完整的需求分析流程。这个流程里的每一个环节——需求抽取、用户画像、用例建模、优先级排序、需求验证——都会在以后任何一次真实的项目开发中用到。我个人当年做这份作业时最大的教训就是太追求形式上的“全”各种图表都画了文档写了七八十页结果被导师一针见血地指出你的需求和分析脱节了。后来我调整了策略把重心放到核心链路的用例场景推演上反而拿到了不错的效果。如果你现在正卡在这份作业上我的建议是先别急着写文档花一个晚上把你所有能想到的需求写在小卡片上再分类、排序、找关联。当你觉得卡片之间的关系已经理不清楚时你就知道自己对项目的理解还不够需要回去重读题或补充场景。理清了卡片文档就是水到渠成的事。最后再分享一个实用技巧写需求分析时一定要多问自己一句“为什么”。每一个需求背后都应该有一个业务逻辑的支撑。如果某个需求你连为什么都说不出来那它就很可能只是你硬凑出来的、没有实际价值的伪需求。砍掉它你的文档会更好。