[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] 05.html Wed Jan 11 07:25:31 PST 2012

Contents


    CSci 375/05 More Requirements


      Table
      Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
      Previous4Use Cases61-89-W1 (section 4.3)
      Today5More Requirements89-120Q2(61-120)-
      Next6Domain Model121-157-W2(Use Case Model 1)

      (Close Table)

      Project 1 Due at start of class.

      Input on Requirements

        Two kinds of Requirements -- Functional vs NonFunctional

        This is an important distinction. Functional requirements tell us what the software should do and map naturally into code via use cases.

        The non-functional requirements don't map so easily -- they are often expressed in terms of How much of some resource can be used.

        For example: time to respond, memory needed, cost of CPU, hours of training, user mistakes per hour, time to train a new user, time to deliver the software, and so on.

        Other non-functional requirements tend to come from above: the HIPA and ADA requirements for example, or the choice of technology -- "must be Windows".

        Security and reliability are high level non-functional requirements. Security is about things that will not be done rather than what can be done. Reliability is about how often a system can fail vs be unavailable.

        Modern Requirements Engineering Terminology -- Functional vs Quality

        Requirements Infrastructure

        You can spend a lot of money on tools that store requirements. You can also use pencil and paper. The problem with paper is that requiremnts change and it is inefficient to change paper. This is especially true if you use pen and paper.

        So, you need a system that allows these use cases

        1. Analyst rapidly inputs new requirements.
        2. Analyst shows impressive requirements to the client.
        3. Analyst shares requirements with other members of the team.
        4. Analyst edits requirements.
        5. Analyst recovers earlier versions. (version control)
        6. Analyst compares many different artifacts.
        7. Create new project.
        8. Backup data.
        9. Recover data after disaster.
        10. Etc.

        Suggestions: a team web site, Google docs, Drop Box, ...

        Example of a Simple system

          System -- Shopping Aid

          Vision

          A hand-held, wireless device that helps shoppers buy the items that they want. A shopper has a list of items that they want. They are sold at different stores. The device keeps an up-to-date list of wanted items as the user shops.

          Use Case -- Go Shopping


          (Main Go Shopping Scenario): The shopper inputs a list of wanted items and the system displays stores where they can be found. The shopper goes from store to store looking for the products that match their list. They buy a product at the first store where they find it, mark it as bought and the system updates their list or items and stores.

          Use Case -- Start Up

          Use Case -- Administer User Accounts

          Use Case -- Backup data

          Glossary

          1. Shopper::=a person who wishes to by a number of itwms that might be found in several different stores.
          2. Shopper::data={id, name, password, ... }.

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

          Supplementary Specification

          1. System will not allow shopper's data to be shared with shops, other shoppers, or unauthorized employees.
          2. ...

          . . . . . . . . . ( end of section Supplementary Specification) <<Contents | End>>

          Domain Rules

          1. R1. Each item is suitable for one product.
          2. R2. Each wanted item matches various items in different stores.
          3. R3. Stores have different quantities of each item for sale.
          4. R4. A product can have a different price at each store.
          5. ...

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

          Etc.

        . . . . . . . . . ( end of section Example of a Simple system) <<Contents | End>>

        UML Use Case Diagrams

        Important fact. A Use Case diagram shows many use cases. It connects actors to use cases -- period! A use case is primarily described by text not diagrams.


        1. *** Learn the notation -- it is unambiguous and simple:
          • Bubbles are Use Cases. Name inside or underneath.

            [Bubble with Name inside or outside]

          • Stick figures are Actors (probably human). Name underneath.
          • Boxes with "<<actor>>" are also actors (probably computerized).
          • Boxes with no "<<actor>>" are probably mistakes.

            [Two actors and an error described in text above]

          • Lines connect Actors to their Use Cases. Lines do not connect use cases to use case or actors to actor.

            [Good and bad lines]

          • The Big Box shows the system boundary and can have the name of the project or product on it.

          Common error in use case diagrams

          Omitting the system boundary or context. The big box that contains all the use case bubbles and none of the actors. It is nice if it has the name of the system at the top.

        2. Exercise: what are A, B, and C in this image?

          [Use case diagram with A B and C]

        3. *** Applying the UML: use case diagrams
          • * Actors(sticks for people, <<actor>> boxes for systems)
          • * Use Case Bubbles (name inside or underneath)
          • * Boundary(Scope at top)
          • * Actors communicate with Bubbles (no arrows)
          • * Layout: primary actors on left, supporting actors on right An older notation was to give the primary actor an arrowhead at the use case end.
        4. Exercise -- Draw a use case diagram for Shopping Aid.

        5. Applying the UML: Activity diagrams(modernized flowcharts see CSci372)

        6. Motivation: benefits
        7. Example: monopoly game
        8. * Process: iterating
        9. History
        10. Resources
        11. ++ A Business Use Case describes how an business actor gets something that they want but does not describe the systems that are involved.
        12. + Danger: a "Business case" is the reason the business needs to develop the software.


        Other Requirements are put in other artifacts


        1. How complete?
        2. How Thoroughly in inception?
        3. On the project's website
        4. Example NextGen
          1. Supplementary Specification
          2. Vision
          3. Glossary
          4. Business Rules

        5. **** Process: Evolve Requirements by iteration
        6. Resources

      . . . . . . . . . ( end of section Input on Requirements) <<Contents | End>>

      Questions and Answers

        [ 05q.html ]

      Review Questions on Requirements

      [ 05r.html ]

      Example from 2010

      [ example2010.html ]

      Exercise for class 05

      [ 05x.html ]

      Assigned Work Next Week: A FIRST set of Requirements for your project

      [ w2.html ] is due next week (Class 07).

      For the next class study [ 06.html ] and the reading (and give me a review question [ 06r.html ] + answer).

      Quiz 2 on Use Cases and other Requirements

      TBA

    . . . . . . . . . ( end of section CSci 375/05 More Requirements) <<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.
  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 class 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 is not needed, 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 Dept, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

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

  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 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