How to get a good specification from client? Or how can I _BE_ the perfect client?

Question

I've just had a new project land on my desk which is more than a little bit beyond me, so I'll be delegating it to a colleague. However, I don't want to be the nightmare user with the forever changing specs; so what is my best way to plan and spec out the application that needs to be developed?

Are there template spec documents out there I could work to?

Do you guys have standard questions you ask users when they come to you for a program?

I think if I can get a good, accurate specification to my colleague as early on in the process as possible then I should be able to make his job a whole lot easier

Answer 1

You need to gather good requirements. Interview the client and ask as many relevant questions as you can. Ideally, you would go and observe the user doing the work as it is done currently, if this is applicable. You might to make sure you understand the problem as the user will not tell you everything you need. You have to be more proactive. In a sense, the users expect a lot more magic than you can really provide; when they see the finished product they will be perplexed as to why a feature is absent or doesn't work the way it should even though there was no discussion around it. Your job is to prevent this from happening.

Answer 2

Requirements gathering is not an exact science as it will generally depend on a) you and b) the customer's personalities.

I personally work from a template but arrange meeting to develop the user requirements.

There are 2 extremes but you will find that customers will normally say something like

"I want a screen that shows x and when you press y it will update with widget list".

In this case you would want to know why they want a screen with x and y on it. In some cases they may actually want to just actually want to autoupdate the widget list.

OR

"Here is a 10000000 page document of what I want" Again you need to look at the underlying reasons why.

I guess the rule of thumb is to never just do what customers ask for. Find out what they really want.

Answer 3

Go Agile !! There's always scope for Late Changes & you would end up building a quality product..

Answer 4

What you want to write is called a System Requirements Specification or SRS, entire college courses are taught on all the nitty gritty details. But it's essentially an overview of the entire project, and the objectives that are expected to be met.

Here is the first decent link I found on google describing the process.

Answer 5

"I don't want to be the nightmare user with the forever changing specs;"

Both you, and the guy you're pushing this project off to, need to adopt an Agile mindset. Requirements change. This is a fact of life. The sooner you stop resisting it and change your mindset to cope with it, the better a developer/customer you'll be.

The trick isn't having requirements that never change, but being able to adapt to the change. This requires good SOLID coding practices.

When it comes to gathering the initial requirements (understanding that they are going to change as the customer gets access to prototypes, builds, etc.) the simplest thing you can do is make sure that both parties understand: What problem are you trying to solve? If you both can come to some agreement on what that is, then you can begin to flesh out solutions.

Answer 6

I'd second the Agile idea, and give a bit more detail:

Chances are that the project's requirements aren't going to be fixed in stone for the next 100 years and will change, so one could embrace that by trying to get a prototype up and then fine tuning it by getting feedback from the end user and repeating the process of tweak and test over and over again to get to a quality product.

At least that is part of one of the ideas in Agile programming: Having more communication and understanding that requirements will change and somewhat accepting that.

Answer 7

When I gather requirements, I do it through user interface design. The steps are as follows:

1. Do user observations. Make detailed notes of what the users do, by writing short notes and by taking pictures of each step of the user's workflow. A typical user observation takes 2-4 hours until you are too exhausted. After that (on the same and following day) you go through the notes, try to understand the reasons for what the users did, and extract use cases and the goals of the users from the work sequences. The pictures that you took will provide you with detailed and real example data, which will be needed in the design phase.

2. Design a paper prototype with which it's possible to execute the goal-based use cases gathered previously. Use whatever methods you have to test the utility and efficiency of the UI. This step takes a couple of days for each iteration.

3. Go show the UI prototype to the users, and go through the use cases with the users, that how the use cases are executed on the UI (the use cases that you have already gathered, and any use case that the user happens to be working on right now). Ask the users to point out any illogical mistakes, missing data and functionality. Use contextual interviews and other methods to dig out more details and use cases from the users. This step takes 2-4 hours per iteration.

4. If the UI design is ready, meaning that you can not find any more use cases or mistakes, and that all the gathered use cases execute nicely (usually there a only a handful of use cases for any system), then you proceed into implementing the design. Otherwise, iterate to any of the previous steps, depending on what will give you the most value.

In total this requirements gathering and design phase will take a few iterations and a couple of weeks from a team of 1-2 user interface designers.

When the design of some part of the system has stabilized, so that you are quite sure that no radical changes will come to it, it's possible to start implementing that part (for example, first implement support for the most important use case). So there can be some interleaving of UI design and implementation.

The use of agile methods is preferrable, so that you get also early feedback from the parts that are implemented. The UI designers should work together with the programmers, so that the knowledge of how the system is designed will transfer accurately from the heads of the designers to the programmers and to the code. The UI designers do some testing to make sure that the implementation works as designed.