超过70% 的IT 项目失败的根本原因 1可以归结为需求编写不当。如果您想按时、在预算内交付高质量的软件，学习如何编写软件需求至关重要。
本文将分享编写有效软件需求的 12 条注意事项，以便您可以制定完美的需求集并开始交付更成功的软件。
1 目录
2 为什么软件需求很重要？
软件需求是任何软件项目成功的关键，它为开发过程提供了路线图，并作为项目团队做出所有决策和采取所有行动的基础：
- 达成共识：对正在开发的软件的目标和目的达成共识。这可以消除误解的可能性，并确保每个人从一开始就达成共识。
- 指导开发：通过概述特定的功能、特性和用户要求，作为软件开发团队的指导，开发团队可以集中精力创造满足预期结果的产品。
- 基础测试：成为QA测试计划的基础，确保软件按预期运行，检测任何潜在问题或错误，并验证其是否符合预期目的。
- 监控进度：使项目利益相关者能够监控开发团队的进度，并确保正在创建的软件符合项目目标和目的。这样就可以在必要时及时进行调整和更正，最大限度地降低延误和预算超支的风险。
3 编写软件需求时的6大要点
3.1 从用户的角度和语言来写作
软件需求应以通俗易懂的语言来编写，以反映用户的观点和术语。它们应该具体但易于理解，尽量少用技术或行业术语。重点是以一种所有利益相关者都能完全理解的方式编写需求，而无需查阅其他文档。
糟糕的要求: - 购物车中有商品清单和购买总价。
良好要求: - 作为顾客，我希望能够查看购物车中的商品清单以及总购买价格，以便能够快速决定是否要继续结帐。
专业提示: - 尽可能多地使用图形和图示工具来帮助表达用户的观点。例如，在需求文档中，您可以通过包含用例图、序列或活动图、功能流程图、结构图、分配图、数据流 6图、对象图、故事板和实体关系图来突出显示系统功能。
3.2 编写与实现无关的需求
软件需求文档 7不是设计文档。因此，它们不会也不应该从设计的角度定义必须如何执行功能需求。因此，您的所有功能需求都应与实现无关。换句话说，需求应该说明系统应该做什么，而不是应该如何做。
糟糕的要求: - 应用程序必须使用宽度为 500px、高度为 300px 的模态窗口显示入职指南。
良好要求: - 无论用户在哪个屏幕上，都应该能够查看入职指南。
专业提示: - 虽然实施细节应该留给开发团队，但在某些情况下，您确实需要指定系统应如何与其他软件系统交互，或者需要满足哪些技术规格。这些要求应该在软件应用程序的非功能性需求中定义，而不是在功能性用户故事 8中定义。
3.3 尽早并经常让利益相关者参与
在软件文档编制过程中，尽早并经常让利益相关者参与进来非常重要，以确保软件能够充分满足所有相关人员的需求。利益相关者应该：
- 在需求流程开始时进行咨询，以获取有关项目范围 9、目标受众和总体项目目标的意见。
- 在开发开始之前要求对需求草案提供意见。
- 在软件开发过程中通知需求或产品范围的变化。
专业提示: - 当与众多不同的利益相关者打交道时，使用图表、方案和模型等视觉效果来改进软件需求规范会很有帮助，这些视觉效果可以直观地表示系统的用例、用户旅程、屏幕等。这可以提供一种更简单的方法来理解和解释需求中的功能、流程和场景。
3.4 分析、细化和分解需求
起草软件需求最好分阶段完成。一旦您有了一组高级需求，您就可以开始使用以下过程分析 10、细化和分解需求：
- 评估可行性：评估每个高级需求的可行性、在项目限制内的可靠性以及验证能力。如果无法在成本和进度限制内实现该需求，则必须将其视为问题并通过调整预算、放宽进度、更改或取消该需求来解决。
- 功能分析：实践功能或面向对象分析来定义可用作分配需求基础的功能架构。
- 分析新需求：
- 完整性：所有较高级别的需求是否都已分配？
- 一致性：需求与需求之间、规范与规范之间的内容、格式和符号是否相似？
- 可行性：能否满足要求？
- 平衡：需求之间的权衡是什么？
- 可验证/可测试性：需求是否可以被客观验证？
- 人为因素：设计是否符合合理的人为因素原则？
示例: - 糟糕的要求: - 作为一名学生，我需要能够完成我的电子学习课程中的课程。 - 良好要求: 1. 作为学生，我需要能够在我的电子学习课程中观看视频课程。 2. 作为学生，我需要能够在我的电子学习课程中阅读基于文本的课程。 3. 作为学生，我需要能够按顺序完成每节课，而无需在我的电子学习课程中直接跳到下一节课。
专业提示: - 尽可能使用操作场景来展示或体现需求所要捕捉的内容。操作场景描绘了目标环境中的产品、最终用户和其他实体，是发现和细化需求的有用工具。
3.5 指定需求的优先级
确定软件需求的优先级至关重要，因为它有助于确保首先开发和实施最重要的功能，从而最大限度地提高软件对用户的价值。成功的优先级排序需要明确定义的优先级矩阵，该矩阵应该：
- 确定权力：确定谁有权力请求或决定需求优先级 11。
- 建立标准：建立一组标准的优先级，例如：“必须有”、“应该有”和“最好有”或优先级 1-10。
- 定义标准：定义每个优先级标签的标准。换句话说，什么决定了要求是“1”而不是“10”，或者是“最好有”而不是“必须有”？
示例优先级矩阵:
| 优先事项 | 定义 |
|---|---|
| 1 | 最高优先级、核心功能和/或必须在 MVP 中实现基本的客户成功 |
| 2 | 中等优先级，理想情况下包含在 MVP 中，因为它可以实现更高级的功能 |
| 3 | 最低优先级，有就好，但不是 MVP 必需的 |
专业提示: - 传达您的优先级矩阵几乎与创建它一样重要。所有项目利益相关者都需要了解需求的优先级排序方式以及请求更改优先级的正确项目管理流程。最佳做法是尽早将其作为更广泛的需求管理 12计划的一部分进行定义。
3.6 系统地追踪变化
修改是软件开发周期的固有特征。无论最初的需求集记录得多么完善，项目经理和软件开发人员都必须应对整个开发过程中不断变化的需求集。
专业提示: - 监督需求是一个持续的过程，贯穿整个系统的生命周期。在每次技术评审 13中，项目负责人应审查软件需求文档，以确保需求继续满足客户和利益相关者的要求和期望。
4 编写软件需求时需要注意的6大坑
4.1 使用模棱两可的语言和技术术语
含糊不清的语言和技术术语可能会导致误解和浪费时间。即使您认为项目中的每个人都会明白您的意思，也必须具体明确，不要做任何假设。
糟糕的要求: - 系统应提供直观、易于使用的用户界面。
良好要求: - 用户应该始终能够一键访问主页。
专业提示: - 拼写出所有首字母缩略词和缩写。 - 解释第三方团体可能不知道的任何内部机构知识。 - 如果确实需要技术术语，请在附录中对其进行定义。 - 让核心团队以外的人审查要求以确保其明确。
4.2 放弃验收标准
在编写软件需求时忽略验收标准可能会对开发过程产生不利影响。如果没有明确的验收标准，开发人员可能无法理解项目的确切要求，这可能导致他们对需求做出错误的假设或解释。这也意味着没有一种方法可以验证需求是否得到满足。
糟糕的要求: - 用户必须能够按部门搜索员工。
良好要求: - 用户必须能够按部门搜索员工。 1. 用户必须能够从可用部门列表中选择一个部门。 2. 搜索必须返回所选部门的员工列表。 3. 搜索结果必须包括员工的姓名、部门和职位。 4. 搜索必须在 5 秒内完成。
专业提示: - 更新您现有的 SRS 模板以要求满足每个要求的验收标准。 - 在整个开发过程中定期审查和更新验收标准。 - 让开发人员参与编写验收标准的过程，以确保需求可行且明确。
4.3 忽视使用标准化格式
在创建软件需求规范时使用标准化格式非常重要，因为它有助于确保所有需求都以一致且可理解的方式指定，以便所有利益相关者轻松理解并在将来更新。
不良要求: 1. 应用程序必须能够实时跟踪和显示销售数据。 2. 用户必须能够从任何带有 Web 浏览器的设备访问应用程序。 3. 所有页面必须安全且受密码保护。
良好要求: - 管理员必须能够获取实时销售数据报告。 - 用户必须能够从任何带有网络浏览器的设备访问该应用程序。 - 用户在访问该应用程序的任何页面之前都应输入密码。
专业提示: - 建立一个可接受的软件需求规范格式，并确保所有利益相关者对如何使用它达成共识。 - 使用模板或清单确保所有文件均符合可接受的格式。 - 建立批准和签署软件需求文件的流程。 - 提供培训和/或参考资料，以确保所有利益相关者了解软件需求规范的接受格式以及任何相关指南或标准。
4.4 做出技术假设
在编写软件需求文档时，不要做出技术假设，这一点很重要。不要简单地假设您的开发团队将使用某些技术或了解系统的技术要求。非功能性需求应明确列出系统的任何技术要求，例如某些技术的使用或特定软件接口的必要性。
糟糕的要求: - 用户活动数据的实时分析应该存储在关系数据库中。
良好要求: - 管理员应该能够访问用户活动数据的实时分析。
专业提示: - 写下您做出的任何假设，然后努力将这些假设作为非功能性需求纳入软件需求规范文档 14中。 - 将高级需求分解为低级需求。完成此过程有助于识别您所做的任何假设。
4.5 添加冲突的要求
确保软件需求文档中没有相互冲突的需求非常重要。存在相互冲突的需求可能会在开发软件时造成混乱和歧义，最终导致昂贵的延误甚至项目失败。
糟糕的要求: 1. 团队领导应具有报告的完全访问权限。 2. 管理员应能够为每个团队领导单独分配“只读”或“编辑”权限。
良好要求: 1. 团队领导应默认被授予“编辑”报告权限。 2. 管理员应能够更改各个团队领导的报告权限，为他们分配“编辑”或“只读”访问权限。
专业提示: - 在将需求交给开发团队之前识别任何潜在的冲突。 - 指定一名所有者将需求添加到官方列表中，而不是向所有利益相关者开放以直接添加需求。 - 记录所有需求变更以及在最终确定之前审核变更的流程。
4.6 忘记非功能性需求
非功能性需求是软件需求规范文档的重要组成部分，因为它们有助于定义所需系统的质量和利益相关者的期望。
许多团队忽视非功能性需求，认为它们不如定义为用户故事的功能性需求那么重要。然而，如果没有它们，构建的软件解决方案可能无法从安全性 15、质量或可靠性角度满足利益相关者的核心期望。
非功能性需求应该解决：
- 安全：您是否会存储 PII 或其他敏感数据？您的公司是否有任何应遵守的特定安全标准？
- 容量：您有什么样的数据存储要求？您是否预计您的需求会随着时间的推移而改变？
- 兼容性：最低硬件要求是什么？应考虑哪些技术限制？是否有任何特定的外部接口要求？
- 可靠性：用户是否需要全天候访问？您的系统可接受的停机时间是多少，才能满足用户的基本需求？
- 可扩展性：能够处理的最大负载是多少？考虑数据和用户流量。
- 可用性：是否有特定的 UX 标准需要遵循？还应考虑 ADA 可访问性。
专业提示: - 使用具体的语言来描述软件的预期行为。避免使用“高效”或“用户友好”等模糊术语，而是尽可能详细地描述软件应满足的具体标准。
希望这些注意事项能帮助您编写更有效、更明确的软件需求，从而提高项目的成功率。