Purpose and Scope of Use Case Model

The purpose of the use case model is to define how the users need to interact with the system. This definition includes two key elements: actors and use cases.
The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example login to system, register with system and create order are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behaviour. Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.

A Use Case description will generally include:

1. General comments and notes describing the use case;
2. Requirements: Things that the use case must allow the user to do, such as <ability to update order>, <ability to modify order> & etc.
3. Constraints: Rules about what can and can't be done. Includes
   • pre-conditions that must be true before the use case is run -e.g. <create order> must precede <modify order>;
   • post-conditions that must be true once the use case is run e.g. <order is modified and consistent>;
   • invariants: these are always true - e.g. an order must always have a customer number
4. Scenarios: Sequential descriptions of the steps taken to carry out the use case. May include multiple scenarios, to cater for exceptional circumstances and alternate processing paths;
5. Scenario diagrams: Sequence diagrams to depict the workflow - similar to (4) but graphically portrayed.
6. Additional attributes such as implementation phase, version number, complexity rating, stereotype and status

1. Actors: Actors reflect the roles that users play in relation to the system. Users may be people, other systems, or even devices. Anything or anyone that will eventually interact with the system is considered a user. One user may play many roles, and many users may play the same role, that is, perform the same duties. For example, many people on a project play the role of programmer. But the same people in relation to the payroll system play the role of employee. Do not automatically equate actors (roles) to job titles. Job descriptions change like the weather, and for reasons other than good system design. In fact, careful attention to good actor definition provides strong justification for redefining job descriptions to improve cohesion and coupling in the work environment as well as in the systems.
2. Use cases: A use case is a goal that the system must achieve to be considered successful. For example, an automated teller system must validate access, deposit funds, and withdraw funds. A use case can usually be expressed as a noun and a verb; for example, deposit (verb) funds (noun). The kinds of funds and how the deposit is implemented will be taken care of later. Be careful not to equate goals with processes. There are many possible processes to achieve a goal. Processes tend to describe implementation alternatives instead of the goal that the processes must achieve.

You will hear me say over and over again that it is absolutely critical that you keep the scope of each task foremost in your mind.
The scope of the use case model is to define how the users will interact with the system. Do not try to anticipate screen designs, system behavior, programming languages, or anything else that has to do with software. After all, if you do not first know what the system is supposed to do, then what is your basis for choosing between the implementation options?
There is a time and a place in the methodology for all the decisions required to develop a complete solution. Tackle one problem at a time, at the right time. Allow the products of one step to become a resource for subsequent steps. Following this approach supports the development of a repeatable and measurable process, key ingredients of a fully mature development methodology.

• Use Case Model:
  The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example login to system, register with system and create order are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behaviour. Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.
  Watch the scope of your use case models.
  Question:
  1. How detailed should the use cases be?
  2. Should you include (for example) saving data, error handling, screens, and forms?
  
  The answer is in the concept of encapsulation. The use case model describes an encapsulated view of the system; that is, it describes only the purpose and the interfaces of the system. The internal design should be completely hidden. Encapsulation hides the implementations of input/output (I/O) mechanisms. So when you define input and output, focus purely on content and ignore the form completely. The same I/O can be supported through a number of equally valid implementations.