简介：面向软件工程课程设计的需求分析完整范例，涵盖京东商城网站系统从项目背景到运行环境的全过程描述。这份指导书由学生团队撰写，明确系统目标、用户特点与假定约束，重点包含业务描述、系统框架图、步骤图、用例分析、类图及部分用例次序图，覆盖用户注册、商品浏览、购物车管理、下单支付、订单跟踪、退换货等关键环节，并给出设备、支持软件与控制方面的运行环境要求，为后续设计编码测试提供了清晰基线。文档章节包括引言、任务概述、需求分析、运行环境要求，其中系统框架图可直接用于理解整体架构，步骤图梳理登录与支付流程，用例分析界定用户、商家、管理员三类角色的交互，类图展示商品、用户、订单等核心对象关系。资源为1个doc文件，压缩包大小1.62MB，目录结构完整，适合软件工程专业学生撰写需求文档、准备课程答辩或学习UML建模参考。已有125人学习浏览，可作为类似电商系统开发需求阶段的实用模板。
1. 这份京东商城的.doc，教的其实是需求怎么“拆”
项目启动第一周，老板往群里丢了一份《京东商城软件需求说明指导书.doc》。第一次打开这份文档的人最容易误判：以为它是京东商城的产品说明书，照着做完就能搭一个京东。实际上这份指导书解决的是另一件事——需求怎么被“写出来”。它从京东商城这类典型电商平台的页面、交易链路、售后环节里，拆出一份能评审、能估算工期、能被测试用例覆盖的软件需求规格说明书（SRS）。适合接商城类外包的团队、需要给客户交付需求文档的需求分析师，以及刚上手电商产品、不知道从哪下手的新人。
2. 从京东商城首页反推模块：把“逛网站”变成需求清单
2.1 三个电商网站逐页拆解：首页、列表页、详情页藏着什么需求
我做需求分析时有个习惯：先当用户把网站逛一遍，再当分析师把页面拆一遍。拿京东商城、淘宝网、阿里巴巴1688这三个站做对照，你立刻能看到什么功能是电商的“标配”，什么是平台自己的差异化。打开京东商城首页，从上往下数：顶部搜索框、用户登录入口、类目导航、轮播Banner、京东秒杀、排行榜、新品首发、PLUS会员入口。这一屏里，半数以上是功能点，不是视觉设计。
搜索框背后是搜索服务，前提是商品数据得有标题、关键词、上架状态这些字段；类目导航背后是类目树和商品挂靠关系；轮播Banner背后是运营位的配置后台。很多人拆需求时只写了“首页要有Banner”，没写“运营人员能通过后台配置Banner图片和跳转链接，配置后前台在有效期内展示”。这两句话的差距，就是需求分析指导书存在的意义。
列表页和详情页同样要拆。京东商城列表页有筛选区：品牌、价格区间、是否自营、配送方式；排序区：综合、销量、价格、评论数；还有分页。详情页的核心是SKU选择、价格与促销信息、库存状态、加入购物车和立即购买按钮。把三个网站这几个页面的对照写下来，你会得到一张公共功能点清单，再按自己项目的范围做增删。这一步不用写代码，拿Excel或者纸笔就能干。
2.2 购物车到售后：交易主链路上的功能点识别
浏览完页面，接着走交易链路。京东商城的购物车支持勾选、修改数量、删除失效商品、批量结算，有商品降价提醒时还会在购物车里提示。结算页要选收货地址、配送方式、优惠券、发票信息、支付方式。下单之后有订单状态流转：待付款、待发货、待收货、已完成、已取消，还有京东特有的价格保护。这些环节每拆一个，都要问一句“异常情况怎么办”——支付成功但扣款失败、库存扣减了但订单没生成，都是需求文档里必须写清的分支。
售后链路也不要漏：申请退换货、填写退款原因、商家审核、退款原路返回、用户评价。评价还分好评差评、带图评价、追评。整个交易主链路串起来，就是从“用户搜索”到“订单完成”的一条完整业务流。把这条链路上的每一步写成一个功能点，再标上输入、输出、前置条件、后置条件，你的需求素材就已经有雏形了。
拆到这里，你要区分核心链路和支撑链路。搜索、商品浏览、加购、下单、支付、订单查询是核心链路，一个商城没有这些跑不起来。秒杀、拼团、优惠券叠加、会员积分、价格保护、社区内容这些属于支撑链路，按项目预算和排期决定做不做、做到什么程度。京东商城把支撑链路做得很重，但这不代表你的项目也要这么重。
2.3 用表格收敛需求清单：编号、名称、优先级、来源
逐页拆完之后，必须收敛成一张清单。我一般在Excel里建四列：需求编号、需求名称、需求描述、来源页面。编号用模块缩写加序号，比如首页是HOME，列表页是LIST，详情页是DETAIL，购物车是CART，订单是ORDER。下面是一个收敛后的样例：
| 需求编号 | 需求名称 | 需求描述 | 来源页面 |
|---|---|---|---|
| FR-HOME-001 | 全局搜索 | 用户可在首页顶部输入关键词搜索商品，支持搜索历史记录展示和清除 | 京东商城首页 |
| FR-LIST-003 | 多条件筛选 | 列表页支持按品牌、价格区间、是否自营、配送方式筛选商品，筛选条件可叠加 | 京东商城列表页 |
| FR-DETAIL-001 | SKU规格选择 | 商品详情页支持选择颜色、尺寸等规格，不同规格联动价格、库存和图片 | 京东商城详情页 |
| FR-CART-002 | 批量结算 | 购物车支持勾选多件商品后进入统一结算页，生成一个订单 | 京东商城购物车 |
| FR-ORDER-005 | 订单状态流转 | 订单状态在待付款、待发货、待收货、已完成、已取消之间流转，状态变更可追踪 | 京东商城订单列表 |
这张表拉开以后，你会发现需求分析的地基已经打好了。下一步不是直接写文档，而是把这些零散条目按用户的角色和业务链路编排成章节。你手里有一堆素材，但还没形成一栋房子。
3. 需求规格说明书的骨架：指导书教你按什么顺序排章节
3.1 先定读者对象，再定章节顺序
很多新人拿到需求清单就急着往Word里塞，结果写出来的东西像一份功能清单流水账。软件需求说明指导书的做法不一样：先问这份文档给谁看。项目经理关心范围、工期和风险，开发关心功能逻辑和规则，测试关心验收标准，UI关心界面元素背后的交互约束，客户关心整体方案和费用。同一份文档，读者不同，各章节的侧重点就不同。
常见的需求规格说明书结构是：引言与项目背景、总体描述、功能需求、非功能需求、数据需求、接口需求、验收标准。这个顺序不是拍脑袋定的，它是从“为什么做”到“做什么”再到“做成什么样”的逻辑递进。很多人写SRS跳过了引言和总体描述，上来就写功能需求，客户看完不知道你为什么要做这套系统，评审会上第一个问题就是“你这个范围谁定的”。
标题里的“指导书”三个字，重点就在这：它不直接给你一份固定的模板，而是告诉你每个章节解决什么阅读问题。引言解决“为什么有这份文档”，总体描述解决“系统是给谁用的、边界在哪”，功能需求解决“系统能干什么”，非功能需求解决“系统要扛住什么压力”，数据需求解决“系统里存什么”，验收条件解决“怎样才算做完”。六块拼起来，才是一份能拿去签字的SRS。
国内做软件文档，很多团队会参照《计算机软件文档编制规范》里的建议结构来组织SRS。我不建议原样照抄标准结构挂在项目文档里充门面，而是把标准当目录骨架，往里填自己项目的实料。比如说总体描述这一章，标准里写“系统环境与约束”，落到商城项目就是开发语言、部署环境、第三方支付接口的对接方式。骨架用标准，血肉用项目。
3.2 功能需求、非功能需求、数据需求怎么编排
功能需求要按用户角色分块，不要按页面分块。按页面写的问题在于：同一个功能可能横跨多个页面，比如“查看商品评价”在列表页、详情页、订单页都有入口，按页面写就重复了。按角色分，买家、商家、运营、系统管理员四类角色各占一节，每节写这个角色能执行的操作和业务规则。京东商城的买家侧能做什么、商家后台能做什么，边界自然就清楚了。
非功能需求是容易被忽视但返工率最高的章节。性能、安全、兼容性、可用性，一个不能少。性能要写具体数值：商品详情页接口在1000并发下响应时间不超过800毫秒，而不是“系统性能要好”。安全要写密码加密传输、支付接口签名校验、后台权限分级。兼容性要写支持哪几种浏览器版本、移动端适配到多大屏幕。这些数值不要求一开始就拍准，但要有人为它负责，写“待压测后确认”也比不写好。
数据需求要画实体关系，至少要列出核心实体清单：用户、商品、SKU、类目、购物车、订单、支付单、优惠券、售后服务单。每个实体写清关键字段和状态枚举。拿订单来说，状态字段必须有统一枚举，不能用“待发货”“已发货”和“商家已发货”三种写法并存。数据字典不统一，开发写出来的代码就各说各话，联调时全是扯皮。
3.3 需求编号与追踪矩阵：让每条需求被测试扣住
需求编号是SRS的骨架连接件。没有编号，测试用例没法对应需求，变更影响也说不清。编号规则简单易读就好，比如FR-SHOP-024，FR表示功能需求，SHOP是模块，024是序号。非功能需求用NFR，数据需求用DR，接口需求用IF。改需求时把编号写进变更记录，评审会上一说“FR-SHOP-024要改”，所有人都知道是购物车批量结算那条。
需求追踪矩阵是一张表，三列：需求编号、需求描述、对应测试用例。它的价值不在评审会当时，而在开发后期。等到联调阶段测试追着开发问“这个FEATURE到底做没做完”，矩阵一拉，哪条有没有用例、用例过了没有，一目了然。这张表也是验收报告的基础，客户签字确认的验收范围就是以它为锚点的。矩阵维护起来有工作量，但有它，项目后期少吵一半的架。
4. 把功能点写成可评审的需求条目：用例、验收标准与优先级
4.1 用“用户故事+场景”代替口语描述
需求条目最忌讳写成“系统支持用户浏览商品”。这种话翻译成测试用例时毫无指导意义：浏览是什么操作？在哪个页面？看到什么算完成？指导书的处理方式是把需求描述拆成用户故事加场景。用户故事强调“作为谁，想做什么，为了什么”，场景是关键操作路径。比如这条：
作为买家，我想在商品详情页选择颜色和尺寸后加入购物车，以便在同一下单页集中结算多个商品。
这句话要落到更细一层才算可执行：进入商品详情页默认展示第一个规格组合；未选择完整规格时“加入购物车”按钮置灰；选择的规格组合已售罄时，该按钮变为“缺货”，且页面上提示可选库存。这四种状态各写一遍，测试用例自然就出来了。具体到这一步，需求不再是口号，而是一组明确的规则。
写用户故事时还有一个常见问题是主体不清。“用户能把商品加进购物车”和“买家能把商品加进购物车”，看起来差不多，但权限设计差很多。游客身份加购物车和登录买家加购物车，前者要提示登录，后者直接写库，这是两种业务规则。指导书里每条功能需求都对应明确的角色，就是这个原因。
4.2 验收标准怎么写才不产生扯皮
验收标准是需求文档里最能省钱的章节。写评审意见时，开发最爱说“需求没写清楚”，操作前条件是开发猜的，报错文案是开发编的，最后上线效果跟产品脑子里想的不一样。验收标准的目的就是消灭这些猜测。一条验收标准不用长篇大论，写清楚前置条件、操作步骤、预期结果、性能要求四件事就够了。
拿“搜索商品”举例：前置条件为买家已登录且商品库中有金额不少于3万元的已上架商品；步骤为在搜索框输入“空调”，点击搜索按钮；预期结果是搜索结果页在2秒内展示出商品列表，单页展示48条，列表项包含商品图、名称、价格、评论数；若库存低于10件，列表项展示“仅剩N件”标识。这样的条目开发不需要再回来问你“没货要不要提示”，测试也不需要猜“2秒还是10秒算正常”。
写验收标准要用可测量的词：响应时间、数量、状态值、金额，不要用“良好”“快速”“美观”。“响应快”和“99%的请求在2秒内返回”是两份完全不同的验收文档，前者是形容词，后者是承诺。客户签字确认验收标准时，确认的实际上是这批承诺。
4.3 优先级排序：MoSCoW方法与版本切分
需求没有优先级，等于所有需求都是第一优先级，最后变成什么都没做完。指导书里常用的排序法是MoSCoW：Must必须有、Should应该有、Could可以有、Won't这期不做。这四档不是随便拍拍脑袋就能分的，它取决于项目的业务目标和上线时间。
Must是主线闭环。一个商城第一期上线，搜索、商品展示、购物车、下单、支付、订单查询是Must；优惠券、积分、秒杀是Should；社区评价、直播带货、个性化推荐是Could；和第三方平台的数据互通如果是远期计划，就是Won't。每档要有明确责任人认可，尤其是Won't这一档，写清楚了能省掉大量“这个我觉得可以加”的干扰需求。
优先级定完，版本自然切出来了：Must覆盖V1.0，Should和Could进V1.1或者V2.0，Won't进入产品路线图观察池。版本切分不光是需求文档的工作，它直接决定研发排期、测试范围、上线验收的边界。需求指导书之所以要单独成文，就是因为没有这个共识，开发做了一堆功能却发现核心链路缺一个退款入口，这种翻车案例在电商项目里太多了。
5. 软件需求说明书里的高频坑：从条目模糊到doc版本失控
5.1 坑一：“系统支持用户浏览商品”，被测试打回三次
现象：需求条目写得像宣传语，测试拿到手不知道验证什么，开发拿手手写了一套自己的理解。评审会上一问细节，产品经理当场现编。
原因：需求描述停留在“能力声明”，没有落到角色、操作、规则和结果上。写需求的人把“做这个功能”和“这个功能有几条行为规则”混为一谈了。
解决：把每条需求描述改成“角色+操作+业务规则+预期结果”四段式。浏览商品改成“未登录用户可浏览商品列表与详情页，点击加入购物车时跳转登录页，登录后返回原页面并保留已选规格”。测试能照着写用例，开发不用猜，这才是需求条目该有的精度。
5.2 坑二：把UI设计写进需求，前端和产品互相甩锅
现象：条目写着“确认订单页的背景色为浅灰，按钮用圆角”，前端照着做完，UI设计师过来说视觉稿不是这样。需求评审没人发现，测试按条目测了，UI按视觉稿验收，两边对不上。
原因：需求文档混入了界面表现层描述。背景色、圆角、间距属于设计稿范畴，不属于SRS的功能规则。
解决：需求只写交互规则，例如“确认订单页需展示收货地址、商品清单、配送方式、优惠金额、应付总额五项信息，支付按钮在未勾选‘我已阅读并同意服务协议’时置灰”，视觉风格全部指向UI设计稿，写清楚“具体样式以UI稿为准”。这堵墙立起来，责任边界就清楚了。
5.3 坑三：只写了主流程，库存不足、支付超时全留给开发猜
现象：上线后用户反馈“我付了钱订单没生成”“明明显示有货点进去就说库存不足”，客服截图一张接一张往群里丢。
原因：用例只覆盖了happy path。加购正常、库存充足、支付成功这些路径写了，库存不足、支付回调超时、重复点击提交按钮这三个分支全没写。开发只能按自己习惯处理，每个模块处理方式还不一样。
解决：每条关键路径至少补一条异常分支描述。加购要写“所选规格库存为0时按钮置灰”；支付要写“支付成功回调超时，订单状态保持待付款并允许用户手动刷新”；提交订单要写“防重复提交，按钮点击后置灰并在2秒内不可重复触发”。把异常分支补进验收标准里，这类线上事故能少一半。
5.4 坑四：没有数据字典，同一个“订单状态”各写各的
现象：需求文档里“已发货”“已出库”“商家已发货”三种写法并存，开发建表时一个字段既有INT又有VARCHAR，测试提Bug时描述的状态和开发理解的还对不上。
原因：数据需求章节缺失，核心实体没有统一定义。每个人用自己口语里的词写需求，没人负责把它收敛成字段级定义。
解决：在数据需求章节维护一张核心状态枚举表，字段名、类型、取值、含义四列齐全。订单状态就八个值：待付款、待发货、待收货、已完成、已取消、售后中、退款中、已关闭，其它叫法一律不用。数据字典建起来，需求文档的术语体系才算闭环。
5.5 坑五：doc版本失控，“最终版2.0”旁边还有一个“最终版2.0(真)”
现象：项目群里有七八份命名类似的.doc，有人改了正文，有人改了目录，客户手里那份还是上周的。评审时说的全是旧内容，讨论完才发现白开。
原因：多人直接在同一份Word文件上各自编辑，没有版本管理机制；Word的目录域没更新，打开文档显示的页码和内容对不上，打印出来更是惨不忍睹。
解决：定两条规矩。一是文档目录区放本文件的修订历史表，每次修改必须登记版本号、日期、修改人、修改摘要，正文不允许无痕改动；二是正式评审前用Word的“更新域”刷新目录，再另存一份带日期的PDF发给与会者，评审以PDF为准。这套流程不需要额外工具，但能治住大部分版本翻车。
6. 让doc真正可用：大纲、目录、修订记录与C#书签操作
6.1 Word样式决定目录能不能一键生成
需求指导书最后要交付成一份能评审、能修改、能追溯的doc文档，这就要回到Word本身。最容易踩的坑是：全文用手动改字号的方式做“伪标题”，结果“插入–引用–目录”一生成，目录是空的。解决办法是给所有标题套用Word内置的“标题1”“标题2”“标题3”样式，而不是手动放大加粗。大纲级别正确，目录生成和导航窗格才能工作。生成完目录再按F9更新域，页码和标题文字才会同步。
修订记录表放在目录之后、正文之前，固定四列：版本、日期、修改人、修改摘要。V0.1草稿、V0.2按评审意见修订、V1.0评审通过。客户签收时按版本号签字，不要在正文里翻哪里改过。再看一眼标题里的“.doc”——如果是老式的.doc二进制格式，建议在编辑前“另存为”成.docx再工作，目录、域、书签这些特性在.docx里表现更可靠，也更适合程序化处理。
6.2 C#操作doc：书签定位让评审意见可追踪
到了评审后半段，我已经不想在正文里来回翻找被修改过的段落了——用代码在Word里插入书签、替换书签对应的内容，比肉眼定位可靠得多。这也是很多人问“doc能不能程序化编辑”的真实动机：批量给一份模板文档的占位符替换项目名、公司名、日期，生成N份带差异的SRS。C#做这件事有两类路径：一是Word COM互操作，适合老.doc；二是OpenXML SDK，处理.docx更干净。用COM的方式是：
using Word = Microsoft.Office.Interop.Word; public static void ReplaceBookmarkText(string docPath, string bookmarkName, string newText) { Word.Application app = new Word.Application(); Word.Document doc = app.Documents.Open(docPath, ReadOnly: false, Visible: false); try { Word.Bookmarks bookmarks = doc.Bookmarks; if (bookmarks.Exists(bookmarkName)) { Word.Range range = bookmarks[bookmarkName].Range; range.Text = newText; // 替换书签范围内的文本 } doc.Save(); } finally { doc.Close(); app.Quit(); } }这段逻辑不复杂：先以只读方式准备一个Word文档对象，按书签名找到对应位置，拿到Range后直接赋文本，保存退出。注意三点：环境里必须先装有Word且引用了Microsoft.Office.Interop.Word；书签名区分大小写，与之对照的模板里插入什么名字就要传什么名字；替换书签内容后书签标记会丢失，如果之后还要定位，需要重新插入书签。生产环境如果要批处理几十份doc，建议加一个重试机制，因为Word进程偶发来不及释放——这个偶发问题很玄学，但确实常见。
敲完这段代码，我还是那句老话：需求指导书最核心的价值，是逼着你在写功能之前把规则定下来。我以前吃过亏，以为需求文档就是列功能清单，后来被开发问了一百个“这里没写怎么办”，才把验收标准一节一节补齐。现在任何一份SRS落到我手里，我都会在评审前先自己跑一遍异常分支，把“这个没写”变成“这个已经定了”。这份功夫省下的扯皮时间，远比写文档的时间多，希望帮到你。
本文还有配套的精品资源，点击获取
