作为一名网络架构师，我一直在从事一个大型、多年的项目。
到目前为止，我的职责是将客户分析师提供的需求文档转化为技术设计文档。
“存在的权力”建议我接管需求文档并将它们与我在技术设计方面的工作结合起来。
您是否发现将需求和技术设计合二为一的具体问题？
请注意，我们已经进入开发阶段，因此很多技术选择（操作系统、应用程序框架、数据库、服务器等）已经确定。
【问题讨论】：
标签： architecture project-management requirements
“您是否发现将需求和技术设计合二为一的具体问题？”
是的。
需求几乎与技术设计无关。
需求定义了“什么”必须发生。设计解释了“如何”实现这一目标。
例如，我想要一杯啤酒——这是我的要求。
技术设计可以
从椅子上下来，走下楼。低成本。这里有风险。可能没有啤酒。
从椅子上下来，走到酒吧。成本较高。这里的风险很小。周日不营业。
问我妻子。这里风险很大。可能的意外后果。然而，我已经把问题委托给了她，她现在必须要么在家里找啤酒，要么跑到商店，要么告诉我自己买。如果她无论如何都要出去，我们又回到了低成本且没有风险的状态。
一个要求。解决方案的多种设计。 你不能一步完成这两件事。
您必须记录需求（参与者、用例、概念数据模型、概念处理模型）
然后您必须设计一个解决方案。该解决方案可能（也可能不）涉及创建新软件。
在研究需求时，您经常会发现用户需要改变他们的工作方式的情况。可以通过多种方式满足要求。
一个人既可以记录需求，也可以进行设计。但是你必须分开做。您必须以用户理解并同意问题的性质以及声明问题已解决所需的内容的方式记录需求。
然后 - 单独 - 您决定如何最好地优化成本、风险、交付时间、技能、可用技术以提供一些解决问题的方法。
【讨论】：
如果您“进入开发阶段”，我希望大多数要求都非常明确。我不认为需要在开发开始之前就确定需求（天堂禁止），但我希望到那时你可以确定你正在构建什么样的东西。因此，如果现在的重点只是“需求文档”（而不是真正深入研究客户正在寻找的内容），我在这里看不到任何深层次的问题。
虽然将开发与“客户倡导”角色分开有一定的优势，但专业的开发人员在跟踪需求时不应该产生任何利益冲突。您是否还担心其他问题？在这一点上，需求文档甚至是一项艰巨的任务吗？减少客户和开发人员之间的层数实际上听起来是件好事。
【讨论】：
是的。将需求和技术设计结合起来会影响您的思维 - 它会阻止您以后想出关于如何通过不同的技术方法/优化来改进系统的新想法。
尤其是在新技术领域，您很可能会从错误的方法开始。结合技术设计和需求，您可以将您的技术方法视为一项需求，而它很可能会被废弃并以不同的方式完成。
此外，当需要进行测试时（实际上应该在设计之前），那么您可能正在测试您的技术方法，而不是 porgram 实际需要做的事情。
【讨论】：
我认为由同一个人完成需求和设计非常有价值。
如果您收到需求，您实际上是在与业务部门交谈。它将让您有机会了解业务并听到他们真正需要的、未经修饰和未经过滤的内容。您将有机会说服他们以业务术语讨论问题，而不是假设技术解决方案并直接进行设计（例如，“将此列添加到此表并将其绑定到此页面上的此文本框。” ) 也许您将能够看到解决他们甚至不知道存在的问题的方法。
【讨论】：
我没有机会在敏捷团队或 Scrum 团队中工作，也没有机会应用它们。我为客户做了很多一次性的开发工作1~3个月。但我在这种环境中学到的一件事是：
在项目的每个阶段都与客户签署。
这将回答您的问题： 切勿将要求与设计文档混在一起。
其实还不止于此。
我们多次看到不合理的客户，他们的要求不断变化。但是，他们不希望为这些变化买单。如果管理不当，项目成本将大大超过并超过项目收入。
拥有已签署的 SoW 可以保护您免受超出范围的要求，例如。 “供应商将安装应用 xxx”，突然间，“客户想要安装完整的 PKI 基础设施来保护与应用 xxx 的通信”。
签署要求可以保护您免受突然和不合理的要求，就像上面的类似案例一样，“无需保护和加密与应用 xxx 的通信”。
请注意，这些是法律保护。是否应该满足客户的新要求仍由您决定。不过还是要强调一下，它们不在要求中，完全是出于善意。
将设计文档合并到主要需求文档中会阻止您签署需求文档。客户会对此非常高兴，但我认为您的开发团队会讨厌可能的关键时间。
我确实看到了人们拥有的另一种方法（但不是将设计与需求相结合）。
将需求文档拆分为带有单独附录文件的主文件。在需求文档中保留重要和具体的内容。这允许您签署需求文档，同时允许在稍后阶段对附录进行更改。我们主要将这种方法用于支持文档作为附录。它可能与设计文档作为附录一起使用，但我没有看到设计文档作为附录。
此外，在某些项目中，您甚至可能希望在开发开始之前签署设计文档。或者这些设计/要求/SoW 是交付或里程碑付款。
真的，尽量避免合并它们。
【讨论】：
要求是指需要做什么。 技术设计是指如何满足要求。
缺点：
可能的优势：
【讨论】：
两者的另一个区别是需求开发需要与客户（外部或内部客户）进行广泛接触，而许多优秀的技术人员根本不具备良好管理客户关系或与实际用户交谈而不侮辱的人际交往能力他们。如果你这样做，只有你可以说。如果你没有这样做，你会发现它比你想象的要困难和复杂得多。另外，您可能会发现自己提出了错误的问题，因为您没有看到用户的观点，因为您的专长是开发人员和设计师的观点。
就我个人而言，我还发现让多人参与设计过程（收集需求并将其转化为设计）有助于产生创意，并思考其他人可能错过的事情。从团队协同的角度来看，从两个人这样做可能不是一个好主意。当同一个人同时做这两件事时，很容易只以您习惯的方式做事，并且没有其他人参与挑战您的假设，直到您在变得更难改变的道路上走得更远。
【讨论】：