[Skip Navigation] [CSUSB] / [CNS] / [CSE] / [R J Botting] / [Samples] / usecases
[Index] [Contents] [Source Text] [About] [Notation] [Copyright] [Comment/Contact] [Search ]
Thu May 9 14:28:33 PDT 2013

Contents


    Use Case Templates

      About

      This is a quick summary of how to write use cases.

      Advice


      1. The name should start with a strong verb.
      2. A use case is a set of scenarios. A scenario is a list of steps.
      3. Each step should state what the user does and/or what the system responds.
      4. The steps must not mention how the system does something. Keep the steps essential or logical -- no colors, clicks, typing!
      5. Each step needs to be analysed in detail before it becomes code.
      6. Keep It Simple: use the simplest format you need.
      7. Refine interesting use cases first.
      8. Make sure you store use cases so that they are easily found, edited, and used.
      9. Put use cases on a project web site.
      10. Keep track of different versions.
      11. Writing use cases is a team sport.
      12. Focus on a particular user (give them a name) in each use case and each step.
      13. Don't get bogged down in all the special ways it can go wrong until you've finished the main success story.
      14. Also see Rules below.

      Start with a meaningful name

      The minimum documentation is a well chosen name. It should start with a verb and indicate the type of user, and what they achieve:
       		Enrol student in class.

      This is better than nothing... and the start for drafting more complete descriptions of the use case.

      There is a lot to be said for labelling use cases with a short identifier.

       		(UC1): Enrol student in class.

      Brief Format

      Name + Terse one paragraph description of who does what to get what.

      Notice that we just add the description to the name+label:
      (UC1): Enrol student in class.


        The student logs in to the enrolment system and requests a list of sections of a class. They then select one class to enrol in and the system records this enrolment. The student is provided with confirmation that they have been enrolled.

      Casual Format

        Name
        (Main Success Scenario): Brief one paragraph description.
        (Alternate scenario 1): if ...., one paragraph
        (Alternate scenario 2): if ...., one paragraph

      . . . . . . . . . ( end of section Casual Format) <<Contents | End>> Notice that the scenarios are labelled for later cross reference and discussion.

      Example
      (UC1): Enrol student in class.



        (UC1main): The student logs in to the enrolment system and requests a list of sections of a class. They then select one class to enrol in and the system records this enrolment. The student is provided with confirmation that they have been enrolled.


        (UC1a): The class is full and the system proposes an alternative.
        (UC1b): The student cancels the enrollment after confirmation.
        (UC1aa): The class is full and there is no alternativ,e the system suggests talking to an advisor.


      Notice that the scenarios are labelled for later cross reference and discussion.

    . . . . . . . . . ( end of section Casual Format) <<Contents | End>>

    Less Casual Format

      This differs from a casual format in that the scenarios are numbered lists of steps. Name
      (Main Success Scenario): list of steps.
      (Steps letter): if ...., list of steps.
      (Steps letter): if ...., list of steps. Example
      (UC): Enrol student in class.

        (UC):
        1. The student logs in to the enrolment system and requests a list of sections of a class.
        2. The student selects one class to enrol in and the system records this enrolment.
        3. The student is provided with confirmation that they have been enrolled.
        4. They can select more classes.
        5. The student logs out.


        (UC2a): The class is full and the system proposes an alternative.
        (UC3b): The student cancels the enrollment after confirmation.
        (UC2aa): The class is full and there is no alternative, the system suggests talking to an advisor.


    . . . . . . . . . ( end of section Less Casual Format) <<Contents | End>>

    Fully Dressed

      Use this only for the really valuable and interesting use cases.

      Here are the headings for a fully dressed use case

      Name

      Start with a verb, numbering optional

      Scope

      The System Under Design or Context

      Level

      Enterpise goal, User-goal, or subfunction

      Primary Actor

      Name the actor who uses the system under design to achieve some goal.

      Stakeholders and Interests

      Preconditions

      State what special and interesting things must be true for this particular case to work.

      Postconditions

      List the interesting things that are true after a scenario is completed.

      Main Success Scenario

      1. step_number: actor does something or system responds

      Extensions


        (step numbers letter): condition
        1. actor does something/system does something

      . . . . . . . . . ( end of section Extensions) <<Contents | End>>

      Special Requirements

      Variations in Technology and Data

      Frequency of Occurrence

      Miscellaneous

      Fully dressed as a table

      Here is a Tabular Format
      Table
      Name Start with a verb, numbering optional
      Scope The System under Design
      Level User-goal or subfunction
      Primary Actor Asks the SUD to deliver service to meet goals
      Stakeholders and Interests (stakeholder1): what they want.
      Preconditions State what special and interesting things must be true for this particular case to work.
      Postconditions List the interesting things that are true after a scenario is completed
      Main Success Scenario actor does something or system responds
      Extensions (steps letter): condition steps
      Special Requirements desired qualities or technological limitations
      Variations in Technology and Data step number: possible change in technology or data format
      Frequency of Occurrence How often
      Miscellaneous Open issues to research

      (Close Table)

      Fully dressed template

      [ fullydressed.txt ] [ fullydressed.html ]

    . . . . . . . . . ( end of section Fully Dressed) <<Contents | End>>

    Rules for scenarios

      Source: Rules [YueBriandLabiche13]

    1. Each event is a sentence with either the system or an actor as the subject.
    2. Describe a sequence of events.
    3. No interations between actors.
    4. One action per sentence.
    5. Use active voice not passive.
    6. Clearly show who is sender and who reciever.
    7. Use Declarative sentences.
    8. Use words consistently.
    9. Don't use modal verbs like "might".
    10. Avoid adverbs.
    11. Use simple sententences: one sobject + one predicate.
    12. Don't use negative adjectives and adverbs.
    13. No pronouns.
    14. Don't use participle phrases as an adverbial phrase.
    15. Use "The system" consistently to refer to the system under design.
    16. You can INCLUDE another use case.
    17. You can indicate an EXTENDED BY use case.
    18. You should indicate where an alternative sequence flows from.
    19. Use IF-THEN-ELSE-END IF, and ELSEIF
    20. Use MEANWHILE ___
    21. Use VALIDATE THAT ___
    22. Use DO-UNTIL
    23. Use ABORT
    24. Use RESUME_STEP ___
    25. Each basic flow and alternative flow should have its own postcondition ** Controversial **

    . . . . . . . . . ( end of section Rules for scenarios) <<Contents | End>>

    Tools

    Use a dumb editor!

    See Also

    [Cockburn02b] (Alistair Cockburn's article).

    [ http://www.accompa.com/product-management-blog/2009/10/08/use-case-template-example-requirements-management-basics/ ] (shorter fully dressed form).

    [ url?sa=t&source=web&cd=4&ved=0CC0QFjAD&url=http%3A%2F%2Fninova.itu.edu.tr%2Fen%2Fcourses%2Finstitute-of-informatics%2F156%2Fbbl-502%2Fekkaynaklar%3Fg99523&rct=j&q=fully%20dressed%20use%20case%20example&ei=a5ztTMnuKMGVnwfi_sD9CA&usg=AFQjCNHEWXzGLEj3rDMNrNzzGQw_p3VPAQ&cad=rja ] (Larman's UC1: Process Sale in PDF).

    [ Use_case ] (Wikipedia).

. . . . . . . . . ( end of section Use Case Templates) <<Contents | End>>

( End of document ) <<Contents | Top