需求和技术设计是单方面的努力？

Question

我一直作为Web架构师从事一个大型的多年项目。

到目前为止，我的责任是获取客户分析师提供的需求文档，并将其转换为技术设计文档。

“存在的力量”建议我接管需求文档，并将其与我在技术设计上的努力相结合。

将需求和技术设计整合到一个步骤中，您是否看到一个特定的问题？

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

Answer 1

“将需求和技术设计整合到一个步骤中，您是否看到一个特定的问题？”

是。

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

需求定义“必须”发生的事情。 设计解释了“如何”实现这一目标。

例如，我要啤酒-这是我的要求。

技术设计可能是

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

2. 从我的椅子上下来，步行到酒吧。 成本较高。 这里没有什么风险。 除周日关闭外。

3. 问我老婆 这里的风险很大。 可能的意外后果。 但是，我已经下达了问题，她现在必须在屋子里找到啤酒，跑到商店，或告诉我自己买啤酒。 无论如何，如果她要外出，我们将回到低成本且无风险的状态。

一个要求。 解决方案的多种设计。 您不能一step而就。

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

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

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

一个人既可以记录需求又可以进行设计。 但是您必须分别进行操作。 您必须以用户理解并同意问题性质以及声明已解决问题的要求的方式来记录需求。

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

Answer 2

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

尽管将开发与“客户支持”角色分开具有一定的优势，但是专业的开发人员应该不遗余力地跟踪需求，而不会产生任何利益冲突。 您还担心其他问题吗？ 此时需求文档甚至是一项繁重的任务吗？ 减少客户和开发人员之间的层数实际上听起来不错。

Answer 3

是。 将需求和技术设计相结合会笼罩您的思想-它阻止您以后提出关于如何通过执行不同的技术方法/优化来改进系统的新想法。

特别是在新技术领域，您很可能会从错误的方法开始。 将技术设计和要求结合在一起，可以使您将技术方法视为一种要求，而这种方法很可能会被废弃并以不同的方式进行。

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

Answer 4

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

如果您有需求，那么您实际上就是在与企业交流。 这将使您有机会学习业务，并了解他们真正需要的东西，不加任何装饰和过滤。 您将有机会说服他们用商业术语谈论该问题，而不是假设采用技术解决方案并直接进行设计（例如，“将此列添加到此表中并将其绑定到此页面上的此文本框中。”）。 ），也许您将能够看到解决他们甚至不知道存在的问题的方法。

Answer 5

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

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

这将回答您的问题： 不要将需求与设计文档混在一起。

实际上，它不仅限于此。

1. 首先，签署工作范围（SoW）。
2. 然后，签署需求。

我们已经多次看到不合理的客户，他们的需求不断变化。 但是，他们不希望为这些更改付费。 如果管理不当，项目成本将大大超过甚至超过项目收入。

签署的SoW可以保护您免受超出范围的要求，例如， “卖方将安装应用程序xxx”，然后突然，“客户端希望安装整个PKI基础结构以保护与应用程序xxx的通信”。

遵循已签署的要求，可以保护您免受突然的和不合理的要求，遵循上面类似的情况：“无需保护和加密与应用xxx的通信”。

请注意，这些是法律保护。 您仍然可以决定是否应该执行客户的新要求。 不过，仍然要强调，它们不在要求之内，纯粹是出于善意。

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

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

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

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

确实，请尝试避免合并它们。

Answer 6

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

缺点：

• 结合使用它们的一个缺点是，如果您是技术人员，则将着重于如何影响需求以简化技术任务。 最后， 您可能会开发一个不能真正解决（所有）该系统用户问题的系统 。
• 另一个缺点是，在澄清需求的同时，还需要对技术解决方案进行调整，以实现在需求获取过程中阐明或发现的新功能/细节。 这意味着在需求澄清期间多次修改/重新考虑技术解决方案 。

可能的优势：

• 在讨论需求时对技术解决方案进行概述，您可以“弯曲”或协商需求，以避免以后发现技术问题 （例如，性能问题，不可行或昂贵的功能，增加的价值与实现成本成比例） ）。 但您必须小心，不要在真正弄清要求之前在技术设计上投入过多。

Answer 7

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

我个人还发现，在设计过程中涉及多个人（收集需求并将其转化为设计）对于产生想法和思考他人可能错过的事情很有帮助。 从团队协作的角度来看，从两个人转移到一个人可能不是一个好主意。 当同一个人同时做这两种事情时，就很容易以您习惯的方式去做事情，并且没有其他人会挑战您的假设，直到您走得更远，这使得改变变得更加困难。