1

代码可以是完美的，同时也可以是完全无用的。正确获取需求与确保正确实施需求同样重要。

您如何验证您正在处理的代码中是否满足了用户的需求？

4

11 回答 11

5

您尽可能早且尽可能频繁地向用户展示它。

很有可能他们所要求的实际上并不是他们想要的——而发现这一点的最好方法是向他们展示你所拥有的，甚至在它完成之前。

编辑：是的，这也是在 StackOverflow 上回答问题的一种方法 :)

于 2009-07-14T13:38:55.557 回答
1

您编写测试来断言用户需要的行为存在。而且，正如另一个答案中提到的那样，您会尽早并经常收到用户的反馈。

于 2009-07-14T13:40:02.890 回答
0

即使您与用户交谈，并且一切都正确，用户也可能弄错了。直到他们使用了他们不想要的软件，他们才会知道。最可靠的方法是做一些原型，让用户在编写代码之前“尝试一下”。你可以试试纸质原型

于 2009-07-14T13:41:55.320 回答
0

您如何验证您正在处理的代码中是否满足了用户的需求？

对于以这种形式提出的问题，答案是“你不能”。

最好的方法是从一开始就与用户合作，向他们展示原型并不断整合他们的反馈。

即便如此，在路的尽头，很可能不会有任何类似于最初讨论和商定的内容。

于 2009-07-14T13:42:46.160 回答
0
  1. 在构建之前询问他们希望您构建什么。
  2. 把它写下来并向他们展示你写下的要求清单。
  3. 让他们在功能设计上签字。
  4. 建立一个模型并确认它是否符合他们的要求。
  5. 向他们展示正在实施的功能，以确认它们是正确的。
  6. 完成后向他们展示应用程序，并让他们通过验收测试。

他们仍然不会高兴，但你会尽你所能。

任何不在他们签署的文档中的功能都可以被视为变更请求，您可以向他们收取额外费用。让他们签署您向他们展示的所有内容，以限制您的责任

于 2009-07-14T13:44:30.573 回答
0

通过使用通常控制实现和需求之间的一致性的开发方法。对我来说，最好的方法是让“专家客户”以交互方式尽可能频繁地验证和测试实施....如果你不这样做，你就有风险，正如你所说，一个非常漂亮的软完全没用....

于 2009-07-14T13:44:55.550 回答
0

您编写单元测试，期望得到支持需求的答案。如果要求是对一组数字求和，你写

testSumInvoice()
{
     // create invoice of 3 lines of $1, $2, $3 respectively
     Invoice myInvoice = new Invoice().addLine(1).addLine(2).addLine(3);
     assertTrue(myInvoice.getSum(), 6);
}

如果单元测试失败，则您的代码可能是错误的，或者可能由于某些其他要求而被更改。现在您知道这两个案例之间存在冲突需要解决。它可以像更新测试代码一样简单，也可以像用需求未涵盖的新发现的边缘案例返回客户一样复杂。

编写单元测试的美妙之处在于它迫使你理解程序应该做什么，这样如果你在编写单元测试时遇到困难，你应该重新审视你的需求。

于 2009-07-14T13:45:34.567 回答
0

如果可能，请让您的用户编写验收测试。这将帮助他们思考应用程序正常运行意味着什么。将开发分解为相互依赖的小增量。正如其他人所说，尽早（并且经常）将这些暴露给客户，让他们使用它，但也让他们运行验收测试。这些也应该与被测代码一起开发。通过测试并不意味着您已经完全满足要求（测试本身可能缺乏），但它会让您和客户相信您在正确的轨道上。

这只是开发代码时繁重的客户交互得到回报的一个例子。最大程度地确保您正在开发正确的代码的方法是让客户参与开发工作。

于 2009-07-14T13:48:53.017 回答
0

你可以尝试角色；使用该系统的一组示例用户。

量化他们的需求和愿望，并根据对他们来说重要的内容进行设想；以及他们需要使用该软件完成什么。

最重要的是——确保满足用户（角色）的目标。

这是我写的一篇文章，更详细地解释了它。

于 2009-07-14T13:48:59.790 回答
0

我真的不同意代码可以是完美的……但这不是真正的问题。在完成任何设计或编码之前，您需要从用户那里了解他们想要什么——问他们“成功是什么样的”、“系统完成后你期望什么”、“你希望如何使用它'......然后将响应录制下来，制作思维导图或线框图，然后与他们一起进行审查，以确保您捕捉到最重要的方面。您可以使用这些项目来验证迭代交付......期望用户随着时间的推移改变他们的想法/需求，一旦他们“掌握了它”（IKIWISI - 当我看到它时我就知道了）......并且以同样的方式记录任何变更请求。

于 2009-07-15T13:10:16.443 回答
0

AlbertoPL 是对的：“大多数时候，即使是用户也不知道他们想要什么！”

如果他们知道，他们就会想到一个解决方案，并指定该解决方案的各个方面，而不仅仅是说出问题。

如果他们告诉你一个问题，他们可能会遇到其他问题，而没有意识到这些问题与共同的原因或共同的解决方案有关。

因此，在你实施模型和原型之前，去看看客户已经拥有的东西的使用情况或员工仍在手工做的事情。

于 2013-03-06T22:36:48.880 回答