It stroke me today at the train (on my way home) while I was reading a book named “Object Thinking” (by David West); I’m at chapter 7 which is talking about discovering the client domain, i.e what does he(the client) expect from the application. In short, although it’s hard(especially if you’re a technical person in your nature), you must understand the client’s requirements without casting it to your world “I’ll implement it with web-service” or “This is a classic multi-threading application”; You’re job in this initiatory step is just to analyze the client’s needs and trying to depict his world in simple “objects” world; What are my primary entities (for example: “Employee”, “Employer”, “Agreement” etc), what are the relationships between them and how the client expect to “activate” those entities (screens functionality).
I remembered my meeting with our last client and reading this stuff made me think about how well (?) did I managed to handle this task. While the client was depicting his world to me I was trying to understand and write his requirements and his special needs from the application. I’ve noticed that writing down the client’s needs\remarks\requests sometimes stopped the conversation flow, caused needless repetition over the question & answers and sometimes even got me out of focus.
So, maybe tape-recording the entire meeting(well, the important stuff anyhow), concentrating on asking the right question and analyzing the answers later can create a better characterization ? better understanding of the client’s domain ? shorter and more thorough meetings ?
It seems like a good idea, I think I’ll give it a try on my next meeting.
What do you think?
Another huge benefit from this – use it as an evidence later ..
"Now .. here is the conversation – Do you hear yourself telling me that you want the data to be saved to the DB from inside an Excel application ??????"
(Thanks God – it’s not a project I’m involved in .. but I understood that we have a client that expected the web application that was developed for him to open excel file – there he can make some changes – and then the data will be saved from the Excel to the DB , instead of doing it from a normal web page , and it’s only because he’s used to work with Excel . It’s not impossible of course .. but … )
Anyhow – I think it has many things to do with the situation you described with the "2-weeks" application . I’m so familiar with this .
I see people that write characterizations – there are those that are very strict with it .
(means : what we agreed on in the characterization is what the client gets )
Others tend to please the client , and change the characterization every day – as the client suddenly realize that he actually want X to work in a little ( or much ) different way .
(Even if the code was already written and tested , and I’m not talking about minor things like adding a field here and there )
I guess in many cases what actually matters is the importance ( aka:money ) of the client.
Since I see the same people that for one client – turn all his "new wishes" – to "add-ons" ( aka : more money ) and for other client they just change an existing characterization (aka:it’s ok .. Alex will just throw that piece of …code away and will write a new one) .. everything to please him .
Now.. I don’t complain ( though it sounds like that ) about this .
Sure it’s less fun to rewrite something that you’ve worked on, but still it’s a work.
I also understand the reasons for this , but I just want to hear what others have to say about this ,
and how these things work at your place .
(Oren – I think that this comment will actually fit more in that "2-weeks app" ..
but I’ve decided to write it here somehow )
Recoding your customer is an option you should have in your arsenal or toolset. It is definitely worth using in some circumstances and might prove a hinder in others (e.g. it may make the customers less spontaneous and she will try to come up with a "right" answer which may not be the real answer).
I have to say that in most cases where I was involved in requirements elicitation we had a mix of the following situations:
• Customer on-site – a customer or her representative was present during most of the development (at least the early iterations) and was able to clarify requirements as we go.
• Technical Writers – One of our team members in customer meetings was a technical writer whose job was to take down the minutes of meeting. This means that the analysts/architects etc. were free to concentrate on the discussion. Furthermore, on the next meeting with the customer the minutes ware read out so that the customer comment on anything that doesn’t match her original intentions.
• Written specifications – The customer produced some formal or semi-formal document with her requirements (e.g. RFP) – what follows next is series of meeting where we go over written comments on the documents and fine-tune it until it is agreed by both sides
Also regarding your comment "you must understand the client’s requirements without casting it to your world" you can you may find interesting the concept of PDOM (Problem Domain Object Model) (you can read a little about it in my use case paper (step 3): http://www.rgoarchitects.com/blog/content/binary/uc.pdf