SE311 · Annotated SlidesChapter 5.6 — Use-Case Detailed Specification
Chapter 5.6 · Annotated slides

Use-Case Detailed Specification

Two templates (styles) for writing a detailed use-case specification: ID, actors, description, preconditions, postconditions, normal flow, alternative flows and exceptions.

Slide text Study notes Highlight: key words Tips, tricks & traps Seen again elsewhere How it can come up
Slide 1: PSU: Use-case Detailed Specification — Style 1
Exam weight High
  1. Fields: ID and name, primary/secondary actors, description, trigger, preconditions, postconditions, normal flow, alternative flows, exceptions, priority, business rules.
🎯 How this can come up · 2 questions
MCQ

A condition that must be true BEFORE a use case starts is a:

MCQ

An error path such as "card declined" belongs in the:

Slide 2: PSU: Use-case Detailed Specification — Style 1 (cont'd)
Exam weight Low
    Slide 3: PSU: Use-case Detailed Specification — Style 1 (cont'd)
    Exam weight Low
      Slide 4: PSU: Use-case Detailed Specification — Style 2
      Exam weight Low
      1. Style 2 writes the flows as numbered actor-action / system-response pairs.

      PSU: Use-case Detailed Specification—Style 2 (cont'd)

      Subflows S1: Create Schedule {Begin Creating Schedule}

      1. The system retrieves and displays the available course information for the given term if the final date for changes has not passed.

      {Deadline Passed}

      1. The Instructor selects the courses that he would like to teach.

      {Confirm Creating Schedule}

      1. The Instructor confirms the selection.
      2. The system creates the Instructor's teaching schedule in the database.
      3. The system notifies the Instructor that the teaching schedule has been created.

      S2: Modify Schedule {Begin Modifying Schedule}

      1. The system retrieves and displays the Instructor's teaching schedule and the available course information for the given term if the final date for changes has not passed.

      {Deadline Passed}

      1. The Instructor adds course sections to and/or deletes course sections from his teaching schedule for the given term.

      {Confirm Modifying Schedule}

      1. The Instructor confirms the changes.
      2. The system updates the Instructor's teaching schedule in the database.
      3. The system notifies the Instructor that the modifications have been made.
      5
      Exam weight Low

        PSU: Use-case Detailed Specification — Style 2 (cont'd)

        Alternative Flows A1: Invalid Term At {Select Activity} if the entered term or year is invalid,

        1. The system informs the Instructor that the term or year is invalid.
        2. The flow of events is resumed at {Enter Term}.

        A2: Schedule Exists At {Begin Creating Schedule} if a schedule already exists.

        1. The system informs the Instructor that a schedule already exists.
        2. The flow of events is resumed at {Select Activity}.

        A3: No Section Selected At {Display Schedule} or {Begin Modifying Schedule} if the Instructor has not selected any sections of courses to teach in the given term,

        1. The system notifies the Instructor that this function is currently not available.
        2. The flow of events is resumed at {Enter Term}.

        A4: Change Date Passed At {Deadline Passed} if the final date for changes has passed,

        1. The system rejects the request.
        2. The use case ends.

        A5: Cancel Activity At any point between {Begin Creating Schedule} and {Confirm Creating Schedule} or between {Begin Modifying Schedule} and {Confirm Modifying Schedule},

        1. The Instructor can cancel the activity.
        2. The flow of events is resumed at {Select Activity}. We note that the preceding two styles are only examples . There are many different ways to write use-case descriptions. A project should select a style and use it consistently.
        6
        Exam weight Low