在需求工程过程中,项目需生成关键信息文档,包括利益相关者需求规范 (StRS)、系统需求规范 (SyRS) 和软件需求规范 (SRS)。这些文档可能包含相似的信息点,从不同角度描述同一产品的需求。ISO/IEC/IEEE 15289 提供了识别和规划特定信息项的指导。信息项管理应遵循 ISO/IEC 12207 和 ISO/IEC 15288 的规定。StRS 描述了组织开发或更改系统的动机,定义了使用系统的流程和政策,并记录了最高级别的需求。StRS 确保利益相关者积极参与需求流程,并涵盖了组织需求、业务需求和用户需求。

信息项指南

在需求工程的过程中,项目应当生成以下几种关键的信息文档:

  • 利益相关者 1需求规范文档 (StRS)
  • 系统需求规范文档 2 (SyRS)
  • 软件需求规范文档 3 (SRS)(如果遵循 ISO/IEC 12207 标准)

需要注意的是:

  1. 在实际操作中,针对上述每种类型的文档可能会产生多个具体的规范文件。例如,可以分别为整个系统及其各个组成元素创建独立的 SyRS 文档。
  2. StRS、SyRS 和 SRS 这三种规范可能包含相似的信息点。这些信息点可以从不同的角度来描述同一产品的需求。为了便于理解和使用,本标准分别列出了这三类规范文档的典型内容结构。
  3. 参考 ISO/IEC/IEEE 15289 标准可以获得关于如何识别和规划在整个系统及软件生命周期中需要产生的特定信息项的具体指导。

对于信息项的管理,应按照 ISO/IEC 12207:2008 (IEEE Std 12207-2008) 和 ISO/IEC 15288:2008 (IEEE Std 15288-2008) 中规定的信息管理过程以及 ISO/IEC 12207:2008 的文件管理过程来进行。需要注意的是,信息项并不强制要求以物理形式存在;只要确保相关信息能够方便获取,并且按照逻辑顺序组织即可。

示例: 在采用模型驱动开发 (MDD) 方法时,几乎所有系统信息都是通过建模工具进行维护的。在这种情况下,信息会根据其上下文关系存储于建模工具的数据库中。用户可以直接查看模型中的信息,或者将所需数据导出为报告或表格的形式以便进一步分析和处理。

1 需求信息项概述

本文档系列以大纲的形式提供了三种规范文档的典型内容结构,这是第一部分 StRS 部分。

2 利益相关者需求规范 (StRS)

2.1 简介

利益相关者需求规范 (StRS) 描述了组织开发或更改系统的动机,定义了使用系统的流程和政策/规则,并从利益相关者的角度记录了最高级别的需求。这些需求包括基于使用环境得出的用户、操作员和维护人员的需求。

在商业环境中,StRS 说明了组织如何开展新业务或调整现有业务以适应新的市场环境,以及如何利用系统作为促进业务发展的手段。在组织层面,StRS 涵盖了组织环境、目标与目的、商业模式 4及信息环境;而在业务运营层面,则涵盖了业务运营模式、质量标准、组织结构以及拟议系统的概念。

利益相关者指定的信息项 应当包含在 StRS 中,且利益相关者需对规范的内容负责。StRS 是确保利益相关者积极参与需求流程的基础。通常情况下,StRS 包含的利益相关者需求类型有:

  • 组织需求:涉及组织整体的目标和方向。
  • 业务需求 5:描述具体的业务活动及其目标。
  • 用户需求:反映最终用户的实际需要。

注释 1: ISO/IEC/IEEE 15289 标准提供了关于如何将业务、组织和用户(即利益相关者)的需求整合进系统需求规范的指导。本国际标准将这些需求纳入 StRS,因为内容应从利益相关者的视角出发。随后,这些需求可以通过解决具体技术问题在系统需求规范文档 (SyRS) 中得到实现。

注释 2: 在许多行业中,StRS 常被视为等同于业务需求规范 (BRS)。根据具体情况,本国际标准的用户可以选择将 StRS 替换为 BRS。

注释 3: 根据《商业分析知识体系指南》(BABOK),利益相关者需求和业务需求之间存在以下区别: - 业务需求 是对企业目标、目的或需求的高层次描述,它们解释了启动项目的原因、预期达成的目标以及衡量成功的指标。 - 利益相关者需求 则是针对特定利益相关者或利益相关者群体的具体需求的表述,它描述了该利益相关者的需求以及他们如何与解决方案互动。利益相关者需求起到了连接业务需求与各种解决方案需求之间的桥梁作用。

通过这种方式,StRS 不仅帮助明确了项目的宏观方向,还确保了所有关键参与者的需求都得到了充分考虑和满足。

2.2 StRS 示例大纲

StRS 的具体要求条款 应以利益相关者一致同意的组织方式来编排,即采用有助于理解需求的结构。不同的项目可能需要不同的组织方式,并没有一种通用的最佳方法。如下展示了一个在组织/业务环境中创建的 StRS 示例大纲。

1. 简介

  • 1.1 业务宗旨:概述项目的总体目标和愿景。
  • 1.2 业务范围:定义项目的边界和覆盖范围。
  • 1.3 业务概况:提供项目的背景信息和上下文。
  • 1.4 定义:列出文档中使用的术语及其定义。
  • 1.5 利益相关者:识别并描述关键的利益相关者及其角色 6

2. 参考文献

列出编写 StRS 时参考的所有文档、标准和其他资料。

3. 经营管理要求

  • 3.1 经营环境:描述组织所处的外部环境,包括市场条件、竞争状况等。
  • 3.2 目标和宗旨:明确组织的长期目标和短期目标。
  • 3.3 商业模式:阐述组织如何创造、传递和获取价值。
  • 3.4 信息环境:描述组织的信息技术 7基础设施和支持系统。

4. 业务运营要求

  • 4.1 业务流程:详细说明主要的业务流程和活动。
  • 4.2 业务运营政策与规则:列出指导业务运营的政策和规则。
  • 4.3 业务运营约束:描述对业务运营有影响的限制条件。
  • 4.4 业务运营模式:解释业务运营的具体模式和方法。
  • 4.5 业务运营质量:定义衡量业务运营质量的标准和指标。
  • 4.6 业务结构:描述组织的结构和各部门之间的关系。

5. 用户要求

详细说明用户(如最终用户、操作员、维护人员)的具体需求。

6. 拟议系统的概念

  • 6.1 运行概念:概述系统如何运行以满足业务需求。
  • 6.2 运行场景:提供具体的运行场景示例,展示系统如何在实际情况下工作。

7. 项目约束

列出项目实施过程中必须遵守的各种约束条件,如时间、成本、资源和技术限制。

8. 附录

  • 8.1 首字母缩略词和缩写:提供文档中使用的所有首字母缩略词和缩写的完整列表。

通过这种结构化的组织方式,StRS 能够清晰地传达利益相关者的需求,确保所有参与者都能理解和遵循项目的目标和要求。