Claimer: The published outline at https://outline.uwaterloo.ca/viewer/view/nrdh3x 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 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.

Course Times and Locations:

• Section I, SE463

  • Lecture: Tuesdays: 8:30am--9:50am in MC 2054

  • Lecture: Thursdays: 8:30am--9:50am in MC 2054

  • Tutorial (occasionally): Fridays: 10:30am--11:20am in MC 2054

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

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 8 September for SE490 or when your SE463 group self registered by 10 September 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 10 September by 5:00 pm	Deliverable 0: Self Registration of Groups at the course's Learn site and Deposit of Abstract to the dropbox for Deliverable 0 at the course's Learn site	0	(but -2% of final course grade for each day late)
Wednesday 24 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	Friday 3 October
Wednesday 8 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	Friday 10 October
Friday 24 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 31 October
Friday 4 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	Monday 25 November
Friday 21 November by 5:00pm	Assignment 1: Ambiguity Exercise, an optional excercise for your own understanding, for feedback and no points, to the dropbox for Assignment 1 at the course's Learn site	0	Friday 28 November
Wednesday 3 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
TBA	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
4 September	Thursday Lecture: Daniel Berry
	Administration, Plans, and Requirements of the Course	The Importance of Ignorance
	Video & Sound: Administration, Plans, and Requirements of the Course
5 September	Friday Tutorial: NO TUTORIAL
9 September	Tuesday Lecture: Daniel Berry
	Requirements Engineering Reference Model: Domain Modeling
10 September	Wednesday Due Date: by 5:00pm	Deliverable 0: Self Registration of Groups at the course's Learn site and Deposit of Abstract to the dropbox for Deliverable 0 at the course's Learn site
11 September	Thursday Lecture: Daniel Berry
	Requirements Engineering Reference Model: Domain Modeling
12 September	Friday Tutorial: Daniel Berry
	Classes: Concepts and Context
	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
16 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
18 September	Thursday Lecture: Daniel Berry
	Use Cases and Scenarios
19 September	Friday Tutorial: Daniel Berry
	Use Cases and Scenarios
23 September	Tuesday NO LECTURE: Professor On Holiday!!!
24 September	Wednesday 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
25 September	Thursday Lecture: Daniel Berry
	Finding Exceptions and Variations to Use Cases
26 September	Friday Tutorial: Daniel Berry
	Scope Determined (D) and Scope Determining (G) Requirements: A New Categorization of Functional Requirements
30 September	Tuesday Lecture: Daniel Berry
	Case Studies
2 October	Thursday NO LECTURE: Professor On Holiday!!!
3 October	Friday Tutorial: Daniel Berry	Discuss Deliverable 1
7 October	Tuesday Lecture: Daniel Berry
	SRSs
	User's Manuals as Requirements Specifications
8 October	Wednesday 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
9 October	Thursday Lecture: Daniel Berry
	User's Manual Advice
10 October	Friday Tutorial: Daniel Berry	Discuss Deliverable 2
15 October	Tuesday NO LECTURE: Reading Week!!!
17 October	Thursday NO LECTURE: Reading Week!!!
18 October	Friday NO TUTORIAL: Reading Week!!!
21 October	Tuesday Lecture: Daniel Berry
	User Interface Specifications
23 October	Thursday Lecture: Daniel Berry
	Requirements for AI (RE4AI)
24 October	Friday NO TUTORIAL
24 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
28 October	Tuesday Lecture: Daniel Berry
	Software Cost Estimation
28 October	Thursday Lecture: Daniel Berry
	Head Start or Bad Bet?	Costs of AI Assistance to Coding
31 October	Friday Tutorial: Daniel Berry	Discuss Deliverable 3
4 November	Tuesday Lecture: Daniel Berry
	Ambiguity in Requirements Specifications
6 November	Thursday Lecture: Daniel Berry
	Ambiguity in Requirements Specifications
7 November	Friday NO TUTORIAL
11 November	Tuesday Lecture: Daniel Berry
	Nonfunctional or Quality Requirements
13 November	Thursday Lecture: Daniel Berry
	Elicitation
14 November	Friday NO TUTORIAL
14 November	Friday 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
18 November	Tuesday Lecture: Daniel Berry
	State Machine Diagrams
20 November	Thursday Lecture: Daniel Berry
	Linear Temporal Logic
21 November	Friday Tutorial: Daniel Berry	Discuss Deliverable 4
21 November	Friday Due Date: by 5:00pm	Assignment 1: Ambiguity Exercise, an optional excercise for your own understanding, for feedback and no points, to the dropbox for Assignment 1 at the course's Learn site
25 November	Tuesday Lecture: Daniel Berry
	Linear Temporal Logic
27 November	Thursday Lecture: Daniel Berry
	The Requirements Iceberg
28 November	Friday Tutorial: Daniel Berry	Example State Machine Diagrams & Linear Temporal Logic & Discuss Ambiguity Exercise
2 December	Tuesday Lecture: Daniel Berry
	Key Slides from the Full Set of Iceberg Slides	The Requirements Iceberg Bibliography
3 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