什么是软件需求规范文档 （SRS）？
软件需求规范 （SRS） 文档列出了未来项目的需求、期望、设计和标准。其中包括规定项目目标的高级业务需求、最终用户要求和需求以及产品在技术方面的功能。简而言之，SRS 提供了软件产品应如何工作以及您的开发团队应如何使其工作的详细说明。
想象一下，你有一个关于应用程序的好主意。你对你想要它做什么以及你希望它的外观有一个愿景，但你知道你不能只是给开发人员一个口头描述，并期望他们符合你的期望。这就是SRS的用武之地。
为什么要使用 SRS？
如果开发人员在创建新产品，您最终可能会花费比预期更多的时间和金钱来尝试使软件与您的想法相匹配。
撰写 SRS 文档可帮助您将想法写在纸上并设置清晰的要求列表。本文档成为您产品的唯一事实来源，因此您的所有团队（从营销到维护）都在同一页面上。
由于软件需求规范是动态文档，因此它们还可以充当每个文档之间的通信点。利益 相关 者参与产品开发过程。在任何软件开发项目中，产品迭代都必然会发生 — 通过记录 SRS 中的更改，所有各方都可以在文档中验证它们。这将减轻有关产品要求的任何混淆。
SRS 文档中应包含的内容
基本的 SRS 文档大纲包括四个部分：简介、系统和功能要求、外部接口要求和非功能要求。
1. 简介
SRS 介绍正是您所期望的 — 它是整个项目的 10，000 英尺视图。在撰写介绍时，请描述产品的目的、目标受众以及受众将如何使用它。在您的介绍中，请确保包括：
产品范围： 这范围应与产品的总体业务目标相关，如果多个团队或承包商有权访问文档，这一点尤其重要。列出产品的好处、目的和目标。
产品价值： 为什么您的产品很重要？它将如何帮助您的目标受众？它将发挥什么作用，或者它将解决什么问题？问问自己，您的受众将如何从产品中找到价值。
目标受众：描述您的理想受众。他们将决定您产品的外观和感觉以及您如何营销它。
预期用途：想象一下您的受众将如何使用您的产品。列出您提供的功能以及受众根据其角色使用您的产品的所有可能方式。包含用例来说明您的愿景也是一种很好的做法。
定义和缩略语：每个行业或企业都有自己独特的首字母缩略词或行话。列出您在SRS中使用的术语的定义，以确保各方都理解您想说的话。
目录一份详尽的SRS文件可能会很长。包括一个目录，以帮助所有参与者准确找到他们正在寻找的内容。
确保您的介绍清晰简洁。请记住，您的介绍将成为您 SRS 大纲其余部分的指南，并且您希望使用该文档的每个人都对其进行相同的解释。
2. 系统要求和功能要求
有了介绍后，就该更具体了。功能要求分解了系统特性和功能，使您的系统能够按预期执行。
使用概述作为参考，在填写详细信息时检查您的要求是否满足用户的基本需求。根据您的产品，有数千种功能要求需要包括。一些最常见的是：
如果/那么行为
数据处理逻辑
系统工作流程
事务处理
行政职能
法规和合规性需求
性能要求
针对每个屏幕执行的操作详细信息
如果这感觉很多，请尝试一次满足一个要求。SRS 文档中可以包含的详细信息越多，以后需要执行的故障排除就越少。
3. 外部接口要求
外部接口要求是确保系统与外部组件正确通信的功能要求类型，例如：
用户界面：应用程序可用性的关键，包括内容呈现、应用程序导航和用户帮助等组件。
硬件接口：系统软件和硬件组件之间每个接口的特征，例如支持的设备类型和通信协议。
软件接口： 产品与其他软件组件（包括数据库、库和操作系统）之间的连接。
通信接口： 您的产品将使用的通信功能的要求，例如电子邮件或嵌入式表单。
嵌入式系统依赖于外部接口要求。您应该包括屏幕布局、按钮功能以及您的产品如何依赖其他系统的描述等内容。
4. 非功能性需求
SRS 的最后一部分详细介绍了非功能性需求。虽然功能需求告诉系统要做什么，但非功能需求 （NFR） 决定了系统将如何实现这些功能。例如，功能要求可能会告诉您的系统在客户订购您的产品时打印装箱单。NFR 将确保装箱单打印在 4“x6” 白纸上，这是装箱单的标准尺寸。
虽然如果您不符合 NFR，系统仍然可以工作，但您可能会将用户或利益相关者的期望置于危险之中。这些要求控制了功能要求，因此它仍然包括产品可负担性和易用性等属性。
最常见的NFR类型称为“Itys”。它们是：
安全：确保软件从用户那里收集的任何敏感信息受到保护所需的条件。
能力：产品当前和未来的存储需求，包括系统如何扩展以满足不断增长的卷需求的计划。
兼容性：软件的最低硬件要求，例如对操作系统及其版本的支持。
可靠性和可用性： 您期望用户使用您的软件的频率以及正常使用情况下的关键故障时间。
可扩展性：系统仍按预期执行的最高工作负载。
可维护性：应用程序应如何使用持续集成，以便快速部署功能和 bug 修复。
可用性：使用该产品是多么容易。
其他常见的非功能性需求类型包括性能、法规和环境要求。
软件需求文档模板
准备好开始自己的软件开发企业了吗？我们的 SRS 模板概述了优秀 SRS 文档的所有四个关键组成部分，为您和您的团队提供了有关您将要开发的产品的宝贵见解。请记住保持您的要求详细、清晰和简洁，以便各方都有相同的愿景。
免费软件需求模板
编写 SRS 文档的最佳做法
SRS的目的是让每个部门的每个团队朝着明确的目标努力。话虽如此，有一些最佳实践可以确保您的 SRS 达到其目的。
使用视觉效果丰富您的 SRS
包括图表、方案和模型等视觉对象将帮助团队成员更好地了解该过程。这些在说明软件的主要功能和可操作性时特别有用。
在头脑风暴项目时可以尝试的一种技术是思维导图，它组织想法、功能和场景，并在它们之间建立联系。创建一个思维导图，在您开始拼凑您的想法时构建随机想法。此视觉对象不需要非常详细 - 这就是 SRS 的用途。相反，请专注于软件的关键功能以及它们之间的关系。
阅读：29种头脑风暴技巧：激发创造力的有效方法
保持清晰简洁
您最不希望看到的是开发人员在构建产品时对自己进行二次猜测。尽量不要为团队成员留出发挥创造力和填补空白的空间。在描述软件要求时尽可能详细地描述，并避免：
使用模糊的词，如一般或大约
将术语与“/”组合，可解释为“和”或“或”
使用复杂的边界值
使用双重和三重负片
正式的同行评审是查明 SRS 文档中歧义的好方法。计划与每个参与者一起检查它，以比较他或她对要求的理解并进行必要的更改。
了解您的最终用户
在 SRS 中添加您的现场研究和用户访谈，以清楚地了解您的最终用户要求、期望和需求。这应该可以帮助您可视化最终用户将使用该软件执行的操作。考虑可能发生的每个可能的情况和细微差别，并将其包含在您的 SRS 中。请记住，您的开发人员将完全实现您在文档中包含的内容 - 不多也不少。
包括灵活性余量
您的 SRS 是一个动态文档，这意味着您将在每次迭代时添加新功能和修改。通过保持需求灵活性来考虑这一点，以防结果不符合您的期望。最好记录对文档所做的更改，以避免任何误解。参与者应该能够将每个需求追溯到其原始要求，并查看谁进行了更改，何时以及为什么进行更改。
使用软件需求文档阐明您的愿景
编写 SRS 并不容易，但无休止的故障排除或团队成员之间的争论也不容易。您在全面的软件需求规范文档中所做的工作将获得回报，推出您和您的利益相关者可以引以为豪的令人惊叹的产品。
