Use Cases2018-05-14T05:59:32+00:00

Software Use Cases

A software use case defines how an actor will interact with software to achieve a goal.

A use case is a sequence of actions that provide a measurable value to an actor. Another way to look at it is a use case describes a way in which a real-world actor interacts with the system. In a system use case you include high-level implementation decisions. System use cases can be written in both an informal manner and a formal manner. Techniques for identifying use cases are discussed as well as how to remain agile when writing use cases.

Informal System Use Cases
Let’s start by considering the types of use cases that you’ll write as part of your initial requirements modeling efforts during “the Inception phase” of your projects. These use cases will either be essential use cases or “informal” system use cases, a detailed example of which is presented in Figure I-1. As you can see the steps are written in very brief, bullet/point-form style. They contain just enough information to get the idea across and no more. Note that this version takes technology issues into account, for example the text “Student inputs her name and address” implies some sort of information system. The reference to the system also implies the same.

Figure I-1. Enroll in seminar as an informal system use case (automated solution).

Name: Enroll in Seminar

Identifier: UC 17

Basic Course of Action:

  • Student inputs her name and student number
  • System verifies the student is eligible to enroll in seminars. If not eligible then the student is informed and use case ends.
  • System displays list of available seminars.
  • Student chooses a seminar or decides not to enroll at all.
  • System validates the student is eligible to enroll in the chosen seminar. If not eligible, the student is asked to choose another.
  • System validates the seminar fits into the student’s schedule.
  • System calculates and displays fees
  • Student verifies the cost and either indicates she wants to enroll or not.
  • System enrolls the student in the seminar and bills them for it.
  • The system prints enrollment receipt.

Figure I-2 presents an alternate version, this time as a manual process involving a registrar (a person) instead of an automated system. Choosing a manual process over a software-based one is still a technical architecture decision, in this case a low-tech architectural decision. The differences between the two versions illuminates how system use cases are not analysis and arguably even design artifacts, not requirements artifacts.

Figure I-2. Enroll in Seminar as an informal use case (manual solution).

Name: Enroll in Seminar

Identifier: UC 17

Basic Course of Action:

  • Student provides her name and student number on the enrollment form.
  • Registrar verifies the student is eligible to enroll in seminars. If not eligible then the student is informed and use case ends.
  • Registrar asks the student which seminar they’d like to enroll in. If they don’t know, the registrar provides the student with course catalog if required.
  • Student chooses a seminar or decides not to enroll at all.
  • Registrar checks the student record to see if student has previously passed prerequisite courses. If not eligible the student is asked to choose another.
  • Registrar validates the seminar fits into the student’s schedule.
  • Registrar calculates fees
  • Student verifies the cost and either indicates she wants to enroll or not.
  • Registrar enrolls the student in the seminar and bills them for it.
  • The Registrar writes a payment receipt.

Figure I-3 provides yet another alternate form, in this case as a very high-level use case written on an index card. Very Agile teams start with this level of detail, captured during their initial high-level requirements modeling efforts.

Figure I-3. Enroll in seminar as a very high-level use case.

Enroll in Seminar

  • Student chooses a seminar to enroll in
  • System checks that the student can enroll in the seminar
  • System calculates fees
  • Student pays fees and is enrolled