Monte Library 私人知识库 资料库 EN

原始笔记

3.1 Software Requirements

3.1 Software Requirements（整理版）

原始笔记: Software Requirements.md 原始教程: 3.1 Software Requirements created: 2026-07-26 14:53 整理说明: 本版本保持原笔记已有的需求分类与示例，只用教程补充这些概念之间的关系和术语解释。

内容简要概括

软件需求可以从业务、用户和解决方案三个层次理解：业务需求解释项目为什么值得做，用户需求说明利益相关者需要获得什么能力，解决方案需求再把这些目标转化为可实现、可验证的功能和约束。三类需求应当能够相互追溯，避免软件实现偏离最初的业务价值。

Business Requirements、User Requirements、Stakeholder Requirements、Solution Requirements、Functional Requirements、Non-functional Requirements、需求追溯、质量约束

目录

1. 需求的三个层次

需求可以采用多种分类方式。一个实用的高层划分是：

业务需求→用户需求→解决方案需求\text{业务需求} \rightarrow \text{用户需求} \rightarrow \text{解决方案需求}
层次 核心问题 主要视角 是否描述具体实现
Business Requirements 为什么要做？ 组织、公司或研究机构 否
User Requirements 用户需要获得什么能力？ 用户或其他利益相关者 通常不描述
Solution Requirements 软件必须具备什么功能和约束？ 产品与实现 是

这三类需求不只是同一件事的不同详细程度。它们代表不同利益相关者的视角，也使用不同的目标和语言。

2. Business Requirements

业务需求站在组织、公司或研究机构的角度，描述项目希望实现的战略目标，例如：

  • 提高利润率；
  • 扩大市场份额；
  • 开拓新的研究方向；
  • 建立新的合作关系。

它回答的是：

这个项目为什么值得做？它要为组织带来什么价值？

2.1 如何判断是不是业务需求

一个合格的业务需求通常满足三个特点：

  1. 站在组织视角，而不是单个用户视角；
  2. 描述目标或价值，而不是具体功能；
  3. 与项目战略相关，能够解释项目存在的理由。

例如：

  • “降低临床报告的审计风险”是业务需求；
  • “报告中增加标准差”是功能或解决方案需求；
  • “报告必须在 30 秒内生成”通常属于用户期望或非功能需求。

2.2 原笔记示例

  • BR1：提高临床试验报告的统计质量，以满足外部审计需要；
  • BR2：提高试验分析吞吐量，以应对高峰期更高的需求。

3. User or Stakeholder Requirements

用户或利益相关者需求描述特定群体希望最终系统提供什么能力，是业务目标与具体软件实现之间的桥梁。

它回答的是：

为了实现业务目标，某类利益相关者需要完成什么事情或获得什么结果？

3.1 如何判断是不是用户需求

用户需求通常具有以下特点：

  • 明确对应某类利益相关者；
  • 描述用户期望获得的能力或结果；
  • 能够追溯到某个业务需求；
  • 不深入指定技术实现。

3.2 原笔记示例

  • UR1.1（来自 BR1）：按照修订后的审计标准，在生成的试验报告中支持标准差等统计量；
  • UR1.2（来自 BR1）：按照修订后的审计标准，支持在试验报告中生成统计结果的文本表示；
  • UR2.1（来自 BR2）：单份试验报告能够在 30 秒内处理并生成。

UR1.1 和 UR1.2 描述用户需要的结果，没有规定具体的模块、函数或数据结构。UR2.1 则提出了用户可以感知的性能目标。

4. Solution Requirements

解决方案需求描述软件为了满足用户需求而必须具备的具体特征。

它回答的是：

为了满足用户需求，软件具体必须具备什么能力和约束？

解决方案需求可以进一步分为 Functional Requirements 和 Non-functional Requirements。

4.1 Functional Requirements

功能需求关注解决方案“做什么”，即需要提供的功能和特性。

原笔记示例：

  • SR1.1.1（来自 UR1.1）：在数据模型中加入标准差，并提供图形可视化视图；
  • SR1.2.1（来自 UR1.2）：新增用于生成统计量文本表示的视图，并通过可选命令行参数调用。

这些需求已经进入可实现的产品行为层面：需要修改数据模型、视图和命令行接口。

4.2 Non-functional Requirements

非功能需求关注软件行为“如何表现”或受到哪些约束，常见类别包括：

  • 性能；
  • 安全性；
  • 可用性；
  • 可移植性。

非功能需求也称为 Quality of Service Requirements。

原笔记示例：

  • SR2.1.1（来自 UR2.1）：在临床工作站配置上，于 30 秒内生成图形统计报告。

该需求没有增加新的业务功能，而是为已有报告功能规定了运行环境和性能上限。

5. 需求之间的追溯关系

需求编号可以帮助记录上下层关系：

BR1
├── UR1.1
│   └── SR1.1.1
└── UR1.2
    └── SR1.2.1

BR2
└── UR2.1
    └── SR2.1.1

这种追溯关系便于检查：

  • 每个解决方案需求是否服务于真实的用户需求；
  • 每个用户需求是否支持明确的业务目标；
  • 修改或删除某项需求时，哪些上下游需求会受到影响；
  • 测试结果最终能够验证哪项需求。

需求编号本身没有唯一标准，关键是团队采用一致、清晰且可追踪的命名方式。

Switch to English