Course Outline for SE463 - Spring 2016

Course Times and Locations

Lectures:	Tu-Th 10:00-11:20, MC 4058 Tu-Th 1:00-2:20, DWE 3516
Tutorials:	Mon 2:30-3:20 (on select weeks), MC 4058 Mon 3:30-4:20 (on select weeks), MC 4042

Course Instructor
    Joanne Atlee
   DC 2337
   519-888-4567 x34871
   jmatlee@uwaterloo.ca
   OFFICE HOURS:
           Mondays 3:00-4:20, or by appointment

Teaching Assistants

Name	Office	Email
Sandy Beidu	DC 2551A	sbeidu
Manish Chauhan	DC 3587	m5chauha
Kristen Morgan	DC 3335	k7morgan
Bryan Muscedere	DC 2551A	bmuscedere
Rafael Olaechea	DC 3587	rolaechea
Ivens Portugal	DC 2517	iportugal
Parsa Pourali	DC 2551B	ppourali

Calendar Description

Introduction to the requirements definition phase of software development. Models, notations, and processes for software requirements identification, representation, validation, and analysis. An important component of the course is a group project: the software requirements specification of a large software system.

Required Background

Knowledge of finite-state machines (e.g., as used in CS 241 or ECE 251)
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 103)

Overall Goals

SE463 exposes students to the problem of determining, or deciding, what a proposed software system should do. That is, it focuses on identifying the problem to be solved by software. In this sense, the course is very different from other CS/SE courses, which tend to focus on knowledge and techniques that lead to software solutions. There are some nontechnical aspects of the course, with respect to communication and negotiation. However, most of the course covers technical approaches to the requirements problem, such as notations for modelling and documenting requirements, strategies for prioritizing requirements, and techniques for analyzing and verifying documented requirements.

Learning Outcomes

Ability to separate requirements from specifications from domain assumptions, and argue that a specification + domain assumptions satisfy requirements
Ability to elicit requirements using different strategies
Ability to model requirements in a variety of modelling paradigms
Ability to elicit and document nonfunctional requirements, such that the to-be-developed software can be objectively tested for their satisfaction
Ability to prioritize requirements using AHP
Ability to explain and compare different techniques for validating and verifying a requirements document

Course Readings

The lecture material is structured around a collection of book chapters and papers that cover different aspects of requirements elicitation, modelling, and analysis. All materials are available online, either from IEEE Reference Shelf, ACM Digital Library, or Safari OnLine@UW:

Robertson, S. and Robertson, J., Mastering the Requirements Process, 3rd ed., Addison-Wesley Professional, 2012.
Larman, C., Applying UML and Patterns, 3rd ed., Prentice Hall, 2004.
McConnell, S., Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.
Wiegers, K. and Beatty, J., Software Requirements, 3ed, Microsoft Press, 2013.
Jackson, M. and Zave, P. "Deriving specifications from requirements: an example", in Proceedings of the 17th International Conference on Software Engineering (ICSE), 1995, pp. 15-24.
Mavin, A. et al., "EARS (Easy Approach to Requirements Syntax)", in Proceedings of the 11th IEEE International Requirements Engineering Conference (RE), 2009, pp. 317-322.
Berander, P. and Andrews, A., "Requirements Prioritization", in Engineering and Managing Software Requirements, Aurum and Wohlin (eds.), 2005.
Karlsson, J. and Ryan, K. "A Cost-Value Approach for Prioritizing Requirements." in IEEE Software, vol. 14, no. 5 (Sep. 1997), pp. 67-74.
J. D. Kiper and M. 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.
Rumbaugh et al., UML Reference Manual, 2ed (available via Safari Online@ UW), Chapter 7: "State Machine View", Addison-Wesley, 1999.
Huth and Ryan, Logic in Computer Science: Modelling and Reasoning about Systems, Ch. 3.2 "Linear Temporal Logic", Cambridge University Press, 2004.
McConnell, S., Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.

General Overview of Topics to be Covered

The course covers the four major phases of the software requirements process: elicitation, modelling, analysis (e.g., prioritizing requirements, detecting conflicting requirements, risk analysis), and documentation. The phases are broken down into 12 topics, each of which is 1-3 lectures long. Each topic 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 required topics to be covered in every offering of this course, and the expected number of lecture hours needed to cover the topic. The topics need not be taught in the order in which they are listed below. The only real constraint on topic order is that each project-related topic should be covered at least two weeks before the corresponding project deliverable is due.

1. Introduction (1 hours)
Course philosophy and logistics. Why requirements analysis is hard.

2: Requirements Engineering Reference Model (3 hours)
Context diagram. Identifying or determining a system's interfaces. Monitorable inputs and controllable outputs. Requirements vs. specifications.

3: Requirements Elicitation (4.5 hours)
Stakeholders, sources of requirements, strategies for identifying requirements.

4: Domain Modelling (1.5 hours)
Modelling of the system's environment. Entity-relationship diagrams. UML Class and object diagrams.

5: Functional Requirements and Specifications (3 hours)
Lightweight modelling (Use-case diagrams, Activity diagrams, Process models). Functional requirements.

6: Behavioural Modelling (7 hours)
Modelling dynamic behaviour of a software system. Use cases, scenarios, sequence diagrams. Extended state machine models, including state hierarchy, concurrent regions, communication, activities, history. UML State Machines.

7: Constraint Modelling (1.5 hours)
Temporal Logic. Specification patterns.

8: Requirements Analysis (6 hours)
Requirements triage and prioritization. Cost-benefit analysis. Analytic Hierarchy Process. Conflicts and negotiation. Cost Estimation. Risk Analysis.

9: Quality Requirements (1.5 hours)
Nonfunctional requirements (e.g., performance, security, useability, maintainability). Fitness criteria. User-interface requirements.

10: Validation and Verification (3 hours)
Walkthroughs, inspections, technical reviews of requirements documents. Executable specifications. Automated analysis. Verifying that specifications satisfy requirements.

11: Documenting Requirements (1.5 hours)
Expected contents and organization of a Software Requirements Specification (SRS). Nontraditional means for documenting requirements (e.g., user manuals, test cases).

12 Other Topics (3 hours)

Course Deliverables

The course content is delivered via lectures (3 hours a week) and reading material. The course covers techniques for performing various requirements-related tasks (elicitation, modelling, analysis, documentation), with a heavy emphasis on modelling. Students apply these techniques as they work on the course project.

The course project consists of a number of requirements-related activities and artifacts as applied to their Software Engineering Fourth Year Design Project. If a student's FYDP is not suitable as a requirements project (i.e., it has few stakeholders, offers little new functionality, focuses mostly on improving nonfunctional properties like performance), then he or she will be given an alternate project. Part of the project is the students' professional interactions with their projects' stakeholders.

1%	Fri. May 13 12:00 PM	Team membership; Problem statement; Purpose
3%	Wed. May 18 12:00 PM	Stakeholders; Context diagram; Use case diagram (with brief use-case descriptions)
5%	Wed. May 25 12:00 PM	Domain model
3%	Wed. June 1 12:00 PM	Lightweight process model for up to 5 use cases; Scenarios (3 x number of team members); Indicate the sources of each process model and scenario
5%	Wed. June 8 12:00 PM	Functional requirements; Indicate the sources of each requirement
5%	Wed. June 15 12:00 PM	AHP Prioritization of functional requirements; Indicate the stakeholders involved
3%	Wed. June 22 12:00 PM	Functional specifications; Assumptions; Indicate the stakeholders involved
3%	Wed. June 29 12:00 PM	Nonfunctional requirements; Indicate the sources of each requirement
4%	Wed. July 6 12:00 PM	Risk Analysis; Indicate the sources of each Risk, Impact assessment, Countermeasure, Effect assessment
10%	Wed. July 20 12:00 PM	Prototype (Storyboards, Executable, Behaviour Model); Evaluations by 5 stakeholders
3%	Tue. July 26 12:00 PM	Cost Estimation

In addition, 5% of the course marks will be based on the students' professionalism in their interactions with their projects' stakeholders, the peer evaluations that they write, and their teammates' evaluations of their performance.

Tutorials (1 hour a week) on select weeks during the term. Tutorials are used to discuss the deliverables of the course project. A majority of these tutorials cover extra examples of modelling notations used in the course.

Late Policy

Each team has a total of 5 late days that it can apply to the course deliverables, in any manner that it chooses (e.g., 1 late day to 5 deliverables, 5 late days to 1 deliverable). Note that feedback on deliverables that are submitted late is likely to be returned late.

Assignment Submission and Pickup

All project deliverables in this course will be submitted electronically. Feedback from course personnel will also be provided electronically (through MarkUs).

Assessment

The marking scheme is as follows:

Project (11 deliverables) 45%

Project professionalism 5%

Final Exam 50%

The final exam is weighted 50% of a student's final mark, to conform to an ECE Department policy. Students must pass the final exam to pass the course. Final grades will be computed as follows:

           Normal% = 0.45*Project% + 0.05*Professionalism + 0.50*FinalExam%
           IF FinalExam% < 50%
            FinalGrade = min{Normal%, FinalExam%}
           ELSE
           FinalGrade = Normal%

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. Refer to the Academic Integrity website for details.

Discipline

A student is expected to know what constitutes academic integrity to avoid committing an academic offence, and to take responsibility for his/her actions.

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.

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.

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 he/she has a ground for an appeal should refer to Policy 72 (Student Appeals).

Notes for students with disabilities

AccessAbility Services, located in Needles Hall, Room 1132, 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.