How do you verify that users' requirements are addressed in the code you're working on?

Question

Code can be perfect, and also perfectly useless at the same time. Getting requirements right is as important as making sure that requirements are implemented correctly.

How do you verify that users' requirements are addressed in the code you're working on?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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....

Answer 7

1. Ask them what they want you to build before you build it.
2. Write that down and show them the list of requirements you have written down.
3. Get them to sign off on the functional design.
4. Build a mock up and confirm that it does what they want it to.
5. Show them the features as it is being implemented to confirm that they are correct.
6. 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

Answer 8

How do you verify that users' requirements are addressed in the code you're working on?

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.

Answer 9

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

Answer 10

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.

Answer 11

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 :)