需求收集和用例示例

Question

我在理论上听说过很多关于需求收集和用例的事情，但是在实践中我们经常会问自己：“我们应该包括这个吗?这应该是一个用例吗?我们应该用哪种语言来编写这个特定的需求”等等。这些问题主要是因为缺乏实践，而且由于我们不能选择项目来“实践中学习”，所以在收集新应用程序需求的过程中，我们很难适应我们所需要的想法。

在这种情况下，有什么地方可以让我找到需求收集和用例应用的真实示例？我找到了一些书，但它们主要集中在团队上，我独自工作，所以它变得有点混乱。

Answer 1

一个简单的例子。你帮助测试你的电子商务产品的用户。在某种程度上，用户希望在一定的价格范围内得到每个产品匹配给定的标签。目前，这是不可能的，因为产品允许通过标签过滤产品或按价格过滤产品，但不能同时进行。

用户的需要是：

我想通过标签和价格过滤产品。我该怎么做呢？

转换成一个用户故事，它将变成：

作为用户，我应该能够使用标签和价格标准过滤产品列表。

从那时起，您可以研究新更改的含义，并开始编写测试并实现新特性。

Answer 2

实际上，需求收集应该先进行，然后再进行用例(您可以有一个反馈循环来验证需求)。您所描述的“我们应该包括这个”、“如果这是一个用例”的案例主要出现在产品开发环境中。根据你对风险的兴趣和你的团队，做出这个选择是很棘手的。

但是，如果您想为客户开发一个解决方案，那么问题确实是“客户机需要这个吗？”而仅此而已。您可能会遇到客户真的不知道他需要什么的情况，在这种情况下，我建议您深入了解需要解决的业务问题。一旦清楚了，技术解决方案就会随之而来。在这种情况下，我通常会推荐简短的迭代和有活动客户参与的增量解决方案。

我们应该用哪种语言来写这个特殊的要求？

你是在暗示一种编程语言吗？在这种情况下，在收集需求时问这个问题肯定是错误的。技术实现通常是在需求收集阶段之后决定的。

首先，应该有一个技术解决方案，比如web应用程序、移动应用程序、中间件、集成、db解决方案等等。

当然，如果您的客户端有一家.net商店或java商店，或者与某个特定的供应商打交道，或者更糟的是供应商被锁定，您当然可以从中得到提示。即便如此，第一件事应该是技术解决方案，并根据时间/预算/资源/misc的条件，技术实施将逐步发展。

不幸的是，书籍只能提示不同的情况，最好的学习是在实践中。

Answer 3

您可以从用户或客户端获得用例。

从本质上讲，它们驱动着接受标准。

不与用户或客户交谈，我们可以想到我们软件的许多可能的使用(模式)，但是应该告诉我们哪些是关键。

另一方面，用户通常会想出使用我们从未考虑过的软件的方法，并在此过程中发现bug。这就是成功的软件如何进化和产生新的需求。

把用例看作用例。