''.
Software Requirements: Specification & Analysis (SE463)
Spring 2021
To Go Directly to the Topics List
There are two nominally two sections. However, the notion of sections, whose purpose is to split the enrollment into groups each of which fits in one lecture room, is meaningless in an online course.
We can meet via Zoom. Please send to me e-mail that you want to meet with some possible times, and I will reply with one of those times or an alternative proposal. When we agree on a time, I will send you a Zoom invitation.
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 ATT uwaterloo DOTT ca, the course e-mail address.
One of the TAs or the instructor 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 class 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.
Click Here for an archive of the e-mail sent to the entire class
This course is officially asynchronous. Therefore, there are videos of lectures at the course Web site, in the Topics List. There are regular live-lecture recording sessions that you are encouraged to attend. If you attend, you can have your questions answered immediately by asking them during the live lecture. Also, I need an audience to laugh at my jokes. Here are the days and times of the recording sessions:
The student is responsible for knowing anything significant that arises from any in-class discussion that occurs in any lecture.
No textbook. Notes are provided at this Web site.
References:
EVLA Array Operations Software Requirements, an example of a good SRS document
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".
The assessment covers any and all material in the the Topics List. Part of the assessment 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.
The above distribution was always tentative in two different ways:
The distribution of the marks for your total grade, adhering to current university regulations, which say that the final assessment can count no more than 20% of your total grade, is:
You need to pass the final assessment in order to pass the course.
The assessment covers any and all material in the Topics List.
If university regulations change on the worth of the final assessment, the above distribution will change.
Deliverables, How to Deliver Them, Group Numbers, and Due Dates
This is only the second time I am teaching this course when each group has a different system to write a specification for. In the past, every group wrote its own specification of single shared system, for which I served as the chief customer. I was able to be quite precise about what was expected in all deliverables and to even prepare my 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 I learn what is needed and what is possible.
The first three deliverables are the three artifacts described here:
A number of you will run the two classes 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.. and 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 SE 463.. so what I have done is make the SE 463 project be related to your capstone project .. it might or might not inform the capstone.. if it doesn't.. no loss.. because you never had the time any way.. but if it DOES.. wow.. a gift!!!
OK.. REMEMBER THIS.. I will keep reminding you :-) -->
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 team 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 team 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.
On each due date, one of these artifacts, that was not delivered before, is due. They are actually listed in the most common order in which they are produced for any system. However, sometimes, for any given system, a different order is better. Your team should decide, in consultation with your TA, the best order in which to do them. Generally, you try to rank them 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. As each new artifact is done, you will 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 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,
If your team 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 he or she 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.
| Due Date and Time | Deliverable Details |
|---|---|
| Monday 31 May by 5:00pm | Deliverable 1: One Artifact to the course e-mail address |
| Monday 14 June by 5:00pm | Deliverable 2: One Artifact to the course e-mail address |
| Monday 28 June by 5:00pm | Deliverable 3: One Artifact to the course e-mail address |
| Friday 16 July by 5pm | Deliverable 4: First Draft Specification of Your System to the course e-mail address |
| Friday 23 July by 5:00pm | Assignment 1: Ambiguity Exercise to the course e-mail address |
| Thursday 5 August by 5:00pm | Deliverable 5: Final Draft Specification of Your System to the course e-mail address |
|
Saturday 7 August at 12:30 -- 3:00PM EDT (2.5 hours synchronous) If you are in a time zone whose awake hours do not include 12:30 -- 3:00PM EDT, you will have to do a time-zone shift. Plan ahead! | Final Assessment (Incomplete Policy Sample Final Exams) |
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.
The URLs, particularly of published journal articles, conference articles, and books, should be exercised from within the University of Waterloo Library, where you can sign on with your watIam credentials. Then, you should not have to pay for a download.
The reason that the videos are recorded with the speaker's head bigger than usual and the slides smaller than usual, i.e., at 50% of the window each, is to allow the hearing impaired, such as the prof of this course, to read lips. See Instructions for Staging and Recording a Lipreading-Deaf-Accessible Video of a Lipreading-Deaf-Accessible Zoom Lecture in a Manner that Improves Accessibility to the Blind for an explanation. If you are having difficulty reading the smaller-than-usual slides, then please follow along with a local copy of the slides, downloadable from this site, or among the not-for-redistribution material sent to all registered students of this course.
The contents of this Topics List is evolving, both in the topics covered
and in the content associated with each topic. Any video from a previous
year is left in until it is replaced by a new one from this year's
recording. Any video installed this year is marked with ``''.
This page is at http://www.student.cs.uwaterloo.ca/~se463/index.shtml
