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