企业官网建设流程全解析

简介：这份Word文档围绕IBM软件需求规约（SRS）格式模板与案例展开，面向需求分析人员、项目经理、开发及测试/QA成员，也适合软件工程课程学习者参考，用于解决SRS章节组织不完整、需求描述口径不统一等问题。内容按概述、指定、标准、数量、可用性、安全性等部分梳理模板结构，并涉及假设与问题、地理组织、预选应用包、特殊硬件、现有数据、技术/网络架构、评测单元与业务量、服务时间与灾难恢复等条目，同时说明功能性需求与非功能性需求的记录方式，以及SRS在团队沟通、设计实施和测试用例设计中的参考作用。资源包共1个doc文件，约150KB，轻量便于查阅和二次整理；已有277人学习。读者可据此快速搭建规范的需求规约框架，对照案例完善章节内容，并用作项目讨论与需求评审的检查清单。

1. 需求规约不是文档而是包：SRS 为什么被当成「信息包」来组织

很多人第一次打开这份需求规约（SRS）模板，第一反应是啰嗦：客户在哪个时区办公、现有数据躺在哪台机器上、晚上能不能整体关机、中断一小时值多少钱，全都要写进去。反直觉的地方在于，它压根没打算做一份「写给人看的文档」。模板里明确把 SRS 定义成一个信息包，一个可以被项目经理、开发、测试三方同时引用、并在整个项目周期里反复被改写的东西。所以它解决的不是「需求怎么写得漂亮」，而是当有人说「这个功能当初没说要这么做」时，能不能立刻翻到那一行。搞懂这个定位，后面六个部分的排序才不会显得莫名其妙。

2. 从前景到 SRS：需求是在哪一刻从「愿望」变成「契约」的

绝大多数团队对 SRS 的误解从命名开始：以为它是一个 Word 文件，评审通过、定稿、归档，然后开发照着做。模板的第一段就把这个做法否掉了——它说 SRS 记录的是「对于系统或系统一部分的完整软件需求」，而且要按包来组织。包和文档的差别不是叫法，而是能否被逐条引用、逐条追溯、逐条变更。这一章先把「从前景到 SRS」这条链路拆开，看清需求在哪个节点上完成了身份转换。

2.1 前景文档与 SRS 的分工：同一批需求的两种粒度

前景文档概括地说明用户需要、目的和目标、目标市场和系统特性；SRS 说明的是这些特性在解决方案里如何实施的具体细节，用模板的原话说就是「为了交付这些功能，系统必须执行以下操作」。这两个工件服务于不同的需要，通常也由不同的作者来写。前景文档可以作为 SRS 的输入，但它替代不了 SRS。

判断粒度是否合适有一条简单的检验：把一句话写进 SRS，如果开发看完还得回头问「那到底谁在什么时间能做什么」，说明它还是前景级表述。举个虚构的例子，模拟项目X 的前景文档写「支持跨区域团队协作」，这句话放进 SRS 就必须变成「A 区用户在当地时间 7:00 到 19:00 之间必须能对本区数据执行创建、修改、查询；B 区用户同理，且两区数据维护窗口不得重叠」。前者是愿望，后者才是可设计、可测试的约束。

这里有个常被忽略的机制：前景和 SRS 的变更源不一样。前景的变更由市场判断和业务策略驱动，SRS 的变更由实现细节的澄清驱动。把两者合并成一份文档，等于让每一次业务口风变化都直接污染实现基线，开发会陷入「需求天天变，但说不清哪里变了」的状态。分开维护，本质上是把两种变更频率隔离开。

2.2 文档还是包：工具差异为什么可以被忽略

模板里有一段很工程师式的表述：并没有充分理由去关注所用工具之间的差异，重点应放在有效收集和组织需求上，而不是工具。所以它假定 SRS 中的需求集合构成一个信息包，各种系统需求的详细说明都收在名为 SRS 的包里。功能性需求可以来自用例模型里的若干用例，非功能性需求和设计约束则更适合放在补充规约里用文本记录——因为它们的验证方式不是「走一遍场景」，而是「量一个数」。

这个「包」的机制含义是：命名空间加成员工件加稳定标识。工具换了不影响它是不是一个包，判断标准只有一条——每条需求能不能被一个稳定地址引用。能引用，就能在评审、变更、测试用例、缺陷单之间建立链接；不能引用，所有讨论都会退化成「我记得当时说过」。

一个最小可用的条目结构大概是这样：

# 单条需求的最小可引用结构 id: SRS-AVL-0042 # 稳定标识，一旦分配不再复用 type: nonfunctional # functional / nonfunctional / constraint statement: > # 只写可验证的断言，不写背景故事 自助终端在每日 03:00-04:00 的余额查询中断， 单次持续时间不得超过 10 分钟。 source: vision-v3#sec4.2 # 这条需求从哪来，用于回答“为什么有它” verification: # 测试组可以直接照着做 method: measure window: 30d threshold: p99_break_minutes <= 10 owner: platform-team # 谁对这条需求的实现负责 status: active # active / superseded / withdrawn links: [UC-017, RISK-08] # 关联用例与风险项，供变更影响分析

关键字段的动机值得单独说。source让每条需求都能回答「凭什么有这一条」，避免评审时陷入立场之争；verification强制作者在写下需求的同一刻想清楚怎么验收，写不出验证方式的需求通常本身就没想清楚；links支撑变更影响分析——改一条需求，能立刻看到关联的用例和风险；status而不是直接删除，是因为 SRS 是活体工件，被废弃的需求也需要留下痕迹，否则半年后没人说得清当初为什么放弃。

2.3 活体工件：三种读者、三种职能

模板专门反驳了一种做法：为了符合质量体系标准，把 SRS 编制好然后放在角落里，在随后的项目过程中不再理会。它强调 SRS 是活动的、有生命的工件，并在开发人员进入实施阶段后承担多项关键作用。

第一重职能是对外的交流基础，也是契约性协议：如果不是 SRS 包中的内容，开发人员就不应处理它；如果是 SRS 包中的内容，开发人员就有责任交付该功能。这句话看着霸道，实际是范围控制的唯一可行手段——没有这条规则，「顺手做一下」和「这个不归我做」都会变成扯皮。

第二重职能是项目经理的参考标准。项目经理不太可能有足够的时间、精力或能力去读开发写的代码，再拿代码和前景文档逐行比对。他们必须把 SRS 当作与团队讨论的标准参考。换句话说，SRS 是管理者唯一能低成本介入技术判断的抓手。

第三重职能是对测试和 QA 小组的输入。这些小组应当参加一些早期讨论，以充分理解前景文档里讲的「前景」，但他们的职责是创建测试用例和 QA 过程，确保系统确实满足了 SRS 包中提出的需求。SRS 同时是他们的计划依据和标准参考。注意这里的顺序：先理解前景，再以 SRS 为准绳——理解前景是为了设计出有意义的测试，而不是让他们拿前景去质疑 SRS。

一份包同时承担范围裁定、实现输入、验收依据三种职能，这就解释了为什么条目必须同时携带来源和验证方式。也解释了功能性需求与非功能性需求为什么要分开放：前者靠用例场景验证，后者靠度量验证，混在一起写，两类验证都会失效。

3. 六段式结构：为什么「指定」和「标准」要排在功能需求前面

模板给出的章节顺序是概述、指定、标准、数量、可用性、安全性。初次接触的人容易以为这是分类习惯，实际上它是一条依赖链：前面的章节定义解空间，后面的章节在这个解空间里描述行为。顺序颠倒，写出来的需求看着齐全，一到设计阶段就大面积作废。这一章按依赖关系拆开讲。

3.1 概述与指定：先把设计自由度锁死

概述部分包含两个容易被当成形式主义的东西：假设与问题、地理组织。假设与问题要求维护两份清单——一份记录你在需求和设计流程中作出的所有假设及基本原理，以及可能用来确定本项目之外或之后相关子项目、工作项的假设；另一份记录所有可能中断项目进行的主要问题。在每个阶段结束时与客户一起复审问题清单，假设也需要复审，但对于不太重要的假设，客户可能并不是合适的复审人选。这套机制在非功能性需求上尤为常见，因为这类需求经常拿不到满意答案：要么缺信息，要么你判断说出真实答案会危及设计可行性。

地理组织则要求记录客户的地理组织、受该系统影响的业务部分所处位置、未受影响但安装有主要 IT 设备的工作地点，特别是所有移动工作部门，比如四处旅行并使用工作站的销售部门，以及可能需要提供特殊自然语言支持的所有地理位置。这些不是背景介绍，而是后面可用性、连接策略、NLS 设计的输入。

真正锁死自由度的是「指定」这一节。模板点名了一个最重要的指定：使用可提供预定义软件逻辑和数据组织的特定应用程序包。有些包比较灵活，允许大量定制；有些非常固定，不允许定制。包可能直接要求以下构件和决策：工作站类型、连接方法、处理器和直接访问存储设备类型、系统控制程序、数据组织与存放和管理、编程语言、批接口、进程和数据关系、业务逻辑、屏幕设计和最终用户界面、性能和可用性特征、现有或必需的打印架构与首选打印数据格式、国家语言支持。

机制很清楚：影响这个包的因素，同样会影响你的设计。所以模板要求确认能获得该包的适当技能和知识，来源可以是包厂商、外部顾问或经过专门培训的设计团队成员，并且特别提醒「不要认为这些知识很容易获得」。这句话是血泪经验——知识获取的延迟经常直接变成项目排期的延迟。

「其他指定」覆盖那些会限制设计灵活性的既有约束：使用现有的处理器或操作系统映像、现有工作站设备、现有网络、现有系统管理惯例，或者指定某种模型，比如「要在设计中清楚显示表示逻辑、业务逻辑、数据访问逻辑以及它们相互作用的位置和方式，就必须使用客户机/服务器系统模型」。这里有一组必须回答的追问：新系统若跑在现有处理器、操作系统映像或网络上，现有平台和工作量特征是否会影响新系统；现有工作量已经占用了多少连接和处理容量；用的是什么安全控件；有什么可用性特征，例如是否一定要求每天晚上关闭整个处理器。最后这条经常被漏掉，等到设计完才发现维护窗口根本不存在。

「特殊硬件」要求记录得尽量具体：硬件或软件先决条件、厂商及其支持组织、国家语言考虑事项、加密设备。表述可以笼统（「系统必须支持高速平板绘图仪」），也可以具体到设备型号，但先决条件和支持组织必须落到字面。「现有数据」同理：数据当前位于什么系统、结构是关系型文件还是平面文件、大小、目前哪些用户和系统在用、有哪些可用性考虑（比如数据库维护或批处理导致数据不可用的时间段）、能否移动或复制。能否移动这一条决定了迁移方案是复制还是改造，属于典型的早期一句话、后期一个月。

3.2 标准与连接策略：企业架构怎么反向约束设计

「标准」这一节问的是：客户是否已有技术架构和 IT 战略计划，或等同的标准集合。技术架构大致等同于企业技术平台、企业技术基础设施。在技术架构里可能已经定义：计算中心的数量和用途、企业的广域网络连接性、某些设施的局域连接性、客户机/服务器基础设施服务（中间件）的覆盖范围、跟踪网络资源和属性的目录及命名服务、防止网络资源被非法使用的安全服务及权限级别、校准全网日期与时间的时间服务、协调各种系统资源恢复活动的事务管理服务、将用于新应用的开发方法、已接受的可支持产品集（硬件、系统控制软件、常用应用、帮助台使用、安全规则）、打印子系统架构。

这段列表的价值不在于全，而在于它提示了一种读法：技术架构文档里几乎一定藏着会改变你设计的规则。模板还提醒，这个列表可能涉及非常广泛的内容，所列项可能被非常严格地实施，也可能根本不执行——所以要专门记录「明确要求使用或排除某些子架构」的需求，以及客户所需的开放程度，即厂商独立性和互操作性。若有技术架构，设计几乎肯定要与它保持一致。

网络架构是「架构即需求」的典型：它是一组公用的高层连接性规则，外加一个公用传输基础设施，可能包括对主干网络（集线器和线路）的定义。要记录物理拓扑方面的考虑（网络在地理上是集中还是分散、附属装置是密集还是松散分布）、当前基础设施支持哪些高层连接功能、用哪些通信标准支撑这些连接（如 OSI、TCP/IP 这类通用标准）、支持哪些编程接口，以及对客户机/服务器层或基本系统模型层连接性的任何定义。最后这条经常以极其具体的形态出现：关系型数据访问必须借助特定关系数据库产品的协议；表示逻辑必须始终在工作站，而数据访问逻辑必须始终在集中式主机系统中。这类句子一旦成立，等于把分层架构钉死了，后续所有关于「要不要把逻辑下沉」的讨论都是浪费时间。

连接策略则关注物理与合约层面：是否使用特殊协议或通信设备（在单独建筑物内，或在建筑物、组织以外的地方实现连接）；是否隐含要求用特定协议支持现有设备或软件；是否使用现有物理连接设备（电缆、电线、网络或外围控制器、常用载体），如果不使用，原因可能是政策、物理空间、产权或第三方参与；如果可能需要安装或修改物理设备，则可能需要承包商或通信服务商参与，要弄清如何承包和职责管理，业务交互涉及跨区域连接时这种管理尤其重要；最后是移动用户支持。这些内容写进 SRS 后，能提前暴露一类典型冲突：业务方要求三周上线，而线路施工要三个月。

「其他策略」是隐性需求的集散地：新系统接口必须按面向对象原则设计并允许拖放；所有新系统必须基于客户机/服务器应用模型；所有新系统必须按公开标准定义；国家语言支持的标准和政策，尤其从右向左文本这类操作；定义用户身份验证、访问控制和数据保护的管理职责与标准的安全策略；可能需要特殊连接或安全设备的应用交换标准。还有一条特别实际：对于用户或部门是否可以在工作站、服务器（尤其磁盘空间）上添加和开发自己的本地程序，实施的是什么策略。如果不加控制，本地程序会很快耗尽为生产系统购买的资源，到首次公开展示生产系统时，可能发现根本装不上。

3.3 数量：把业务语言翻译成可计数的 IT 单元

「数量」这一节解决的是容量规划的语言不通问题。第一步叫「评测单元」：与应用程序开发人员合作，把业务流程细分为更小的单元，比如更小的业务流程或事务。原因很直接——下一步要记录数量，必须先确定计数对象。这里有个必须记住的乘数：一个业务流程可能启动几个更小业务事务的实例，例如各个客户订单中的多项订购商品，记录数量时要把这些乘数算进去。模板同时提醒不必过分深究细节，复杂系统尤其不必，因为估算精度到了一定程度就没有收益了。

还有一个组织层面的机制值得单独说。通常一个业务「流程」（如客户订单处理）由一个 IT 意义上的「应用程序」实施，但也可能由多个应用程序实施；每个应用程序内部通常有很多 IT「事务」，例如「查询库存水平」或「生成客户信函」。麻烦在于不同人群用各自的名称标识我们试图一致认同的单元：「事务」对具有应用开发背景的人是一种意思，对基础设施团队则是完全另一种意思。所以务必先通过协作把名称的对应关系对齐，再收集信息。跳过这一步直接发问卷，收到的数字彼此不可加。

第二步是业务量和大小：预计一般时间和高峰期各有多少用户使用各个业务流程或应用；高峰期按天、周、月分别是什么时候；高峰期和一般时间各需要什么处理速度；每个数据组中数据元素和实例的数量及大小。第三步是业务流程性能标准：各类别的响应或周转需求、在哪里评测、不同时间（如夜间非高峰）是否可以接受不同标准、恢复或应急期间是否可以达到标准、是否需要性能保证、没达到性能需求会对各方产生什么影响，以及一个经常被遗漏的定义——业务流程被认为可用的最低性能条件，也就是在该点以下，系统应被视为「不可用」而不是「缓慢」。

对已选定封装应用方案的团队，还有一条前置动作：务必知道如何访问它的性能特征，现在可能不需要，但将来一旦需要，应该知道从哪里找；让第三方提供数字要花时间，所以现在就提要求。这条建议背后是很朴素的教训：性能数据不属于你能临时催出来的东西。

4. 可用性与安全性：为什么必须从成本和威胁倒推

这两节在模板里篇幅最长，也最容易被压缩成口号。原因不难理解——它们讨论的都是「没发生的事」，而人对没发生的事缺乏痛感。模板的处理方式是把它们全部转成可计算的量：可用性从业务损失倒推，安全性从威胁场景倒推。倒推的好处是，每一条需求背后都站着一个数字或一个具体场景，评审时能吵的只有数字准不准，而不是「我觉得够了」。

4.1 计划服务时间与中断成本：可用性需求的钱从哪来

模板给了一套四步推荐方法：确定系统的真实最终用户、他们正在执行的业务流程、执行这些流程的时间；分析服务可用或不可用将如何影响最终用户完成业务目标的能力；指定适当的可用性需求，直接反映最终用户为完成业务目标而具有的需求；注意如果已选定封装应用方案，它的结构和设计可能显著影响最终用户看到的可用性特征——未被设计为连续运行的包很难连续运行，尤其在维护和批窗口方面。

这里最有力的一条原则是「以较小间隔指定」：按流程、用户组、数据组分别指定可用性需求，而不要给整个系统一个全局需求。这样设计人员才有灵活性满足不同用户的真实需要；系统有很高连续可用性需求时，这一点尤其重要。模板举的例子可以改写成：语句「系统必须每天 24 小时为两个区域的用户提供服务」给设计人员的灵活性，远不如「从 A 区当地时间上午 7 点到下午 7 点，A 区用户必须能对他们的数据执行事务处理；从 B 区当地时间上午 7 点到下午 7 点，B 区用户必须能对他们的数据执行事务处理」。后一种写法下，即使一个区域仍处于工作时间，设计人员也可以对另一个区域的数据或系统构件做维护。

第二条原则是区分希望和强制。模板的例子是自助终端：必须能够每天 24 小时接受存款和取出现金；希望每天 24 小时提供准确的账户余额信息，但余额查询可以有偶发中断，单次中断持续时间必须少于 10 分钟，并且只能发生在凌晨 3 点到 4 点之间。把「必须」和「希望」写在同一句里，实施方就无法判断该为哪部分付出成本。

第三条原则是拒绝间接表述。「必须启动某个中间件控制区域」这类需求的间接性太强，不如「柜员必须能够执行流程 X 和 Y」有用，因为后者直接对应到最终用户的业务目标。判断标准很朴素：这条需求失效时，能不能说清哪个用户、哪个流程受影响。

计划服务时间要按业务流程和用户组分别确定；与用户组不直接相关的流程（比如夜间批处理）也要确定执行时间；位于不同时区的用户组应当作为独立用户组处理；还要说明是否存在不需要应用系统的偶然时间段，比如业务假期——这样设计人员就能灵活地在这些时间段做大规模维护。接着要问：在预计的应用程序生命期内，这些服务时间会发生什么变化；当系统与其他系统交互时，服务时间还会受对方服务时间的影响。

中断成本这一节是整份模板里最不「技术」、却最影响技术决策的部分。要确定的业务影响包括：在计划服务时间内发生短暂中断或响应极其缓慢时段的影响（定义「短暂」和「极其缓慢」时要结合具体应用，参照前面的业务流程性能标准）；各种延续时间更长的中断，1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时等；长时间中断，一次换班、一天、许多天；以及与用户组不直接相关的流程，比如夜间票据交换。

量化尽量落到财务：员工或设备生产效率降低的成本、失去当前业务的价值损失、因客户不满意而对未来业务造成的估计损失、利息开支、处罚类成本。模板还要求方案反映不同中断情况的成本和风险差异——持续时间不同、发生在一天中的时段不同、计划中断还是意外中断、影响的业务流程或用户不同。这个要求的实际作用是防止「上双活」这种一句话方案：如果只有某类中断代价高，就该只针对那类中断投入。

与中断成本配套的机制是缩减功能。对已认同的重要业务流程逐一复审，确定系统某些部分暂时不可用时，可以采取哪些替代方案让流程中最关键的元素继续运行。模板给的三个例子是：完整功能「读取和更新交易记录」对应缩减功能「录入更新数据，排队等待恢复后处理」；完整功能「读取最新客户余额」对应缩减功能「从可能不很新的备选来源读取」；完整功能「更新电子日记」对应缩减功能「更新纸质副本」。要注意缩减状态下的可接受程度也有限制，比如过时余额的过时时间不得超过 24 小时。这类需求如果不写进 SRS，实施阶段没人会主动做排队和降级，等真出事时只能干等。

4.2 可用性和恢复标准：怎么写成可验收的句子

标准要针对「正常」情况，不含灾难情况（严重损失或整个计算设备关闭）。制定依据是上一节确定的业务和财务成本、风险：必须满足这些标准，才能避免严重阻碍用户执行他们负责的业务流程。模板给了两种句式：在给定的分钟或秒数内被恢复的中断所占的百分比；在给定的周、月、年内，用户无法执行特定功能的最大时间长度。两句都要尽量具体地反映差异因素——计划中中断和计划外中断的区别、中断发生的时间（关键时间段还是使用率不高的时间段）、受影响的用户（所有用户还是少数几位）。

还有一条反向建议特别值得记住：注意不要指定不太紧迫的可用性标准，因为这会显著影响实施成本。判据是，如果在一组给定的中断条件下无法确定重要的业务或财务成本、风险，那可能表明不应当把这种中断条件纳入规定的可用性标准。这条判据把「拍脑袋写 99.99%」这类玄学操作直接堵死了。

若使用加密系统，还要额外考虑恢复和可用性事项：能够恢复可能保存在系统外的机密信息；确保加密保护数据的恢复与相应加密密钥的恢复相互协调。密钥恢复和数据恢复不同步，是典型的黑匣子问题——数据在，钥匙没了。

把「在给定分钟内被恢复的中断所占百分比」落成代码，能看清这句自然语言里到底藏了多少未定义项：

from dataclasses import dataclass @dataclass class Outage: started_at: float # 中断开始时间（秒级时间戳） recovered_at: float # 服务恢复时间 planned: bool # 是否为计划内中断 scope: str # 影响范围：流程/用户组/数据组的标识 def compliance_rate(outages, scope, window_days, window_minutes, include_planned=False): """ 计算某范围内、观测窗口内，恢复时长不超过 window_minutes 的中断占比。 - scope: 必须与 SRS 中定义的可用性粒度一致，避免全局指标掩盖局部问题 - window_minutes: 承诺的恢复时限，直接对应 SRS 里的“在给定分钟内” - include_planned: 计划内外中断的差异，决定分母怎么算 """ window_seconds = window_days * 24 * 3600 horizon = max(o.started_at for o in outages) if outages else 0 denominator, numerator = 0, 0 for o in outages: if o.scope != scope: continue # 范围不匹配不计入 if horizon - o.started_at > window_seconds: continue # 超出观测窗口不计入 if o.planned and not include_planned: continue # 计划内中断是否算违约，取决于 SRS 约定 denominator += 1 if (o.recovered_at - o.started_at) <= window_minutes * 60: numerator += 1 if denominator == 0: return None # 分母为 0 时应报“无数据”，不是 100% return numerator / denominator

这段代码体现的正是模板反复强调的几件事：可用性标准必须绑定范围（scope），否则一个全局数字无法定位到哪个流程受影响；必须绑定观测窗口（window_days），否则「百分比」没有时间基准；必须显式处理计划内外中断（include_planned），因为这直接改变分母；分母为 0 时必须返回「无数据」而不是满分，否则上线第一个月永远达标。参数改动的方向也很清楚：要提高标准就缩短window_minutes，要覆盖更长周期就加大window_days，要区分关键时段就把时段信息并入scope。

4.3 灾难恢复与其他设计事项：缩减功能也是一种需求

灾难恢复要先回答「在本次设计项目范围内是否需要」，再回答「标准是什么」。模板明确提醒：并不一定所有业务流程都需要灾难恢复设备，只应选择那些至关重要并且的确需要灾难恢复的流程；即使在这些流程内，也可能不需要包括所有功能。这个克制很重要，灾难恢复一旦被当成「全系统都要」，成本会失控。

需要问清的问题很具体：服务必须在多长时间内恢复；恢复时间从灾难发生时开始计算，还是从决定前往远处工作地点时开始计算；组织在什么条件下会决定在远处工作地点恢复，而不是在本地；在远处工作地点的数据必须处于怎样的更新状态才能让业务继续（必须时刻最新、故障后几分钟内更新、可接受前一天的数据）；首次从远处工作地点恢复服务是什么时候；这项能力是否要在未来某个时间点具备；相对于依赖相同计算设备的其他业务应用，这组应用的远程恢复具有什么优先级。注意，对系统的不同部分或不同类型的灾难，可能有不同的标准集；也要估计这些需求在预计生命周期内会怎么变。

「其他可用性设计事项」这一节把设计人员真正需要的信息列成了四个问题。第一，为了进行必需的维护活动，系统是否可以在短时间内只执行查询而不更新，或者接受用户的更新请求、但实际上在维护完成后才更新数据库。第二，对于需要数据恢复的中断，是尽快恢复服务（即使这意味着使用并非最新的数据）更重要，还是先把所有数据恢复到当前状态（即使耗时长得多）更重要。第三，如果故障发生时用户的请求处于「正在处理中」，服务恢复后该用户是否一定会重新输入。第四，是否存在可能影响系统可用性的非技术事项，比如业务策略规定流程 B 对用户不可用则流程 A 也不能可用。

这四个问题的共同点是它们没有标准答案，但每个答案都会显著改变实现方案：排队写库、读写分离的降级、幂等性设计、跨流程的联动开关，成本差了一个数量级。写进 SRS，就等于提前把选择权交给业务方，而不是留给开发在凌晨两点即兴决定。

4.4 安全性：对象、侵害场景、威胁来源三层拆解

安全需求最容易被压缩成一句「数据必须加密」。模板给的拆解方式分三层。第一层是对象：确定需要保护的数据，并按逻辑或物理安全性列出需要保护的对象。第二层是侵害场景，典型三类是查看访问（违反保密性，例如账户信息、客户列表、专利）、更新访问（为进行欺骗、掩饰和资金转移而修改数据）、资产丢失（所有权被他人获得从而对拥有者不再可用，区别于因灾难造成的丢失，例如客户和潜在客户列表、合同）。注意并非所有对象都对上述所有场景敏感，这层分析的目的恰恰是找出敏感组合。

第三层是威胁来源与环境。模板列举的威胁类型包括意外损坏或破坏、故意的损坏或破坏、商业间谍行为、欺骗、可能被笼统称为黑客的行为、病毒；物理安全威胁包括偷窃构件、未经授权的物理访问、用户的人身安全；威胁来源包括数据中心工作人员、其他 IT 工作人员（如开发人员）、组织中的非 IT 工作人员、组织外的人员；环境层面的具体威胁包括心怀不满的雇员、未经授权的雇员、在公共场合进行的终端会话、

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