user's requirements verification, howto?

Question

My question is: How can you verify the users' requirements early in the software creation process?

I show the user specifications, prototypes, demos... but still users forget to share some "insignificant details" about the process or business rules and data. Which pops up after the final test as some "really small and rare exceptions" - which are turned into change request and accumulate a lot of work.

So how do you prototype (or verify) users requirements early in the project?

Answer 1

Use iterative development that forces you to have frequent feedback to the customer/user.

Also increase collaboration between developers and users by removing (usually useless) intermediate such as project managers or even business analysts (the latter can be very required in very complex business domains).

That's just a few recommandations. There is a lot to say on the subject.

I highly suggest you to have a look at Scrum. Which saved my life.

Answer 2

Start by not getting rid of intermediates like business analysts, because they are actually trained in this. If you don't have such people, accept that at least one of your developers is going to need to develop this skill.

Next, over time, accumulate a set of instincts about the sorts of things people often ask for late in projects, and bring them up in conversation early in the project. "Will the discount always be the same for all orders, or does it vary by customer?" "Can every user see every report, or are some just for supervisors?" "Is the sales tax always the same, or does it depend where the customer is?" and so on.

In addition, try to write your code so it's insulated from these kinds of changes coming late, because some will still come in late no matter what. If you have business logic in the click handlers for your buttons, these changes really hurt. If you have business logic in a specific class whose name makes it easy for you to find it, and you can leverage polymorphism to, say, have regular orders and rush orders and each order calculates its own shipping charge, then the change they've asked for is much less painful.

You cannot prevent late changes. Laws change, business drivers (customers, what sales is promising, the great idea the CEO has while reading something on the plane) change. Prevent what you can and embrace the rest by designing your code to be changeable.

Answer 3

You really just need to along the way make sure you are meeting the criteria listed there. For example if it says "functionality x should be available to all users" then make sure this is true.

Early in the development process this will be tough but closer to deadline the more you should be able to verify.

Perhaps the things you do not yet have implemented, you can verify they are in the design considerations so you know they are being considered during early development.

Answer 4

I remember being in a business meeting and having one of the business analysts saying that it must be great being a developer always having a fixed specification to work to.

In the real world, there are a few things that greatly help with this. The first one, is to accept that these last minute details are a fact of life. the only 100% complete specification of the final product is the source code. If the customer already has this, then they have no need for you to write it do they?

The second thing to do is to actively try to flush out the missing specification details. now you could try getting the customer to sign off 300 page Use Case documents and other contractual mechanisms, but in the end, I can say with 100% confidence, the best way is to deliver software to your customers. Get them to review it, use it, actively encourage them to change the specification to their needs (and when appropriate to charge them for the work). Even when only some of the features are implemented, customer feedback is key.

The third, when reading the specification, think about what would cause this requirement to change and how you could handle variations. its often not sensible to over engineer for changes that may not appear, but having a plan, and just as importantly not designing in extra difficulties will make your life much easier - and the extra brownie points for keeping your cool and being confident when you say 'we can handle that by .... and it will take about 4 days to do.' will inspire others to have confidence in you.

Answer 5

I think you must not forget the other side. For any user it is difficult to produce a complete list of details of what you want. Think of yourself, you think of new things all the time.

It is an incredible hard job to come up with all the requirements and details of something you only have a vague idea about. I don't think anyone can.

I have a book here from the 70's called "why software projects fail". When I read on blogs and get IT magazines I read on the cover "why software projects fail". And when I compare the book contents with the current listings.... nothing changed. Iterative development: yes lots of variations and it helps at some level. But after all this time the contents of the magazines have the same covers. If you don't believe me go digg up some magz from the way past and see how you can copy and paste the text to the now.

This problem is not solvable on the IT end. We have been inventing new tools, processes, checklists, requirements analysis schemes, (business) use cases, development frameworks, BPM, SOA, you call it and still the same problem exists...

You need to optimize this around 'the requirements specifier'. So you need to give those people the adequate tools, whatever to enable them to bring their level higher:

So e.g. for these persons: spec patterns out of the box, input from other projects and companies doing the same copy their end-result requirements and lessons, get people in there who have been through the dirt and can help this person to specifiy the things that caused the greatest problems and are not "trivial" but can only be learned after doing it (e.g. senior technical consultants doing the same stuff at other companies), give these people requirements composer tooling, for insurance, banks, telco etc...: dont invent your own processes buy the generic processes out of the box, etc... they NEED tools just like developer need tools and patterns and frameworks.

Does not solve it but improves it significantly IMHO the improvement should be around that area and not later down the road.

Just like a developer these persons just try to do the best they can. But unlike developers for their field most of the stuff we take for granted after 30 years is not even present in that field. In general their tools are outlook, excel, word and a board. Their processes are brainstorm sessions. A lot of improvement can be done in this field. Ofcourse the problem is mostly that they are sitting "outside" IT so even plans from the CIO to improve the situation in that field fall on deaf ears... but that is another question: how to "sell" this.

Answer 6

You need to let users know that the later a 'requirement' is identified in the project, the more it will cost. They may decide that they don't really need the change after all. If they insist on the changes, but refuse the extra costs/time delay, you have a problem that needs to be negotiated. That is not going to be solved through technology or planning but by sales and client relationship management.

Continuously getting working software in front of them AND requiring them to make the effort to use/test/evaluate is your best bet. They won't fully comprehend contracts, specs, diagrams, and user stories.

This is part of the Joel Test. Grab anyone you can find to test the software as much as possible throughout the entire development process.

Answer 7

If you really want to do the job right, before you start working on code or designing an architecture, sit down with some of the people who will be the users of your code ( not their management or any other higher level stakeholder ) and get them to show you how to do their job. Ideally actually do the job for a day or two. That will give you an understanding of the way the current system works and the type of people who are doing it. It will also show you the frustrations they have with the current system and the things that are hitting their productivity. You need to hear all the daily gripes and annoyances too, which may mean you have to do what is necessary to make sure their feedback stops with you or your design team, if the idea of passing their views on to other members of their organisation is likely to inhibit that.

For each group of users you need to have someone who will be working on the development of that part of the software do the same thing. Then you can all meet up and discuss what you have learned in the roles you have shadowed to see whether there are areas of crossover and how you can make things easiest for everyone involved.

I don't suggest this replaces other requirements gathering processes, but it is a supplement that lets you understand what the real users need from your system. Whatever managment thinks they need, it is likely that the managers and business analysts will not be the actual users of the system, but if you can make the system work well for those users it's going to make them more productive, making the managers happy and making your company look good.