Working with many organizations, I've discovered that there are always a few people who are afraid of use cases.  This is mostly because they have never had training on how to build one.  Below are some guidelines that I use to coach these folks in writing use cases.

First of all, what is a Use Case?  A use case describes a system's behavior as it responds to a request from a stakeholder under various conditions.  Your stakeholders will provide input, validation, and final approval of the use cases.  Use cases add value because the stakeholders get to see the exact behavior of the system.  More importantly, use cases contain goals that the system will support, hence clarify the scope of the system.  It becomes an efficient way to communicate the system under definition between the various stakeholders.  Another value that use cases add is coming up with of all the things that could go wrong and documenting how the system should behave to the failures.  Without these alternate flows, error conditions go undetected until it is time to program the system.  What usually happens is that the programmer will write whatever they think is logical (with the best of intentions), but will probably result in failure during the use of the system.   As the saying goes, the path to hell is paved with good intentions.

Not all use cases look alike.  Business process people write business use cases to describe the operation of their business, while the design teams write system use cases to break down the requirements to small subsystems.  A business use case is written to show what the processes do to achieve their business goals.  A system use case is written to specify the function or the service that the system provides to a stakeholder. Always remember that system use cases are black-box use cases that do not describe the guts of the system.  This forces you to focus on what the system must do versus how it is to be done.  Leave the "how" to the hardware and software development teams.

Use cases are requirements that describe the behavior of the system, but they do not all constitute of the requirements.  I would say a quarter of your requirements are use cases, and do not represent other requirements such as external interfaces, data, business rules, quality of service, glossary, implementation, technical, integration, performance, etc.  However, use cases should connect many of the other requirements through traceability.  Think of use cases as the framework that links information in different requirements.

If a quarter of my requirements are use cases, then how much time should one spend on them, considering you have other requirements to define.  I always follow the simple "accuracy to precision" model.  What do I mean by that?  Here is an example that I learned from one of my software engineering professors that shows how accuracy and precision are not the same.  If I tell you that π = 9.141593, then my number is precise, but not accurate.  But if I tell you that π is around 3, then I am accurate, but not very precise.  Using the above analogy for each of my use cases, I begin with 3 and then I delve into the .141xxx as time and project permits.  I start by stating the primary actor and then list all the secondary actors, and each of their goals the system will support.  I also write a short description of the use case describing the interaction with the primary actor.  Validate this with your stakeholders for accuracy and completeness.  It is surprising how many use cases are already wrong because they weren't accurate or how many were missed because not all of the stakeholder's goals were included.  After the initial validation, you can prioritize and assign these use cases to individuals and releases.  For the use cases that are selected to be written, they need to precisely describe the main success scenario/basic flow.  Review and validate these basic flows with your stakeholders to make sure that the system is behaving in the interests of the stakeholders and meeting their goals.  Once you know your basic flows meet your stakeholder's needs, then you can start listing all the failure conditions and alternate flows.  Verify this with your stakeholders to make sure your list is accurate and you haven't missed any important what-if scenarios.  This will also help you prioritize the failure conditions and alternate flows that you want to add detail.  This is very tedious work, but I often find missing requirements or goals that were not initially given to me by the stakeholders.  I know your time is limited, so working in the above flow will help you manage your accuracy and precision level.

There is no standard template for documenting use cases.  I find the below core parts of a use case to be utilized (more or less) by organizations:

Use case name 

Level:  Business or System

Goal:  You MUST have a goal.  The goal should be a description or a list of what the primary actor will achieve within this use case.

Scope:  You can describe the service or the part of the system that will be defined by the use case.

Summary/Overview: A short description of the use case interacting with the primary actor.

Actors:  An actor can be a person/role, organization, computer system, data, etc. - anything acting on the system.

• Stakeholders:  They are 100% interested in the behavior of the use case.  They may or may not interact in the use case, but the outcome of the use case affects them.
• Primary Actor - This is a stakeholder that acts on the system to achieve a goal.
• Secondary Actors - These are stakeholders that are acted upon by the system.  In other words, these actors provide a service to the system so that the primary actor can achieve its goal.

Triggers:  This describe the event(s) that causes the use case to get started

Preconditions: This describes all the conditions that are true before the use case starts.

Postconditions: This describes the change(s) in state of the system after the use case completes, positively and negatively.

Basic flow/ Main Success Scenario: This is the top down description of the typical set of actions in which the goal(s) is delivered.  Any one step can describe an interaction between the primary actor and the system, between system and secondary actors, or a validation step to protect a goal of the actor.  Each step should use simple grammar that clearly shows the Actor - Verb - direct object structure, and it should move the process forward in the use case.  Finally, I find Miller's Law (7 +/- 2) to be a good heuristic to use to determine how many steps should be in a use case.  Use cases with more than 10 steps in the basic flow can get cumbersome for review because some of these steps will have alternative/error flows that have to be validated in context of the basic flow.  I find the most common mistake in use case writing is leaving out the subject of the action step.  Here are a couple of examples of poorly written use cases using one of my favorite examples, the ATM.

Use Case mistake - not showing system action - This use case shows everything the actor does, but does not show the system's reaction.

1. Customer enters card and PIN
2. Customer selects "Withdrawal" and amount
3. Customer takes card, cash, and receipt
4. Customer leaves

The system should always respond to an actor's action. Ever present in a use case is the cause and effect relationship between the actor and system.

Use Case mistake - not showing the actor - This use case is written from the system's perspective and does not show the actor's behavior.

1. Reads ATM and PIN
2. Sets transaction type as "Withdrawal" and amount
3. Delivers card, cash, and receipt
4. Logs the transaction

Use Case fix - This use case names all the actors and their actions.

1. Customer enters card and PIN
2. System validates card and PIN against the main banking system and displays main screen
3. Customer selects "Withdrawal" and amount
4. System updates the account with the amount and logs the transaction as a "Withdrawal"

5. System delivers card, cash, receipt, and resets.

Alternative flows/Extensions/Exceptions/Errors: These are all the other flows.  It starts with a condition/trigger and a goal for the alternative flow.  It contains a sequence of action steps describing what happens for that condition/trigger.  It ends with the success or failure of the extension goal.  An alternate flow can end in several ways: a successful end; a total failure; ending goes back to a previous step in the basic flow (looping); or ending remerges somewhere in the next steps of the basic flow (fan-out/fan-in).

You can apply use cases on almost any project that requires you to define the behavior of a system.  The standard template to write the use case is selected according to each project's needs.  Projects that are short or quick will need less detail versus projects that are detailed, expensive, or distributed.  Finally, a central repository will allow you to define, validate and manage the use cases and all the other linked requirements in context of each other.