需求开发向设计规划的转化

虽然在项目启动阶段遇到了许多困难，但“物流管理系统”的开发工作总算取得了进展。项目的发起人张经理和仓库产品代表李小姐对于花费大量时间收集需求的必要性表示怀疑。然而，他们还是愿意参加由开发团队和其他产品代表共同参与的一天的软件需求培训。此次培训强调了在编写软件程序之前，让所有项目利益相关者对需求达成共识的重要性。通过培训，成员们了解了需求术语、概念以及将要使用的方法，这有助于激发他们在具体需求实施过程中采用一些改进技术。

在项目开发过程中，张经理收到了用户代表关于如何进行需求开发的良好反馈。后来，他邀请开发团队成员和产品代表共进午餐，以庆祝他们在“物流管理系统”确定需求基线方面达到了一个重要的里程碑。在用餐时，张经理热情地感谢了参与获取需求的人员所做出的贡献及其合作，然后他继续说：“现在我们已经获得了完整正规的需求，我期待开发团队能尽快编写出程序代码。”

项目经理提醒张经理：“我们并不打算立刻开始编写程序代码。我们计划分阶段发布产品，所以需要找出一个最佳方法来设计系统，使其能够适应未来系统的扩展。我们可以从产品原型中获得一些关于有效技术途径的想法，并且产品原型有助于我们了解用户喜欢的界面特性。如果现在我们在软件设计上多花一点时间，那么明年我们扩展产品功能时就不会出现太多问题。”

这时张经理有些失望，因为他觉得开发人员现在就可以开始编写程序了。但是张经理是否过于急切呢？

经验丰富的项目经理和开发人员知道将软件需求转化为健壮设计和合理项目规划的重要性。本文将通过需求与项目规划、设计、编码和测试之间的联系，探讨需求开发与成功发布产品之间的转换方法。

1 从需求到项目规划

你的项目规划、预测和进度安排都必须以软件需求为基础。这意味着你需要仔细分析客户的需求 ^[1]，并确保你的计划和时间表都是基于这些需求的。如果你没有正确地理解客户的需求，那么你的项目可能会失败，因为你无法满足客户的期望。

因此，在制定项目计划之前，你需要与客户进行深入的讨论，以确保你完全了解他们的需求。然后，你可以使用这些需求来制定一个详细的项目计划，包括每个任务的时间估计、资源分配和风险管理 ^[2]计划。

一旦你有了一个完整的项目计划，你就可以开始预测项目的进展情况。这将帮助你识别潜在的问题，并及时采取措施来解决它们。最后，你可以使用进度安排来确定项目是否按计划进行，并在必要时进行调整。

1.1 需求和进度安排

在软件工程中，许多团队采用“从右到左的进度安排”，即先确定产品的发行日期，然后定义产品的需求。这种方法可能导致开发者无法按时完成项目，因为他们可能无法实现预期质量标准下的所有功能要求。因此，在做出详细的规划和约定之前定义软件需求是更现实的。然而，如果可以在需求的哪些部分适应进度安排的限制，哪些部分不能适应进度安排的限制之间进行权衡，那么“从设计到进度安排”的策略可能会更有效。

对于复杂的系统来说，软件只是最终产品的一部分时，只有在产品级需求产生后才能建立高层的进度安排。然后，将系统需求分解并分配到各个不同的软硬件子系统中。从这个角度来看，就可以以不同来源的输入为基础建立一致的产品发行日期。如果存在进度安排的约束条件，那么具有交叉功能的开发小组必须在功能、质量和费用上作出合理的决策。

在需求开发向设计规划的转化这个过程中，需求探索作为第一阶段将提供足够的信息，使你能够为一个或更多的构造阶段进行现实的规划和预测。定义需求的优先级可以使你判断出哪些功能应包括在首发版中，哪些功能放到随后发行的版本中。

软件项目可能经常不能达到预定的目标，这是因为开发人员和其他项目参与者是拙劣的规划者，而不是因为他们是拙劣的软件工程师。主要的规划失误包括：忽略公共的项目任务、低估了要花费的工作量和时间、没有考虑项目风险以及没有考虑返工所需的时间。正确的项目规划需要以下元素：

• 根据对需求的清楚理解来估计产品规模的大小。
• 根据历史记录了解开发小组的工作效率。
• 需要一张综合的任务列表以完整实现和验证每一特性或使用实例。
• 有效的预测和规划过程。
• 经验。

1.2 需求和预估

在项目估计的第一步中，我们需要将需求和软件产品规模的大小相联系。我们可以通过以下几种方式来预估产品的大小：

1. 功能点和特性点的多少：这包括了3-D功能点的数量。
2. 图形用户界面元素的数量、类型和复杂度：这涉及到界面的复杂性和设计。
3. 实现特定需求所需的源代码行数：这取决于代码的复杂性。
4. 对象类的数量或者其他面向对象系统的衡量标准：这反映了系统的设计复杂性。
5. 单个可测试需求的数量：这可以反映系统的可测试性。

所有这些方法都可以用来预估软件的大小，但需要根据具体项目的经验进行选择。如果你没有记录当前项目所完成的实际结果并与预估进行比较，那么预测的准确性将大打折扣。因此，积累数据并定期评估是非常重要的。

你的目标应该是建立一种方程或方法，可以从需求文档 ^[3]中预测整个软件的大小。另外，你也可以使用商业预估软件来帮助制定人员水平和开发进度的计划。

需求的不确定性会导致你在软件大小预估中的不确定性，进而影响工作量和进度安排的预估。因此，在项目初期，应预计到需求的不确定性，并在进度安排中预留一定的空间以应对需求的变更和可能的超预算。对于任何项目来说，合理的计划都应考虑到不可预见的风险和事件。

2 从需求到设计和编码

需求与设计之间确实存在差异，但应尽量使规格说明在具体实现上保持中立。理想情况下，设计的考虑不应歪曲对预期系统描述的理解。需求开发和规格说明应强调理解和描述预期系统的外部行为。让设计和开发人员参与需求审查，判断需求是否可作为设计基础。

不同的软件设计方法通常都能满足最终需求，而设计方法会因性能、效率、健壮性以及采用的技术不同而有所变化。如果直接从需求规格说明跳入编码阶段，所开发的软件可能会结构不佳。在构建软件之前，应仔细考虑构建系统最有效的方法。考虑其他设计方案有助于确保开发人员遵循提出的设计约束或与设计有关的质量属性 ^[4]规格说明。

我曾参与一个项目，进行了完整的需求分析，并创建了详细描述模拟摄像系统行为的8个数据流程图。大量需求分析后，我们并没有立即编写源代码，而是以数据流程图为表示方法创建了一个设计模型。我们发现模型中有三个步骤使用了相同的计算算法，另外三个使用不同的方程集，剩下两个步骤共享三分之一集合。

分析模型代表了用户和开发小组对我们正在解决的问题的理解，而设计模型则描绘了我们应如何构建系统。通过设计期间的仔细思考，我们将核心问题简化了60%，将8个复杂的计算集合减少到3个。如果我们在需求分析之后立即进行编码，那么在构建阶段必定会出现代码重复。然而，由于及早发现了可简化的问题，我们节省了许多时间和金钱。设计上的返工比编码返工可能效率更高。

基于需求进行反复设计将产生优良的成果。当你获得更多信息或额外的想法时，可以用不同的方法进行设计以精细化最初的概念。设计错误会导致软件系统难以维护和扩展，最终无法满足客户在性能和可靠性方面的目标。在将需求转化为设计时花费的时间是对建立高质量、健壮性产品的关键投资。

在设计产品时，产品的需求和质量属性决定了合适的构建方法（Bass, Clements和Kazman，1998年）。研究和评审提出的体系结构是另一种解释需求的方法，并会使需求更加明确。这与原型法类似，是一种自下而上的需求分析方法。两种方法都围绕着这样的思维过程：“如果我正确理解了需求，那么这种方法可以满足这种需求。既然我手中有一个初步的架构，它是否能帮助我更好地理解需求？”

在你开始实现各个部分需求之前，不必为整个产品进行完整、详细的设计。然而，在开始编码前，必须设计好每个部分。设计规划将有益于具有许多内部组件接口和相互作用的系统，以及开发人员无经验的项目。然而，以下介绍的步骤将有益于所有项目：
• 应该为在维护过程中起支撑作用的子系统和软件组件建立一个坚固的架构。
• 明确需要创建的对象类或功能模块，定义他们的接口、功能范围以及与其他代码单元的协作。
• 根据强内聚、松耦合和信息隐藏的良好设计原则定义每个代码单元的预期功能。
• 确保你的设计满足了所有功能需求，不包括任何不必要的功能。

当开发者将需求转化为设计和代码时，他们将遇到不确定和混淆的地方。理想情况下，开发者可沿发生问题回溯至客户并获得解决方案。如果不能立即解决问题，开发者所做的任何假设、猜想或解释都要记录成文档，并由客户代表评审。如果遇到许多此类问题，说明在实现需求之前，这些需求还不十分清晰或具体。这种情况下，最好安排一两个开发人员对剩余需求进行评审后再继续开发工作。

3 从需求到测试

详尽的需求是系统测试的基础，反过来只能通过测试来判断软件是否满足了需求。你必须针对软件需求规格说明中所记录的产品的预期行为来测试整个软件，而不是针对设计或编码。基于代码的系统测试可以变成“自满足的预见”。产品可以正确呈现基于代码的测试用例所描述的所有行为，但这并不意味着产品正确地实现了用户的需求。如果你没有文档形式的需求，你应该重新获取需求以开发合适的测试用例，这将是一个低效的和不准确的方法。让测试人员参与需求审查以确保需求是明确的，通过验证的需求才可以作为系统测试的基础。

在需求开发中，当每个需求都稳定之后，项目的系统测试人员应该编写文档，以记录他们如何验证需求——通过测试、审查，演示或分析。对如何验证每一需求的思考过程本身就是一种很有用的质量审查实践。根据需求中的逻辑描述，利用诸如因果图等分析技术来获得测试用例，这将会揭示需求的二义性、遗漏或隐含的其他条件和其他问题。在你的系统测试方案中，每个需求应至少由一个测试用例来测试，这样就会验证所有的系统行为。你可以由跟踪通过测试的需求所占的比例来衡量测试进度。有经验的测试人员可以根据他们对产品的预期功能、用法、质量特性和特有行为的理解，概括出纯粹基于需求的测试。

基于规格说明的测试适用于许多测试设计策略：动作驱动、数据驱动（包括边界值分析和等价类的划分）、逻辑驱动、事件驱动和状态驱动。从正式的规格说明中很容易自动生成测试用例，但是对于更多的由自然语言描述的需求规格说明，你必须手工开发测试用例。比起结构化分析图，对象模型更易于自动生成测试用例。

在开发的进展过程中，你将通过详细的软件功能需求仔细推敲来自使用实例高层抽象的需求，并最终转化成单个代码模块的规格说明。测试方面的权威专家认为针对需求的测试必须在软件结构的每一层进行，而不只是在用户层进行。在一个应用程序中有许多代码不会被用户所访问，但这些代码却是产品基础操作所需要的。即使有些模块功能在整个软件产品中对用户都不可见，但是每个模块功能必须满足其自身的需求或规格说明要求。因此，针对用户需求来测试系统是系统测试的必要但非充分条件。

4 从需求到成功

我最近遇到一个项目，在该项目中，一个新的开发小组将针对早先的开发小组所开发的需求实现 ^[5]一个应用程序。这个新的开发小组一看到由3英寸活页纸订成的软件需求规格说明就感到十分恐惧，于是立刻编写代码。在构造软件的过程中，他们没有参考软件需求规格说明，而是根据他们对预期系统的不完整且不正确的理解，按他们自己的想象进行编码设计。因此，该项目遇到许多问题便不足为奇了。试图理解这个庞大的需求规格说明肯定会令人恐惧的，况且需求规格说明有些部分可能还不完善，但忽略了需求规格说明必定会导致失败。

我知道一个十分成功的项目，在开发项目的过程中，开发人员列出了与特定代码版本相对应的需求。项目的质量保证组通过对照需求来执行测试用例从而评价其对应的代码版本。根据测试标准，如果不满足需求的话就算是一个错误。如果不满足的需求数量超过预先给定的一个数字，或者特定的有重大影响的需求没有被满足，那么这个代码块就被拒绝了。这个项目的成功之处在于把需求文档作为何时发行产品的基础。

一个软件开发项目最终可发行的是满足客户需求和期望的软件系统。需求是从产品概念通向用户满意之路的最本质的一步。如果你不以高质量的需求作为项目规划、软件设计和系统测试的基础，那么在试图开发优秀产品的过程中将浪费大量的人力和物力。

然而，也不要成为需求过程的奴隶。避免陷入畸形分析的陷阱，此时，开发小组将花费大量的时间创建不必要的文档，并举行各种形式上的会议和评审，而并不编写任何软件代码，这将会导致项目被取消。努力在精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择。

5 实践计划操作

检查你的软件需求规格说明中所有需求是否与软件设计的各元素相对应。这些可能在数据流模型、实体联系图中的表、对象类或方法，或者其它设计元素中处理。如果开发人员在编写代码前，没有进行软件设计，那么他们可能要进行软件设计方面的培训。记录实现每一个产品特性或使用实例的代码行、功能点、对象类或图形用户界面元素的数量。并且还要记录对完全实现并验证每个特性或使用实例所估计的工作量和实际的工作量。尽力获取产品大小与所花费工作量的关系，这将有助于你对将来的需求规格说明作出更精确的预估。

为了执行这个实践计划操作，我们需要采取以下步骤：

1. 审查软件需求规格说明 (SRS): 彻底阅读SRS文档，确保理解每项需求。

2. 对照设计元素: 对于SRS中的每一项需求，检查对应的设计文档，如数据流图、实体-关系图（ER图）、类图等，确认需求是否得到了体现。

3. 培训需求: 如果开发人员没有遵循设计就编码，考虑安排设计原则和设计工具的培训。

4. 跟踪产品特性与设计元素: 创建一个跟踪矩阵，将每个产品特性或使用实例与实现它们的设计元素（如代码行数、功能点、类数量等）对应起来。

5. 估计与实际工作量: 对于每个特性或使用实例，记录预估的工作量和实际工作量。这包括设计、编码、测试等所有阶段的工作。

6. 分析工作量与产品大小关系: 利用收集到的数据，尝试找出产品大小（如功能点数）和工作量之间的关系。这可以通过统计方法，如回归分析来完成。

7. 改进预估过程: 根据以上分析结果，调整你的需求规格预估模型，以便未来能更准确地预测工作量。

通过上述步骤，可以确保需求在设计中得到满足，并通过跟踪及分析工作量，提高对未来项目的预估精度。

本文同步发表在 软件需求探索的http://www.srs.pub/theory/xu-qiu-kai-fa-xiang-she-ji-gui-hua-de-zhuan-hua.html

---

1. 客户的需求观.http://www.srs.pub/theory/ke-hu-de-xu-qiu-guan.html ↩

2. 软件需求与风险管理.http://www.srs.pub/theory/ruan-jian-xu-qiu-yu-feng-xian-guan-li.html ↩

3. 需求文档的编写.http://www.srs.pub/theory/xu-qiu-wen-dang-de-bian-xie.html ↩

4. 软件的质量属性分析.http://www.srs.pub/theory/ruan-jian-de-zhi-liang-shu-xing.html ↩

5. 需求管理的原则与实现.http://www.srs.pub/theory/xu-qiu-guan-li-de-yuan-ze-yu-shi-xian.html ↩