0

作为一名网络架构师，我一直在从事一个大型、多年的项目。

到目前为止，我的职责是将客户分析师提供的需求文档转化为技术设计文档。

“存在的权力”表明我接管了需求文档并将它们与我在技术设计上的努力结合起来。

您是否看到将需求和技术设计合二为一的具体问题？

请注意，我们已经进入开发阶段，因此许多技术选择（操作系统、应用程序框架、数据库、服务器等）已经确定。

4

7 回答 7

3

“在将需求和技术设计合二为一时，您是否发现了一个特定问题？”

是的。

需求几乎与技术设计无关。

需求定义了必须发生的“什么”。设计解释了它将如何构建以实现这一目标。

例如，我想要一杯啤酒——这是我的要求。

技术设计可以

  1. 从我的椅子上下来，走下楼。低成本。这里有风险。可能没有啤酒。

  2. 从我的椅子上下来，走向酒吧。成本较高。这里的风险很小。除了周日关门。

  3. 问我老婆。这里风险很大。可能的意外后果。然而，我已经把问题委托给了她，她现在必须要么在家里找啤酒，要么跑到商店，要么告诉我自己买。如果她无论如何都要出去，我们又回到了低成本且没有风险的状态。

一要求。解决方案的多种设计。 你不能一步完成这两件事。

您必须记录需求（参与者、用例、概念数据模型、概念处理模型）

然后，您必须设计一个解决方案。该解决方案可能（也可能不）涉及创建新软件。

在研究需求时，您经常会发现用户需要改变他们的工作方式的情况。可以通过多种方式满足要求。

一个人既可以记录需求，也可以进行设计。但是你必须分开做。您必须以用户理解并同意问题的性质以及声明问题已解决所需的内容的方式记录需求。

然后 - 分别 - 您决定如何最好地优化成本、风险、交付时间、技能、可用技术，以提供一些解决问题的方法。

于 2009-07-30T00:09:09.410 回答
2

如果您“正在开发中”，我希望大多数要求都非常牢固。我不认为需要在开发开始之前就确定需求（天堂禁止），但我希望到那时你可以确定你正在构建什么样的东西。因此，如果现在的重点只是“需求文档”（而不是真正深入研究客户正在寻找的东西），那么我在这里看不到任何深层次的问题。

虽然将开发与“客户倡导”角色分开有一定的优势，但专业的开发人员在不产生任何利益冲突的情况下跟踪需求应该不会有困难。还有其他你担心的问题吗？在这一点上，需求文档甚至是一项艰巨的任务吗？减少客户和开发人员之间的层数实际上听起来是件好事。

于 2009-07-29T23:49:05.043 回答
1

是的。将需求和技术设计结合起来会影响你的思维——它会阻止你以后想出关于如何通过不同的技术方法/优化来改进系统的新想法。

尤其是在新技术领域，您很可能从错误的方法开始。结合技术设计和需求，你会认为你的技术方法是一种需求，而它很可能被废弃并以不同的方式完成。

此外，当需要进行测试时（实际上该时间应该在设计之前），那么您可能正在测试您的技术方法，而不是 porgram 实际需要做的事情。

于 2009-07-30T13:31:25.993 回答
0

两者的另一个区别是需求开发需要与客户（外部或内部客户）进行广泛接触，而许多优秀的技术人员根本不具备管理客户关系或与实际用户交谈而不侮辱他们的人际交往能力。如果你这样做，只有你可以说。如果你没有这样做，你会发现它比你想象的要困难和复杂得多。另外，您可能会发现自己提出了错误的问题，因为您没有看到用户的观点，因为您的专长是开发人员和设计师的观点。

就我个人而言，我还发现让多人参与设计过程（收集需求并将其转化为设计）有助于产生想法和思考其他人可能错过的事情。从团队协同的角度来看，从两个人这样做可能不是一个好主意。当同一个人同时做这两件事时，很容易以你习惯的方式做事，并且没有其他人参与挑战你的假设，直到你沿着变得更难改变的道路走得更远。

于 2009-07-30T20:50:00.893 回答
0

需求是指需要做什么。技术设计是指如何满足要求。

缺点：

  • 将它们结合起来的一个缺点是，如果您是一名技术人员，您将尝试影响需求以使技术任务更容易，专注于如何. 最后，您可能会开发出一个实际上并不能解决（所有）该系统用户的问题的系统。
  • 另一个缺点是，在阐明需求时，需要调整技术解决方案以实现在需求获取期间阐明或发现的新功能/细节。这意味着 在需求澄清期间多次修改/重新考虑技术解决方案。

可能的优势：

  • 在讨论需求时对技术解决方案有一个概述，您可能会“弯曲”或协商需求，以避免以后发现技术问题（例如性能问题、不可行或成本高昂的附加值与实施成本不成比例的特性）。但是在真正明确需求之前，你必须注意不要在技术设计上投入太多。
于 2009-07-30T13:26:34.377 回答
0

我认为由同一个人完成需求和设计是很有价值的。

如果你得到要求，你实际上是在与业务部门交谈。它将让您有机会了解业务并听到他们真正需要的、未经修饰和未经过滤的内容。您将有机会说服他们以业务术语讨论问题，而不是假设技术解决方案并直接进行设计（例如，“将此列添加到此表并将其绑定到此页面上的此文本框。” ) 也许您将能够看到解决他们甚至不知道存在的问题的方法。

于 2009-07-30T00:02:39.673 回答
0

我没有机会在敏捷团队或 Scrum 团队中工作，也没有机会应用它们。我为客户做了很多一次性的开发工作1~3个月。但我在这种环境中学到的一件事是：

在项目的每个阶段与客户签署。

这将回答您的问题： 永远不要将需求与设计文档混为一谈。

其实，还不止于此。

  1. 首先，签署工作范围 (SoW)。
  2. 然后，签署要求。

我们多次看到不合理的客户，他们的要求不断变化。但是，他们不希望为这些变化买单。如果管理不当，项目成本将大大超过和超过项目收入。

拥有签署的 SoW 可以保护您免受超出范围的要求，例如。“供应商将安装应用程序 xxx”，突然间，“客户想要安装整个 PKI 基础设施来保护与应用程序 xxx 的通信”。

签署要求可以保护您免受突然和不合理的要求，遵循上述类似案例，“无需保护和加密与应用程序 xxx 的通信”。

请注意，这些是法律保护。是否应该满足客户的新要求仍由您决定。但是，强调它们不在要求中并且纯粹是出于善意，仍然很好。

将设计文档合并到主要需求文档中会阻止您签署需求文档。客户会对此非常高兴，但我认为您的开发团队会讨厌可能的关键时间。

我确实看到了人们拥有的另一种方法（但不是将设计与需求合并）。

将需求文档拆分为带有单独附录文件的主文件。在需求文档中保留重要和具体的内容。这允许您签署需求文档，同时允许在稍后阶段对附录进行更改。我们主要将这种方法用于支持文档作为附录。它可能与设计文档作为附录一起使用，但我还没有看到设计文档作为附录。

此外，在某些项目中，您甚至可能希望在开发开始之前签署设计文档。或者这些设计/要求/SoW 是交付或里程碑付款。

真的，尽量避免合并它们。

于 2009-07-30T02:30:54.667 回答