A use case document takes a related set of requirements and structures them for purposes of prioritization. It states the case for a particular way that the intended application is to be used. Use-cases have actors, dependencies, and parts.

• An actor is to a use-case what a design persona is to a requirement.
• There are two types of dependencies that use-cases can have on each other; extends and includes.
  • One use-case extends another if it provides additional specifications.
  • You can factor out duplicitous specifications into a single use-case that can be included by other use-cases.
• There are many parts to a use-case.
  • Pre conditions state what needs to have already occured before this use-case goes into affect.
  • Post conditions state what will be true once this use-case has completed.
  • A normal course describes a typical step in this use-case.
  • An alternative course describes an unusual, but legitimate, step in this use-case.
  • An exception is an error condition in the use-case and how to handle it.
  • Each business rule states a piece of functionality required by the business. A good example of this would be any kind of accounting validation.

Use case parts are grouped by type and ordered by sequence within each type. Use-cases also come with a lot of standard features.

You may have noticed some really weird and terse fields in the use case (e.g. det and ret) and use cast part (e.g. ei, eif, eo, eq, and ilf) screens. These fields are associated with Function Point Analysis. One of the most important facts that key decision makers will want to know before approving or rejecting any use-case is how long will it take to implement. Typically, the developer and/or software architect is tasked to answer that question. The disadvantage of that approach is that you have very highly trained and paid professionals spending lots of time estimating use-cases that might get voted down instead of developing applications. FPA is used by the analyst to come up with an estimate as to complexity which, when combined with statistically oriented performance data of the assigned developer, can arrive with an estimate as to how long it takes to implement a particular use-case. The disadvantage to this approach is that your analysts have to learn FPA which is very complex and abstract. If you don't want to use FPA, then just ignore these fields.

• det are the data element types. This is a count of all database columns affected or used by this screen.
• ei are the external inputs of a screen. Think of this as a count of all editable input fields on a form.
• eif are the external interface files. This is a count of all sets of data that this screen relies on that are maintained by a separate application.
• eo are the external outputs from a screen. Think of this as a count of all pieces of data on a screen that come from the database, editable or not.
• eq are the external inquiries of a screen. Basically, this is a count of all parameters on which a screen depends. For search screens, that would be a count of all search criteria.
• ilf are the internal logic files. This is FPA speak for a count of all tables in the database affected or used by this screen.
• ret are the record element types. This is a count of all database tables affected or used by this screen.