Definition: Are Use Cases Functional Requirements? UML

Use cases are requirements, primarily functional or behavioral requirements that indicate what the system will do. In terms of the FURPS+ requirements types, they emphasize the "F" (functional or behavioral), but can also be used for other types, especially when those other types strongly relate to a use case. In the UP - and many modern methods - use cases are the central mechanism that is recommended for their discovery and definition.

A related viewpoint is that a use case defines a contract of how a system will behave [Cockburn Ol].

To be clear: Use cases are indeed requirements (although not all requirements). Some think of requirements only as "the system shall do..." function or feature lists. Not so, and a key idea of use cases is to (usually) reduce the importance or use of detailed old - style feature lists and rather write use cases for the functional requirements. More on this point in a later section.

Definition: What are Three Kinds of Actors?

An actor is anything with behavior, including the system under discussion (SuD) itself when it calls upon the services of other systems. Primary and supporting actors will appear in the action steps of the use case text. Actors are roles played not only by people, but by organizations, software, and machines. There are three kinds of external actors in relation to the SuD:

  • Primary actor :- has user goals fulfilled through using services of the SuD. For example, the cashier.
    • Why identify? To find user goals, which drive the use cases.
  • Supporting actor :- provides a service (for example, information) to the SuD. The automated payment authorization service is an example. Often a computer system, but could be an organization or person.
    • Why identify? To clarify external interfaces and protocols.
  • Offstage actor :- has an interest in the behavior of the use case, but is not primary or supporting; for example, a government tax agency.
    • Why identify? To ensure that all necessary interests are identified and satisfied. Offstage actor interests are sometimes subtle or easy to miss unless these actors are explicitly named.

Notation: What are Three Common Use Case Formats?

Use cases can be written in different formats and levels of formality:

  • brief :- Terse one - paragraph summary, usually of the main success scenario. The prior Process Sale example was brief.
    • When? During early requirements analysis, to get a quick sense of subject and scope. May take only a few minutes to create.
  • casual :- Informal paragraph format. Multiple paragraphs that cover various scenarios. The prior Handle Returns example was casual.
    • When? As above.
  • fully dressed :- All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.
    • When? After many use cases have been identified and written in a brief format, then during the first requirements workshop a few (such as 10%) of the architecturally significant and high - value use cases arc written in detail.

The following example is a fully dressed case for our NextGen case study.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

UML Topics