软件开发需求文档案例_第2部分：开发软件需求，一个案例研究

软件开发需求文档案例

这是4部分系列的第2部分。 第1部分：为什么“现实世界中的软件需求很难” 讨论了开发需求的挑战以及好的需求。 这篇文章着眼于需求开发过程及其在实际项目中的输出。

TL; DR

优先考虑运输软件以引出实际需求的敏捷方法与优先考虑先期需求工程的瀑布方法之间的熟悉的二分法过于简单。 在这些极点之间，存在一种用于开发需求的中间方法，该方法易于实施，并且可以更好地为用户和利益相关者带来价值。 这种方法的功能和优点包括：

• 定义一个迭代的需求开发过程，生成标准并达成一致的输出，并与更广泛的敏捷交付方法集成
• 利用廉价的实验（例如快速原型制作）以循证的方式快速进行，而无需交付功能全面的软件
• 使用层次结构（通常与需求工程相关联）在适当的抽象级别为用户和涉众提供有用的上下文
• 选择性地填充层次结构（不一定是自上而下的），以便开发团队和其他人员拥有他们需要的背景，以便进行调整并做出更好的决策。

视觉教练

Vision Coach是我将用作该主题的一种实际项目。 这是我的团队与拜耳医疗保健合作建立的一个平台，用于患有糖尿病性黄斑水肿 （DME / DMO）的眼病患者和医生的治疗。 DME影响全球约2100万糖尿病患者，并且是工作年龄成人失明的主要原因。

拜耳医疗保健提供的一种疗法是眼科医生用来改善患有DME等视网膜疾病的人的视力的一种疗法。 尽管存在视力障碍的情况，但是患者对治疗的依从性差，这意味着视力结果通常不是最佳的。 解决该问题成为该项目的重点。

为简便起见，我始终使用传统术语，例如“需求，启发，规范”。 尽管并不完美（将假设称为“要求”很奇怪吗？），但它们具有熟悉的优势。

需求方法

关于如何满足需求的争论通常集中在我称之为分析瘫痪和迭代崇拜的两种对立的方法上。 分析瘫痪说，您必须在任何编码开始之前就预先提出并指定需求，它们必须具有一组完美的属性（一致性，缺乏歧义性，完整性等），如果这需要花费数周甚至数月的精力，就这样吧。

迭代崇拜则相反-得出需求的最佳方法是构建某些东西并与用户进行测试。 用户不知道他们想要什么，或者至少不能总是清楚地表达出自己的想法，直到向他们提供工作软件后，他们的真正需求才出现。 因此，预先规范是浪费时间。

从广义上讲，这描述了需求开发的瀑布式和敏捷方法。 两者是相反的，通常假设您是站在另一侧。 那你站在哪一边？

好吧，显然您并不处于Analysis瘫痪状态 。 花费大量时间从利益相关者那里获取需求，使它们在开始编码之前是一致的，完整的，可测试的（以及其他所有需求），在面对不确定性和变化的情况下是徒劳的，而成功完成的一切只是增加失败和学习的成本。

像大多数团队一样，如果您需要失败并学习很多东西，那就不好了。 哦，事实证明它行不通-Standish Group的Chaos调查是经常被证明的一种来源。

这意味着您处于迭代崇拜方面，对吗？ 嗯，不，至少不是因为这里已被描述（或讽刺？）。 这种方法也有问题。 首先，如果没有第一个交付给用户的软件就无法说出任何与需求有关的宝贵信息，这是完全不对的-使用线框图工具进行快速原型制作是一种能够在编码开始之前为需求提供有用证据的技术。

其次，迭代实际上并不便宜-当然，它们比提供软件瀑布式样式便宜，但与快速原型制作等技术相比，它们仍然昂贵。

第三，如果您真的不花时间来定义需求，那么您构建的内容可能会离目标更远，因此需要进行更多的迭代才能达到目标。

我们的方法介于两者之间-预先结合了一些规范，并早日附带了工作软件，以在更高保真度的实验中引起用户的进一步要求。

流程和层次

在第1部分中，我确定了需求开发流程及其输出的一些关键属性-例如，它需要协作，迭代，并且需要针对不同的受众量身定制其输出。 除此之外，定义流程和确定用于优化输出的技术将很有帮助。

图1显示了我们遵循的过程。 它包括四个活动：

• 启发 -使用各种技术从用户和利益相关者中提取需求
• 分析 -了解要解决的基本问题，完善用户和利益相关者的要求，并将其与系统要求结合
• 规范 -使用层次结构和约定的模板制定需求，并记录下来
• 验证 -验证要求的准确性与所提供证据的准确性一样，一旦实施便可以验证。

图1 。 需求开发流程（改编自Wiegers＆Beatty， 软件需求 ，第三版）。

该过程是反复进行的，涉及经常在同一会话中在不同活动之间来回移动，这意味着更快的反馈循环和更好的输出。 它还涉及客户利益相关者的审核和批准决策点，这是开始任何编码之前所必需的。 除此之外，它还集成到了我们用于交付项目的更广泛的Scrum流程中，包括2周的冲刺，每日站立，在冲刺结