Advanced

CS/SE 6361 Section 001, Fall 2009

*

 

 

Instructor:        Lawrence Chung

 

Office:              ECSS 3.204, ECS, UTD

 

E-mail:             chung@utdallas.edu

 

Phone:             972-883-2178

 

Web page:        http://www.utdallas.edu/~chung/RE/syllabus.htm (NOT webCT!)<

 

Office hours:    T 1:00-3:00pm, or by appointment

 

Lectures:          TR 11:30am-12:45pm, ECSS2.201

 

TA:                   Rutvij Mehta (rutvij.mehta@student.utdallas.edu  ; office hours: TR 3:00-5:00pm; ECS4.609)

 

Textbook:         Lecture Notes

 

References:

      • System Requirements Engineering, P. Loucopoulos and V. Karakostas, McGraw-Hill: [all.rar] [Preface; Chap1; Chap2; Chap3; Chap5; Chap6] – thanks to Varshada!
      • Managing Software Requirements: A Use Case Approach, 2nd edition, Dean Leffingwell, Don Widrig, Addison Wesley: Boston
      • Non-Functional Requirements in Software Engineering, L. Chung, B. Nixon, E. Yu and J. Mylopoulos,

Kluwer Academic Publishing, 2000 (An earlier version of a framework book chapter)

      • Software Requirements: Objects, Functions, & States, A. M. Davis, Prentice Hall: Englewood Cliffs, 1993.
      • System and Software Requirements Engineering: Tutorial, R. H. Thayer and M. Dortman (Editors),

IEEE Computer Society Press

      • Problem Frames: Analyzing and Structuring Software Development Problems, M. Jackson, Addison-Wesley Professional; 1st edition (December 15, 2000)
      • Requirements Engineering: Processes and Techniques, G. Kotonya and I. Sommerville, John Wiley Sons
      • Requirements Engineering - A Good Practice Guide, I. Sommerville and P. Sawyer, Wiley
      • Scenarios, Stories, Use Cases Through the Systems Development Life-Cycle,  I. Alexander and N. Maiden (eds.), John Wiley & Sons, 2004.
      • Requirements Engineerng: Frameworks for Understanding, R. Wieringa, Wiley, 1997
      • Requirements Engineering: Social and Technical Issues, J. Goguen, and M. Jirotka (Eds.), Academic Press, 1994.
      • Requirements Engineering, L. Macaulay, Springer Verlag, 1996
      • User-Centered Requirements Analysis, C. F. Martin, Prentice-Hall, 1994
      • Information System Requirements: Determination and Analysis, D. Flynn, McGraw-Hill, 1992
      • Are Your Lights On?: How to Figure Out What the Problem Really Is, D. C. Gause and G. M. Weinberg, Dorset House, 1990.
      • Exploring Requirements, D. Gause and G. Weinberg, Dorset House, 1989
      • Managing Systems Requirements: Methods, Tools, and Cases, S. J. Andriole, McGraw-Hill, 1996.
      • System Requirements Analysis, J. O. Grady, McGraw Hill, 1993.
      • Systems Engineering: Coping with Complexity, R. Stevens, K. Jackson, P. Brook, and S. Arnold, Prentice Hall 1998.
      • Requirements Engineering and Rapid Development: A Rigorous, Object-Oriented Approach, I. S. Graham, Addison-Wesley, 1998.
      • Practical Software Requirements; A Manual Of Content And Style, B. L. Kovitz, Manning Publications, 1998
      • User-Centered Requirements: The Scenario-Based Engineering Process, K. L. McGraw and K. Harbison, Lawrence Erlbaum Associates, 1997.
      • The Complete Systems Analysis, J. Robertson and S. Robertson, Dorset House, 1998.
      • Applying Use Cases: A Practical Guide, G. Schneider and J. P. Winters, Addison-Wesley, 1998.
      • Object-Oriented Analysis and Design, with Applications, G. Booch, Benjamin-Cummings, 1994
      • Object-Oriented Methods: A Foundation, J. Martin and J. Odell, Prentice-Hall, 1995
      • The Unified Modeling Language Reference Manual, J. Rumbaugh, I. Jacobson and G. Booch, Addison-Wesley, 1998

§  The Unified Modeling Language User Manual, G. Booch, J. Rumbaugh and I. Jacobson, Addison-Wesley, 1998.

 

Prerequisites:  CS 5354 (SE 5354) Software Engineering, or CS 3353 (SE 3354)

 

Objectives:       To be able to systematically establish, define, and manage the requirements for a large, complex, changing, software-intensive system, be it organizational or mostly a computer sub-system. To be able to understand the central issues which form the background to, or have tendency to deform, the process. To be able to understand, evaluate and choose from traditional techniques and further advances in the field.

 

Computer Usage:

You can obtain a trial version of Rational Rose to run the program(s) on your home PC from http://www.rational.com/tryit/index.jsp, demo and online tutorial from http://www.rational.com/tryit/rose/seeit.jsp .  A student version is also available.

If you wish, you can use the facilities at UTD too (ES2.104 on the ground floor in ECS). All PC’s in the labs of UTD are installed with Rational Rose.  There are several open access labs: http://www.utdallas.edu/ir/tcs/labs/locations.htm. You will need to get a user ID for the lab, https://netid.utdallas.edu. Need help? 972-883-2911, assist@utdallas.edu, http://www.utdallas.edu/ir/tcs

 

Project:           There will be a 2-phase project. 

 

Each project phase should be submitted by the expected due date in the beginning of the class that day – one hardcopy per team and all the softcopies should be available on the team web site.  Project phases should be submitted with project phase #, class/section, team name; team URL; (rotating) team leader(s); and for each member of the team: student name, student ID, and student email address, written on the first page. There should also be a description of all the meeting conducted, and for each meeting: date, location, agenda, participants, and summary.

 

The project will be done by teams of approximately 3-7 students (The team size will depend on the number of students in the course, and more on this will be discussed in class). All students in a team will get the same mark for the work they do unless they unanimously agree (in writing) to an unequal division. You are to choose your own team members. An orphan will be assigned to a team by the instructor.

 

For each deliverable, there should be at least one team leader, who coordinates communication and deliverable submission.

 

Project I under development should be presented approximately 2 weeks before the final submission due date; Project II under development should be presented approximately 2 weeks before the submission due date.

 

The first or second page of your deliverable should describe all the meetings your team had, while indicating the participants in each of the meetings. This page should be signed by all members of the team.

 

The last page of your deliverable should describe why you believe your deliverable is at least as good as, or better than, any other team’s work, based on your observation on other teams’ presentations.

 

 

Tests:               There will be two tests, one in the middle  (test 1) and the other at the end (test 2)  of  the course.

 

Late work:        Any assigned work will have 10 points deducted for each week passed. 

 

Grading:

Project (2 x 15)

30 %

Test 1

25 %

Test 2

40 %

Class Participation

5 %

 

Important Dates:

 

1.     August 20 (Thursday) - First day of class for this course

 

2.     September 3 (Thursday)   - Preliminary Project  Plan (Team organization, Team leaders/deliverable, Team web site URL, Tools, etc.)

http://wwwbruegge.informatik.tu-muenchen.de/twiki/bin/view/OOSE/SoftwareProjectManagementPlanTemplate;  some samples

 

3.     October 1 (Thursday) – Interim Project I ([PDF]) presentation

 

4.     October 8 (Thursday) – Test 1

 

5.     October 22 (Thursday) – Final Project I submission (updated presentation, models/specs, updated project plan)

 

*Devise your own template, but you could consider using this as a reference

reqs-creeping-rates.docx reqs-creeping-rates.doc

 

 

6.     November 12 (Thursday) – Interim project II  ( [PDF]) submission (and possibly also presentation)

*A tool you might want to consider using.

 

7.     November 24 (Tuesday) – Test 2

 

8.     November 26 (Thursday) – Thanksgiving holiday

 

9.     December 1/3 (Tuesday/Thursday) – Final Project II submission, presentation and demo

 

(Each team should set up a time with the TA to do a demo). At the time of the demo, a hardcopy should be submitted, which should include;

§  Final project plan

§  Project I

§  Project II

§  Any dependency/traceability between Project I and Project II

all in one document.

 

Guest Lecture, Ashok Nare, former CTO Intellium --- November 10, 2009 : presentation slides

 

Cheating/Dishonesty:

 

The University of Texas System Policy on Academic Honesty (The Regents and Regulations, Part One, Chapter VI, Section 3, Paragraph 3.22):

 

Any student who commits an act of scholastic dishonesty is subject to discipline. Scholastic dishonesty includes but is not limited to cheating, plagiarism, collusion, the submission for credit of any work or materials that are attributable in whole or in part to another person, taking an examination for another, any act designed to give unfair advantage to a student or the attempt to commit such acts.

 

The minimum penalty for academic dishonesty is a failing grade (zero)

     

Course Outline (subject to evolution, hence it is recommended that you download 1-2 modules at a time on  a weekly basis)

layer hidden off the screen

            Topics                                                                                                                                                                                                                         Approx. duration

 Introduction {System and software reqs. eng., Error propagation, Types and cost of requirements defects, definitions}                                          2 weeks

 Why, What and How [small-pdf]

-          Requirements Engineering Journal and a Swing cartoon 

-          Examples of requirements defects

-          http://techdirt.com/articles/20060818/1613226.shtml

-          The Standish Report; About the CHAOS report

-          Also see cases 1 and 2 below (patriot missile; TCAS –transponder)

 

 Requirements Engineering Processes [small-pdf] {RE evolutionary process, RE basic process, RE in software lifecycle, Process vs. product specifications }           1 week

 

 Requirements Analysis, Modeling and Specification [small-pdf] {Problem analysis, Solution space, Requirements prioritization}                                        1 week

 

 Requirements Elicitation:                                                                                                                                                                                        1.5-2 weeks

 Essential Concepts [small-pdf]{Critical issues, Four worlds of RE, Desirable properties of requirements, Requirements traceability, goal-orientation, other elicitation techniques}

 Scenario Analysis   {Use cases, episodes, scripts, completeness of scenarios, mis-use cases, anti-goals} 

 

Enterprise Requirements:                                                                                                                                                                                         1.5 weeks

 Modeling Techniques [small-pdf] {Agent-oriented enterprise modeling, Business modeling with UML, Conventional enterprise modeling techniques}

            A vision document template

            A sample vision document 1

A sample vision document 2

A sample stakeholder requests

 AS-IS or TO-BE?

 

case 1: patriot missile: clock drift - 28 killed, over 90 injured

case 2: TCAS - transponder

case 3: NY subway collision

case 4: U.S. Census Bureau collision

                                                                                                                                               

Functional Requirements: Semi-formal Structural Models   {Structured analysis}                                                                                                  0.5-1 week

 

Functional Requirements: Formal Structural Models                                                                                                                                              2 weeks

 A Formal OO-RML/Telos  {Deficiencies of SA, RML/Telos Essentials, A Formalization}

 Metamodeling {Models, Metaclasse, Metamodels, Metamodels for UML and other notations}

Functional Requirements: Behavioral Models   {Decision-oriented, State-oriented, Function-oriented behavioral models}                                          1 week

 

Non-Functional Requirements: {Why, What – definitions and classifications, How – product- and process-oriented approaches}   [4-on-1] [white-background]  1.5 weeks

                                               


 Another possible topic: Requirements Verification

 Model Checking

 Model Finder

 

 

Priorities: Class Discussions !!, Lecture Notes !, Primary Reading and References!!!

 

Presentations – Fall 2005

 

Presentations – Summer 2006

 

Presentations – Fall 2006

 

Presentations – Spring 2007

 

Presentations – Fall 2007

 

Presentations – Fall 2008

 

Presentations – Spring 2009

 

Presentations – Summer 2009

 

 


Sample Project Descriptions

Course Project - Part I  [PostScript]  [PDF]

Sample Deliverable

Course Project - Part II –   [PostScript]  [PDF]

Sample Deliverable

Course Project - Part III – old, to be updated   [PostScript]  [PDF]


Sample Tests

Sample Test 1   [PostScript]  [PDF]

Sample Test 2   [PostScript]  [PDF]

Sample Test 3 and Answer   [PostScript]  [PDF]

Sample Test 4   [PostScript]  [PDF]

Sample Test 5   [PostScript]  [PDF]

 


           

Frequently Asked Questions

 

errorPropagation

 

IEEE standard (IEEE standard – temporarily broken)

Document Templates – general IEEE

SRS sample

http://wwwbruegge.informatik.tu-muenchen.de/twiki/bin/view/OOSE/RequirementsAnalysisDocumentTemplate

 

Other samples and templates

 

A Tutorial on Temporal Logic

Case Studies on Temporal Logic

 

A UML Tutorial by Bruegge 

A UML Tutorial by Bruegge (A copy) 

 

Job Posting

Raytheon

Last updated: 03/20/00 22:25:00


  Back home

Pre-Requisite Verification Form:

Savio Monteiro

Naziya Sultana