如何编写软件需求规格说明书（SRS）

• 促进相关方沟通
  帮助客户、用户、开发团队和测试团队等项目相关方对待开发的系统形成一致的理解。
• 为开发打下基础
  为设计、实现和测试等后续环节提供依据。
• 为变更管理提供基准
  作为追踪和管理项目过程中需求变更的依据。
• 为验证与确认提供依据
  提供标准，用于验证（Verification）和确认（Validation）开发出的系统是否满足用户需求。

1. 引言（Introduction）
   • 目的（Purpose）
     ：说明 SRS 本身的用途及目标读者。
   • 范围（Scope）
     ：简述待开发软件的名称、目标和主要功能，明确系统的职责边界。
   • 定义、首字母缩略词和缩写（Definitions, Acronyms, and Abbreviations）
     ：定义文档中使用的术语与缩写。
   • 参考资料（References）
     ：列出编写 SRS 时参考的文件，例如项目计划和相关标准。
   • 概述（Overview）
     ：简要说明 SRS 其余部分的组织方式及各章内容。
2. 总体说明（Overall Description）
   • 产品定位（Product Perspective）
     ：说明待开发系统与其他相关系统或现有系统的关系，例如它是独立产品，还是更大系统的一部分。
   • 产品功能（Product Functions）
     ：概括系统应执行的主要功能。详细的功能需求在下一章说明。
   • 用户特征（User Characteristics）
     ：介绍主要用户群体及其知识水平、经验和技术背景。
   • 约束（Constraints）
     ：列明影响开发过程或交付成果的限制，例如必须使用特定硬件或软件、开发语言限制、预算或工期约束，以及安全合规要求。
   • 假设与依赖（Assumptions and Dependencies）
     ：说明 SRS 以哪些假设为前提，以及哪些外部因素会影响项目成功。
3. 具体需求（Specific Requirements）

   这是 SRS 的核心，具体描述系统必须满足的所有需求。

   通常分为功能需求、非功能需求和接口需求等，下面会详细介绍。
4. 附录（Appendices）与索引（Index）

   （可选）

   可以放入不适合纳入正文的补充信息，例如数据模型、详细的用例说明或术语索引。

• 常用“系统应当……（The system shall...）”或“用户可以……（The user can...）”等句式。
• 每项功能都应描述得清楚、无歧义，并且可以验证。

• “用户应当能够使用账号和密码登录系统。”
• “系统应支持按书名、作者或出版社关键词搜索图书。”
• “管理员应当能够创建新用户账号，并修改或删除现有用户的信息。”
• “用户订购商品时，系统应检查库存，并在库存不足时通知用户。”

• 从用户角度识别所需功能。用例分析有助于完成这一步。
• 针对每项功能，明确输入、处理过程、输出和异常情况。
• 为每项需求分配唯一标识，例如“FR-001：用户登录”，便于追踪和管理。

• 性能（Performance）
  ：
  “在正常条件下，系统应在 2 秒内响应用户请求。”
  “系统应支持 1,000 名用户同时使用。”
• 易用性（Usability）
  ：
  “系统应提供直观的 UI，使首次使用的用户能在 10 分钟内掌握基本功能。”
  “所有功能都应支持仅用键盘访问。”
• 可靠性（Reliability）
  ：
  “系统应保证每年 99.9% 的可用性，即每年停机不超过 8.76 小时。”
  “系统发生故障时，应在 5 分钟内自动恢复。”
• 安全性（Security）
  ：
  “所有用户密码都应加密存储。”
  “系统应能抵御 SQL 注入和 XSS 攻击。”
• 可维护性（Maintainability）
  ：
  “代码应符合内部编码规范，主要模块应有注释。”
  “新增支付模块时，不应影响现有支付系统。”
• 可移植性（Portability）
  ：
  “系统应能在 Windows 和 Linux 操作系统上运行。”

• 清晰（Clear）、无歧义（Unambiguous）
  每项需求都应表述清楚，只能有一种解读。避免主观表述和含义模糊的术语。
  • 反例：“系统应对用户友好。”（含义模糊）
  • 正例：“系统的主要功能应在三次点击内访问。”（具体）
• 完整（Complete）
  列出系统应实现的全部功能、性能目标和约束。
  尽量减少标记为“待定（To Be Determined，TBD）”的内容。
• 一致（Consistent）
  文档内的需求应彼此一致，避免矛盾或冲突。
  术语和表述方式也应统一。
• 准确（Correct）
  所有需求都应准确反映客户或用户的真实需要。
• 可验证（Verifiable / Testable）
  每项需求都应能通过测试或分析判断系统是否满足要求。
  避免无法衡量的需求。
• 可追踪（Traceable）
  每项需求都应有唯一标识，并与设计文档、代码和测试用例等关联，以便追踪变更历史。
• 易修改（Modifiable）
  需求可能变化，文档结构应便于在发生变化时更新和管理。
• 有优先级（Prioritized）
  不同需求的重要程度不同。可以用 MoSCoW（Must have、Should have、Could have、Won't have）等方法标明优先级，便于在资源有限时合理安排开发。

下一篇将详细介绍各种需求分析方法，例如形式化和非形式化分析、访谈与研讨会。

• IEEE 830-1998 - IEEE Recommended Practice for Software Requirements Specifications↗（英文，IEEE 的 SRS 编写规范，可能需要付费。可查找摘要或解读资料。）
• Software requirements specification - Wikipedia↗（英文，维基百科对 SRS 的介绍。）
• How to Write a Software Requirements Specification (SRS Document) - Perforce↗（英文，详细的 SRS 编写指南。）