All in One Syllabus

Academic Integrity

In order to maintain a culture of academic integrity, members of the University of Waterloo community are expected to promote honesty, trust, fairness, respect and responsibility. Check out the Office of Academic Integrity for more information.

Grievance

A student who believes that a decision affecting some aspect of his/her university life has been unfair or unreasonable may have grounds for initiating a grievance. Read Policy 70 (Student Petitions and Grievances), Section 4. When in doubt please be certain to contact the department’s administrative assistant who will provide further assistance.

Discipline

A student is expected to know what constitutes academic integrity to avoid committing an academic offence, and to take responsibility for their actions. Check out the Office of Academic Integrity for more information. A student who is unsure whether an action constitutes an offence, or who needs help in learning how to avoid offences (e.g., plagiarism, cheating) or about “rules” for group work/collaboration should seek guidance from the course instructor, academic advisor, or the undergraduate Associate Dean. For information on categories of offences and types of penalties, students should refer to Policy 71 (Student Discipline). For typical penalties check Guidelines for the Assessment of Penalties.

Appeals

A decision made or penalty imposed under Policy 70 (Student Petitions and Grievances) (other than a petition) or Policy 71 (Student Discipline) may be appealed if there is a ground. A student who believes they have a ground for an appeal should refer to Policy 72 (Student Appeals).

Sometimes we all “need a little help from [our] friends” (The Beatles on Spotify). If you’re having one of those times now, please reach out.

Your instructor is not a trained counsellor or physician, but if you’re at the end of your rope, need help now, and don’t know where else to turn, reach out.

Mental Health Supports

On-campus Resources:

• Campus Wellness
• Counselling Services 519-888-4096
• UW Mates: one-to-one peer support program offered by the Waterloo Undergraduate Student Association (WUSA) in consultation with Campus Wellness
• Health Services: located across the creek from the Student Life Centre 519-888-4096

Off-campus Resources:

• Good2Talk (24/7): Free confidential help line for post-secondary students. Phone: 1-866-925-5454
• Here 24/7: Addictions, Mental Health & Crisis Services Waterloo Wellington. Phone: 1-844-437-3247
• OK2BME: support services for lesbian, gay, bisexual, transgender or questioning teens in Waterloo Region. Phone: 519-743-6333. Email: ok2bme@caminowellbeing.ca
• EMPOWER ME allows students to connect with qualified counsellors, consultants, and life coaches for a variety of issues. Available 24/7. 1-833-628-5589 in Canada/USA

Accessability and Accommodations

AccessAbility Services is located in Needles Hall, Room 1401, and collaborates with all academic departments to arrange appropriate accommodations for students with disabilities without compromising the academic integrity of the curriculum. If you require academic accommodations to lessen the impact of your disability, please register with the office at the beginning of each academic term.

Accommodations for Illness or Extenuating Circumstances

The Accommodations section of the Undergraduate Calendar provides an overview for accommodation, whereas the process below addresses the specifics for students enrolled in the Faculty of Mathematics.

1. If you are sick or are experiencing extenuating circumstances that are not covered by Late Days, contact the course instructor before or within 48 hours of the exam or deliverable due date.

2. If you’re unable to complete a course component due to symptoms of COVID-19 or flu-like symptoms then complete the self-declaration form in Quest.

3. If your illness is because of other reasons then you must complete and submit a Verification of Illness Form (VIF).

   • Math Faculty students including Computing and Financial Management (CFM) students: Submit your VIF electronically here. Please have an electronic copy of your VIF ready to upload (take a picture or scan the VIF making sure all sections are readable). When you register your VIF with MUO, all of your Math instructors (i.e. course subjects: ACTSC, AMATH, CO, COMM, CS, MATH, MATBUS, MTHEL, PMATH, STAT) and Science instructors (i.e., course subjects: BIOL, CHEM, EARTH, MNS, PHYS, SCI, and SCBUS) will be notified. If you have questions, contact the Math Undergrad Office.
   • Software Engineering (SE) students: Submit your VIFs to the SE office.
   • Other students enrolled in the Faculty of Engineering should submit their VIFs to the course instructor.

Decisions around accommodations due to the submission of the VIF is at the discretion of the instructor. But accommodations can be requested only upon submission of the VIF.

Calendar Description

Introduces students to the requirements definition phase of software development. Models, notations, and processes for software requirements identification, representation, analysis, and validation. Cost estimation from early documents and specifications.

Overall Goals

CS445/CS645/ECE451 is about the problem of identifying what software to build, such that the end product is useful for stakeholders and users. The course is different from other computing courses in that it focuses on activities and technologies for being efficient and effective in determining what software to build, rather than on knowledge and techniques for how to build the software itself. The course emphasizes people-facing activities of determining requirements (e.g., eliciting needs from stakeholders, seeking user feedback, and negotiation) as well as technical activities, such as requirements analyses, strategies for prioritizing requirements, and notations for modelling and documenting requirements.

Expected learning outcomes include being able to

• elicit requirements using artifact-based, model-based, stakeholder-based, hypothesis-based, and creativity-based techniques
• communicate efficiently and effectively with customers, users, and other stakeholders
• prioritize requirements and determine the scope of the product
• manage risk in software development
• document requirements in a range of informal to formal modelling paradigms
• review and validate requirements
• estimate the cost of development from a requirements specification

Required Background

• Knowledge of finite-state machines (e.g., as used in CS 241 or ECE 351)
• Experience with object-orientation (e.g., experience with OO programming languages like Java or C#)
• Knowledge of propositional and predicate logic (e.g., as used in CS 245 or ECE 108)

If you are concerned about any of these prerequisites, contact the instructor and we will provide some resources that can help you learn and review this material.

The course covers the four major aspects of software requirements engineering: elicitation, modelling, analysis (e.g., triage, conflict management, risk analysis), and documentation. The aspects are broken down into nine topics, each of which focuses on a particular requirements-related problem to be solved when developing a software system or on a particular technique for addressing a requirements-related problem.

Listed below are the topics that are typically covered in every offering of this course. This term the order in which topics are covered will generally progress from (1) techniques employed when developing software at start-ups and tech companies to (2) techniques employed when developing enterprise software systems or when consulting (i.e., developing bespoke software for a client) to (3) techniques employed when developing safety-critial systems. One impact of this ordering of topics is that course concepts become increasingly difficult over the course of the term, where some of the later modelling languages are mathematical in nature.

1: Introduction

The costs of poor requirements engineering, and why requirements engineering is difficult.

2: Requirements Elicitation

Project scoping, business requirements, (lean) business modelling, stakeholder analysis, sources of requirements, strategies for identifying requirements.

3: Requirements Analysis

Requirements triage and prioritization. Cost-benefit analysis. Analytic Hierarchy Process. Conflicts and negotiation. Cost Estimation. Risk Analysis.

4: Requirements Modelling

Workflow modelling (Use-case diagrams, Scenarios, Activity diagrams, Data-Flow Diagrams). Functional requirements. Domain modelling (UML Class and Object diagrams). Modelling dynamic behaviour of a software system (extended state machine models). Constraint modelling of business rules (Object Constraint Language (OCL)) and of behaviours (temporal logic).

5: Quality Requirements

Nonfunctional requirements (e.g., performance, security, useability, maintainability). Fitness criteria.

6: Requirements Engineering Reference Model

Defining a system’s boundaries. Monitorable inputs and controllable outputs. Requirements vs. specifications. Environmental assumptions.

7: Prototyping

Design and refinement of user-interfaces. Navigation maps.

8: Validation and Verification

Walkthroughs, inspections, technical reviews of requirements documents. Executable specifications. Automated analysis. Verifying that specifications satisfy requirements.

9: Software Requirements Specification

Organizing a system’s requirements, specifications, and other relevant details into a Software Requirements Specification (SRS).

In Winter 2026, CS445/CS645/ECE451 will be delivered as an in-person flipped course. There will be weekly prerecorded lectures. However, most of the learning and most of your time in the course will be spent on activities that are carried out during in-person team meetings. Lecture videos will be released on Fridays for the following week. You are expected to watch each week’s videos in advance of your team meeting that week.

In-person team meetings will be held during the scheduled lecture time on Tuesdays 2:30 - 4:20 in DWE 3522. Your team is expected to meet for those nearly two hours to work through that week’s activities and deliverables. During this time, the instructor and project TA will drop by your meetings to mentor your activities and provide feedback on your prelimimary work in progress. Other feedback that your team will receive over the course of the term includes: (1) feedback from other teams (buddy teams) and (2) feedback from your project TA. Use the feedback to improve your deliverables – the weekly deliverables will contribute towards a final Software Requirements Specification (SRS) for your project.

The Thursday lecture slot (same time and place) is available for teams to meet as needed. The course instructor and TA is not expected to be present.

The tutorial time (12:30 - 2:20 in MC 2038) is available for team meetings. Several quizzes throughout the term will also be held in the tutorial time/room.

There will be an in-person final exam.

See Public Health for contingency plans.

Contingency Plans

If COVID mutates badly or another public-health emergency emerges that precludes in-person courses, then all team meetings will be online synchronous meetings (e.g., via Teams) at the same time they would have occurred in-person. The course instructor and TAs will join your meetings and provide the same Q&A, advising, and feedback as we would if we were in-person.

Similarly, if university regulations preclude in-person exams then the final exam will be an online exam.

Accommodating Team Members

COVID is still a thing for some people, depending on their own risk tolerance and other people in their lives that may be vulnerable or depending on them. Your instructor is in this situation and will likely mask when in class.

If one (or more!) of your team members is in a similar situation, please do all that you can to work with them. Mask if requested, etc. Speak with the instructor about it, as necessary.

The work in CS445/CS645/ECE451 centres on the course project, which is the scoping and specification of a software system, of your team’s choosing, that is hypothetically to be developed by another team. Your team will choose a real-world problem that you think can be addressed or mitigated by software. I encourage you to use this course project as an opportunity to think about how software can be used to improve people’s lives (e.g., improve mental health and happiness, reduce waste and share resources, combat climate change, promote equity and inclusion). If you are looking for ideas, consider something related to the UN sustainable development goals. Another source of ideas are projects from past terms (here and here), but your team needs to find its own problem to tackle.

Over the course of the term, your team will progress from choosing a problem to address; identifying the customers and users who are interested in this problem; understanding their problems and needs; expressing their work and workflow using lightweight models; resolving, analyzing, and prioritizing needs into the requirements of a proposed solution; refining requirements into more detailed models and specifications for a software system; and testing your hypotheses, ideas, and prototypes along the way. The weekly deliverables that you produce during the term will contribute to the final deliverable: a Software Requirements Specification that describes a software solution to your team’s problem, in sufficient detail that it can be developed by another team. More details can be found on the course’s Project page.

The success of your project depends on your dedication towards teamwork. There will be materials and activities that aim to help you and your teammates gel as a team and to monitor the health of the team (e.g., team contract, team health survey, peer evaluations). A portion of your grade will depend on your attendance at team meetings and contributing a fair share of the work on your team’s deliverables.

As part of the course project, you will need to interview people who represent members of the target user class for your proposed software system. Because your course project will involve interviews with people external to the course, you will need to complete the TCPS 2 Tutorial Course on Research Ethics (CORE), also known as the TCPS2 tutorial, on ethical conduct for research involving human participants. Every student must complete the ethics tutotial individually. This will probably take 2-3 hours.

The following grading scheme is based on points, not percentages. Each component of your final grade is worth up to the given number of points. Your final grade will be computed as the number of points earned divided by the number of points available.

The points available depends on whether you are an undergrad or grad student and whether we are forced to have on-line exams.

If COVID or another public-health emergency emerges that precludes in-person exams, then:

• the final exam will be an online exam worth 10 points (instead of 25)
• your team’s final SRS will be worth 35 points (instead of 25)
• quizzes will simply be dropped

Teamwork marks are based primarily on meeting attendance and completeness of tasks. Some teamwork activities (peer evaluations, and feedback to other teams) are evaluated based on the quality of the write-ups and quality of the feedback provided.

Points for weekly deliverables are spread fairly evenly throughout the term; each week is worth either 3 or 4 points as indicated by the provided rubrics.

Due Dates

Weekly Deliverables are due on Mondays at 8:59pm. The final Software Requirements Specification (SRS) for your course project is also due at 8:59pm ET on its due date. Any Weekly Deliverables or SRS deliverable that are submitted after their due date will accrue one Late Day for every 24 hours beyond their original due date.

Late Policy

Each team has a total of 10 Late Days that it can apply to the Weekly Deliverables and the final SRS deliverable, in (almost) any manner that the team chooses (e.g., 1 Late Day to each of the 10 weekly deliverables, 5 Late Days to 1 deliverable). The purpose of Late Days is to give your team some flexibility in your schedule (e.g., to overcome conflicts with other courses) and to accommodate short-term challenges that the team faces (e,g., illnesses, including “mild” COVID). The maximum number of Late Days that can be applied to any single deliverable is 5 days.

If you plan to use Late Days on a deliverable, notify your project TA in advance (e.g., via Teams) and tell them when you plan to submit your work, so that they know not to start marking your deliverable before it is ready. Please note that TA feedback on late submissions is likely to be delayed.

If you are experiencing long-term challenges that are impacting your ability to succeed in this course or to stay connected with your team, please reach out to me or your project TA immediately so that we can discuss options.

Remarking Policy

If you believe that your submission has been incorrectly marked, start by consulting with your project TA. Send them email, clearly stating the questions/models/requirements that you want to be remarked. Explain in detail why you believe that your submission deserves more marks than it received. Remark requests must be received within two weeks of when the submission was handed back (ideally sooner), so that your follow-on deliverables are based on correct understanding and expectations for your project.

See also Resources→Exams

Quizzes

There will be three quizzes conducted in the Tutorial time slot/room:

• Friday, Jan 30, 12:30 - 14:20, MC 2038
• Friday, Feb 27, 12:30 - 14:20, MC 2038
• Friday, Mar 20, 12:30 - 14:20, MC 2038

Final Exam

Scheduling: The final exam for this course will be held in-person at a date and time still to be determined by the Registrar’s Office.

• It will be a 2.5-hour closed-book exam.
• Calculators are not allowed.
• You will be assigned a seat for your exam. Please check where you will be sitting in advance of the exam!
• You are required to show your UW Student ID at the final exam.

Conflicts: If you have an examination conflict, complete the Final Examination Timetable Conflict Form on the Registrar’s web site.

Illness: If you are unable to write the final exam due to illness, you should seek medical treatment and provide confirmation of the illness within 48 hours by submitting a completed University of Waterloo Verification of Illness Form, as described below under Accommodations for Illness TODO. There will be no makeup exam. Normally you will receive an INC (incomplete), and must write the final exam in a subsequent term.

Microsoft Teams

We will be using Microsoft Teams as our primary forum for course communications, including announcements, questions, and private team chat. Be sure to pay attention to the Announcements channel for announcements from course personnel.

If you have a question, ask on Teams first.

• You can ask your question in the public Questions channel. The TAs and I will be checking the Questions channel several times a week. If you see a question that has not yet been answered and you know the answer, please “reply” and share your knowledge with your classmates.
• Your team will be provided with a private team channel, which the instructors and your project TA will also have access to. You can ask your question in your private team channel, especially if it relates to your team’s project.
• You can ask private questions to a specific TA or instructor by direct messaging them. You can also send an email to cs445@uwaterloo.ca.
• To book a 15-minute Teams meeting with the instructor or your project team’s TA ouside of your team’s normal Tuesday meetings, email us or DM us on Teams to set up a meeting time that works for everyone.

While online chat tools like Teams provide a convenient way for students to reach TAs/instructors and fellow students, do not expect instanteous answers. Also, Teams does not lend itself to long messages. Keep your questions clear/concise and your comments professional.

Online etiquette is important. I am committed to creating an inclusive learning environment. I ask that all students work with me and the TAs to create a class culture (and Teams culture) based on open communication, mutual respect, and inclusion. As a class we will approach all discussions with respect and civility. Disagreements (e.g. among teammates) may arise, but personal attacks are never OK and will not be tolerated. If I or the TAs err in this regard, please don’t hesitate to reach out and talk with me. We are all learning together.

LEARN

We will use LEARN for submitting deliverables, but that’s about all. Course content will be on this web site.

There is no good single text for this course because the course does not focus on any single methodology or any single type of software system. Therefore, there is no required textbook for this course, but there are several references (which the lectures are drawn from) that are worth reading and having on your bookself.

You can gain free access to online versions of all these references, in a way that you can annotate and highlight your own copy, via the university’s subscription to the O’Reilly Learning platform. Use this opportunity to take a look at these texts and see if any are worth buying. See the course’s Resources Web page for instructions on how to access these references.

• Karl Wiegers and Joy Beatty, Software Requirements, 3ed, Microsoft Press, 2013.
• Ash Maurya, Running Lean, 2ed, O’Reilly, 2012.
• Steve Adolph, Paul Bramble, Alistair Cockburn, and Andy Pols, Patterns for Effective Use Cases, Addison-Wesley Proessional, 2002.
• Mike Cohn, User Stories Applied: For Agile Software Development, Addison-Wesley Professional, 2004.
• Richard Banfield, C. Todd Lombardo, and Trace Wax, Design Sprint, O’Reilly Media, Inc., 2015
• Craig Larman, Applying UML and Patterns, 3ed., Prentice Hall, 2004.
• Lenny Delligatti, SysML Distilled: A Brief Guide to the Systems Modeling Language, Addison-Wesley Professional, 2013.
• Steve McConnell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.
• Steve McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press, 2996.
• Alan Davis, Just Enough Requirements Management: Where Software Development Meets Marketing, Dorset House Publishing, 2005.
• James D. Kiper and Martin S. Feather, “A Risk-Based Approach to Strategic Decision-Making for Software Development,” in Proceedings of the 38th Annual Hawaii International Conference on System Sciences, 2005.
• Michael Jackson. “The Meaning of Requirements”, in Annals of Software Engineering, vol. 3, pp. 5–21 (1997).
• Joachim Karlsson and Kevin Ryan, “A Cost-Value Approach for Prioritizing Requirements.” in IEEE Software, vol. 14, no. 5 (Sep. 1997), pp. 67-74.
• ISO/IEC/IEEE, “Section 9.6: Software Requirements Specification (SRS) content”, in Systems and Software Engineering – Life Cycle Processes – Requirements Engineering, International Standard 29148-2018, November 30, 2018.

Graduate students enrolled in CS645 are expected to do a small library-research project on top of the normal course work. The deliverables of this project are:

• A 12-15 minute video lecture to be presented to the class (comprising a pre-recorded video and slides)
• A 15-20 page written summary of your lecture topic, complete with references

Your project can be on any topic related to requirements engineering, or possibly a more general software engineering topic. Example topics include requirements notations not covered in class (e.g., Alloy, SCR, SysML), requirement-phase activities (e.g., conformance to privacy laws, security requirements, requirements for product lines, or traceability), or an interesting case study.

Topics must have the instructor’s approval.

The graduate lecture is to be just that: a lecture on a course-related topic aimed at an audience that is familiar with requirements-engineering activities and techniques. The topic is expected to be an overview, based on several sources (journals, conference papers, textbooks, etc.). Electronic copies of graduate-student lectures (videos, slides) will be made available below.

This project is worth 10 points of a graduate student’s final mark calculation.

Here are slides from a 20-minute lecture and a writeup of a graduate lecture on Risk Analysis.

It is our intent that students from all diverse backgrounds and perspectives be well served by this course, and that students’ learning needs be addressed both in and out of class. We recognize the immense value of the diversity in identities, perspectives, and contributions that students bring, and the benefit it has on our educational environment.

Your suggestions are encouraged and appreciated. Please let us know ways to improve the effectiveness of the course for you personally or for other students or student groups. In particular:

• We will gladly honour your request to address you by an alternate/preferred name or gender pronoun. Please advise us of this preference early in the term so we may make appropriate changes to our records.
• We will honour your religious holidays and celebrations. Please inform of us these at the start of the course.
• We will follow AccessAbility Services guidelines and protocols on how to best support students with different learning needs.

Students should be aware that this course contains the intellectual property of their instructor, past instructors, TA, and/or the University of Waterloo. Intellectual property includes items such as:

• Lecture content, spoken and written (and any audio/video recording thereof);
• Lecture handouts, presentations, and other materials prepared for the course (e.g., PowerPoint slides, Web pages);
• Questions or solution sets from various types of assessments (e.g., assignments, quizzes, tests, final exams); and
• Work protected by copyright (e.g., any work authored by the instructor or TA or used by the instructor or TA with permission of the copyright owner).

You are allowed to download lecture videos and course materials for your own academic use, but you should not copy, share, disseminate, upload, or use them for any other purpose without the explicit permission of the instructor. For example, do not share this course’s materials with third-party online repositories. Doing so is a violation of intellectual property rights and laws and (depending on the use) may be an academic offence.

Permission from the instructor is also necessary before sharing the intellectual property of others from completed courses with students taking the same/similar courses in subsequent terms/years or sharing them by uploading them to an online repository. In many cases, instructors might be happy to allow distribution of certain materials. However, doing so without explicit permission is considered a violation of intellectual property rights.

Please alert the instructor if you become aware of intellectual property belonging to others (past or present) circulating, either through the student body or online. The intellectual property rights owner deserves to know (and may have already given their consent).

Relevant University policies include:

• Policy 71 - Student Discipline
• Policy 73 - Intellectual Property Rights

The Faculty of Mathematics has guidelines on making solutions available to others, even after you have completed the course. There are significant interactions with various cheating policies that may not be obvious at first glance. Please read them.