There was a project the customer provided only very vague requirements for. They were also prone for an unexpected changes and the customer was absolutely reluctant to provide a write-up of them after multiple requests.
I wanted to ditch the project entirely, but the client persisted that the things would change for the better soon. The things were not changing for some time and I was unable to proceed with the actual work. When the client orders something I know is not a good idea, it is my moral duty to inform him and ask for the second confirmation, to prevent meaningless work, even if paid. I have explained the client the situation without written requirements is comparable to the following scenario:
Imagine you ask the architect to make plans for the house, with a twist that you tell the architect nothing about what the house should look like. This means you essentially ask the architect to make up the requirements. When the house is later finished, the following situation can arise: you look at the house and tell architect you did not want the pool to be in the basement, you wanted the pool to be on the roof, so you are refusing to pay.
This would be a really unfortunate scenario as both sides involved would be severely disappointed by the end result. This is the reason the requirements have to be very specific. The more specific in fact, the better. It is however a subtle skill to ask people for a very specific results to not be disappointed later. A skill not many people are good at or even aware of.
When you go dine outside and you do like your French onion soup with the slice of bread covered with butter on both sides or whatever specific requirements regarding the food you might have, you have to ask for it before the meal is prepared. The same applies for programming and development. The problem with the latter is however, that it is far more abstract. With food, one can even see photos or even with the naked eye what the result looks like. The taste can be judged from the visuals to some degree. With programming, apart from GUI, judging the properties beforehand is harder.
Staying with the client has paid off. The problem was not so much in the lack of abstract thinking. It turned out the client was simply overwhelmed with other tasks and really could not find anyone to delegate the task of writing the requirements to. He decided to hire me for the task to gather and write the requirements down for the project, so I can finally start working on it. Now the both sides are satisfied. I would be interested how this situation is handled elsewhere, because I was not used to not getting any kind of written requirements for the project before.
This is a 71th post of #100daystooffload.