[Skip Navigation] [ CSUSB ] / [CNS] / [Comp Sci & Engineering] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Question] [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] w2.html Mon Sep 28 15:48:37 PDT 2009

Contents

    Assigned Work 2: An initial Set of Requirements for your project

     Deliverables
    1. Use case diagram naming actors and use cases.
      At least one fully dressed critical use case.
    2. Two or three casual use cases
    3. Brief descriptions of all the other use cases.
    4. Any interesting supplementary specifications, business rules, or glossary items.

    Process
    1. Make a list of names for use cases.
    2. Add primary actor to each
    3. Add any secondary actors.
    4. Brief descriptions for all of them(note)
    5. Refine three or four into casual format.(note)
    6. Refine one casual one into a fully dressed use case(note)
    7. Draw the use case diagram.(note)
    8. Refine the non-functional requirements and glossary.


    (note): While doing this step take note of any other requirements: non-functional, business rules, odd terms....

    5 minute presentation per group. Name and brief description Use case diagram on board/web/floppy/zip/handout? Give fully dressed format if asked.

    By the way.... if your vision or business case changes then note this, but I don't need to see the whole -- yet.

    Advice

    Keep it

    Present one interesting use case at start of next class.

    Paper copy to be completed and submitted before deadline.

    Standard Definitions

  1. CS202::= See http://cse.csusb.edu/dick/cs202/.
  2. CS372::= See http://cse.csusb.edu/dick/cs372/.

  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. DRY::XP="Don't Repeat Yourself".

  5. ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

  6. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  7. GoF::="Gang of Four", [ patterns.html#GoF ]
  8. 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 class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  9. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  10. 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 is not needed, see YAGNI.

  11. OO::shorthand="Object-Oriented".

  12. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  13. patterns::="Documented families of problems and matching solutions", see Patterns.
  14. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

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

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

  18. SSD::="System Sequence Diagrams", see chapter 10.

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

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

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

  22. 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 means "It won't be on the final or in quizzes".

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

End