how do you deal with a vague software proposal?

Question

We all get them. What do you do when you are supposed to write a functional spec from a woolly proposal? You can write a ton of questions about the proposal but answers are not always forthcoming. Sometimes for political reasons you cannot make someone firm them up. How do you deal with a vague software proposal, when experience and intuition only go so far?

Answer 1

I do as much as I can with what is not vague (which in some cases has been nothing, if you don't include setting up the workspace and naming the project), and then send an email to supervisors say "I need to get details regarding requirements X, Y, and Z or I cannot proceed". If the supervisor says "do it anyway!" I then push them to explain what I should do, and ask for a time allocation to undo and correct when my code inevitably does not meet the late-given requirements. Even if the supervisor/team lead doesn't like this, it makes sure they know that progress is being blocked by lack of requirements.

If I am dealing directly with a client, I tell them very clearly what I need. If they can't get back to me with it right away, I tell them that work will start only after we both agree on the requirements. Again, this is not always popular, but it has saved significant amounts of wasted effort with clients who in some casese never got requirements back to me.

Answer 2

In addition to

• Focus on the things that -are- concrete and build around those
• Engage the proposal author (customer?) as much as possible as soon as possible
• Plan on lots of iterations as part of the development plan (pick your favorite iterative methodology...)
• Build in acceptance/review gates into the project (that is, if all else fails, you may need to propose -a- solution, which the customer must accept, or provide comments on why it isn't acceptable)
• Make sure the Project Manager has factored in lots of buffer time & money :-)

Also consider

• Jump to an architectural spec (based on existing products/technologies/whatever) - proposing and discussing something concrete can be helpful in pulling the more abstract functions/behaviors out of the customer
• Try to understand the problem from the customer's perspective and look at the problems they are trying to solve and see how other solutions solve similar issues (e.g. a proposal that says "Add security" can generally be expanded reasonably well based on an understanding of the problem domain (banking vs marketing web form)
• Build a prototype - it will either solve your "experience only goes so far" problem, or provide a talking point for the customer, or make it clear what can be achieved in the budget and what is impossible.
• Write to the "Negative space" in the Functional Spec... list out what the product will -not- do so you have some scope control. The pieces that you just can't do in the time/budget get listed as "out" and you then can negotiate/discuss/make a pass at the other areas that are easy to implement/change as the project progresses

I assumed that you are doing this as part of proposal writing and eventually the customer will be able to answer your questions, if not, seriously ask management if the risk is worth taking on the project/customer (who knows, maybe the customer just doesn't care?)

Answer 3

Be creative, work by example. Fill in some blanks yourself and try to present it to them early. Listen and (re)work your functional description/code with their feedback.

Develop by example. Bill by the hour.

Answer 4

You wouldn't expect someone to build an office building with vague requirements, why should someone expect you to build software with equally vague requirements.

Without concrete feature requirements, you are guaranteed to fail! Because you will never be able to meet what the customer has or doesn't have in their head as expectations.

Software development Agile Methodologies like SCRUM exist to force this very issue, you only work on what is the most important thing, if they can't tell you what is important from a business value stand point why should you know what to do?