0

I've always worked under an IT manager, so I don't know how to interact with end users. I have a problem now, because someone has asked me to develop a program.

My situation:

  1. He has limited time to discuss requirements.
  2. He is not an IT person.

How do I collect the requirements I need about the program that I want to build? What approach (questionnaire, interview, observation) I should take?

|improve this question|||||
2

First get information what ever that person(client) has. Then you think technically and after a day or two call back to that person to confirm that this is what you wanted?. By this way you will be able to get full requirements.

Without understand 100% requirement there is no mean to develop things. If client do not have time at once then you take initiative to expand actual requirements from their short note. Once you start counter questions politely , you will get whole requirements easily.

Better you ask them for reference website or something that can help you. I have worked with many client who give just one line requirement like I want my website like X website.

|improve this answer|||||
  • from "this is what you wanted?" your suggestion is to make the prototype first then ask the detail requirement later?, what prototype you would suggest?a mockup?or a simple version of the app? – stacheldraht27 Dec 10 '15 at 1:12
  • I mean first ask for requirement what ever client have. Then check in which format he/she gives you requirement. May be in mockup, as document, as image etc. After this you can ask like Do you have mockup? OR Do you have prototype? – Helping Hands Dec 10 '15 at 4:10
0

Helping Hands' answer is a good starting point, especially asking for a reference. Let your client outline the main features in written form - and don't bother them with technical stuff.

Managers typically don't care how anything is done as long as the result is working, and good looking; depending on the kind of work, a mock-up can be very useful to be sure you're heading in the right direction.

In a nutshell, concentrate on the final results, and not the way towards them.

|improve this answer|||||
  • "let him outpoint the main features in written form" <- a lay user will not know how to write a requirements document. The OP will have to play the role of a business analyst, and work with the end user to capture these things. – Xavier J Dec 8 '15 at 17:26
  • Yes, you're right, working with the clients to clarify things would be the best way and formal requirenments documents would be great too. But if that "Not IT Person" customer doesn't have the time to discuss and at least for smaller projects, I'd still suggest to just get some informal goals, like "App for Android that tracks data from system xy" or "db front-/backend for data in that excel sheet" or whatever. – Tutonaut Dec 8 '15 at 21:27
  • sorry, couldn't complete that comment, damn it ... so here's the rest: ... The point is the lack of time, for sure it's far away from a perfect approach. And are programmers the best to interact with customers and to "guess" what a Enduser wants to see? Well ... But that is a typical freelancer problem, to do marketing and it-stuff. – Tutonaut Dec 8 '15 at 21:35
0

Be aware that non IT people are unable to formulate their needs in the precise terms that you need (not that they lack the skills, but they aren't used to that). One option is to formalize for them after an interview and submit them your written requirements document, written in "easy" terms.

But I believe that a much better approach is to let them play early with a preview/prototype and get feedback.

Also notice that a contractor with "limited time" will get "little satisfaction".

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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