One of the most difficult and critical part of a project is to get good requirements from your client (internal or otherwise).

I understand by 'good requirement' one that is not so high-level that's barely tangible to the system, and not so low-level that it'll constraint the system creation with really needing it (it happens when your client has some knowledge in programming).

So, firstly how to guide you client into giving precise information that will help you at specification/implementation?

And finally, how one can tell at Requirement gathering if you have a mature enough requirement?


1 Answer 1


You don't, because gathering requirements is not the job of the customer.

It's up to you to figure out what the customer needs and to translate it into a formal spec. The usual problem is that you often don't know the business domain quite well to determine the actual needs, while your customer doesn't know what is technically doable, and what is not.

This is why requirements gathering should rely on regular communication between you and your customer, which makes it possible for you to understand better the actual needs.

In order to help the customer to realize what answers her needs better technically, prototypes (and mockups) are usually used.

Not the answer you're looking for? Browse other questions tagged or ask your own question.