- 理解用户需求
控制原则统称为业务规则或业务逻辑。业务规则通常通过人工的政策和流程来保证。
大多数业务规则起源于任何特定的软件应用之外。
由于业务规则是业务的属性，所以它们本身并不是软件需求。然而，业务规则是需求的来源，因为它们决定着系统必须具备哪些属性才能符合规范。
业务需求描述了组织期望的产出或概要目标。
业务需求是项目实施的理由。业务过程描述了将输入变为特定输出以达成特定结果的一系列活动。
业务规则通过建立词汇表、施加限制、触发行动或监控运算过程等方式影响业务过程。
业务规则如何影响各类软件需求
| 需求类型 | 业务规则的影响 |
| 业务需求 | 政府法规可能成为项目的某个业务目标 |
| 用户需求 | 隐私策略决定哪些用户可以或者被禁止使用系统完成某些任务 |
| 功能需求 | 公司政策规定所有供应商在收到发票之前必须经过核准登记 |
| 质量属性 | 来自政府机构的法规可以指明安全性要求，它们必须由系统功能强制执行 |
业务规则分类法
从业务角度–“业务规则是一个指导原则，它描述了在某个特定活动或环境中的行为、行动、实践或流程所应尽的义务。”
从信息系统角度–“业务规则是对业务某些方面的定义或限制的声明。它的目的是维护业务结构或控制以及影响业务行为。
事实
事实就是业务在某个特定时间点简单而正确的陈述。事实描述重要业务术语之间的关联或关系。
将重点放在项目范围内的事实上，不要试图收集完所有业务知识集。尝试将事实联系到内外关系图的输入/输出、系统事件、已知数据对象或者特定的用户需求。
约束
约束描述的是限制系统或其用户可执行的行为。
>组织政策
>政府法规
>行业标准
业务规则约束即使不能直接映射到功能，也能够为软件开发传达一些隐性的信息。
因为很多约束类型的业务规则都涉及哪个类型的用户可以操作哪些功能,所以一种可以记录这些规则的简明方法就是使用角色与权限矩阵(Beatty and Chen 2012）。
触发规则
当特定条件满足时触发某些活动的规则，称为触发规则。
可能会提出软件功能方面的要求，使系统探测到触发事件时表现出正确的行为。
触发行为的条件可能是某些独立真假条件的复杂组合。
决策表提供了一个简便的方式来记录涉及复杂逻辑的行为触发类业务规则。
推理
有时也称为推断的知识或派生的事实，推理通常是指从已知的事实中产生新的事实。
运算
通过使用特定的数学公式或算法将已知数据加工为新的数据。
在记录业务规则集或是描述带范围的需求时，要小心边界值重叠问题。很容易将范围定义为1~5，5~10以及10~20，此时5和10到底应该归于那个区间就会令人疑惑。
原子业务规则
一个较好的策略是在原子级别记录业务规则，而不是在一条规则中组合多个细节。这可以使得规则简明扼要。还有利于规则的重用、修改以及任意组合。
最终可能会得到很多原子业务规则，而功能需求将依赖于这些规则的各种组合。
记录业务规则
因为业务规则可能影响很多应用，所以组织应当把自己的规则视为企业级资产进行管理。
规则库的所有者应该是业务部门，而不是IT部门或者项目团队。
为每个业务规则提供一个唯一ID可以帮助将需求链回到特定规则，与之联系起来。
“规则类型”这列指出每个业务规则是事实、约束、触发、推理还是运算。“静态或动态”列说明规则将来变化的可能性。
发现业务规则
以下是一些常见的规则发现方式和地点（Boyer and Mili2011）
>组织内的“常识”，通常来自从事此业务很长时间的个人，他们通常都知道业务的运作细节。
>其需求和代码中已内嵌业务规则的遗留系统。这时需要对需求或代码的原理进行反向工程来理解背后的规则。
>业务过程建模，通常引导分析师找出可能影响每个流程步骤的规则:约束、触发事件、运算规则以及相关的事实。
>现有文档分析，包括以往项目的需求规范说明、法规、行业标准、企业规范、合同以及业务计划书。
>数据分析，例如数据对象可以有的各种状态以及在什么情况下用户或系统事件可以改变对象的状态。
>公司其他部门构建合规系统。
| 角度 | 提出规则 |
| 政策 | 为什么必须这么做？ |
| 数据模型 | 数据是如何关联的？ |
| 用户决策 | 用户下一步可以做什么？ |
| 事件 | 什么事必须发生？什么不能发生？ |
| 系统决策 | 系统如何知道下一步做什么？ |
| 对象生命周期 | 什么会改变对象的状态？ |
| 运算 | 数字是怎么计算得来的？ |
| 法规 | 政府有什么要求？ |
业务规则与需求
识别并记录业务规则之后，需要决定哪些必须在软件中实现。
规则是来自外部的策略声明，必须通过软件强制执行，因此提出了系统功能要求。
业务分析师必须决定哪些规则和应用有关，哪些必须由系统强制执行，如何强制执行。
把一切串起来
为了避免冗余，不要将业务规则目录中的规则复制到需求文档中。
>如果使用需求管理工具，就为需求新建一个“来源”属性并把原始规则列为功能需求的来源。
>在需求跟踪矩阵或需求映射矩阵中定义功能需求与相应业务规则之间的可跟踪链接（Beatty and Chen 2012）。
>如果业务规则和需求存储在文字处理软件或电子表格文件中，在需求描述中插入业务规则ID的超链接并将其指向记录业务规则描述的文件。
- 记录需求
需求开发的结果就是各方干系人对所要开发的产品达成一个协议文档。正如前文所述，业务需求包含在愿景和范围文档之中，而用户需求以用例或者用户故事的形式来捕捉。产品的功能和非功能需求通常都存储在一个软件需求规范说明（software requirements specification，SRS），交付的对象包括设计、开发和验证解决方案等人员。
规范说明和建模有助于项目参与人从全局考虑，并准确陈述重要事宜。
永远也不可能得到完美的需求。
逐步精炼细节是高效需求开发的一个重要原则。就达多数项目而言，在项目初期确定每一个具体需求既不现实也没有必要；相反，应当逐层分析。只有充分了解需求，才能先对其进行粗略的优先级排序，并将其分配到接下来的发布和迭代之中。
软件需求规范说明
人们有时称之为商业需求文档（BRD）、“功能规范说明”、“产品规范说明”、“系统规范说明”，抑或简单地称之为需求文档。因为“软件需求规范说明”是一个行业标准术语，因此我们在此也这样称呼（ISO/IEC和IEEE2011）。
软件需求规范说明阐述软件系统必须具备的功能及性能、其特征和必须遵循的约束。它必须尽可能完整地描述系统在各种条件下的行为、预期的系统属性，诸如运行状况、安全性和易用性。软件需求规范说明是后续项目规划、设计和编码的基础，也是系统测试和用户文档的基础。
除了已知的设计和执行约束，它不应该包含设计、构建、测试或者项目管理方面的细节。
开发团队在实现每个需求之前，每个项目都应该对每一个需求集合设置一个基线。设立基线是一种过程，在这个过程中，软件需求规范说明要由开发状态转为评审和批准状态。
在开工之前，大家要对需求达成一致意见，这样就可以减少沟通不畅以及不必要的返工。
标识需求
每个需求都需要有一个唯一的和持久的标识。
>序列号–最简单的方法是赋予每个需求一个唯一的序列号。
>层次化编号
>层次化文本标签–基于文本的层次化标签方法来标识每个需求。
处理不完整性
缺少特定需求的某些信息，可以用“待定”（to be determined，TBD）这样的符号将知识缺陷标记出来。在实现一个需求集合之前，要计划解决掉所有 TBD。遗留的任何不确定因素都可能使开发人员或测试人员犯错和返工。
TBD不能自我解决。可以给TBD编号，记录谁在何时负责解决每个问题，定期审查这些问题的状态并跟踪到解决掉为止。
用户界面和SRS
将用户界面设计纳入软件需求规范说明，这样做既有好处又有坏处。
好处是如果用纸原型、实物模型、线框图或模拟工具来探索用户界面，用户和开发人员对需求的感觉会更真实。
坏处是屏幕图和用户界面架构描绘的是解决方案，可能并非真正的需求。
早期的可视化可以使需求清晰明了，但随着时间的推移，可能会妨碍对用户界面的完善。
屏幕布局无法代替书面的用户和功能需求。
软件需求规范说明模板
1.引言
引言提出的是一个整体介绍，有助于读者了解SRS是如何组织的，如何使用它。
1.1目的
对产品或应用进行定义，在这个文档中说明产品或应用程序的需求，包括修订或者发行版本号。
描述文档所针对的不同读者类型。
1.2文本约定
描述所用的标准或排版约定，包括具体的文本风格、高亮或符号的意思。
如果是在手动标注需求，说明采用的格式。
1.3项目范围
简要描述所制定的软件及其目的。将软件与用户、公司目标及业务目标和策略相关联。
如果有一个独立愿景和范围或其他类似文档可用，可以将其作为参考。
1.4参考文献
列举本软件需求规范说明所参考的文件或其他资源。
2.整体描述
这一部分高度概述产品及其使用的环境、预期的用户和已知约束、假设及依赖。
2.1产品前景
描述产品的背景和起源。
考虑将视觉模型包含进来，如背景图或生态系统图，展示产品与其他系统之间的关联。
2.2 用户类别和特征
确定可能使用该产品的不同用户类别并描述其相关特征。
2.3运行环境
描述软件运行环境，包括硬件平台；操作系统和版本；用户、服务器和数据库，组织。
有时我们必须使用某种特定的编程语言，以及需要对特定代码库花费时间再次开发以便可以使用等等。描述限制开发人员选择的因素，并说明每个约束的基本原理。如果需求包含或者写入解决方案思路，而不是以需要为前提，就是在施加无意义的设计约束，所以要引起我们的警觉。第14章将对约束进行深入的探讨。
2.5假设和依赖
假设就是在没有确凿证据或明确知识的情况下假定为真的说明。
这里所包含的假设要与系统功能相关；与业务相关的假设包含在愿景和范围文档中。
确定开发中的项目或者程序对外部因素或者其控制之外的组件存在的所有依赖关系。
3.系统特性
对要素进行层级组合。
3.X系统特性X
针对每种特性，都可以用3.x中的下一小节3.x.1和3.x.2来重述。
3.x.1描述
对系统特性进行简要描述，表明它级别是高、中还是低。
3.x.2功能需求
列出与此特性相关的具体功能需求。
用户执行特性的服务或者完成用例。
描述产品如何响应可预知的错误条件以及无效的输入和动作。
每个功能需求都要有独一无二的标识。
4.数据需求
信息系统通过处理数据来提供价值。
4.1逻辑数据模型
数据模型从视觉上呈现了系统要处理的数据目标和集合以及它们之间的关系。
数据建模中含有大量的符号，包括实体关系图和UML类图。
针对系统要处理的数据展示其逻辑关系。
4.2数据字典
数据宇典定义数据结构的组成及其意义、数据类型、长度、格式以及组成这些结构的数据元素的允许值。
4.3报告
在此确定出报告并描述特征。
如果报告必须要与某个具体的预定义的布局相吻合，可以将其定义为一个约束，可能还要有一个示例。
将重点放在报告内容、排列顺序、总体水平等的逻辑描述上。
4.4 数据获取、整合、保存和处理
描述数据是如何获取和保存的。
陈述任何涉及需要系统数据完整性保护方面的需求。
5.外部接口需求
保证系统与用户、与外部硬件或软件元素之间的正常通信。
5.1用户界面
描述系统所需的每个用户界面的逻辑特征。6.1“易用性”这一小节介绍
了用户界面的一些具体特征。下面是可能涉及的一些内容：
>参考将要遵循的用户界面标准或是产品线风格指南
>字体、图标、按钮标签、图像、色彩方案、字段序列、常用控件、品牌图形、版权和隐私声明等标准
>屏幕大小、布局或分辨率约束
>显示在每一屏上的标准按钮、功能或导航链接，例如帮助按钮
>快捷键
>信息显示和语法规则
>数据验证准则（如输入值的限制和何时验证字段内容）
>便于软件本地化的布局标准
>为视力受损者、色盲或其他受限用户提供的便利方案
5.2软件接口
描述该产品与其他软件组件之间的关联，包括其他应用程序、数据库、操作系统、工具、库、网站和集成的商业组件.
指出影响接口的非功能需求。
5.3硬件接口
硬件接口描述软件组件和硬件组件之间每个界面（还可能包括系统）的特征。这部分描述可能包括支持的设备类型、软硬件之间的数据和控制交互以及将会用到的通信协议。列出输入和输出、其格式、有效值或范围以及开发人员需要注意的时机问题。
5.4 通信接口
陈述与产品通信功能相关的所有需求。定义任何相关的信息格式。规定通信安全和加密问题、数据传输率、信号交换和同步机制。
6.质量属性
本节主要规定非功能需求而非约束和外部界面需求。质量需求必须是确定的、定量的并可验证的。
6.1易用性
易用性需求涉及易学程度、易用程度、错误的规避和恢复、交互效率和可理解性。
6.2性能
陈述针对各种系统操作的具体性能需求。
6.3保密性
这里规定的需求都关系到限制产品进入或使用的涉及保密或隐私问题的需求。主要包括物理、数据或软件方面的保密性。保密性需求通常起源于业务规则，因此要确定产品必须遵守的保密或隐私政策或法规。
6.4安全性
这里规定的需求涉及产品在使用过程中可能遭受的损失、破坏或伤害。规定必须采取的安全保障措施或行动以及必须预防的有潜在危险的行动。
6.×【其他】
针对每一个额外的产品质量属性，在软件需求规范说明中单独设置一节来描述对客户、开发人员和维护人员都很重要的特征。这些需求可能涉及易用性、效率、可安装性、完整性、互操作性、可修改性、可移植性、可靠性、可重用性、稳健性、可扩展性和可验证性。
7.国际化和本地化需求
国际化和本地化需求确保产品适用于不同国家、文化和地理区域而非产品开发所在地。
8.[其他需求]
定义软件需求规范说明中没有涵盖的其他一些需求。
附录A：词汇表
定义所有专用词条，以便读者能够理解软件需求规范说明。
附录B：分析模型
这一节是可选，包含或涉及相关的分析模型，例如数据流程图、特性树、状态转化图或是实体关系图。