如何避免“坏”的要求

Question

我经常听到“X％的软件项目由于要求不好而失败”。该声明中的X大约介于70到95之间。但是，我很少听到要求变坏的情况。事实上，声明本身表明实际上有要求。

什么造成“坏”要求？怎么可以避免？

Answer 1

要成功获取需求，您需要

• 让您的客户到现场，讨论要求，让他向您解释
• 要求必须是可测试的，可验证的。有了它们的列表，最后你应该可以查看列表并直接验证它们在最终产品上的正确实现。
• 他们应该有适当的细节。存在不同类型的要求（目标级别，域级别，产品级别，设计级别）。要求应适当分类。

通常问题在于客户与开发人员之间缺乏沟通和理解。此外，请记住，有时甚至客户本身也不能完全了解他想要的东西。因此，讨论，纸张原型等非常重要。

这张照片是我的最爱：）

Answer 2

敏捷开发方法的很大一部分是接受需求会发生变化的事实。

因此，你不应该试图与之斗争，而是创造一个包含它的过程。

Answer 3

每当我看到这些统计数据时，我都会想起昂贵的，头重脚轻的瀑布式项目，第一个版本已经完成并呈现给客户，他们很快告诉项目“这不是我想要的。”

这就是为什么现在大多数成功的项目都是使用“迭代”模型完成的，客户经常参与设计过程。

在这种情况下，“需求”的定义更为松散，随着项目的进展，它们会有所不同。

Answer 4

在敏捷中，我们使用缩写词INVEST。故事（代表要求）应该是：

• 我 - 独立
• N - 面议
• V - Valuable
• E - Estimable
• S - 小
• T - Testable

要求不是从山顶交给你的神器。它们是您和您的客户（或其代理人）之间发现和对话过程的生动副产品。

Answer 5

首先，要求有效，需要可测试。如果没有，就没有可能跟踪它，测量它，报告它......这是邪恶的根本原因。

如何避免这种情况？确保要求：

• 在时间和时间都有限制。资源（例如$）

• 可测试

否则，你正在开发一个“开环”，我相信你可以理解后果。

注意有时候要求具有“定性”性质：产品经理/团队需要为其定义“定量”定义。

Answer 6

我想你会发现，如果你将其解释如下，那就更有意义了：

“由于需求定义不正确，X％的软件项目失败”

你可以做很多事情

• 确保您可以实际测试要求
• 确保分析师确实了解用户真正的含义。通常用户要求的不是他们真正想要的东西。
• 确保开发者了解要求。如果开发人员得到一个糟糕的规范并且必须做出错误的假设，那么当程序员必须纠正这个假设时，时间就会浪费，而不是常见的错误。
• 确保用户确实测试了他们的要求是否得到满足。比（从未发现过）更好（发现）。

Answer 7

除了不可能/不切实际或无法验证的要求之外，“坏”可能是指错误收集 - 它们要求您与应用程序实际需要的不匹配。其中一个原因是用户经常不知道他们需要什么或想要什么。

Answer 8

可能他们的意思是“误传”的要求。

如果您考虑一下，有很多方法可以有意或无意地错误地陈述要求。解决问题的一些方法：

• 意识到系统的要求可以不断变化。否则客户会说“是的，那改变了，没有人告诉你？”

• 询问几个关键人物的要求 - 这不足以问首席执行官，同样地，要求较低级别的人实际使用你的系统是不够的。

• 确保有少数人负责向您传达要求 - 这些人（中型项目中不超过5人）应该有一个很大的动力来为您提供成功的所有信息实现。如果你没有这些人，你可能会失败，因为每个人都会忙着向你解释事情，他们会有动力不和你说话，因为你可以要求X人告诉你实施你按照他们的方式做的系统。您需要管理层的支持才能创建这一群人。

• 您需要与其他人核实假设。有时您需要以五种不同的方式提出相同的问题。

• 害怕绝对......“销售价格无法改变”有时意味着“我希望在需要为当前客户更改价格时执行主管覆盖。”

• 尽可能了解业务流程。如果您正在撰写银行应用程序，请在银行花一天时间查看人们如何使用该系统。如果你交付项目的一个阶段做同样的事情：观察正在使用的系统，并积极寻找漏洞。

• 识别何时没有详细说明某些内容并坚持要求正确。做模型，手绘，流程图，确保需求来源和你在同一页面上所需的一切。

这些都来自经验...我认为“不良要求”实际上意味着“客户与实施者之间的沟通不畅。”

Answer 9

我的经验显示了糟糕要求的下一个可能来源：

• 用户/客户通常不知道他们想要什么。 处理这种方法的可能方法是拥有优秀的业务分析师 执行必要的分析或有适合该用户的良好现成产品（或不）。
• 分析师无法提供适当的质量要求。 是的，它发生了。聘请更好的分析师/技术专家，但失败之前 后的 。测试要求，分析用例，绘制状态序列图 尽早了解用户案例的覆盖范围 等等。换句话说，这与一般建模有关。
• 嗯，有可能从营销要求/模型转换成错误 技术规范。
• 设计质量问题（实施不符合要求）。

应该采取什么措施来克服这些问题？让我们允许工程师提供反馈，让我们不要关闭要求并尽可能灵活。通常即使具有通常良好的一致性要求，我们也会在实施阶段面临一些低级硬件限制，并需要跟踪更改。从另一方面来说，让我们了解客户，而不仅仅是技术。我看到大量项目被丢弃的大部分工作只是因为它们对开发人员而不是客户看起来很好。与客户的沟通越好，这种情况就越可能发生。

我的理解是流程应该允许在所有阶段中灵活的需求变更，但是从另一方面应该使所有这些工作都可以跟踪并将范围限制到所需的最小值。问题是在所有这些之间取得平衡。至少我的建议是我们应该采用最短的开发周期来降低所有风险。

Answer 10

开发组织可以做的最有价值的事情之一（但很少完成）是验证需求。尽可能快速，低成本地模拟设计，并与客户一起审核。如果可能的话，以可以将审核结构化为任务演练的方式进行，因此开发人员和用户可以一起浏览用例并确定所提议的设计是否解决了问题。然后，如有必要，再做一次。

JoAnn Hackos和Janice Redish撰写了一本关于收集和理解需求的精彩书籍，称为界面设计的用户和任务分析。这是一本很大的书，但它非常易读，并且充满了实用的技巧和工具。

Answer 11

什么是不好的要求？一个不存在的

我在这里看到很多好的答案，关于一个错误传达或半生不熟的错误要求。他们可能是正确的。

但对我而言，最糟糕的“不良要求”之一就是那个简直缺失的。我在系统中一次又一次地看到。上线后的第二天，用户说：“哦，XYZ怎么样？我们真的需要它。”项目组响应的是什么？“XY是什么？我们已经在这个项目上工作了一年，现在你告诉我们了吗？”

为什么不好？

这是一个杀手，因为现在每个人都必须争抢和推出一个解决方案，而不是普通的开发人员需要任何帮助促进半生产的生产，但你只知道它会为所有的生产提供大量的生产支持。穷人这个'解决方案'被移交给维修......你知道，那些没有获得项目奖金的人。

同样，这不是一个糟糕的要求，但永远不需要以开头。这并不意味着它无效;它肯定是至关重要的。但是，在急于完成工作和积极的项目节奏之间，以及我们都是人类并且我们犯错误的事实之间，这被忽视了。

你如何避免它？

你可以花更多的时间在前面，希望一个敏锐的主题专家能够找到缺失的差距。一种更有效，更昂贵的方法是花时间参与一些所谓的“模范办公室”阶段。这就像一个系统测试，但旨在模拟真实的生活条件。测试人员不仅要验证系统是否为1 + 1提供正确的输出，而且所有部件都在业务流程的上下文中工作。

当然这很难卖。许多项目将进行业务分析和测试，以维护“按时和按预算”的全能指标。但是如果你想要摆脱这些缺失的需求，你必须让用户运行它。然后，他们会在口头要求定义会话中认识到他们认为理所当然的事情。敏捷专家会补充说，这项测试需要尽早和尽可能频繁地发现，以发现这些风险，并让项目团队有时间确定他们的优先事项，并在有需要的情况下进行调整。