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, 2^nd 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