答案。

SRS 是一个结构化文档，描述了开发系统的所有需求。它的任务是尽可能明确和完整地将商业期望“翻译”成项目组的语言。主要部分：

1. 引言（目的、适用范围、术语）
2. 产品描述和商业背景
3. 用户描述及其角色
4. 功能需求（用例，用户故事）
5. 非功能需求（安全性，性能，可用性）
6. 约束
7. 接口
8. 外部依赖
9. 需求验收标准
10. 术语表

关键特点：

• SRS 包含功能需求和非功能需求。
• 需求表达明确，尽量减少歧义。
• SRS 必须反映使用场景、约束、成功结果标准。

为了控制完整性和质量，分析师使用验证检查表、模板、IEEE 830 标准以及与关键利益相关者的定期协调。

难题。

仅仅描述用户故事就足够形成完整的 SRS 吗？

不可以。用户故事展示了功能方面，但未涵盖非功能需求、约束、接口、异常场景和验收标准。

在文档中对同一实体可以使用不同术语吗？

不可以。必须保持术语的一致性：为此会创建术语表并进行文档的交叉评审。

SRS 是否应该包括安全和性能要求？

是的。非功能需求至关重要：缺乏这些会导致技术债务或无法使用系统。

常见错误和反模式

• 需求细节不足，缺乏示例和验收标准。
• 使用模糊表达：“快速”、“方便”、“可靠”没有数值特征。
• 忽略非功能需求。

生活中的例子

消极案例

SRS 只基于用户故事编写，忽略了性能和安全要求。

优点：

• 文档准备快速。

缺点：

• 项目未通过安全审计，无法承载所需的同时用户数。

积极案例

SRS 包含了所需属性的完整清单——功能、非功能需求、验收标准、术语表。

优点：

• 为审计做好准备，所有参与者的要求明确，变更管理高效。

缺点：

• 准备和协调文档的劳动成本增加。