Hi Mesh,

Good questions!  I am not very prescriptive when it comes to documentation - I think you need to determine what a) works for you and b) works for the people you interact with.  So I would ask myself the following questions:

• What written documentation do I need to provide to my customer so that they can both understand:
  • How the system will support the business process(es) that the customer has
  • How the system interacts with people and other systems in those processes
  • What the system is expected to do
  • What considerations, limitations, etc. there are on the system
• What written documentation do I need so that developers can actual create the solution that the customer expects based on the above?

Sometimes the documentation to accomplish these tasks can be the same, other times it needs to be different.  When it's different it needs to be clearly documented how the documents translate to one another.

I find that most customers do not understand a lot of the fancy diagrams and verbiage that we put in front of them, so Iusually  use simple yet effective diagrams and documentation (i.e. not use cases, state charts, DFDs, etc.).  Surprisingly my developers usually also like this documentation since it doesn't use artifacts that may misrepresent what the client really wants.  I'll rant on that another day...

Anyway, I would come up with a brief template/snippet of your total documentation and show it to the client to make sure they understand the information.  If they are comfortable with the presentation of the information then go to your developers and do the same.  If both can use the same set of documentation then you're good to go.  If the developers require additional information or a different format, then come up with a way that you'll be able to translate the details and also trace the translation.

Hi Mesh,

Just to clarify - the client is both the end business user as well as the development team that will implement the solution?

If so, I would recommend sitting down with the development group and ask them what they're looking for.  The artifacts that you described before sound reasonable for a development group.  Just don't forget to ensure that the business side of the client also understands what will be built before moving ahead with development.