Claimer: The published outline at https://outline.uwaterloo.ca/view/nbesn3 is only a snapshot, taken at the beginning of the term, of this living, canonical, outline here, that you are looking at now. Wherever the published outline and this living, canonical outline here differ, this living, canonical outline's contents is taken as correct.

To Go Directly to the Lecture Schedule

To Go Directly to the Deliverables Due Dates

For Other Information including about Mental Health Support, Continuity Plans, Academic Integrity, Grievance, Discipline, Academic Offenses, Appeals, a Note for Students with Disabilities, Turnitin.com, and If You Do Not Write Your Final Exam

"E", "em", and "er" are gender non-specific third-person singular pronouns in subjective, objective, and possessive forms, respectively.

Course Description:

Instructor:

• Daniel Berry, DC 3329, No telephone, dberry ATT uwaterloo DOTT ca
  Office hours: by appointment made by e-mail,
  but feel free to knock on his room door, if the door is closed.
  Berry says, "The reason I have no telephone is that I am nearly deaf. I do not sign, but I do read lips. So I cannot use a voice-only telephone. I can use a video communication medium if the bandwidth of the connection is high enough that the image gets updated at the frequency of television or movies and thus, the lip movement is smooth enough to be decipherable."
  An appointment can be via Zoom.

  Please send to Berry e-mail that you want to meet in person or via Zoom, along with some possible times, and he will reply with one of those times or an alternative proposal. When you and he agree on a time, if the meeting is to be via Zoom, he will send you a Zoom invitation.

Evaluation of Instructor at the End of the Term

TAs:

• Joel Rorseth, jerorset ATT uwaterloo DOTT ca
• Yelizaveta Brus, ybrus ATT uwaterloo DOTT ca
• Noble Saji Mathews, ns3mathe ATT uwaterloo DOTT ca
• Shimon, ssarefin ATT uwaterloo DOTT ca
• Mohamed Rouili, mrouili ATT uwaterloo DOTT ca
• Max Zhang, m492zhan ATT uwaterloo DOTT ca

Class Communication:

If you have a question that is not private and is not targeted directly to one of the Instructors or TAs, then send it to se463@uwaterloo.ca, the course e-mail address.

One of the TAs or the prof will answer it. If the question is deemed to be of general interest and not private, the answer, including the question WITH THE SENDER'S IDENTITY REMOVED, will be sent by e-mail to the whole class so everyone gets the benefit of the answer.

The main way that the course prof will announce things to the class is by e-mailing to everyone's watIam e-mail address. You are responsible for all information sent this way. If you prefer to receive such e-mail at a different address, please send e-mail to the course e-mail address from your watIam e-mail address, with the new e-mail address that you prefer given in the body of the message. To help you in case you delete any such messages too quickly, below you will find a link to an archive of every e-mail message sent in this manner.

Archive of E-mail Sent to Class:

Click here for an archive of the e-mail sent to the entire class.

Highest Level Course Outline:

1. Administration, Plans, and Requirements of the Course
2. Requirements Modeling
   1. RE Reference Model
   2. Domain Modeling
   3. Use-Case Modeling
   4. Assumptions and Exceptions Identification
3. Requirements Specifications
   1. Software Requirements Specification (SRS) documents
   2. Users' Manuals
4. SE and RE Economics
   1. Cost Estimation
   2. Classifying Requirements wrt Downstream Repair Costs
   3. RE in Agile Development
5. RE Issues To Be Aware Of
   1. Ambiguity in Requirements Specifications
   2. Non-Functional Requirements
   3. Verification and Validation
   4. Importance of Ignorance in RE
   5. Requirements Elicitation
6. Things to Specify
   1. User Interfaces
   2. RE for AI and ML
7. Formal Specification Notations
   1. State Machines
   2. Linear Temporal Logic
8. General Overview of RE
9. Case Studies

Course Times and Locations:

• Tutorial (occasionally): Mondays: 2:30pm--3:20pm in MC 4045

• Lecture: Tuesdays: 2:30pm--3:50pm in RC 211

• Lecture: Thursdays: 2:30pm--3:50pm in RC 211

The student is responsible for knowing anything significant that arises from any in-class discussion.

Readings:

No textbook. Notes are provided at this Web site.

References:

• Gause and Weinberg, Exploring Requirements: Quality Before Design, Dorset House, 1989.
• Gause and Weinberg, Are Your Lights On? How to Figure Out What the Problem REALLY Is?, Dorset House, 1990.
• Rumbaugh, et.al., Object-Oriented Modeling and Design, Prentice-Hall, 1991.
• Davis, Software Requirements: Objects, Functions, & States, Prentice-Hall, 1993.
• Braek and Haugen, Engineering real-time systems: an object-oriented methodology using SDL, Prentice-Hall, 1993.
• Jackson, Software Requirements and Specification, ACM Press, 1995.
• Ellsberger, Hogrefe, Sarma, SDL, Prentice Hall, 1997.
• Larman, Applying UML and Patterns, Prentice Hall, 1998.
• Rumbaugh, Jacobson, and Booch, The Unified Modeling Language Reference Manual, Reading, MA, 1999.
• Bray, An Introduction to Requirements Engineering, Addison-Wesley, 2002.
• Leffingwell and Widrig, Managing Software Requirements: A Use Case Approach, Addison Wesley, 2003.
• Robertson and Robertson, Requirements-Led Project Management, Addison-Wesley, 2005.
• Kotonya and Sommerville, Requirements Engineering: Processes and Techniques, Wiley, 2005.
• Sommerville and Sawyer, Requirements Engineering: A Good Practice Guide, Wiley, 2006.
• Maciaszek, Requirements Analysis and System Design: Developing Information Systems with UML, Addison Wesley, 2007.
• Nuseibeh and Zave, Software Requirements and Design: The Work of Michael Jackson, Good Friends, 2010.
• Pohl, Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010.
• Brooks, The Design of Design, Addison Wesley, 2010.
• van Lamsweerde, Requirements Engineering: From System Goals to UML Models to Software Specifications, Wiley, 2011.
• Robertson and Robertson, Mastering the Requirements Process: Getting Requirements Right, Addison-Wesley, 2012.
• Wiegers and Beatty, Software Requirements, Microsoft Press, 2013.
• Dick, Hull, and Jackson, Requirements Engineering, Springer, 2017.
• Laplante, Requirements Engineering for Software and Systems, CRC Press, Taylor and Francis, 2017.

UML Cheat Sheets

IEEE Standard for SRSs

EVLA Array Operations Software Requirements, an example of a good SRS document

Example SRSs and User's Manual, including a local copy of the EVLA Array Operations Software Requirements (called "array-sw-rqmts.pdf")
There is also a template for SRSs in LaTeX form, called "srs.tex.txt". To use it as input to LaTeX, strip off the ".txt".

A link to the Website of Understanding Requirements, by David Gelperin, a book targeted to practitioners. The site has a collection of videos on various aspects of requirements engineering. Particularly interesting is Tutorial 1, "Simplistic Requirements Models Considered Harmful".

Workload:

1. a group project: some complete requirements specification of the identified scope of the group's system: This complete requirements specification can be in any of a number of forms, including, but not limited to:
   • a complete Software Requirements Specification (SRS),
   • a complete user's manual (UM),
   • a complete set of complete UML descriptions,
   • a complete online help system,
   • a complete set of complete user stories and for each user story, and associated complete set of test cases, or
   • a set of artifacts accepted by the course prof as providing sufficient completeness.
   The key criterion for completeness is that the group, in writing the specification, is forced to flesh out all the requirements that are already present in the chosen scope of the system that is being prototyped in SE490 or in the project of your choice;
2. some individual or group deliverables, mostly directed at helping you in the group project; and
3. a 2.5 hour in-person final exam (assessment).

• For those registered in SE463 who are BSE students, your group in this class is your team in the concurrent offering of SE490. The TA that your group has in this class is the same that your team has in SE490.

The TA of your group serves as the group's mentor and evaluates the group's project-related work.

See the slides on "Administration, Plans, and Requirements of the Course" for more detail.

General Term-Independent Project Information

How to Deliver Deliverables

Evaluation:

• The non-final deliverables: 10%, as follows:
  1. 1%, for Deliverable 1,
  2. 1%, for Deliverable 2,
  3. 1%, for Deliverable 3,
  4. 7%, for Deliverable 4.
• The final deliverable, Deliverable 5: 40%
• The final exam: 50%

The exam covers any and all material in the lectures and lecture slides. As indicated in the slides for "Administration, Plans, and Requirements of the Course", part of the exam is designed to be easier if you have actively participated in the project, so that overall, more of the final grade comes from the project work.

Deliverables, How to Deliver Them, Group Numbers, and Due Dates

Deliverables

Each group has a different system for which to write a specification. In the past, every group wrote its own specification of single shared system, for which the prof served as the chief customer. The prof was able to be quite precise about what was expected in all deliverables and to even prepare er own solution to the early deliverables against which each group could check its own version. This precision is not possible now.

The descriptions of the deliverables here must be general enough to fit any system, but specific enough to make it clear what is expected of each deliverable. As the term progresses, expect that the descriptions of all deliverables will change, as the prof learns what is needed and what is possible.

The first three deliverables are the three artifacts described here:

1. Domain, Class, and World Model for Your System
2. Use Case Model for Your System
3. Domain Assumptions, Exceptions, Variations for Your System

All three of these should be based on the abstract you have already written for your project and have installed at the capstone repository.

If your group has not written an abstract yet, then the first deliverable includes the writing and installing of this abstract.

If, as a result of what it learns in the doing of any develiverable, your group changes its abstract, then say so in that deliverable and include in the deliverable both the before and after abstract, with the differences somehow highlighted.

As each new artifact is done, you will occasionally discover that one or more previously delivered artifacts needs to be changed. When delivering any new artifact, the updated versions of all updated, previously delivered artifacts need to be delivered as well and included in the same file as the new artifact..

If you believe that a different order of these deliverables makes sense for your project, please approach your TA and the prof to discuss a different ordering, and we will make that ordering the order of the deliverable for your project. Generally, you should try to do the deliverables in order of increasing amounts of information needed from other artifacts. The artifact that needs the least information from the others should be done first, and the artifact that needs the most information from the others should be done last.

If your project is a research project and not an implementation project, then please talk with the prof ASAP so that you, your TA, and the prof can meet to negotiate a set of meaningful deliverables that help identify the requirements for your research. Yes. Even research often has requirements! :-)

If you find that a deliverable uses a notation that is not helpful or not relevant to your system, then please appraoch the prof ASAP so that you, your TA, and the prof can meet to find a notation, perhaps domain specific, that serves the deliverable's purpose, but is helpful and relevant to your system.

In particular, for any deliverable, if the domain in which your project is situated has its own established notation for expressing the content of the deliverable,

• e.g., E-R diagrams for databases
  as a domain model
• e.g.,
  1. Unix manual page headers,
  2. procedure headers, and
  3. language grammars,
  as a use case model,

If your group has started implementating already, then do not specify what you have implemented (aw! shucks!). Instead, specify the system that you and your customer had in mind when you wrote and refined your project's abstract that is at the repository. Remember, that at the time, you got your customer's buy-in to this intent. So E is expecting something similar to that intent. In particular, it is not acceptable to produce a specification that is built from your implementation upward. For an explanation, see these same words in the page on Thoughts on the Purposes of Writing a Requirements Specification.

VERY IMPORTANT: How to deliver deliverables, describing the filenames that you must use. These file names include your group's group number.

Deliverable Due Dates and Dates of Feedback Tutorials

Due Date and Time	Deliverable	Date of Feedback Tutorial
Friday 27 September by 5:00pm	Deliverable 1: Domain, Class, and World Model for Your System to the course e-mail address	Monday 30 September
Friday 11 October by 5:00pm	Deliverable 2: Use Case Model for Your System to the course e-mail address	Monday 21 October
Monday 28 October by 5:00pm	Deliverable 3: Domain Assumptions, Exceptions, Variations for Your System to the course e-mail address	Monday 4 November
Friday 15 November by 5:00pm	Deliverable 4: First Draft Specification of Your System to the course e-mail address	Monday 25 November
Friday 22 November by 5:00pm	Assignment 1: Ambiguity Exercise, an optional excercise of your own understanding, for feedback and no points, to the course e-mail address	Monday 25 November
Thursday 5 December by 5:00pm	Deliverable 5: Final Draft Specification of Your System to the course e-mail address
Tuesday 10 December 12:30pm--3:00pm EST (2.5 hours in-person) in TBA	Final Exam ( Incompleteness Policy            Sample Final Exams)

Example Solutions to Early Deliverables

Feedback on Deliverables

You can find slides with the prof's feedback on any deliverable by clicking on the date of its tutorial in the table above, after it has become a link.

Caveat on Deliverables

Berry says, "A number of you will run the two courses, SE463 and SE490, together in your minds and start considering time spent doing the deliverables for this class as taking time away from doing things in the capstone. NO NO NO!!!!

No matter what, you have to do the homework in this class. I could have made you do a totally unrelated project. You would have to spend the same amount of time on it. You would not be able to spend the same time on the project, but you would not consider it as diverting time away from one task of the project to another.

NO matter what, you will not have as much time on the project as you would have if you were not taking SE463. What I have done is make the SE463 project be related to your capstone project. It might or might not inform the capstone. If it doesn't, there is no loss, because you never had the time any way. But, if it DOES, then wow, you have a gift!!!

REMEMBER THIS. I will keep reminding you :-)"

Lecture Schedule

The list below represents the sequence of lectures as we see they will be given. As time goes on, we may change the order. Also as time goes on, we will see how they divide themselves up into dates.

If a topic has hot links, then the slides for the topic are available for downloading. If there are no hot links on a topic, the slides are not ready yet, and will be later, we hope, at least one day before the lecture.

The title itself is a hot link to a copy of its slides in Acrobat form (.pdf). These slides may not be exactly what we are showing on the screen during the lecture. The lecture may have material that we do not have the legal right to distribute multiple copies of. It may have also an exercise that we want to do alive in class with your help. We do not want you to be able to see such material until we have finished.

Underneath the header Additional Materials OR Deliverable Details, you will find some additional reading or viewing material.

                   

Date	Day & Lecturer OR Topic & Main Slides	Additional Materials
5 September	Thursday Lecture: Daniel Berry
	Administration, Plans, and Requirements of the Course	The Importance of Ignorance
10 September	Tuesday Lecture: Daniel Berry
	Requirements Engineering Reference Model: Domain Modeling
12 September	Thursday Lecture: Daniel Berry
	Requirements Engineering Reference Model: Domain Modeling
17 September	Tuesday Lecture: Daniel Berry
	Classes: Concepts, Context, and Identification
	First Draft Domain Model for whenisgood.net: Scan	Bad Draft Domain Model for whenisgood.net
19 September	Thursday Lecture: Daniel Berry
	Classes: Concepts, Context, and Identification	More on Domain Modeling for Deliverable
	First Draft Domain Model for whenisgood.net: Scan	Final Draft Domain Model for whenisgood.net
	Bad Draft Domain Model for whenisgood.net	Domain Model for Electric Passenger Vehicle: Scan
	First Draft Domain Model with no borders: Photo of Blackboard	Second Draft Domain Model with System Border Updated from First Draft: Photo Of Blackboard
	Third Draft Domain Model with Both Borders and some Trimming: Photo Of Blackboard	Final Draft Domain Model with Both Borders and Trimmed: Photo of Blackboard
24 September	Tuesday Lecture: Daniel Berry
	Use Cases and Scenarios
	WhenIsGood Use Cases Raw	WhenIsGood Use Cases With Labels
26 September	Thursday Lecture: Daniel Berry
	Use Cases and Scenarios	Use Cases for Podium System, including alternatives and exceptions
	WhenIsGood Use Cases Raw	WhenIsGood Use Cases With Labels
	Scenarios for PopulateEvent	Scenarios for Update Event
	Scenarios for ShowResponseCalendar	WhenIsGood Use Cases With Scenario Steps Made Use Cases
1 October	Tuesday Lecture: Daniel Berry
	Finding Exceptions and Variations to Use Cases The Dangerous "All" in Specifications: See Slides 1--30.	Requirements Determination is Unstoppable: See Slides 1--48, 58--60.
3 October	Tuesday NO LECTURE: Professor On Holiday!!!
8 October	Tuesday Lecture: Daniel Berry
	Scope Determined (D) and Scope Determining (G) Requirements: A New Categorization of Functional Requirements	Advice on Where to Find Exceptions
	The 90-10 or 80-20 percent phenomenon	My Self-Administered Hair Cut During the Covid-19 Lockdown: Real-Life, Small-Scale Requirements Engineering
10 October	Thursday Lecture: Daniel Berry
	SRSs	IEEE Standard for SRSs
	User's Manuals as Requirements Specifications
15 October	Tuesday NO LECTURE: Reading Week!!!
17 October	Thursday NO LECTURE: Reading Week!!!
22 October	Tuesday Lecture: Daniel Berry
	User's Manual Advice	Example User's Manual for WD-pic
24 October	Thursday Lecture: Daniel Berry
	User Interface Specifications	"Interface Quotas and Internet-Derived Value", Bob Colwell, IEEE Computer 37:12, pp. 10-12, 2004
	Exiting a textEdit Session	Exiting an MS Word Session
29 October	Tuesday Lecture: Daniel Berry
	Software Cost Estimation	Head Start or Bad Bet?
31 October	Thursday Lecture: Daniel Berry
	"Devs gaining little (if anything) from AI coding assistants", by Grant Gross	Requirements Engineering for a Synagogue's Kitchen
5 November	Tuesday Lecture: Daniel Berry
	Ambiguity in Requirements Specifications	Some "only" Exercises for Class
	Google search for "I only eat"	Google search for "I eat only"
7 November	Thursday Lecture: Daniel Berry
	Ambiguity in Requirements Specifications	All the sentences with "only" in the EVLA Array Operations Software Requirements.
	Google search for "All eat"	Google search for "Each eats"
	Google search for "Both eat"	The Dangerous "All" in Specifications: See Slides 30--34.
	'Requirements for Monitoring Inattention of the Responsible Human in an Autonomous Vehicle: The Recall and Precision Tradeoff' by Johnathan DiMatteo, Daniel M. Berry, Krzysztof Czarnecki
12 November	Tuesday Lecture: Daniel Berry
	Nonfunctional or Quality Requirements
14 November	Thursday Lecture: Daniel Berry
	'Requirements for Monitoring Inattention of the Responsible Human in an Autonomous Vehicle: The Recall and Precision Tradeoff' by Johnathan DiMatteo, Daniel M. Berry, Krzysztof Czarnecki	RE for AI: What is an RS for an AI?
	Some AI Apps	AI Validation TimeLine
	Evaluate Correctness of Translator	Evaluate Correctness of Recognizer
19 November	Tuesday Lecture: Daniel Berry
	State Machine Diagrams
21 November	Thursday Lecture: Daniel Berry
	Linear Temporal Logic
	How to Evaluate the Course Prof
26 November	Tuesday Lecture: Daniel Berry
	Linear Temporal Logic
28 November	Thursday Lecture: Daniel Berry
	Elicitation
3 December	Tuesday Lecture: Daniel Berry
	The Requirements Iceberg

This page is at http://www.student.cs.uwaterloo.ca/~se463/index.shtml