Use Case Diagrams FAQ

Requirements describe external view of a system, system's externally observable characteristics (phenotype). Older approach to requirements is to describe what a system should do without specifying how it does it.

There are different methods of requirements elicitation. To collect requirements:

• recognize the problem being experienced, or
• determine the opportunities to better serve customers,
• ascertain external system behavior that could address those problems or opportunities,
• document the list of the problems, opportunities, and desired behaviors as requirements.

Some types of requirements are:

• Functional requirements - what the system should do.
• Quality (or non-functional) requirements - how fast, reliable, secure system should be.
• Data requirements - what data should be stored by system.

Functional requirements describe what the system should do in terms of system's input, system's behavior in response to that input, and output back to the user of the system. Generally, functional requirements are expressed in the form "The system shall <do> <requirement>", for example, "The system shall accept guest check-in request and allocate a room."

Functional requirements could be collected and documented using different approaches, techniques, tools, and templates. Use cases were created by Ivar Jacobson in 1986 to support visual modeling of functional requirements. Use cases became one of the most widely used approaches for capturing functional requirements for object-oriented systems as part of UML and Rational Unified Process (RUP). It is now a common practice to express functional requirements as use cases, described in both graphical and narrative form.

Use case diagram is UML diagram which shows some business or software system, its external users (called actors), and a set of actions (called use cases) that users of the system should or can perform while using the system. Use case diagrams are used to describe functionality of a system from the point of view of external users.

Each use case describes a unit of complete and useful functionality that business or system provides to its users, how external user interacts with a system to achieve a desired result. Some examples of use cases: Hire employee, Buy ticket, Place order, Deposit funds.

Actor represents some group (called "role") of external customers or users of the business or software system. Actors have some needs and require specific services from the system. Some examples of actors are: Customer, Student, and Passenger. Actor could be not just human but also another system, business, or device.

Use case diagram shows business or system, its external users, and use cases applicable to the system. Use case represents one specific goal or need of the user from the system.