要求和技术设计作为一个单一的努力？

Question

作为一名网页架构师，我一直致力于一个大型的多年项目。

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

'权力'表明我接管了需求文档并将其与我在技术设计方面的努力相结合。

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

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

Answer 1

“将需求和技术设计结合到一个步骤中是否存在特定问题？”

是

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

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

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

技术设计可能

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

2. 从椅子上下来，走到酒吧。成本较高。这里风险很小。周日关闭时除外。

3. 问我的妻子。这里风险很大。可能出乎意料的后果。然而，我已经委派了这个问题，她现在必须要么在家里找啤酒，要么跑到商店，要么告诉我要自己买啤酒。无论如何，如果她出去了，我们又回到了低成本，没有风险。

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

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

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

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

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

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

Answer 2

如果你“很好地进入开发阶段”，我希望大多数要求都得到了很好的巩固。我并不认为在开发开始之前需要一定要求（天堂禁止），但是我希望你能确定在这一点上你正在构建什么样的东西。因此，如果现在的要点只是“需求文档”（而不是真正深入挖掘客户的需求），我在这里看不到任何深层次的问题。

虽然将开发与“客户支持”角色分开有一定的优势，但专业开发人员不应该在不产生任何利益冲突的情况下跟踪需求。您还关注其他一些问题吗？需求文档在这一点上是一项大任务吗？减少客户和开发人员之间的层数实际上听起来是件好事。

Answer 3

是。结合需求和技术设计可以让您思考 - 它会阻止您以后提出有关如何通过不同的技术方法/优化来改进系统的新想法。

特别是在新技术领域，你很可能从错误的方法开始。结合技术设计和要求，您可以将技术方法视为一项要求，当它很可能被废弃并以不同方式完成时。

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

Answer 4

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

如果您有要求，那么您实际上是在与业务部门进行交流。它将为您提供学习业务的机会，并听取他们真正需要的，未经修饰和未经过滤的内容。您将有机会说服他们以商业术语谈论问题，而不是假设技术解决方案并跳转到设计（例如，“将此列添加到此表并将其绑定到此页面上的此文本框”。） ）也许你将能够看到攻击他们甚至不知道存在的问题的方法。

Answer 5

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

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

哪个会回答你的问题： 永远不要将要求与设计文档混合。

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

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

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

签署的SoW可以保护您免受范围外的要求，例如。 “供应商将安装应用程序xxx”，并且突然之间，“客户希望安装整个PKI基础设施以保护与app xxx的通信”。

根据上述类似情况，签署签署要求可以保护您免受突然和不合理的要求，“无需保护和加密与app xxx的通信”。

请注意，这些都是法律保护。您仍然需要决定是否应该从客户端获得新的要求。然而，要强调它们不符合要求并完全是出于善意，仍然是好的。

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

我确实看到了人们有一种替代方法（但不是将设计与要求合并）。

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

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

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

Answer 6

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

缺点：

• 组合它们的一个缺点是 那，如果你是一个技术人员， 你会试着影响 制定技术要求 任务更轻松，专注于如何。在 最后，你可能会开发一个系统 实际上没有解决（全部） 用户的问题 系统即可。
• 另一个缺点是，同时 澄清要求， 需要技术解决方案 适应新的 澄清的功能/细节 或在要求期间发现 启发。这意味着 期间多次修改/重新思考技术解决方案 要求澄清。

可能的优势：

• 在讨论要求时概述技术解决方案，您可以“弯曲”或协商要求，以便避免以后发现技术问题（例如性能问题，不可行或昂贵的功能附加值与实施成本不成比例）。但是在要求得到澄清之前，你必须小心不要过多地投入技术设计。

Answer 7

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

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