我经常听到“X% 的软件项目由于糟糕的需求而失败”。该声明中的 X 介于大约 70 到 95 之间。但是，我很少听到需求如何变差。事实上，声明本身表明确实存在要求。
什么是“坏”的要求？如何避免？
【问题讨论】：
标签： requirements
【讨论】：
什么是不好的要求？一个不存在的
我在这里看到了很多关于错误要求的好答案，即沟通不畅或半生不熟的要求。他们可能是正确的。
但对我来说，最糟糕的“坏要求”之一就是缺少的。我在系统中一次又一次地看到这一点。上线一天后，用户说：“哦，那 XYZ 呢？我们真的需要它。”项目团队的回应是：“XY 什么？我们已经在这个项目上工作了一年，现在你告诉我们吗？”
为什么不好？
这是一个杀手锏，因为现在每个人都必须争先恐后地提出解决方案，并不是说普通开发人员需要任何帮助将半途而废的东西推广到生产环境，但你只知道它会为所有开发者提供大量生产支持可怜的人，这个“解决方案”被移交给维护......你知道，那些没有获得项目奖金的人。
同样，这不是一个糟糕的要求，而是一个从一开始就不是一个要求。这并不意味着它是无效的；它肯定是至关重要的。但是，在急于完成工作和激进的项目步伐之间，以及我们都是人类并且会犯错误的事实之间，这一点被忽略了。
你如何避免它？
您可以在前面多花点时间，并希望有敏锐的主题专家来弥补缺失的空白。一种更有效且成本更高的方法是花时间参与一些人所说的“模范办公室”阶段。这类似于系统测试，但旨在模拟现实生活条件。测试人员不仅要验证系统是否为 1 + 1 提供了正确的输出，而且它的所有部分都在业务流程的上下文中工作。
这当然很难卖。很多项目都会忽略业务分析和测试，以维护“按时、按预算”的万能指标。但是如果你想摆脱这些缺失的需求，你必须让用户使用它。然后，他们将在口头需求定义会议中认识到他们认为理所当然的事情。敏捷专家会补充说，需要尽早并尽可能频繁地进行此测试，以发现这些风险，并让项目团队有时间确定他们的优先事项并在必要时进行调整。
【讨论】：
开发组织可以做（但很少做）最有价值的事情之一就是验证需求。尽可能快速且廉价地模拟设计，并与客户一起审查。如果可能的话，以一种可以将审查结构化为任务演练的方式进行，这样开发人员和用户就可以一起遍历用例并决定所提议的设计是否解决了问题。然后，如有必要，再做一次。
JoAnn Hackos 和 Janice Redish 撰写了一本关于收集和理解需求的优秀书籍，名为 User and Task Analysis for Interface Design。这是一本很大的书，但它的可读性很强，并且充满了实用的技巧和工具。
【讨论】：
我想你会发现，如果你把它解释成这样，它会更有意义：
“X% 的软件项目因需求定义不当而失败”
你可以做很多事情
【讨论】：
我的经验表明不良要求的下一个可能来源：
应该做些什么来克服这些问题？让我们允许工程师提供反馈，让我们不要关闭需求并使其尽可能灵活。通常即使具有良好一致的要求，我们在实施阶段也会面临一些低级别的硬件限制，并且需要跟踪更改。从另一方面让我们了解客户，而不仅仅是技术。我看到很多项目的大部分工作都被抛弃了，仅仅是因为它们对开发人员来说看起来不错，但对客户却不利。您与客户的沟通越好，发生此类情况的可能性就越低。
我的理解是，流程应该允许在所有阶段灵活地更改需求，但另一方面应该使所有这些工作可跟踪，并将范围限制在所需的最小范围内。问题是要在所有这些之间取得平衡。至少我的建议是我们应该采用最短的开发周期来降低所有风险。
【讨论】：
可能他们的意思是“错误传达”的要求。
如果您仔细想想，您可能会通过多种方式错误地陈述要求，无论是有意还是无意。处理问题的一些方法：
意识到系统的需求可以不断变化。否则客户会说“是的，改变了，没人告诉你吗？”
询问几个关键人物的要求 - 询问 CEO 是不够的，同样，询问实际使用您系统的较低级别也是不够的。
确保有少数人负责向您传达需求 - 这些人（在中型项目中不超过 5 人）应该有很大的动机为您提供成功所需的所有信息执行。如果你没有这些人，你很可能会失败，因为每个人都忙于向你解释事情，他们会有动机不和你说话，因为你可以声称 X 人告诉你执行他们按照您的方式使用的系统。你需要管理层的支持来创建这群人。
您需要与其他人验证假设。有时您需要以五种不同的方式提出同一个问题。
害怕绝对...“无法更改销售价格”有时意味着“我希望实施主管覆盖，以防当前客户需要更改价格。”
尽可能了解业务流程。如果您正在编写银行应用程序，请在银行呆一天，看看人们将如何使用该系统。如果您交付项目的某个阶段，请执行相同的操作：观察正在使用的系统，并积极寻找漏洞。
当某些事情没有足够详细地指定时，请识别并坚持正确处理。制作模型、手绘图、流程图等，以确保需求的来源与您在同一页面上。
这些都是经验之谈……我认为“糟糕的需求”实际上是指“客户和实施者之间的糟糕沟通”。
【讨论】：
在敏捷中，我们使用首字母缩略词 INVEST。故事（代表需求）应该是：
需求不是从山顶交给你的神器。它们是您和您的客户（或他们的代理人）之间的发现和对话过程中的一个活生生的副产品。
【讨论】：
首先，要使要求有效，它需要可测试。如果没有，就不可能对其进行跟踪、测量、报告……这是邪恶的根本原因。
如何避免这种情况？确保满足以下要求：
在时间和资源上都有界限（例如 $）
可测试
否则，您正在研究“开环”，我相信您会理解后果。
请注意，有时需求带有“定性”性质：由产品经理/团队为其定义“定量”定义。
【讨论】：
敏捷开发方法的很大一部分是接受需求会发生变化的事实。
因此，您不应试图与之抗争，而应创建一个包含它的流程。
【讨论】：
每当我看到这些统计数据时，我都会想起昂贵的、头重脚轻的瀑布项目，其中第一个版本已完成并呈现给客户，客户很快告诉该项目，“这并不是我真正想要的。”
这就是为什么如今大多数成功的项目都是使用“迭代”模型完成的，在这种模型中，客户不断参与设计过程。
在这种情况下，“需求”的定义更加宽松，并且随着项目的进展而有所变化。
【讨论】：
除了不可能/不切实际或无法验证的要求外，“坏”可能是指收集不正确 - 他们的要求与应用程序的实际需要不匹配。原因之一是用户通常并不真正知道他们需要什么或想要什么。
【讨论】：