[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] usecases.html Mon Mar 11 11:47:16 PDT 2013

Contents


    Use Case Templates

      Advice


      1. All use cases need a name that starts with a strong verb.
      2. In complex systems you should give each use case a short identifier.
         		UC3: Register in class.
      3. Each use case is about how the primary actor achieves some tangible goal.
      4. Use cases should be described using text rather than diagrams.
      5. A use case is a family of scenarios related to one goal of one user.
      6. Scenarios are numbered sequences of steps.
      7. Beware small uses cases like 'login', 'logout', 'input one item': these are only steps in a user-level use case.
      8. Each step should state what an actor does and/or what the system responds.
         	1. John Doe logs in and gets a welcome screen
         	2. John selects a widget and the system displays its details.
      9. Scenarios can repeat steps but any long branches should be placed as an alternative scenario.
      10. The steps must not mention how the system does something.
      11. Why not write use cases in HTML?
      12. Put use cases on a project web site.
      13. Keep It Simple: use the simplest format you need.
      14. Make sure you store use cases so that they are easily found, edited, and used.
      15. Keep track of different versions.
      16. Writing use cases is a team sport.
      17. Focus on a particular user (give them a personal name even).
      18. Don't get bogged down in all the special ways it can go wrong until you've finished the main success story.
      19. Don't repeat yourself: if several use cases include the same steps then document the common steps as a new named use case and include it:
         		1. user logs in. Include $login.
      20. Document hitches and glitches to the main case as extensions: alternative scenarios.
      21. Don't document every use case in complete detail at first: start with a list of names and then drill down and analyze 10% of them.
      22. Analyze the difficult and valuable use cases first.
      23. Your analysis of a use case is incomplete until it is running.
      24. Do the diagram (if any) last. Good for your power point presentations.
      25. Keep a index/table of use case names and their status: named, brief, casual, fully-dressed, designed, coded, tested, accepted by stakeholder, needs maintenance,..., obsolete, removed to archive.

      Level 1 -- Give it a name

      The first level of description is to name the use case and its primary actor.

      Level 2 -- Brief Format

      Name + Terse one paragraph description of who does what to get what.
       Remove abusive poster.
       	The administrator identifies an abusive poster
       	and the system blocks the abuser from posting any more messages

      Level 3 -- Casual

        Name
        (Main Success Scenario): one paragraph.
        (Alternate scenario 1): if ...., one paragraph
        (Alternate scenario 2): if ...., one paragraph
         Remove abusive poster.
         	(main): The administrator identifies an abusive poster
         	and the system blocks the abuser from posting any more messages
         	(Alternative 1): If the administrator identifies a poster
         	who is posting a message then the message is rejected and
         	the poster informed.
         	The system blocks the abuser from posting any more messages
        If a scenario has several steps then it helps to number them.

      . . . . . . . . . ( end of section Level 3 -- Casual) <<Contents | End>>

      Level 4 -- Fully Dressed

        Here are the headings for a fully dressed use case. You don't prepare these for use cases that are neither important nor interesting.

        Name

        Start with a verb, numbering optional
         		UC1: Remove abusive poster.

        Scope

        The System under Design -- -- --(SuD)

        Level

        User-goal or sub-function

        Primary Actor

        Asks the SuD to deliver service to meet goals

        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. an actor does something or system responds
        2. an actor does something or system responds

        . . . . . . . . . ( end of section Main Success Scenario) <<Contents | End>>

        Extensions


          (steps letter): condition
          1. an actor does something/system does something

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

        Special Requirements

        • desired quality or technological limitation

        Variations in Technology and Data

        • step number: possible change in technology or data format

        Frequency of Occurrence

        Miscellaneous

        • Question
        • Topic to research

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

      Fully dressed as a table

      Here is a Tabular Format for a Fully Dressed Use Case.
      Table
      Name Start with a verb, numbering optional
      Scope The System under Design
      Level User-goal or sub-function
      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
      1. actor does something or system responds
      2. actor does something or system responds
      3. actor does something or system responds

      Extensions (steps letter): condition
      1. actor does something or system responds
      2. actor does something or system responds

      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)

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

    Standard Definitions

  1. Artifact::="Anything that is created in the course of a project".
  2. artifact::=see above.

  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code. [ 02DiceGameClasses.gif ] (example).
  4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".

  5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  6. GoF::="Gang of Four", [ patterns.html#GoF ]
  7. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good set of objects and/or classes to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  8. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  9. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what has no value now, see YAGNI.

  10. OO::shorthand="Object-Oriented".
  11. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.

  12. patterns::="Documented families of problems and matching solutions", see Patterns.
  13. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  14. Process::="How to develop software".

  15. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci and Engineering School, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

  17. SSD::="System Sequence Diagrams", see chapter 10 and [ 02DiceGameSSD.gif ] (example).

  18. TBA::="To Be Announced".

  19. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  20. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  21. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need it now. In this class it also means "It won't be on the final or in quizzes".

  22. XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved process.

( End of document ) <<Contents | Top