Ask them what they want you to build before you build it.
Write that down and show them the list of requirements you have written down.
Get them to sign off on the functional design.
Build a mock up and confirm that it does what they want it to.
Show them the features as it is being implemented to confirm that they are correct.
Show them the application when it's finished and allow them to go through acceptance testing.
They still wont be happy but you will have done everything you can.
Any features that are not in the document they signed off can be considdered change requests which you can charge them extra. Get them to sign off everything you show them, to limit your liability
by using development method that often controls alignement between the implementation and the requirements. For me, the best way is to involve a "expert customer" to validate and test in a interative way as often as possible the implementation .... If you don't, you risk to have, as you said, a very beautiful soft perfectly useless....
You write unit tests that expect an answer that supports the requirements. If the requirement is to sum a set of numbers, you write
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);
}
If the unit test failed, either your code is wrong or possible was changed due to some other requirement. Now you know that there is a conflict between the two cases that needs to be resolved. It could be as simple as updating the test code or as complex as going back to the customer with a newly discovered edge case that isn't covered by the requirements.
The beauty of writing unit tests is it forces you to understand what the program should do such that if you have trouble writing the unit test, you should revisit your requirements.
I don't really agree that code can be perfect...but that's outside of the real question. You need to find out from the users prior to any design or coding is done what they want - ask them 'what does success look like', 'what do you expect when the system is complete', 'how do you expect to use it'...and video tape the response, mindmap it, or wireframe it and than give review it with them to ensure you captured the most important aspects. You can than use those items to verify the iterative deliveries...expect the users to change their mind/needs over time and once they have 'it in their hand' (IKIWISI - I Know It When I See It)...and record any change requests in the same fashion.
You show it to the users as early and as often as possible.
Chances are that what they've asked for isn't actually what they want - and the best way of discovering that is to show them what you've got, even before it's finished.
EDIT: And yes, this is also an approach to answering questions on StackOverflow :)
You write tests that assert that the behavior the user requires exists. And, as was mentioned in another answer, you get feedback from the users early and often.
even if you talk with the user, and get everything right, the user might have gotten it wrong. They won't know until they use the software that they didn't want what they asked for. the surest way is to do some sore of prototype that allows the user to "try it out" before you write the code. you could try something like paper prototyping
If possible, get your users to write your acceptance tests. This will help them think through what it means for the application to work correctly. Break the development down into small increments that build on each other. Expose these to the customer early (and often), getting them to use it, as others have said, but also have them run their acceptance tests. These should also be developed in tandem with the code under test. Passing the test won't mean that you have completely fulfilled the requirements (the tests themselves may be lacking), but it will give you and the customer some confidence that you are on the right track.
This is just one example of where heavy customer interaction pays off when developing code. The way to get the most assurance that you are developing the right code is having the customer participating in the development effort.
发布评论
评论（11）
对于以这种形式提出的问题，答案是“你不能”。
最好的方法是从一开始就与用户合作，向他们展示原型并不断吸收他们的反馈。
即便如此，最终，可能不会出现任何与最初讨论和达成一致的情况。
For a question put in this form the answer is "You can't".
The best way is to work with users from the very first days, show them prototypes and incorporate their feedback continuously.
Even so, at the end of the road, there will likely be nothing resembling what was originally discussed and agreed on.
他们仍然不会高兴，但你会尽力而为。
他们签署的文档中没有的任何功能都可以被视为变更请求，您可以向他们收取额外费用。 让他们签署您向他们展示的所有内容，以限制您的责任
They still wont be happy but you will have done everything you can.
Any features that are not in the document they signed off can be considdered change requests which you can charge them extra. Get them to sign off everything you show them, to limit your liability
通过使用通常控制实现和需求之间的一致性的开发方法。
对我来说，最好的方法是让“专家客户”参与进来，以交互方式尽可能频繁地验证和测试实施......
如果你不这样做，你就会冒着风险，正如你所说，一个非常漂亮的软体完全没用......
by using development method that often controls alignement between the implementation and the requirements.
For me, the best way is to involve a "expert customer" to validate and test in a interative way as often as possible the implementation ....
If you don't, you risk to have, as you said, a very beautiful soft perfectly useless....
你可以尝试人物角色； 使用该系统的一组示例用户。
量化他们的需求、愿望，并构建对他们重要的场景； 以及他们需要使用该软件完成什么工作。
最重要的是——确保满足用户（角色）的目标。
这是我写的帖子更详细地解释它。
you can try personas; a cohort of example users that use the system.
quantify their needs, wants, and make up scenarios of what is important to them; and what they need to get done with the software.
most importantly- make sure that the users (the persona's) goals are met.
here's a post I wrote that explains it in more detail.
您编写的单元测试期望得到支持需求的答案。 如果要求是对一组数字求和，您可以写“
如果单元测试失败，则您的代码是错误的，或者可能由于某些其他要求而被更改”。 现在您知道这两种情况之间存在需要解决的冲突。 它可以像更新测试代码一样简单，也可以像用需求未涵盖的新发现的边缘情况返回给客户一样复杂。
编写单元测试的美妙之处在于它迫使您了解程序应该做什么，这样如果您在编写单元测试时遇到困难，您应该重新审视您的需求。
You write unit tests that expect an answer that supports the requirements. If the requirement is to sum a set of numbers, you write
If the unit test failed, either your code is wrong or possible was changed due to some other requirement. Now you know that there is a conflict between the two cases that needs to be resolved. It could be as simple as updating the test code or as complex as going back to the customer with a newly discovered edge case that isn't covered by the requirements.
The beauty of writing unit tests is it forces you to understand what the program should do such that if you have trouble writing the unit test, you should revisit your requirements.
我不太同意代码可以是完美的......但这超出了真正的问题。 在完成任何设计或编码之前，您需要从用户那里了解他们想要什么 - 询问他们“成功是什么样的”，“系统完成后您期望什么”，“您期望如何使用它” '...然后对响应进行录像，进行思维导图或线框图，然后与他们一起进行审查，以确保您抓住了最重要的方面。 然后，您可以使用这些项目来验证迭代交付...期望用户随着时间的推移改变他们的想法/需求，一旦他们“掌握了它”（IKIWISI - 我看到它就知道）...并且以同样的方式记录任何变更请求。
I don't really agree that code can be perfect...but that's outside of the real question. You need to find out from the users prior to any design or coding is done what they want - ask them 'what does success look like', 'what do you expect when the system is complete', 'how do you expect to use it'...and video tape the response, mindmap it, or wireframe it and than give review it with them to ensure you captured the most important aspects. You can than use those items to verify the iterative deliveries...expect the users to change their mind/needs over time and once they have 'it in their hand' (IKIWISI - I Know It When I See It)...and record any change requests in the same fashion.
AlbertoPL 是对的：“大多数时候，连用户也不知道自己想要什么！”
如果他们知道，他们心里就会有一个解决方案，并详细说明该解决方案的各个方面，而不仅仅是告诉问题。
如果他们告诉你一个问题，他们可能还有其他问题，但没有意识到这些问题之间有共同的原因或共同的解决方案。
因此，在实施模型和原型之前，请观察客户已有的东西或员工仍在手工操作的东西的使用情况。
AlbertoPL is right: "Most of the time even the users don't know what they want!"
And if they know, they have a solution in mind and specify aspects of that solution instead of just telling the problem.
And if they tell you a problem, they may have other problems without being aware that these are related by having a common cause or a common solution.
Thus, before you implement mockups and prototypes, go and watch the use of what the customer already has or what the staff is still doing by hand.
您应尽早且尽可能频繁地将其展示给用户。
很可能他们所要求的实际上并不是他们想要的 - 发现这一点的最佳方法就是向他们展示您所拥有的，甚至在项目完成之前。
编辑：是的，这也是回答 StackOverflow 上问题的一种方法:)
You show it to the users as early and as often as possible.
Chances are that what they've asked for isn't actually what they want - and the best way of discovering that is to show them what you've got, even before it's finished.
EDIT: And yes, this is also an approach to answering questions on StackOverflow :)
您编写测试来断言用户所需的行为存在。 而且，正如另一个答案中提到的，您会尽早且经常收到用户的反馈。
You write tests that assert that the behavior the user requires exists. And, as was mentioned in another answer, you get feedback from the users early and often.
即使您与用户交谈并得到所有正确的信息，用户也可能会弄错。 在使用该软件之前，他们不会知道他们不想要他们所要求的东西。 最可靠的方法是做一些原型，让用户在编写代码之前“尝试一下”。 你可以尝试类似纸质原型
even if you talk with the user, and get everything right, the user might have gotten it wrong. They won't know until they use the software that they didn't want what they asked for. the surest way is to do some sore of prototype that allows the user to "try it out" before you write the code. you could try something like paper prototyping
如果可能，让您的用户编写验收测试。 这将帮助他们思考应用程序正常工作意味着什么。 将开发分解为相互依赖的小增量。 正如其他人所说，尽早（并且经常）向客户展示这些，让他们使用它，但也让他们运行验收测试。 这些也应该与正在测试的代码一起开发。 通过测试并不意味着您完全满足了要求（测试本身可能有所欠缺），但它会给您和客户带来一些信心，让您相信您走在正确的轨道上。
这只是开发代码时大量客户互动带来回报的一个例子。 最能保证您正在开发正确代码的方法是让客户参与开发工作。
If possible, get your users to write your acceptance tests. This will help them think through what it means for the application to work correctly. Break the development down into small increments that build on each other. Expose these to the customer early (and often), getting them to use it, as others have said, but also have them run their acceptance tests. These should also be developed in tandem with the code under test. Passing the test won't mean that you have completely fulfilled the requirements (the tests themselves may be lacking), but it will give you and the customer some confidence that you are on the right track.
This is just one example of where heavy customer interaction pays off when developing code. The way to get the most assurance that you are developing the right code is having the customer participating in the development effort.