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?

  • 1
    Do you have a specific issue with a proposal you need help with? In your question's current form, it's either off-topic (it's not an issue that requires a programmer's unique insight) or a chatty, open-ended question (which are not constructive).
    – user8
    Commented May 18, 2011 at 17:17
  • Sorry Mark but in my career, it has always been the role of the developer to write the functional spec. This makes it an issue for the developer as he needs to specify the implementation of the software within that document.
    – Phil Helix
    Commented May 18, 2011 at 17:20
  • Please update the question to be more specific. Please don't add a lot of comments. They're hard to read. Please make the question complete and consistent.
    – S.Lott
    Commented May 18, 2011 at 17:30
  • 2
    I got that. Your question right now is open-ended and vague, which invites open-ended and vague answers. We can only really help with specific, practical, and solvable problems you're actually facing. And it's still not clear how dealing with a vague software proposal is materially different from any other vague business proposal. To that end, there's an entire site on the Stack Exchange network, Project Management devoted to the topic.
    – user8
    Commented May 18, 2011 at 17:44
  • 2
    Sorry, I will fix the question when I get back. An unreliable 3G connection keeps causing timeouts and is making editing difficult.
    – Phil Helix
    Commented May 18, 2011 at 18:00

4 Answers 4


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.


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?


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?)


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.

  • I've done this and it worked exceptionally well for me (except for the hourly billing as the project was my employer's internal consumption).
    – Kramii
    Commented May 18, 2011 at 20:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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