views:

67

answers:

2

Apologies for very general question. I repeatedly find that establishing user requirements is one of the hardest parts of my job. This is for several reasons, for example, lack of shared technical vocabulary, incomplete understanding of domain on my part, inability of user to 'imagine' completed UI / product, etc etc.

Since this appears to be an ongoing challenge for me, has anyone here had a 'eureka' moment that has really helped them with this part of developing? For example, I have heard of the book 'Domain Driven Design', but not read it yet. Has anyone found a book, online resource of piece of advice that has really turned things around for them?

Thanks - woolly question, but a very important one for me.

David

A: 

I won't aspire for eureka experience, however, if you are interested in DDD, which is about establishing common language for you and the users (among other things), than if you don't have access to the book, look for the Domain-Driven Design Quickly on DZone. Generally speaking, any time user cannot imagine the thing and therefore state proper requirements, go for the prototyping (if you can). Recently I was pleased by really super simple tool which is a Firefox extension called Pencil, which enables easy and quite fast prototyping even for non-programmers. It is far from perfect, but it enables you to create own components and it is extensible.

Gabriel Ščerbák
It's not that I haven't got access to the book; it's more that it's some way along in my reading list :)I will definitely check out that extension. Thanks!
David
A: 

Are you creating the user requirements on your own or are you actually interacting with the user to generate the requirements?

If you are creating a piece of software without a customer then starting with a simple high-level mock-up of what I want to create is where I will usually start and will formulate my User Requirements how I think a user would use the software.

If you have a customer I would suggest breaking the software into smaller modules (manageable chunks) and sitting down with the user to talk to them, step-by-step, how they want the module to function.

Seth M.
I'm working with the users. The main problem I find is that when the stuff gets delivered, apparently it seems the user hadn't envisioned it as I thought I had described it.I will look at modularisation. Thanks!
David