安全需求
简介
安全委员会遵循项目安全工作中的 路线 3s 方法，牵头收集反映实现 实际 状态的需求。目标 并非 通过创建新需求来要求为项目增加功能。
需求收集在独立的仓库中：需求仓库
需求仓库内容当前的渲染版本可在 Zephyr 项目需求 中查看。
Zephyr 项目需求管理的目标
在开发过程中，以及为已实现或预期的功能编写文档时，有效的需求管理至关重要，可确保 Zephyr RTOS 满足其预期用途，在约束条件下可靠运行，并能轻松地与硬件平台、嵌入式软件栈及软件应用层集成。
需求管理提供了一种结构化方法，用于在系统整个生命周期内捕获、组织和追溯利益相关方的需求与期望。项目文档 已着重介绍实现细节，涵盖内核功能、API 配置选项以及特定模块的行为。虽然这些内容对开发者至关重要，但仅依赖底层文档可能导致理解碎片化、可追溯性受限，并使采用 Zephyr RTOS 的最终系统难以扩展或通过认证。
为了增进这种理解，并为产品负责人、软件架构师、质量管理人员、安全管理人员和评估人员等非编码角色提供价值，Zephyr 项目需要更高层次的需求来描述整体功能、结构和实现约束。
需求管理指南
以下是需求仓库的使用指南，以及向仓库添加需求时对适当的需求结构和语法的要求。
注意：这些指南用于在需求仓库中创建需求。与面向 Zephyr 用户发布的文档不同，需求仓库中的内容不使用 .rst 编写。有关文档编写指南的更多信息，请参阅 文档准则
范围
需求的初始范围涵盖内核功能。也欢迎提供非内核功能的需求，但这些目前不是重点。
管理 Zephyr 需求：结构、工具和语法
仓库中的需求层级
安全工作组已评估了一种适当的方法，通过需求来补充现有的底层描述。为此，在现有文档结构之上建立了两层需求结构：最高层为系统需求，用于定义 Zephyr RTOS 作为一个整体所具备的总体能力；另一层为软件需求，用于将系统需求中的期望分解为 RTOS 内各个组件的详细规格。
- 系统需求
系统需求描述 Zephyr RTOS（即此处所指的系统）的行为。它们从高层次的角度描述 Zephyr RTOS 的功能和约束，不深入功能本身的细节。
系统需求的目的是概括 Zephyr RTOS 当前已实现的功能。
这些需求从功能、性能和接口的角度阐明 RTOS 必须达到的要求，例如确定性任务调度、中断处理延迟、内存占用限制以及对行业标准的符合性。系统需求是设计决策和确认准则的基础。
编写这些需求时，如果编写者已对 Zephyr RTOS 项目和／或 RTOS 特有的需求与约束有所了解，将有助于需求的编写。
- 软件需求
软件需求位于系统需求层之下，将系统级需求细化到更具体的层次。这些组件级需求将系统级期望分解为 RTOS 内各个组件的详细规格，涵盖调度器、内存管理器以及进程间通信机制等模块。
软件需求描述各个组件的行为、接口和约束，确保它们共同实现系统级目标。这些需求定义功能应能够执行的具体操作及其行为，使每项需求都能通过测试、分析和／或检查进行验证。
这一层级的需求在定义时仍须与具体实现无关。实现的定义应放在文档中；如果文档中尚未包含这些内容，则需要将补充这些内容作为本次需求编写工作的另一项任务。
需求管理工具链
需求仓库：
需求仓库 体现了 Zephyr 的结构化需求管理方法，目前侧重于在其目标安全认证范围内编写需求，但不限于此范围。
使用此仓库时，请遵循常规的 GitHub 分支和拉取请求工作流程。目前，该仓库的拉取请求由安全工作组成员审查，且至少需要获得以下角色之一的批准才能合并：Zephyr 安全经理、Zephyr 安全委员会主席或 Zephyr 安全架构师。
需求工具：
我们使用工具 StrictDoc 来编写 Zephyr 项目的需求、建立需求间的链接，并将其渲染为可浏览的 .html 版本。
StrictDoc 是一款轻量级开源工具，用于编写、浏览和导出结构化需求。它支持分层需求、可追溯性和 HTML 导出，便于评审。
需求使用 StrictDoc 自有的标记语法编写。
对于偏好所见即所得（WYSIWYG）编辑方式的用户，也可以使用 StrictDoc 的本地服务器编辑其导出的 .html 文件。
要设置工具链，请参阅 需求管理入门 一节。
需求验证：
新增和修改的需求（即需求仓库 PR 中的内容）需要通过评审进行验证。评审意见可以直接记录在 PR 评审的评论中。需求评审必须同时考虑技术正确性，以及需求编写必须遵循特定准则这一形式要求。
有关检查清单和形式要求的更多详细信息，请参阅 安全需求检查清单 。Zephyr 项目的测试必须评估实现是否符合需求中描述的功能。
需求语法元素术语表
所有需求都必须使用已定义的语法：
需求 UID（唯一标识符）的管理
需求管理工具 StrictDoc 负责管理每项需求关联的唯一标识符（UID）。要管理 UID，请遵循以下步骤：
不要为新需求添加需求 UID 和 UID 字段
完成新需求的编写后，执行：
strictDoc manage auto-uid .如有需要，使用新分配的 UID 建立需求之间的关联
完成上述操作后，需求便已准备就绪，可以创建拉取请求（PR）。PR 中的 CI 将检查需求 UID 是否有效以及是否存在重复。如果 PR 中存在重复的 UID，需要通过变基并重新执行上述步骤来解决。
一致性
所有需求的语言和措辞应保持一致。（参见：语法 ）
还建议查看 需求仓库 中的现有需求，以及该仓库 PR 中正在进行的讨论，以了解在此上下文中怎样编写需求才合理。
需求仓库的拉取请求
遵循 Zephyr 项目的 贡献指南 。
前提是这些指南适用于需求仓库。
避免创建同时包含细微改动和实质性改动的大型提交。
避免在同一次提交中移动和修改需求。
良好需求的特征
无歧义
可验证（例如，功能需求应可测试）
清晰（简洁、简短、简单、精确）
正确
易于理解
可行（切合实际、能够实现）
独立
原子性
必要
不涉及实现细节（抽象）
需求集合的特征
完整
一致
无冗余
语法
建议采用公认的需求语法。
EARS 是很好的参考，尤其适合不熟悉需求编写的人。
只要满足上述需求特征，也可接受其他格式。