要求和技术设计作为一项努力？

Question

我一直在做一个大型的，多年的项目作为网页设计师。

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

'权力是'建议我接管需求文档，并将它们与我在技术设计上的努力结合起来。

在将要求和技术设计合并到一个步骤中时是否存在特定问题？

请注意，我们已经很好地进入开发阶段，所以很多技术选择（操作系统，应用程序框架，数据库，服务器等）已经成为现实。

Answer 1

“您是否遇到了将需求和技术设计合并为一个步骤的特定问题？”

是的。

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

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

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

技术设计可能是

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

2. 下车，走到酒吧。成本更高。这里风险很小。除周日关闭。

3. 问我的妻子。这里有巨大的风险。可能的意外后果。然而，我已经委托了这个问题，她现在不得不在房子里找啤酒，跑到商店，或者告诉我要自己买。如果她无论如何要外出，我们会回到低成本，没有风险。

一个要求。解决方案的多种设计。 你无法在一个步骤中同时处理这两件事情。

必须文件的要求（演员，用例，概念数据模型，概念处理模型）

然后你必须设计一个解决方案。解决方案可能 - 也可能不 - 涉及创建新软件。

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

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

然后 - 单独决定如何最佳地优化成本，风险，交付时间，技能和可用技术，以便为问题提供一些解决方案。

Answer 2

如果你“很好的开发”，我希望大多数的需求都相当稳定。我并不认为在开发开始之前（天堂禁止）需要将需求置于石头上，但我希望能够确定你到底在做什么样的事情。因此，如果现在的观点只是“需求文档”（而不是真正挖掘客户的需求），我看不出任何深层次的问题。

尽管将开发与“客户倡导”角色分开有一定的优势，但专业开发人员不应该在追踪需求时不会产生任何利益冲突。还有其他一些你关心的问题吗？在这一点上，需求文档是一项大任务吗？减少客户和开发者之间的层数实际上听起来像是一件好事。

Answer 3

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

如果您正在获得要求，那么您实际上正在与业务交谈。它会给你一个学习生意的机会，并听取他们真正需要的东西，没有变化，没有过滤。您将有机会说服他们用商业术语谈论问题，而不是假设技术解决方案并跳跃设计（例如，“将此列添加到此表并将其绑定到此页上的此文本框中”。 ）也许你会看到攻击他们甚至不知道存在的问题的方法。

Answer 4

我没有机会在敏捷团队或Scrum团队工作，也没有机会应用他们。我为客户做了大量的一次性开发工作1〜3个月。但有一两件事，我在这种环境下，当得知是：

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

这将回答你的问题： 永远不要混淆需求和设计文档。

实际上，它超越了这一点。

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

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

拥有已签名的SoW可以保护您不受范围要求的影响，例如。 “供应商将安装应用程序xxx”，并且突然间，“客户希望安装完整的PKI基础设施以保护与应用程序xxx的通信”。

有一个签署过要求保护您免受突如其来的，不合理的规定，从上面下了类似的情况，“没有必要保护和加密通信应用XXX”。

请注意，这些是法律保护。您应该决定是否应该完成客户的新要求。然而，强调他们不符合要求并纯粹是出于善意，这仍然是件好事。

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

我确实看到了人们可以采用的另一种方法（但并未将设计与需求合并）。

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

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

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

Answer 5

要求参考什么需要完成。 技术设计是指如何满足的要求。

缺点：

• 一个结合他们的缺点是 ，如果你是一个技术家伙， 你会尽力影响 要求做出的技术 任务更容易，着眼于如何。在 结尾中，您可能会开发一个系统 ，该系统实际上并未解决（全部） 系统的用户问题。
• 另一个缺点是，虽然 明确要求， 技术解决方案将需要 适合满足 的新功能/那是澄清 或在需求 启发发现的细节。这意味着 在 需求说明期间多次修改/重新考虑技术解决方案。

可能的优势：

• 拥有的技术方案的概述，而讨论的要求，你可能“弯曲”或谈判的要求，以避免的技术问题后发现（例如性能问题，不可行或代价高的特征，附加值与实施它们的成本不成比例）。但在真正澄清要求之前，您必须小心，不要在技术设计上投入太多。

Answer 6

是的。将需求和技术设计结合起来可以让你的想法变得更加复杂 - 它可以防止你后来提出关于如何通过采用不同的技术方法/优化来改进系统的新想法。

特别是在新技术领域，您可能会以错误的方式开始。将技术设计和需求相结合可以诱导您将技术方法视为一种需求，并且可以很好地废弃和完成不同的工作。

另外，当谈到时间测试（其实那个时候应该是设计之前），那么你可能会测试你的技术方法，而不是什么porgram真正需要做的。

Answer 7

两个另一个区别是，要求发展需要与客户（内部或外部客户），并广泛接触很多优秀的技术人员根本不具备人际沟通技巧来管理客户关系好或交谈actaul用户无需侮辱他们。只有你可以说，如果你这样做。如果你没有这样做，你会发现它比你想象的要困难和复杂得多。另外，您可能会发现自己提出错误的问题，因为您无法看到用户的观点，因为您的专业知识来自开发人员和设计人员的观点。

我个人还发现，让多个人参与设计过程（收集需求并将它们转化为设计）对于创意以及他人可能错过的事物的思维方面是有帮助的。从团队合作的角度来看，从两个人做这个事情可能不是一个好主意。当同一个人做这两件事情时，只用习惯的方式去做事情是很容易的，而且没有其他人参与挑战你的假设，直到你在更难以改变的道路上走得更远。