1 简介
本文解读ieee-29148:2011第九章的前半部分，除翻译外有做适当调整。主要是描述了所需信息项的规范内容。不含软件需求规范文档 1的部分（本站另文介绍）。
2 一般内容
2.1 识别
包括以下身份证明事项：
- 标题
- 修订通知 标题和修订通知可唯一标识文档。修订信息可能包括项目名称、文档版本号、发布日期、批准签名、文档当前版本中已更改的子条款列表以及文档所有先前版本的版本号和发布日期列表。
2.2 前言
包括以下前言：
- 目录
- 图片列表
- 表格列表
2.3 定义
为任何具有超出正常词典定义的特殊含义的单词或短语提供定义。
2.4 参考文献
包括有关参考文献的以下信息：
- 提供其他地方引用的所有文件的完整清单；
- 通过标题、报告编号(如适用)、日期和出版机构识别每份文件；
- 指定可以获得参考资料的来源。
- 这些信息可以通过引用附录或其他文件来提供。参考信息应细分为“合规性”部分，其中包含对引用文件中包含要求的引用，以及“指南”部分，其中包含对引用文件中包含信息但不包含要求的引用的引用。
2.5 首字母缩略词和缩写
拼写或定义文件中使用的所有首字母缩略词和缩写。 注：该信息可以通过引用文件中的一个或多个附录或通过引用其他文件来提供。
3 利益相关者需求规范(StRS)文件
本条款定义了利益相关者 2需求规范(StRS)文件的规范内容。项目应根据项目关于利益相关者需求规范文件的政策生成以下信息项。文件中信息项的组织方式(例如顺序和章节结构)可根据项目的文档政策选择。
3.1 业务目的
在组织层面描述组织寻求新业务或改变现有业务以适应新管理环境的原因和背景。在此背景下，它应该描述拟议的系统将如何有助于实现业务目标。
3.2 业务范围
定义所考虑的业务领域
- 通过名称识别业务域。
- 定义相关业务领域所包含的业务活动范围。范围可以根据组织内的部门和与业务活动直接相关的外部实体或业务活动要执行的功能来定义。显示范围之外的环境实体是有帮助的。
- 描述正在开发或变更的系统的范围。描述包括假设系统支持哪些业务活动。
3.3 业务概况
描述相关业务领域的主要内部分部和外部实体以及它们之间的相互关系。建议使用图表描述。
3.4 利益相关者
列出利益相关者或利益相关者的类别，并描述他们将如何影响组织和业务，或将如何影响系统的开发和运行。
3.5 商业环境
定义在理解新业务或现有业务以及引出利益相关者对系统开发或变更的要求时应考虑的外部和内部环境因素。环境因素应包括市场趋势、法律法规、社会责任和技术基础等外部条件对业务以及系统可能产生的影响。
3.6 目标和目的
描述通过所提议的系统将获得的业务成果。
3.7 商业模式
描述预期实现业务目标的方法。描述应集中在要开发或更改的系统所支持的方法上，内容包括产品和服务、地域和区域、分销渠道、业务联盟和伙伴关系以及财务和收入模式等。 注：模型有关商业模式 3元素的详细讨论和定义，请参阅商业动机(BMM)由OMG指定。
3.8 信息环境
描述多个信息系统基于共同基础的组织级决策的总体策略。它应包括以下项目：
- 项目组合当多个系统项目正在运行或计划追求同一业务目标时，优先级 4、相对定位和可能的限制来自组合管理策略。
- 长期系统规划当通用系统基础设施或架构已经确定或计划，它应该被描述为对可能的设计决策的限制。
- 数据库配置组织级数据库配置计划以及可能的限制应明确规定组织全局数据的可用性和可访问性。
3.9 业务流程
提供业务活动流程的描述以及流程内可能的系统接口。此信息项的目的是表示系统如何以及在何种情况下支持业务活动。一般来说，业务流程形成具有分解和分类的层次结构。每个业务流程在层次结构中都应具有唯一的名称和编号。单个业务流程的描述应表示为表示活动序列的图表。
3.10 业务运营政策及规则
描述执行业务流程时应用的逻辑命题。命题将是业务流程中业务活动顺序的开始、分支和终止条件；业务流程中的判断标准；或评估数量的公式，这些公式可能在SyRS和SRS中的功能需求中得到解决。策略和规则应具有唯一的名称和编号，并应在业务流程描述中引用。
3.11 业务运营限制
描述执行业务流程时要施加的条件。这些条件可能是绩效约束(例如，流程应在触发事件发生后的一天内完成)，也可能是管理要求，例如“应监控和记录流程的每次发生”。
3.12 商业运作模式
描述在不稳定状态下开展业务运营的方法，例如，由于某些事件的频繁发生，业务运营可能变得极其繁忙的状态。不稳定的业务运营状态包括当拟议系统由于事故或自然灾害等意外情况而不可用时采用手动操作模式。
3.13 业务运营质量
定义业务运营所需的质量级别。例如，业务流程可能优先考虑紧急性，而不是业务流程的可靠性。
3.14 业务结构
识别并描述与系统相关的业务结构，例如组织结构(分部和部门)、角色 5和职责结构、地理结构以及资源共享结构。可能需要将系统功能与这些结构联系起来，并支持未来的结构变化。
3.15 用户需求
用户需求(在StRS的背景下)包括用户/操作员/维护人员在使用系统时需要执行的输入/选择/信息观察 6；他们为执行这些当任务而需要从系统获得的任何输出；以及任何适用的条件或第条件或约束，这些条件或约束决定了他们与系统的交互(即可用性)。然后，这些需求用于描述操作场景，这些场景指定了在与系统交互时如何满足这些需求。 为设计指定的使用环境(即系统将使用的环境)应作为用户需求规范的一部分进行指定，以明确确定需求适用的条件。系统的可用性要求和目标包括特定使用环境中可衡量的有效性、效率和第效率和满意度标准。 注1：有关使用环境和样本报告的更多信息，请参阅ISO 9241‐11。有关日常产品使用环境的更多信息，请参阅ISO 20282‐1:2006。 注2：有关用户需求、使用环境、用户需求的附加材料可在ISO/IEC TR 2504 注2：有关用户需求、使用环境、用户需求的附加材料可在ISO/IEC TR 25060和ISO 9241‐210中找到。
3.16 运行概念
以高层次的方式描述所提议的系统，指出要提供的操作功能，但不指定设计细节。应包括以下信息：
- 运营政策和限制
- 拟议系统的描述
- 系统运行模式
- 用户类别及其他相关人员
- 支持环境
3.17 操作场景
描述用户/操作员/维护人员如何与系统交互的示例(使用环境)。场景针对系统支持的业务流程中的一项活动或一系列活动进行描述。该场景应具有唯一的名称和编号，并应在业务流程描述中引用。 注意有关使用环境和可用性要求的更多信息，请参阅ISO/IEC TR 25060和ISO 9241‐210。
3.18 项目限制
描述在成本和进度内完成项目的限制。
4 系统需求规范(SyRS)文档
本条款定义了系统需求规范(SyRS)的规范内容。项目应根据项目关于系统需求规范文档 7的政策生成以下信息项内容。文档中内容的组织方式(例如顺序和章节结构)可根据项目的文档政策选择。
4.1 系统目的
定义开发或修改系统的原因。
4.2 系统范围
定义所考虑系统的范围
- 通过名称来识别要生产的系统。
- 引用并陈述先前完成的需求分析的结果，以简短但清晰的方式表达用户的问题。它解释了系统将做什么和不会做什么来满足这些需求。
- 描述所指定系统的应用。作为其中的一部分，它应该描述所有尽可能精确地描述相关的顶层利益、目的和目标。
4.3 系统概述
4.3.1 系统上下文
概括描述系统的主要元素，包括人为因素以及它们如何相互作用。系统概述包括适当的图表和叙述，以提供系统背景，定义跨越系统边界的所有重要接口。
4.3.2 系统功能
描述主要的系统能力、条件和限制。
4.3.3 用户特征
识别系统的每种类型的用户/操作员/维护人员(按功能、位置、设备类型)、每组中的数量以及他们使用系统的性质。 注：适当时，SyRS和SRS的用户特性应该一致。
4.4 功能要求
定义适用于系统操作的功能要求。
4.5 可用性要求
定义可用性(使用质量)要求。系统的可用性要求和目标包括特定使用环境中可衡量的有效性、效率和满意度标准。
4.6 性能要求
通过考虑这些因素来定义关键性能条件及其相关能力
- 发生的动态动作或变化(例如速率、速度、运动和噪音水平)。
- 定量标准，涵盖设备在规定的环境和其他条件下满足用户需求所需的能效能力，包括最低总预期寿命。表明所需的运行持续时间和计划利用率。
- 运行阶段和模式的性能要求。
4.7 系统接口
指定系统元素之间以及与外部实体之间的形式接口要求。系统元素之间的接口应包括与人为因素的接口。与外部实体的接口应包括其他系统。定义与接口相关的任何相互依赖关系或约束(例如，通信协议、特殊设备、标准、固定格式)。每个接口可能代表双向信息流。为了清晰起见，可以在适当的时候使用界面的图形表示。
4.8 系统操作
4.8.1 人机系统集成要求
参考适用文件并指定任何特殊或独特要求，例如，对人员职能分配以及通信和人员/设备交互的限制。定义由于操作的性敏感性或任务的关键性而需要集中人体工程学关注的任何特定区域、站点或设备(即人为错误的影响特别严重的区域)。 注：ISO 18529，人体工程学-人机交互的人体工程学-以人为本的生命周期过程描述，包含一个形式化的模型，可用于规范、评估和改进系统开发和运行中以人为本的过程。
4.8.2 可维护性
指定适用于计划维护和支持环境中的维护的量化可维护性要求。示例如下：
- 时间(例如平均和最大停机时间、反应时间、周转时间、平均和最大交付时间维修，维护操作之间的平均时间)
- 费率(例如，每项具体维护行动的维护人员小时数、运行就绪率、维护每小时运行时间、预防性维护频率)
- 维护复杂性(来(例如，人员数量和技术水平、支持设备的种类、拆卸/更换/修理组件)
- 维护行动指标(例如，每运行小时的维护成本、每次大修的员工小时数)
- **系统内组件和组件内部件的可访问性
4.8.3 可靠性
以量化的方式指定系统可靠性要求，包括满足可靠性要求的条件。这还可能包括可靠性分配模型，以支持将可靠性值分配给系统功能，以达到所需的系统可靠性。
4.9 系统模式和状态
如果系统可以以各种模式或情况存在，请定义这些并在适当的情况下使用图表。 注：系统模式是指一组状态的集合。
4.10 物理特性
4.10.1 物理需求
包括重量、体积和尺寸限制。包括系统安装位置的施工特性、本规范所涵盖的物品或服务所用材料的要求，以及铭牌和系统标记、设备互换性和工艺的要求。
4.10.2 适应性需求
定义增长、扩展、容量和收缩的要求。例如，如果系统需要未来的网络带宽，则应为适用的硬件指定额外的卡槽，以便在需求增加时容纳新的网卡。
4.11 环境条件
包括系统将遇到的环境条件。应解决以下领域：自然环境(例如风、雨、温度、植物、动物、真菌、霉菌、沙子、盐雾、灰尘、辐射、化学物质和浸泡)；感应环境(例如运动、冲击、噪音、电磁、热)；电磁信号环境；自感应环境(例如运动、冲击、噪音、电磁、热)；威胁；以及合作环境。还应考虑法律/法规、政治、经济、社会和商业环境。
4.12 系统安全
定义与系统所在设施和系统本身的操作安全要求相关的系统安全要求。安全要求的一个例子可能是指定安全和隐私要求，包括对系统的访问限制(例如登录程序和密码的存在)以及数据保护和恢复方法。这可能包括保护系统免受意外或恶意访问、使用、修改、破坏或泄露的因素。特别是在安全关键型嵌入式系统中，这可能包含分布式日志或数据集历史记录、将某些功能分配给不同的单一系统，或限制系统某些区域之间的通信。
4.13 信息管理
定义系统对接收、生成或导出的信息的管理要求。示例包括系统需要接收和存储的信息类型和数量、对系统处理的信息征收的任何专有或其他保护，以及对信息的备份和归档要求。
4.14 政策法规
详细说明任何会影响系统运行或性能的相关组织政策以及任何相关的外部监管要求或正常商业惯例所施加的限制。要求的例子包括多语言支持、劳工政策、个人信息保护以及向监管机构的报告。指定健康和安全标准，包括系统设计的基本标准、设备特性、操作方法以及有毒系统和电磁辐射等环境影响。
4.15 系统生命周期维持
概述质量活动，例如评审 8、测量收集和分析，以帮助实现质量体系。生命周期维持还包括提供所需的设施，以提供运营和仓库级支持、备件、采购和供应、供应、技术文档和数据、支持人员培训、初始干部培训和初始承包商后勤支持。
4.16 包装、装卸、装运和运输
定义对系统施加的要求，以确保它可以在预期的工作环境中进行包装、处理、装运和运输。
4.17 验证
提供计划用于鉴定系统或系统要素的验证途径和方法。
4.18 假设和依赖关系
列出适用于系统需求的任何假设和依赖关系，这些假设和依赖关系应该在分配和推导低级系统需求时予以考虑。