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