Use cases are an alternative technique used to document requirements. (In fact, they can be used for other purposes as well, but gathering requirements is the focus here.) Use cases assume that you have a system and you have people that interact with that system. In some literature, the people interacting are referred to as "actors." Use cases describe scenarios, or stories, where the actors interact with the system in certain ways to achieve a desired result. The thought is that if you describe all of the ways that people interact with a system, including the expected results of the interaction; you will end up with a complete set of functional requirements. Use cases are especially popular with newer "light" (agile) development processes.

Since use cases describe interactions, they are especially good at describing functional (process) requirements. They are not as effective for feature-type requirements such as look-and-feel, performance, security needs, etc. For instance, you cannot utilize use cases to describe the layout of a web screen. 

Basically the use cases are written in a format like, "A user (actor) does an action and something happens.” For instance, let's look at an example of a class registration system. The following would be examples of use cases.

• “A student meets with his or her counselor. Together they go over a list of all classes and options. When they agree on a class, the student can register online.”
  
• “Some classes are only for honors students. These must be marked as such, and only students who are designated as being in the honors college can register for them.”
  
• “After a student has registered for his or her initial classes, he/she has the option of changing his/her mind. He or she can just log back onto the registration system with his/her university id and password to add, change and delete classes.”

The use cases themselves can be described and documented just like more traditional requirements. They can be documented on spreadsheets, on text documents or in software tools. In some light methodologies, the preferred technique is simply to write use cases on an index card - one use case per card. However, the information associated with use cases can be more formal and structured. For instance, for each use case, you could include:

• A summary title that reflects the requirement scenario.
  
• Any preconditions that must exist. In other words, other use cases that must be in place first.
  
• Exceptions that may occur during the execution of a use case scenario, as well as the expected outcome of the exception.
  
• Any triggers that cause the use case to execute.
  
• Additional information such as frequency, who might execute the use case, other stakeholders involved, etc.

Generally use cases are a great way to gain agreement with your clients on how a process or system works. The use case can be given to a designer or developer. At that time, the developer may well need to go back to the customer for the additional detailed requirements necessary to resolve the nitty-gritty implementation details. However, these details are not needed up-front when the solution is being conceptualized.