It sounds like you are tasked with process improvement before going into automation.     The UML does not specify any process improvement techniques.    I highly suggest data flow diagrams, espcially if the need is to come up with a comprehensive, integrated whole.  Use data flow diagrams to simplify and integrate.  

To spec for automation, many suggest the UML (use cases and, sometimes activity diagrams, for functional modeling).     But, it has always been my experience that, for larger scale efforts,  the UML techniques fail because they are based on the use of a forced, artificial partitioning and they lack a lithmus test of completedness.  I use a modified version of data flow diagrams for systems design diagrams.  One that substitues, for example, transaction type flows for logical business data flows, and allows for flow of control.

Tony

I'm not sure what "Functional Spec" means in your organization but it sounds like you have a real problem: you have an artifact (the Functional Spec) which is not good enough for either the client or the developer.

What I would suggest is that, if documentation is important to your organization, you split the documentation into two types:

• artifacts to be consumed by the stakeholders/clients, and
• artifacts to be consumed by the development/technical team.

Now these can be separate documents or separate sections in the same document.  Please note that I am not advocating that the dev team cannot read the stakeholder artifacts or that the stakeholders can't review the functional specs.  I'm just saying that you might consider having artifacts tailored for a particular audience.  It's sort of like having to give a speech about the scope of the project to the stakeholder and to the developers.  I bet that while the two messages may be similar and have many things in common, they would also be very different as to what is said, how it is said, and how much is said.

Of course, before you make a decision as to what type of artifacts to use you need to also identify the "why" of creating the artifact.  Why do you need the artifacts?

For example, your organization's process might require that a client sign-off is received on the requirements before proceeding with the functional design.  Or maybe the development team is not close to the client and BA and need to have clear functional specs.  Identifying the "why" is very important or else you won't know the reason behind why you are doing what you're doing.

So without knowing much about your project's needs, processes, or structure, here are some options. Note that in most cases you won't need all of them so look them up and decide what will work for you.

Artifacts for consumption by the clients/stakeholders:

• Business Case
• Vision Document
• Project Charter
• Business Requirements Document
• Business Use Case Model
• Business Use Case Briefs
• User Stories
• etc.

Artifacts for consumption by the development team:

• System Use Case Model
• Detailed Use Case Specifications
• Functional Specification Document
• Data Model
• Data Flow Diagrams
• etc.

- Adrian