- 产品必须执行的操作和工作流程（即产品功能的功能细节）
- 产品输入和输出的数据格式和有效性
- 用户界面行为
- 数据完整性和数据安全要求
- 产品必须做什么才能满足安全和其他监管要求
- 系统如何验证用户对系统的使用和修改的访问/授权
- 标准化需求
- 兼容性需求
- 服务中支持需求
- 报废处置需求。
- 对于开发人员：他们需要构建什么
- 对于测试人员：他们需要执行哪些测试
- 对于利益相关者：他们将获得什么的详细描述
- 系统规范
- 子系统规范
- 系统组件规范
- 软件需求规范
- 任务/阶段/功能
- 功能/子功能
- 特性/用例
- 帮助贡献者专注于需要解决的每个特定领域
- 帮助贡献者在向现有系统添加功能时轻松找到需要修改的区域
- 帮助用户（开发人员、测试人员）快速深入到他们正在寻找的确切功能区域
- 情态动词使用指南
- 标准化术语词汇表
- 记录需求指南
- 管理需求文档指南
- 贵组织遵循的其他指南
- https://almooc.com/downloads/FRDTemplate.doc
- https://doit.maryland.gov/SDLC/Documents/func_req_doc.doc
- https://www.sampletemplates.com/business-templates/ functional-requirement-document.html
- 样板部分在项目之间的可移植性
- 需求定义和识别
- 可追溯到更高级别（父级）和较低级别（子级）需求
- 可追溯到测试用例
当我们购买新手机、电视或电脑时，我们会购买它吗？
当然不是。我们购买它是因为它能为我们做些什么。
同样，当公司或政府购买新系统或新企业软件产品时，他们并不关心产品本身。他们关心的是这些产品如何帮助他们实现目标，使他们更有效率，并对他们的底线或预算使用产生积极影响。
重要的是产品的功能。
一般来说，确定产品的功能（即它的功能）的第一步是确定它的功能需求。
什么是功能需求？它们在产品开发中的作用是什么？
在本文中，我们将回答这些问题，提供典型功能需求和需求类型的示例，并提供制定良好功能需求和良好功能需求规范的技巧。
产品开发中的功能需求是什么？
功能需求是对产品（系统、子系统、系统组件、设备或软件程序）必须执行的操作的陈述。
功能需求的类型包括以下规定（规则）：
功能需求和非功能需求之间的区别
功能需求这一术语意味着还必须有一组被归类为非功能需求。事实确实如此。以下是两者的定义：
功能需求是对产品（系统、子系统、设备或软件程序）必须做什么的陈述。
示例：控制系统应防止发动机超速。
非功能需求是对产品是什么或如何构造的陈述，或对产品的设计或行为方式的限制。
示例：系统子系统之间的串行数字通信应通过 MIL-STD-1553B 总线完成。
功能需求
如前所述，功能需求说明产品必须做什么。换句话说，它们定义了产品的操作。因此，它们通常应以产品输出响应其输入的方式进行陈述。
在产品开发中，功能需求通常在设计过程的渐进阶段分解为更详细的需求。它们的满足情况通过功能测试（软件测试、集成测试等）进行验证和确认。功能需求始终是强制性的；除非要求发生变化，否则产品必须满足这些需求。
非功能性需求
非功能性需求规定了产品设计和构造的限制。它们通常由合同或监管需求决定，其中可能包括：
非功能性需求通常不会分解为更详细的需求。它们通常通过检查产品及其文档来验证。如果合同或监管要求规定，非功能性要求将是强制性的。但是，如果营销目标或其他内部目标规定，它们可能不是强制性的，这在消费产品开发中经常发生。
功能需求的形式和示例
功能需求有多种形式。但有些形式比其他形式更好。一般需求工程 (RE) 的最佳实践是编写尽可能清晰简洁的需求。
工程师 Alistair Mavin 是“简易需求语法方法” (EARS) 的开发者，他确定了五种需求原型（每种原型都有一个简单的模板），可用于制定清晰简洁的需求陈述，几乎涵盖所有功能规范需求。
无处不在的需求
这些原型中的第一个是无处不在的需求。
无处不在的功能需求始终处于活动状态。它们不是由事件或输入调用的，也不局限于系统运行状态的子集。
状态驱动的需求
状态驱动功能需求在定义的状态保持为真时始终处于活动状态。在 Mavin 的 EARS 方法中，状态驱动需求用关键字 WHILE 来标识。
事件驱动需求
事件驱动功能需求仅在系统边界检测到事件时才需要响应。换句话说，它们由特定事件触发。EARS 方法使用关键字 WHEN 来识别事件驱动需求。
可选功能需求
可选功能功能需求仅当可选功能作为系统的一部分存在时才适用。这些要求由 EARS 方法通过关键字 WHERE 来识别。
不良行为需求
不良行为功能要求涵盖所有不良情况。良好的系统工程 (SE) 实践能够预测不良情况并施加要求以缓解这些情况。
当系统必须在非最佳条件下响应触发器时，通常会施加不良行为要求。EARS 方法使用关键字组合 IF/THEN 来识别旨在缓解不良行为的要求。
复杂需求
通常，在特定事件发生之前，必须存在一组特定的一个或多个先决条件（状态或可选功能），以便该事件触发所需的系统响应。在这种情况下，可以使用关键字组合来组合 EARS 模板。
复杂需求可以针对所需行为或不想要的行为进行组合。EARS 方法为每种行为都提供了一个模板。
编写良好功能需求的技巧
编写清晰、准确的功能需求是一项宝贵的工程技能，需要经过一些练习才能掌握。这就是为什么许多工程组织都编制了编写需求的指南，例如国际系统工程理事会 (INCOSE) 发布的《编写需求指南》。
此类指南的详尽列表超出了本文的范围，但以下是在编写功能需求时需要牢记的六个重要技巧：
1. 情态动词的使用要保持一致
情态动词、情态助动词或情态助动词是“shall”、“must”、“will”或“should”等词，与主动词一起使用，表达必要性、意图、期望、建议或可能性等想法。
在工程规范中，情态动词用于区分具有约束力的要求、不具约束力的建议和系统操作环境的预期行为。因此，需求作者在使用情态动词时要保持一致，并向开发人员、测试人员、质量保证工程师和监管机构准确传达每个情态动词在其规范中的解释方式，这一点很重要。
长期以来，情态动词在规范中的使用一直是 SE/RE 社区争论的话题。然而，大家一致认为，“shall”和“must”是表达需求的最佳情态动词选择，而“will”应该用来表达预期的外部行为或目的声明。非约束性建议或规定可以用“应该”或“可以”来表达。
此外，许多组织使用“必须”一词来表达约束和某些质量和性能要求（非功能性要求）。使用“必须”使他们无需诉诸被动语态即可表达约束，并轻松区分功能性要求（用“应该”表达）和非功能性要求（用“必须”表达）。
SE/RE 的良好做法是准确定义某些术语在文档本身中的使用方式，以及在文档引用的非需求文档中发现这些术语时应如何解释。这通常在规范开头的专门部分中完成。
2. 用唯一标识符标记每个需求
另一个 SE/RE 最佳实践是使用唯一的 ID 号或代码标记每个需求。
事实上，需求标识符通常本身就是一项需求。根据客户和供应商之间的合同购买的系统（例如大多数政府购买的系统）通常按照公认的行业标准（如 IEEE/EIA 12207）作为合同规定进行开发。此类标准通常要求每个需求文档中的每个需求都标有项目唯一标识符 (PUI)。
为需求分配唯一标识符为系统开发人员带来了巨大好处。
用 PUI 标记每个需求可促进和简化连续设计级别的需求与验证它们的测试之间的可追溯性。简短的标识符可以轻松构建可追溯性表，这些表将每个需求清楚地链接到更高级别文档中的祖先以及旨在验证它的特定测试。可追溯性表简化了向客户和内部利益相关者展示系统已按照商定的顶级要求开发并证明符合这些要求的过程。
自动化需求管理工具通常包括一种分配唯一标识符的自动方法，从而简化了此过程。
3. 在每个需求陈述中只写一个需求
小心包含单词“and”和多个情态动词的长而复杂的需求陈述。
当试图定义一个复杂的功能时，很容易陷入在一个段落中描述所有内容的陷阱，甚至更糟的是，在一个句子中描述所有内容。花时间分析长需求陈述。如果它们包含单词和或多个“shall”或其他情态动词，它们可能包含多个需求。重写它们以获得两个或更多简单的需求陈述，每个陈述都有自己的 shall。然后，为每个陈述赋予自己的唯一标识符。
4. 尽可能简洁地编写需求陈述
分析和重写长需求（即使只有一个 shall）的另一个原因是，长需求比简短、简洁的需求更容易被误解。
编写尽可能简洁的需求是一种很好的 SE/RE 做法。需求模板（如前面描述的 EARS 模式）可以极大地帮助实现这一目标。
5. 确保每个需求都是可测试的。
每次编写新的功能需求时，您都应该问自己以下问题：
如何验证此需求是否成功实施？
在编写需求时考虑特定的测试场景有助于确保设计和测试工程师都了解他们必须做什么。
特定的测试用例将影响需求的详细程度。高级需求通常通过检查或用户测试进行测试，因此范围可能很广。将通过软件测试或系统集成测试进行验证的较低级别需求必须指定更详细的内容。
什么是功能需求文档？
功能需求文档 (FRD) — 也称为功能需求规范、功能规范或功能规范文档 — 是更高级别的产品需求文档 (PRD) 的更详细的技术后续文档。
FRD 描述系统用户需要什么，通常是系统输出作为其输入的函数。它旨在提供精确的功能需求以及对开发人员和测试人员的指导，这些指导是在对 PRD 中的需求进行分析和分解之后提供的。
FRD 不定义要开发的系统的内部工作原理或系统功能的实现方式。相反，它关注各种外部代理（用户、外围设备、其他系统或子系统）在与系统交互时应该观察的内容。它传达：
对于高度复杂的系统，功能需求可以通过一系列功能规范来分解，这些规范可能包括：
在某些行业和组织中，功能规范通常是更大规范的一部分，该规范还包含适用于要设计的系统或子系统的非功能性要求。然而，这些非功能性要求通常会与功能性需求分开。
建立良好 FRD 的秘诀
编写一个具有凝聚力、可用性和易于导航的 FRD 可能是一项挑战。以下是一些有用的指导原则。
1. 以分层结构组织文档
为了使您的 FRD 易于理解和使用，请使用分层结构进行组织。合适的层次结构可以包括（但不限于）：
分层规范结构提供了多种好处，包括：
2. 标准化您的需求语言
口语中充满了具有多种定义的单词，这些单词会根据上下文产生微妙的含义。虽然这种广泛的灵活性非常适合自我表达，但在指定和解释需求时，可能会导致混乱和分歧。
减少对需求定义不明确和误解的一个好方法是标准化一些用于表达需求的语言。在需求文档的开头创建一个标准化术语词汇表。在这个词汇表中，准确定义某些术语在文档本身中的使用方式，以及在文档引用的非需求文档中发现这些术语时应如何解释它们。
严格定义术语并严格遵守您的定义不仅可以减少负责解释需求的人员之间的困惑；通过实践，使用标准化语言还可以节省您编写需求的时间。
3. 使用好的 FRD 模板或专用的 RM 平台
在构建任何类型的结构时，明智的做法是从坚实的基础或经过验证的模型开始。在构建功能需求文档时，最好从一个好的模板开始。
好的模板将包括标准化部分，例如：
标准化部分（或“样板”）促进和促进项目之间的一致性，这是模板的主要优势。这些部分在项目之间以及公司内部团队之间变化不大。它们只会随着时间的推移随着方法和经验教训的变化而缓慢发展。因此，它们为一致的需求开发、员工教育和与客户的沟通提供了一个稳定的平台。
网络上有许多通用的 FRD 模板。如果您开发商业产品，您可能会发现以下内容之一可以根据您公司的实践和程序进行定制：
另一方面，如果您的公司为美国国防部开发系统或软件，您可能更喜欢根据 MIL-STD-961E（国防部标准实践：国防和程序独特规范格式和内容）构建的系统规范模板。QRA Corp 在其网站上提供了一个模板：https://qracorp.com/requirements-document-templates/。
4. 模板的缺点
最后一条提示的一个警告：在通用文档平台中使用模板有几个缺点。首先，在 Word、Excel 或 Google Docs 中记录需求往往会使协作变得繁琐。其次，这些平台并非为支持清晰、系统的需求可追溯性而构建。
Gartner 表示，公司难以在需求规范中实现足够的可见性和可追溯性的主要原因之一是依赖通用文档软件，而不是协作需求管理平台。
“由于成本、可用性和熟悉程度，最广泛采用的需求工具仍然是通用文档软件，例如 Microsoft Office 或 Google Docs（占市场份额的 40% 至 50%）。然而，这些工具往往导致需求管理不善，从而消除并超出了工具本身的任何成本效益。需求最终被记录在各种文档和电子表格中，并辅以非托管版本的便签，无法追溯或重复使用。这会导致用户验收测试周期成本更高，无论是执行时间还是在流程后期发现的问题的补救，解决这些问题的成本都要高得多。” – Gartner Research
成功开发、验证和确认良好的功能需求对于产品成功至关重要。为了实现这些目标，系统、软件、硬件、测试和集成团队都必须密切合作，以确保项目的功能需求、非功能需求、测试用例和验证/确认程序都得到充分定义。可见性和可追溯性对于此过程至关重要。
良好的需求管理 (RM) 平台将提供字段、格式和结构关系，以促进：
除了这些基本设施之外，最先进的 RM 平台还将通过允许所有用户访问您的最新需求基线及其所有待定更改来促进团队协作。这使得需求跟踪、可追溯性和测试覆盖率保证比使用文档或电子表格更容易实现。
了解有关 Jama Connect 如何简化跟踪和追踪需求的更多信息。查看解决方案。
