WEB SITE FOR FALL 2026 UNDER CONSTRUCTION UNTIL THIS LINE IS REMOVED!
Software Project Management, Requirements, and Analysis (SE463)
Fall 2026 Schedule
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.
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
You will be able to take revenge on and evaluate the course instructor at
https://perceptions.uwaterloo.ca
any time between Wednesday XX November 2026 at 8:30am
and Tuesday XX December 2026 at 11:59pm (just before midnight that starts
Wednesday).
Please see these slides for
more detail about logging into the site and the questions it asks.
Click here for an archive of the e-mail sent to the entire class.
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:
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,
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!
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:
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.
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.
Archive of E-mail Sent to Class:
Deliverables
Specifications of the Contents of the Deliverables
please approach the course professor ASAP so that you, your TA, and
the professor can meet to find a notation, perhaps domain specific,
that serves the deliverable's developmental and educational purposes
and is helpful and relevant to your system.
as a domain model
as a use case model,
Format of Deliverables
Deliverables 4 and 5 will be very long documents;
for each of these, you must provide a cover page that
clearly indicates:
Electronic Submission of Deliverables and File Names
Example Solutions to Early Deliverables
You can find past whole-class projects and possible solutions to their
early deliverables in the subdirectories of the directory
PastProjectsAndDelivs.
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.
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 | |
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. | |
| 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 | ||
| 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 | ||
| 22 September | Tuesday Lecture: Daniel Berry | |
| Classes: Concepts and Context | ||
| 24 September | Thursday Lecture: Daniel Berry | |
| Use Cases and Scenarios | ||
| 25 September | Friday Tutorial: Daniel Berry | |
| Use Cases and Scenarios: Examples | ||
| 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 | ||
| 1 October | Thursday Lecture: Daniel Berry | |
| Finding Exceptions and Variations to Use Cases | ||
| 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