Claimer: The published outline at https://outline.uwaterloo.ca/viewer/view/ncnd5x gives all the details about the course that are not expected to change during the entire term, such as the personnel; an overall description of the course; general, term-independent instructions; course, School, Faculty, and University policies; and the due dates, but not the contents, of course assignments, a.k.a. deliverables. It gives only the tentative, initial snapshot of the lecture schedule and of other details that change according to the class's progress through the course materials. The current version of these changing details, that include assignment contents, the lecture schedule as it happened, the lecture slides, and URLs to newly discovered relevant materials, is found here.

The only information that is at both places is the note about gender-non-specific singular pronouns, the section titled "Class Schedule", and the section titled "Instructor".

To Go Directly to the Lecture Schedule

To Go Directly to the Deliverables Due Dates

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

Class Schedule

• Section I, SE463

  • Lecture: Tuesdays: 2:30pm--3:50pm in EV3 1408

  • Lecture: Thursdays: 2:30pm--3:50pm in EV3 1408

  • Tutorial: Fridays: 10:30am--11:20am in MC 1085
    Occasionally, a tutorial session designated in the lecture schedule as "NO TUTORIAL" will be used as time during which SE490 presentations may be scheduled, because there are not enough hours during the SE490 lecture meetings to allow every team to do all of its required presentations.

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.

Important Caveats About Interacting with the Instructor

These are caveats that I have had to put up to deal with low attendance in class.

About Being Late to Class

Typically, attendance in class drops to close to nothing by the middle of the term. It has even been the case that by starting time, there is no one present. Independently, people do stroll into class at random times, but this event is not guaranteed.

Therefore, if by the official start of class, there is no one present, I will close down the podium and go home. I am not going to wait for the not-guaranteed late arrival who may never come. Moreoever, I will consider the planned lecture as having been delivered, and you are responsible for its contents.

Consulting About the Final Exam

I will not field questions about past and the upcoming final exams in the last 24 hours before the final exam. There is just too much going on in these last 24 hours. So, if you will have any questions about past and the upcoming final exams, please ask them well in advance.

Caveat Concerning Consulting in General and Your Attendance

In general, if you have not been attending classes, i.e., I do not remember seeing you in class, and to answer a question that you ask me, I would have to basically repeat verbatim the whole of, or even a significant part of, a lecture that I gave, I will decline to answer your question and will point you to the lecture's slides.

Requesting a Letter of Recommendation

I am happy to write letters of recommendation based on what I personally know about you from interacting and observing you. If you have not been attending classes, i.e., I do not remember seeing you in class, then I will not have interacted with you, and I will not have observed anything about you. Even if you have been in class, if you have done nothing to particpate in class, I will know nothing about you.

If I don't know anything about you, then the letter of recommendation I can write about you is useless. The letter will say no more than can be determined from the grade you got in class. I do not attempt to say any more. Giving me a resume does not help. I don't use the resume, because I never say anything that I have not learned first hand by interacting with you. In any case, since you give them your resume, anything I can say from your resume, they already know.

So, if you will be requesting a letter of recommendation, please attend and participate in classes.

Evaluation of Instructor at the End of the Term

Archive of E-mail Sent to Class:

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

Deliverables

Specifications of the Contents of the 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 professor served as the chief customer. The professor 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, the descriptions of any deliverable may change, if the professor learns something new about what is needed and what is possible.

The first three deliverables, D1, D2, and D3, are respectively, 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 at the SE490 gitHub or at the SE463 Learn site, when your SE490 team self registered by 14 September at 5:00pm for SE490 or when your SE463 group self registered by 16 September at 5:00pm for SE463.

As any new artifact is being done, you will occasionally discover that one or more of the abstract and previously delivered artifacts need to be updated. When delivering any new artifact, the new versions of all updated, previously delivered abstract and artifacts need to be delivered as well and included in the same file as the new artifact. In any included updated abstract or artifact, the changes to it should somehow be highlighted..

If you believe that a different order of these deliverables makes sense for your project, please approach your TA and the professor to discuss a different ordering, and we will make that ordering the order of the deliverables 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.

Occasionally you will find that a deliverable uses a notation that is not helpful or not relevant to your system, in particular 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 project is a research project and not an implementation project, then please approach the course professor ASAP so that you, your TA, and the professor can meet to negotiate a set of meaningful deliverables that help identify the requirements for your research. Yes. Even research often has requirements! :-)

If your group has started implementating already, then do not specify what you have implemented (aw! shucks!). In particular, it is not acceptable to produce a specification that is built from your implementation upward. 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. Also, this will give you an opportunity to see at no cost to your SE490 work, where the original idea might have gone. You never know in advance what that will tell you!

Format of Deliverables

Neither Deliverable 1, 2, nor 3 needs a cover page, as each is very short, not more than about five pages. In each of Deliverables 1, 2, and 3, you must indicate somewhere on the first page:

• your specification group's number

• your specification group's number
• the names and WatIAM IDs of all specification group members.

Each deliverable will be submitted electronically as a PDF file. The one PDF file you submit must include everything that is required to be in the deliverable, including new versions of the abstract and previous deliverables that you have been requested to update and submit with the current deliverable.

Electronic Submission of Deliverables and File Names

You will need to submit an electronic copy of each deliverable the dropbox for the deliverable at the course's Learn site. It is recommended, but not required, that the file name for the deliverable be "YK-GXX.pdf" where Y is "D" for a deliverable or "A" for an assignment, K is the deliverable or assignment number, and XX is your team/group number, with a leading zero if it's less than 10. This way, should the file ever get separated from its dropbox, we will be able to return it to the right dropbox.

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

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

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

Deliverable Due Dates and Dates of Feedback Tutorials

Due Date and Time	Deliverable	Points	Date of Feedback Tutorial
Wednesdy 16 September by 5:00 pm	Deliverable 0: Creation of Specification Groups information sent as necessary by one group member to the dropbox for Deliverable 0 at the course's Learn site	0	but -5% of final course grade for each day late
Friday 25 September by 5:00pm	Deliverable 1: Domain, Class, and World Model for Your System to the dropbox for Deliverable 1 at the course's Learn site	1	Tuesday 29 September
Friday 9 October by 5:00pm	Deliverable 2: Use Case Model for Your System to the dropbox for Deliverable 2 at the course's Learn site	1	Tuesday 20 October
Friday 30 October by 5:00pm	Deliverable 3: Domain Assumptions, Exceptions, Variations for Your System to the dropbox for Deliverable 3 at the course's Learn site	1	Friday 6 November
Wednesday 18 November by 5:00pm	Deliverable 4: First Draft Specification of Your System to the dropbox for Deliverable 4 at the course's Learn site	7	Friday 27 November
Friday 27 November by 5:00pm	Assignment 1: Ambiguity Exercise, an optional exercise for your own understanding, for feedback and no points, to the dropbox for Assignment 1 at the course's Learn site	0	Friday 4 December
Wednesday 9 December by 5:00pm	Deliverable 5: Final Draft Specification of Your System to the dropbox for Deliverable 5 at the course's Learn site	40
XXXXXX XX December XXXXX-XXXXXam, in XXXX XXXXX	Final Exam (Incompleteness Policy)	50	Sample Final Exams

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 in additional rows, you will find some additional reading or viewing material.

          >            

Date	Day & Lecturer OR Topic & Slides	Additional Materials
10 September	Thursday Lecture: Daniel Berry
	Administration, Plans, and Requirements of the Course	The Importance of Ignorance
	The True Cost of AI Assistance to Programming of Software, Daniel Berry, 2026	Whither Forecasting, Daniel Berry, 2026
	AI Didn't Make Programming Easier. It Just Made It Differently Difficult, Jeremy Osborn, 2026	Neural Coding as Software Engineering Augmentation, Not Abdication, Somdip Dey, 2026; Look particularly at the section titled "Losing the Language of Thought", but you might find the whole article interesting as a prediction of the future of SE.
	The Truth Engine We Have Yet to Build, Solom Heddaya, 2026	The Score Is Not the Skill: The Scoreboard Problem, Antonio Mastropaolo, 2026
11 September	Friday Tutorial: NO TUTORIAL	Occasionally, SE490 presentations may be scheduled during this "NO TUTORIAL" session.
15 September	Tuesday Lecture: Daniel Berry
	Requirements Engineering Reference Model: Domain Modeling	A Question Arising From the Previous Lecture
16 September	Wednesday Due Date: by 5:00pm	Deliverable 0: Creation of Specification Groups information sent as necessary by one group member to the dropbox for Deliverable 0 at the course's Learn site
17 September	Thursday Lecture: Daniel Berry
	Requirements Engineering Reference Model: Domain Modeling
18 September	Friday Tutorial: Daniel Berry
	Classes: Concepts and Context: Examples	But We're Not Sure Yet What It Does
	Zombies vs. Humans Game nouns, properties, and verbs	Bad Draft Domain Model for Zombies vs. Humans Game
	First Draft Domain Model for Zombies vs. Humans Game	Final Draft Domain Model for Zombies vs. Humans Game
22 September	Tuesday Lecture: Daniel Berry
	Classes: Concepts and Context	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 of Classroom Podium System with no borders: Photo of Blackboard	Second Draft Domain Model of Classroom Podium System with System Border Updated from First Draft: Photo Of Blackboard
	Third Draft Domain Model of Classroom Podium System with Both Borders and some Trimming: Photo Of Blackboard	Final Draft Domain Model of Classroom Podium System with Both Borders and Trimmed: Photo of Blackboard
24 September	Thursday Lecture: Daniel Berry
	Use Cases and Scenarios
	WhenIsGood Use Cases Raw	WhenIsGood Use Cases With Labels
25 September	Friday Tutorial: Daniel Berry
	Use Cases and Scenarios: Examples	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
	WhenIsGood High-Level Use Cases Assigned to Classes in the Final Draft Domain Model for whenisgood.net	WhenIsGood Use Cases With Scenario Steps Made Use Cases
25 September	Friday Due Date: by 5:00pm	Deliverable 1: Domain, Class, and World Model for Your System to the dropbox for Deliverable 1 at the course's Learn site
29 September	Tuesday Lecture: Daniel Berry
	Discuss Deliverable 1
	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.
1 October	Thursday Lecture: Daniel Berry
	Finding Exceptions and Variations to Use Cases Scope Determined (D) and Scope Determining (G) Requirements: A New Categorization of Functional Requirements	Part of "Administration, Plans, and Requirements of the Course" slides that are relevant to today's topic
	Advice on Where to Find Exceptions	"A calculator app? Anyone could make that.": a good example of tracking down an exception and deciding on a handler for it
2 October	Friday Tutorial: Daniel Berry
	Case Studies: Examples
6 October	Tuesday Lecture: Daniel Berry
	Case Studies
8 October	Thursday Lecture: Daniel Berry
	SRSs
	User's Manuals as Requirements Specifications
9 October	Friday NO TUTORIAL	Occasionally, SE490 presentations may be scheduled during this "NO TUTORIAL" session.
9 October	Friday Due Date: by 5:00pm	Deliverable 2: Use Case Model for Your System to the dropbox for Deliverable 2 at the course's Learn site
13 October	Tuesday NO LECTURE: Reading Week!!!
15 October	Thursday NO LECTURE: Reading Week!!!
16 October	Friday NO TUTORIAL: Reading Week!!!
20 October	Tuesday Lecture: Daniel Berry
	Discuss Deliverable 2
	User's Manual Advice
22 October	Thursday Lecture: Daniel Berry
	User Interface Specifications
23 October	Friday Tutorial: Daniel Berry
	User Interface Specifications: Examples
27 October	Tuesday Lecture: Daniel Berry
	Requirements for AI (RE4AI)
29 October	Thursday Lecture: Daniel Berry
	Requirements for AI (RE4AI)
30 October	Friday NO TUTORIAL	Occasionally, SE490 presentations may be scheduled during this "NO TUTORIAL" session.
30 October	Friday Due Date: by 5:00pm	Deliverable 3: Domain Assumptions, Exceptions, Variations for Your System to the dropbox for Deliverable 3 at the course's Learn site
3 November	Tuesday Lecture: Daniel Berry
	Software Cost Estimation
5 November	Thursday Lecture: Daniel Berry
	Costs of AI Assistance to Coding
6 November	Friday Tutorial: Daniel Berry	Discuss Deliverable 3
10 November	Tuesday Lecture: Daniel Berry
	Ambiguity in Requirements Specifications
12 November	Thursday Lecture: Daniel Berry
	Ambiguity in Requirements Specifications
13 November	Friday NO TUTORIAL	Occasionally, SE490 presentations may be scheduled during this "NO TUTORIAL" session.
17 November	Tuesday Lecture: Daniel Berry
	Nonfunctional or Quality Requirements
18 November	Wednesday Due Date: by 5:00pm	Deliverable 4: First Draft Specification of Your System to the dropbox for Deliverable 4 at the course's Learn site
19 November	Thursday Lecture: Daniel Berry
	Requirements Elicitation
20 November	Friday NO TUTORIAL	Occasionally, SE490 presentations may be scheduled during this "NO TUTORIAL" session.
24 November	Tuesday Lecture: Daniel Berry
	State Machine Diagrams
	How to Evaluate the Course Prof
26 November	Thursday Lecture: Daniel Berry
	State Machine Diagrams
	Linear Temporal Logic
27 November	Friday Tutorial: Daniel Berry	Discuss Deliverable 4
27 November	Friday Due Date: by 5:00pm	Assignment 1: Ambiguity Exercise, an optional exercise for your own understanding, for feedback and no points, to the dropbox for Assignment 1 at the course's Learn site
1 December	Tuesday Lecture: Daniel Berry
	Linear Temporal Logic
3 December	Thursday Lecture: Daniel Berry
	The Requirements Iceberg
4 December	Friday Tutorial: Daniel Berry	Discuss Ambiguity Exercise
	Linear Temporal Logic Exercises
8 December	Tuesday Lecture: Daniel Berry
	The Requirements Iceberg
	Review of Course Introduction
9 December	Wednesday Due Date: by 5:00pm	Deliverable 5: Final Draft Specification of Your System to the dropbox for Deliverable 5 at the course's Learn site

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