企业官网建设流程全解析

简介：“IBM需求规约案例”以软件需求规约（SRS）的编制为主线，整理自IBM公司提供的需求规约格式模板，面向需求分析师、项目经理及软件开发测试人员。文档详细划分了概述、指定、标准、数量、可用性、安全性六大章节，并说明从前景文档到SRS包的活动工件流转、功能需求通过用例定义、非功能需求记录于补充规约等核心方法，同时涵盖需求管理中假设与问题清单的维护要点。资源包共包含1个doc文档，大小约150KB，便于直接参考与套用，目前已有276人浏览学习。配套案例有助于读者掌握规范化的需求组织思路，在项目实践中快速搭建SRS框架并明确各类需求条目，从而提升需求沟通与交付质量。

1. 需求规约不是“写文档”：它是把 IBM 模板里的六类信息逼出来

写软件需求规约（SRS）这件事，在很多团队里是被当成“交作业”处理的：项目启动会开完，负责人找份模板把功能列表贴进去，评审会签个字，然后文档就躺在共享盘里再没人打开。但 IBM Rational Unified Process 这套需求规约指南最反直觉的一点是：它明确告诉你 SRS 不是一个文档，而是一个“信息包”；并且这个包是活的——开发照它写代码、项目经理拿它做进度对齐、测试照着它设计用例，任何一个环节把它当摆设，后面都会在验收阶段翻车。这份资源的价值不在模板本身，而在它把需求拆成了六类必须回答的问题：概述、指定、标准、数量、可用性、安全性。适合需求分析师、项目经理、QA 和刚接触规范化流程的开发工程师。

2. SRS 到底是个什么“包”：功能性需求走用例、非功能性走补充规约

2.1 先纠正一个惯性：SRS 是信息包，不是装订成册的 Word

模板里有一句反复强调的话：并没有充分的理由让我们注重所用工具之间的差异，重点应放在有效地收集和组织需求上，而不是考虑所使用的工具。这句话放到今天依然能解决很多人的内耗。我见过不少团队在需求阶段花大力气统一文档格式、折腾模板样式，结果真正该收集的信息反而没收集全。

按 IBM 这套思路，SRS 包可以由多个工件组成：非功能性需求、设计约束这类文本内容放在补充规约里；功能性需求放进用例模型和用例；假设与问题列表单独维护。你在 Word 里写也好、在 wiki 里维护也好、用 Rational Rose 这类工具画用例图也好，只要这些内容合在一起能回答“为了交付这些功能，系统必须执行哪些操作”，它们就是一个完整的 SRS 包。

这份模板还把 SRS 定义为“活动的、有生命的工件”，这一点直接戳中了很多项目的死穴。为了过 ISO 9000 审计，团队把 SRS 编制好就放在角落里，后面整个项目过程不再理会。如果 SRS 只是用来应付审计的，那它唯一的作用就是让项目在验收时多一份没人看的存档。真正能用的 SRS 应该在开发、测试、验收全过程中被反复翻开。

2.2 功能性需求与非功能性需求：用例加补充规约的分工

IBM 模板对需求类型和承载位置有明确的划分。功能性需求不鼓励全部堆在一个大文档里，而是通过用例模型和用例来定义；非功能性需求（性能、可用性、设计约束、安全等）记录在补充规约中。

需要留意的是，实施人员在问题解决和性能定义阶段可能已经参与项目，但真正确定“代码必须做什么”时，依据是 SRS 包，而不是早前讨论中的口头约定。模板提醒 QA 和测试小组也要参加早期讨论，理解前景文档里的“前景”，但他们的验收标准依然来自 SRS 包。

2.3 三类读者决定了 SRS 怎么写

SRS 包在不同角色手里作用完全不同。项目经理不太可能去读开发人员生成的代码并与前景文档直接比较，他们的标准参考是 SRS 包，用它作为与项目团队讨论的基准；开发人员把 SRS 当成契约性协议——不在 SRS 包里的内容不应处理，在 SRS 包里的内容就有责任交付；测试和 QA 小组则用它来创建测试用例和 QA 过程，确保系统确实满足提出的需求。

这三类读者决定了写作方式：每条需求都要能追溯到验收方式，每个量化指标都要回答“谁来测、怎么测”。我在写 SRS 时有个习惯，每写完一小节就在旁边标一个“可验证方法”，哪怕是简单到“评审确认”或“上线后统计”，也比裸写一条需求要好。这条习惯就是从这套模板的读者视角来的。

3. IBM 模板六大章节逐项拆解：每节该填什么、哪些是雷

3.1 概述与指定：假设、地理组织、预选软件包

概述部分重点是“假设与问题”两个列表。模板明确要求：收集并验证非功能性需求时，应维护一个假设与问题列表，并在每个阶段结束时与客户一起复审问题。我在实际项目里观察到，这个列表是最容易写了就忘的。假设和问题要分开：假设是你在需求和设计流程中作出的判断，必须写明基本原理；问题是可能中断项目进行的重要事项，必须定期复审。

地理组织这一小节很多人直接跳过，但模板里明确要求记录客户的组织地点、受影响的业务部门、未受影响但安装主要 IT 设备的工作地点，以及需要特殊自然语言支持（NLS）的位置。移动工作部门也要记录，比如四处出差、使用工作站的销售团队。对一个跨国或多分支机构的项目来说，这里漏一项，后面做部署方案时就要返工。

指定部分的四个问题决定了设计自由度：

特别要注意预选应用程序包这条。模板提醒：影响指定程序包的因素同样会影响设计，必须确认你能获得包的厂商、外部顾问或经培训的团队成员支持。不要以为这些知识很容易获得。封装包的灵活性差异很大，有的允许大量定制，有的完全固定，这个判断必须在写 SRS 时完成，而不是选型之后。

3.2 标准：技术架构、网络、连接策略的约束收集

标准这一章是 SRS 最容易写成“摆设”的部分，因为很多项目组觉得架构问题跟自己无关。模板列举的内容，每一项都是硬约束：客户是否有技术架构或 IT 战略计划？其中是否定义了计算中心数量与用途、企业 WAN 连接性、设施 LAN、客户机/服务器中间件、目录与命名服务、安全服务、时间服务、事务管理服务、可支持产品集？

这里容易被忽略的是“记录的开放程度”。客户要求厂商独立性和互操作性到什么水平，直接决定了设计能不能绑定具体厂商。如果存在技术架构文档，几乎可以肯定设计必须与它保持一致。我一般会在这一节末尾加一行“架构兼容性结论”，列出哪些子架构被强制、哪些被排除。

网络架构和连接策略是另一个隐藏雷区。模板建议记录物理拓扑考虑（网络在农村还是大城市、设备密集还是松散分布）、通信标准（SNA、OSI、TCP/IP）、支持的编程接口、客户机/服务器层的连接性定义。连接策略里有一条很实际：如果业务交互涉及国际性连接，要了解第三方（承包商、公用通讯公司）的参与如何管理。此外还有移动用户支持。对今天的项目来说，这部分还要补充云连接和混合网络场景，但模板的提问方式依然适用。

其他策略一节提醒：最终用户接口是否必须按面向对象原则设计、是否必须基于客户机/服务器模型、是否按公开标准定义、NLS 标准（特别是从右向左文本）、安全策略。模板还专门问了一句：用户或部门能否在工作站、服务器上自行开发本地程序？这个问题非常现实——本地程序会很快耗尽生产系统资源，等到首次公开展示时发现系统装不上。

3.3 数量：评测单元、业务量、性能标准的口径统一

数量部分是 SRS 里信息密度最高的部分，也是大多数人不知道从哪下手的地方。模板第一步不是问“系统要支持多少用户”，而是先定义“评测单元”。要和应用程序开发人员合作，把业务流程细分为更小的单元——业务流程、事务。为什么要先做这一步？因为你得先确定计数对象，才能记录数量。

一个业务流程可能启动多个更小业务事务的实例，比如一个客户订单里有多项订购商品，记录数量时要记住这些乘数。但也不要过分深究细节，尤其对复杂系统更是如此。模板特别点出一个协作难点：IT 术语在不同人群里含义不同。“事务”对应用开发背景的人来说是一种意思，对基础设施团队的人来说完全是另一种意思。不先把名称对应关系对齐，后面收集到的“事务数”根本没法比较。

业务量和大小要记录的内容包括：平常时间和高峰期各有多少用户、什么时候是高峰期（每天、每周、每月）、高峰和平常需要以什么速度处理事务、每个数据组中数据元素和实例的数量及大小。这些数据是整个容量规划的黑匣子，不填死的后果就是上线前做压测时没有基线。

业务流程性能标准一节，模板要求记录响应/周转需求、评测地点、不同时段是否接受不同标准、恢复或应急期间能否达标、是否需要性能保证、未达标的影响。还有两个很容易漏的点：系统支持流程（如备份）和应用开发流程也有性能目标；如果选择了封装应用程序解决方案，必须知道如何访问它的性能特征——第三方提供这些数字可能要花时间，现在就应该提出要求。

3.4 可用性：服务时间、中断成本、恢复标准与灾难恢复

可用性章节是这套模板里写得最细的部分。模板给出的可用性建议方法很明确：确定真实最终用户和业务流程、分析不可用性如何影响用户达成业务目标、指定直接反映用户需求的可用性需求。这里第一条原则就是：按更小的粒度指定可用性需求（按流程、用户组、数据组），不要指定整个系统的全局需求。

全局可用性有个经典反例，模板里给了纽约和香港的例子。“系统必须每天 24 小时为纽约和香港用户提供服务”听上去很严格，实际却剥夺了设计灵活性。改成“纽约时间上午 7 点到下午 7 点，纽约用户必须能对他们的数据执行事务处理；香港时间上午 7 点到下午 7 点，香港用户必须能对他们的数据执行事务处理”，设计人员就能在一个时区的工作时间之外维护另一个时区的系统。

计划中的服务时间、服务中断成本、可用性和恢复标准这三节是层层递进的。服务中断成本要求从财务上量化影响：短中断、数分钟、15 分钟、1 小时、2 小时、4 小时、换班、数天，每种持续时长对应的业务损失不同。业务功能缩减是可以接受的替代方案，比如“完整功能：读取最新客户余额；缩减功能：从可能不很新的备选来源读取客户余额”。缩减功能要有限制条件，过时数据不能超过规定时限。

可用性和恢复标准按 RTO/RPO 的思路来写会更清晰：多少比例的中断需要在给定分钟或秒数内恢复、在给定周/月/年内用户无法执行特定功能的最大时长。灾难恢复只选关键业务流程，不必所有流程都做主备，服务恢复时间从灾难发生时算还是从决定前往远程工作地时算，这些口径都要写明。

3.5 安全性：数据分类、威胁场景与特殊需求排序

安全性章节模板提供了一套可操作的流程：确定需要保护的数据、确定威胁类型（意外损坏、故意破坏、商业间谍、欺骗、黑客行为、病毒）、确定物理安全威胁（偷窃、未授权物理访问、人身安全）、确定威胁来源（数据中心工作人员、其他 IT 人员、组织内非 IT 人员、组织外人员）、确定特殊安全需求（访问控制、数据加密、可审核性）。

模板还给出了分类方法：按逻辑或物理安全性列出需要保护的对象，确定与各对象相关的侵害场景。典型类别是查看访问（违反保密性）、更新访问（为欺骗、掩饰、资金转移而修改数据）、资产丢失（所有权被他人获得）。注意，不是所有对象对上述侵害场景都敏感。之后把威胁与具体侵害场景关联，并检查对象在静态位置（硬盘）和移动中（传输期间）的不同安全状态。

如果系统有特别苛刻的安全性要求，模板建议找安全专家或安全从业者协助。判断标准很明确：系统是否涉及高安全等级数据、资金清算系统、个人机密信息。我一般会在 SRS 的安全性章节末尾加一个“特殊安全要求是否成立”的确认项，如果成立，就让安全专家介入设计评审，而不是由开发团队自行判断加密方案。

4. 从前景到 SRS：如何把“大概要什么”变成可验收的量化指标

4.1 前景负责“为什么做”，SRS 负责“必须做什么”

模板明确指出 SRS 包与前景文档（Vision）相关，事实上前景文档可用作 SRS 的输入，但两个工件服务于不同需要，通常由不同作者编写。项目阶段从概括性说明用户需要、目的、目标、目标市场、系统特性，转移到如何在解决方案里实施这些特性的具体细节。

这个转换项目经理要盯住：如果 SRS 里还在写“提升用户体验”“提高运营效率”这类目标性描述，说明前景的内容混进了 SRS。SRS 只回答一件事——为了交付这些功能，系统必须执行哪些操作。前景文档回答的是系统为什么存在、为谁存在。

4.2 评测单元先于数量：命名对齐比数据收集更重要

数量章节的第一动作不是收集数据，而是拆分评测单元并做术语对齐。模板强调：不同人群会对“单元”使用各自名称，应用程序开发背景的人说“事务”是一种意思，基础设施团队说“事务”是另一种意思。因此务必要通过相互协作使名称相互关联，再进行信息收集。

我实际操作时会先做一张“评测单元对齐表”，列出业务流程、对应的应用程序、IT 事务、基础设施视角名称，让各方确认同一件事。比如一个客户订单处理流程可能对应一个应用程序，但内部有“查询库存水平”“生成客户信函”等多个事务；在基础设施团队眼里，这些事务又可能被归并为“在线交易请求”。对齐表做完，数量收集才有意义。

4.3 给每一条非功能需求配一个可度量指标

量化是 SRS 从“文档”升级为“契约”的关键。IBM 模板给出了一系列可借鉴的量化模式：

模板还特意区分了“希望”和“强制”两类可用性特征。比如 ATM 应用必须 24 小时能存取款，这是强制；账户余额查询允许偶尔中断但只能发生在凌晨 3 点到 4 点，这是希望。混在一起写，设计和测试都没法判断优先级。另外，如果某个可用性目标没达成也不会直接影响用户完成业务目标，那它就不适合作为需求写进 SRS，更合适的做法是留在前景文档里。

5. 避坑指南：SRS 评审中常见的五个翻车现场与应对

5.1 五个典型翻车现场：现象、原因、解决

我在评审和审计中见到的 SRS 翻车案例，大部分集中在这五个点上。

第一条，SRS 里只有功能清单，没有非功能项。现象是文档通篇是“用户能查询订单”“系统能生成报表”，评审会上测试问“性能指标呢”才意识到没写。原因是模板只用了功能性需求部分，忽略了数量、可用性、安全性章节。解决方法是把第 4、5、6 章作为强制项，每条功能至少配套一条可度量的非功能需求。

第二条，“系统必须 7×24 小时可用”这类全局指标无人能挑战。现象是评审会上这句写在最前面，所有人默认它很严格，实际设计时发现根本没有可行方案。原因是粒度太粗，业务并没有要求所有功能全天候可用。解决方法是按用户组和业务时段拆分，写成“工作日 8:00-20:00，财务人员必须能完成日终结算操作，结算功能年可用性 ≥ 99.9%”。

第三条，假设与问题列表建了但不复审。现象是列表里有十几条未确认事项，到了设计阶段才发现其中一条假设直接否定了选型方向。原因是列表没有设复审时点和负责人。解决方法是为每一条假设和问题分配 owner，把复审绑定到阶段评审或里程碑会议，问题列表必须和客户一起过。

第四条，现有数据没盘点就开始做迁移设计。现象是系统升级时对接旧数据库，发现数据结构、编码规则和数据量和早前预估完全不符。原因是 SRS 的 2.4 现有数据小节空着。解决方法是写数据盘点表：数据位于什么系统、结构是关系型还是平面文件、大小、当前用户、不可用时间段、是否可移动或复制。

第五条，封装包的性能特征没有提前获取。现象是选完软件包，到容量规划时供应商才告知性能数据需要额外付费或专项测试，项目等了三周。原因是模板 4.3 的警告被无视——第三方提供数字需要时间，现在就该提出要求。解决方法是选型阶段就把性能特征作为技术附件写入合同或采购单。

5.2 评审 CheckList：把避坑经验沉淀进模板

我建议把上述五条整理成 SRS 评审的检查项，每次评审会逐条过：

这套 check list 不依赖具体工具，无论是 Word 模板、wiki 还是专门的 ALM 系统，都能直接套用。

6. 交付前把 SRS 变成验收工具：自检脚本与 15 分钟检查习惯

6.1 用一段脚本快速检查 SRS 章节完整度

SRS 是文本型资源，但章节完整性检查可以自动化。我平时会把 SRS 大纲导出成纯文本，跑一段 Python 脚本确认六个核心章节都在，避免评审会现场才发现有人把“安全性”整章删了。

import re import sys # SRS 大纲章节自检脚本 # 用法: python check_srs.py srs_outline.txt required = ["概述", "指定", "标准", "数量", "可用性", "安全性"] path = sys.argv[1] if len(sys.argv) > 1 else "srs.txt" with open(path, encoding="utf-8") as f: text = f.read() missing = [] for key in required: # 匹配一级或二级标题中包含关键词的行 if not re.search(rf"^#+\s*.*{key}", text, re.MULTILINE): missing.append(key) if missing: print("[缺失章节]", "、".join(missing)) sys.exit(1) else: print("[OK] 六个核心章节齐全")

这段脚本的逻辑是逐行匹配以#开头的标题，只要某个核心关键词在任何层级的标题中出现，就判定该章节存在。required列表可以按项目裁剪，比如把“安全性”拆成“安全需求”和“隐私需求”两个关键词。path默认读取当前目录的 srs.txt，实际使用时改成你的大纲文件路径即可。脚本只是文字层面的完整性检查，不验证内容质量，但它能在一分钟内拦住最基础的结构缺失。

6.2 15 分钟逐章追问：把模板当验收工具

脚本跑完，我会再做一遍 15 分钟的人工检查。六个章节各对应一个追问：概述部分的假设与问题是否还有未确认项；指定部分有没有强绑定现有系统的约束被遗漏；标准部分的技术架构和连接策略是否和实际基础设施矛盾；数量部分是否每个评测单元都有业务量和性能目标；可用性部分是否区分了强制和希望；安全性部分是否所有保护对象都有对应的侵害场景。

这套习惯是从一次失败的项目学来的。那年我们做的系统在开发阶段一切顺利，上线前测试才发现可用性指标压根没法验收——因为 SRS 里写的是“系统必须稳定运行”，没有量化，测试用例只能靠猜。从那以后，我每次交付前都强制走一遍六章节追问，确保整份 SRS 的每一条内容都能被测试或评审直接使用，而不是一段“看起来合理但无法验证”的文字。希望帮到你。

本文还有配套的精品资源，点击获取