[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] syllabus.html Tue Dec 11 14:05:43 PST 2012


    CSE375 Requirements Analysis and Design Syllabus

      This is a required course in the generic BA in Computer Systems but is designed to be useful for anyone interested in producing good object-oriented software. The catalog entry reads
        Requirements analysis, including organizational objectives, functional characteristics, technology, use cases and conceptual models. The use of aspects, patterns, objects, and structure in architectural design specifications. Includes analysis and design of a software system for an organization, and fieldwork.

      The old CSE372 prerequisite is waived. CS372 is now the upper division elective CSE557. It taught how computers can used in an organization but did not discuss how computers are programmed. It determined what software must be programmed to improve a system. CSE375 shows how to refine these requirements and design a robust and correct object-oriented solution.

      This is at least the ninth time the course has been taught.

      Instructor Information and Methods

      See my generic syllabus [ syllabus.html ] ; this defines who I am, how I teach, and how I grade.


      The web site is an important artifact that you should scan at least 3 times a week. It contains notes on each assigned reading and has answers to many questions students have asked in the past.

      We will be using Craig Larman's [ http://www.craiglarman.com/ ] excellent book:

    1. Text::=following,
      • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 3/E
      • Craig Larman
      • ISBN: 0-13-148906-2
      • Publisher: Prentice Hall PTR
      • Copyright: 2003
      There are significant improvements between the 2nd and 3rd editions so you should not buy older editions. The book store has copies. You can buy or rent it there.

      We will not have time to cover chapters 21, 22, 28, 29, 30, and 33 through to 40. There is a lot of wisdom in them but there won't be any assessment made of the content. So you can do the minimum on the following topics:

      • -- Tools and Management
      • -- Persistence -> data base classes
      • -- UML Components
      • -- UML Activity Diagrams (CS557)
      • -- UML State Machines -> Comp Sci Theory
      • -- Documenting architectural decisions
      • -- User Interfaces -- frameworks, design, etc.
      • -- Physical Architecture -- Artifacts and deployment (CS557)
      • -- Deployment Diagrams (CS557)
      • -- Some advanced Patterns (TBA)
      There will be no tests of your knowledge of the history in the book -- but knowing the history will help you recall the best practices.

      I will be stressing

      • *** Use cases and scenarios
      • ** UML Relations between use cases.
      • *** Quality/Non-functional requirements
      • *** Class diagrams: domain and design models
      • **** Interaction diagrams
      • *** GRASP
      • *** Logical Architecture -- especially layered architecture and Model-View-Controller -- (MVC)
      • ** GoF -- Gang of Four Patterns
      (In this class I use the number of asterisks to indicate how important a topic is in the assessment. )

      Course Goal and Student Objectives

      The mission of the course is to give you skills and attitudes you can use to produce modern object oriented software using a light and agile process that gives programs to your stakeholders and clients that they value highly: now and in the future. A detailed list of objectives can be found at [ objectives.html ] on the course web site.

      Work -- 300 points

      (N): Reading. ( 2 points >< 19)
      1. Start with the web site. It lists the assigned reading for each class and tells you how important the different topics are.
      2. Read the assigned pieces of text and take notes.
      3. Follow the links to the review questions. Answer as many as you have time for.
      4. Write down your name, one(1) question and your answer on a piece of paper and hand it in at the start of class for grading.

      (P): Turn up on time and be ready to work and participate in the classroom activities. In the first class I will give a lecture. Normally I minimize the lecture in favor of activities. You will be working on projects, exercises, etc. (2 points).

      (W): In 9 classes a previously assigned piece of work [ projects.html ] will be presented and collected. This will be a series of iterations in a software project. Each starts at the end of the class before the due date. Each piece of work is worth 10 points maximum. Bring whatever you have got at the time to class. Late work scores nothing. Bad or incomplete work can score something. Make a presentation (4 points) in class. I may even ask you to demonstrate how a set of objects carry out some task. Then submit documentation(6 points) to me. These artifacts can be hard copy or on the Web. You can do the deliverables by hand or using CASE tools as you wish.... but it should be readable and spelled correctly. You can even submit photos of diagrams sketched on a board.

      (Q): In 9 classes there will be a Quiz worth 15 points (maximum) on the topics covered in the course up to that time -- but mainly on the most recent topics.

      (Bonus): You can earn 5 points each time you attend a CSE seminar [ ../seminar/ ] and within 24 hours email me a short message that reports on the seminar.

      Final -- 200 points

      There will be a comprehensive final that will cover all the assigned readings, all the work done in class, all the review questions, and your team project. Here [ mock.html ] is the format and topics in the previous final.


      I will be following my generic grading scheme [ ../syllabus.html#Grading ] with these rules:
      • No more than 300 points can be earned for course work (prior to the final) even counting bonus points.
      • Bonus points can not effect the score on the final.


      An up to date schedule is maintained at [ schedule.html ] on the web site. This tells you what assignments are due when. This includes all the assigned reading/study listed by the date due.


      Start at [ http://cse.csusb.edu/dick/cs375/ ] the course web site. It has up-to-date and reference information. Try the [Search______ ] on all these pages. The pages also have a [Contact] button at the top to send me Email. My phone number, office, and calendar are here [ http://cse.csusb.edu/dick/ ] and in my generic syllabus. Come and see me!

    . . . . . . . . . ( end of section CSE375 Requirements Analysis and Design Syllabus) <<Contents | End>>

  1. CS375::= See http://cse.csusb.edu/dick/cs375/.
  2. CS372::=Replaced by CS557.
  3. CS557::= See http://cse.csusb.edu/dick/cs557/.

    Standard Definitions

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

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

  8. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  9. GoF::="Gang of Four", [ patterns.html#GoF ]
  10. 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 ]
  11. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

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

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

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

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

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

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

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

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

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

  24. 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".

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

( End of document ) <<Contents | Top