Hi:

Here the way it is supposed to go.  (How it is twisted around in any given organization is another story.)

Use Case:  Gives the what, but not the what accomplished internally within the system that does not interface with an Actor.  Also, fails to capture the essential interrelationships between the whats (ie the data flows), so alot of the whats are often missed.

Functional Spec:  Gives the whats.  It is not supposed to give the hows.  Use Cases, Data Flow Diagrams, etc., can be, in a more Agile environment, the functional specs, with the details being handled in conversations between developers. 

The design document  gives the how part.

Tony

Craig,

It may help to think of functional specs, use cases, and other artifacts as tools - the decision of which tool to use may be influenced by a number of different factors such as:

• How familiar are project team members with each type of documentation (this includes business team participants, as well as developers, BA's, testers, etc.)?  There is nothing to say that you can't introduce a new type or format for documentation - but if you do, then you may need to consider additional time in the project schedule, potential training sessions or material, etc.
• What is the scope and volume of the requirements to be documented?  A 250-page functional spec may not be as useful as 25 10-page use cases...
• What standards, templates, or models / examples exist within your organization?  Use cases are a UML artifact, so if you are following that methodology then you would want to utilize that standard artifact.  However, you can still choose to create use cases even if you are not using UML.  But it's generally valuable to leverage any existing resources available to you - so it never hurts to see if there is a good format that has previously been used in your organization.
• Who is reviewing and/or approving your requirements documentation?  If you have different reviewers and/or approvers for different sub-sets of your requirements, then a single functional spec might not work as well.  You might still choose a functional spec format, but split it into different documents for each functional area.
• Are you utilizing an iterative / agile methodology, with multiple cycles for building and testing the system?  If so, it could be very difficult to manage the requirements that are being delivered in each cycle within a single functional spec.

Just a follow-up to the reply from Tony as well.  Any requirements artifact - whether use case, functional spec, process model, etc. - has a specific purpose and meaning.  Use cases are not intended to document information flows, so they're not really 'missing' what they are not intended to accomplish.  Whichever format you choose for your requirements, you may want to consider what other supporting documentation might be needed for a given project.  Check out the 'Articles' section of Modern Analyst - there are some good articles on decision models as a way to elicit and document business rules, and context diagrams as a way to illustrate information flows at the system level.  Also don't forget about non-functional requirements - these are often documented separately in a non-functional spec or a supplementary requirements specification.

Good luck!

Sandy