Software Requirements: Specification & Analysis (SE463/CS445/ECE451)
Spring/Summer 2023 Schedule
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.
Officially, CS445/CS645/ECE451 is one course, and SE463 is another course. Each course has two sections, Section 1 and Section 2. Section 1 of both courses are held together, and Section 2 of both courses are held together. The same instructor is teaching both sections. Each of CS445/CS645/ECE451 and SE463 has been restructured to make it possible for them to be taught together. Thus, all registered in any section of any course wll get exactly the same lectures, tutorials, deliverables, and exam! Each student is registered in one of them and will receive er grade under that registration.
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.
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.
Click here for an archive of the e-mail sent to the entire class.
This choice is possible because the same material will be delivered by the same instructor in both options of the choice. While each students's attending er registered course time guarantees that there will be enough seats in the class room, in principle, the instructor does not care which option of any choice you attend. You don't even have to choose the same option each time!
The student is responsible for knowing anything significant that arises from any in-class discussion.
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 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.
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
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 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 the prof learns what is needed and what is possible.
The first three deliverables are 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.
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,
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.
Deliverable Due Dates and Dates of Feedback Tutorials
Due Date and Time | Deliverable | Date of Feedback Tutorial |
---|---|---|
Monday 29 May by 5:00pm | Deliverable 1: Domain, Class, and World Model for Your System to the course e-mail address | Wednesday 31 May or Monday 5 June |
Monday 12 June by 5:00pm | Deliverable 2: Use Case Model for Your System to the course e-mail address | Wednesday 14 June or Monday 19 June |
Monday 26 June by 5:00pm | Deliverable 3: Domain Assumptions, Exceptions, Variations for Your System to the course e-mail address | Wednesday 5 July or Monday 10 JulyWednesday 5 July or Monday 10 July |
Friday 14 July by 5:00pm | Deliverable 4: First Draft Specification of Your System to the course e-mail address | Wednesday 19 July or Monday 24 July |
Friday 21 July 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 | Wednesday 26 July or Monday 31 July |
Thursday 3 August by 5:00pm | Deliverable 5: Final Draft Specification of Your System to the course e-mail address | |
Tuesday 8 August at 9:00 -- 11:30AM EDT (2.5 hours in-person) in PAC 4 | Final Exam ( Incompleteness 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.
You can find slides with the prof's feedback on any deliverable by clicking on the dates of its tutorial in the table above, after they have become a link.
Berry says, "A number of you will run the two courses 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 :-)"
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. Our 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.
This page is at http://www.student.cs.uwaterloo.ca/~se463/index.shtml