NEW or RECENT	Date	Description

☛		Various “goodies” (lecture notes, quiz questions, project description, enrichment study requirements document, research documents, etc.) will be posted from time to time. The place to check for this is: click here.

Course Description

Requirements engineering (RE) covers the activities of discovering, eliciting, negotiating, modelling, analysing, documenting, prioritising, and selecting a set of requirements to denote a desired solution for the envisaged computer-based system. This includes such issues as feasibility analysis, quality attribute analysis, benchmarking, competitive product analysis, market predictions, requirements degradation analysis, alignment with cooperating systems.

For on-going evolution of an existing system, RE also includes analysis of the existing system and its old requirements. RE also involves maintaining the validity of the existing system requirements and keeping them under version and configuration control. Requirements essentially form the reason why specific functionality (or features) is implemented in the system in first place to deliver the system’s anticipated behaviour. Thus, there are explicit and implicit links between the system’s implementation and the requirements that relate to the traceability of software artefacts.

In order to ensure that RE activities are effective and cost optimal, the RE process needs to be managed and improved on an on-going basis. The use of the term “engineering” implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant, etc.

RE is generally a front-end part of a software development process, which enables analysts to define what the operational context (where the system is supposed to run) is desired to be. It also helps to define what a software system is required to do and what the system’s expected bahaviour is under what operational circumstances.

However, refinements of the initial (often high-level) requirements may be driven by the constraints posed by such issues as: precisely what the stakeholder needs at the time of design and implementation, the existing system and infrastructure, development timeframe, developer expertise, the components and systems available in the marketplace, etc. As can be seen, RE is a complex process!

In this course, students will:

1 study how to elicit, analyse and validate requirements,

2 study different types of requirements,

3 study methods for formulating software requirements,

4 study issues related to requirements management,

5 study models of requirements, and

6 learn about requirements processes and the roles of the people involved.

Students will also carry out assignments and projects in requirements engineering related to the concepts taught in the lectures. There shall be teamwork as well as individual work. There is an enrichment study, for “bonus” marks, for those undergraduate students (cs 4473a) who choose to conduct a minor research study. For graduate students (cs9551a), the enrichment study is mandatory.

Prerequisites

· CS3307 -- Object-Oriented Design and Analysis

· IMPORTANT: The students are expected to be proficient in the use of UML, in modelling a software system using UML, and in using related tools (e.g., Rational Rose).

· Also, please note the following regulation from the university:

Unless you have either the requisites for this course or written special permission from your Dean to enroll in it, you will be removed from this course and it will be deleted from your record. This decision may not be appealed. You will receive no adjustment to your fees in the event that you are dropped from a course for failing to have the necessary prerequisites.

Textbook & Lecture Notes:

1 Required Text book:

· Gerald Kotonya and Ian Sommerville: Requirements Engineering – Processes and Techniques, Wiley, 1998. ISBN: 978-0-471-97208-2

2 Supplementary Text books:

· Chapters 1-4, Software & Systems Requirements Engineering – In practice, by Brian Berenbach, Daniel Paulish. Juergen Kazmeier, Arnold Rudorfer, McGraw Hill, 2009. QA76.758.S6452 2009

· Chapters 2 & 4, Requirements Analysis and System Design – Developing Information Systems with UML, by Leszek A. Maciaszek. Addison Wesley, 2005. Available from the library.

· Ian Sommerville and Pete Sawyer: Requirements Engineering – A Good Practice Guide. Wiley, 1997.

· Eric J. Braude: Software Engineering – An Object-Oriented Perspective. Wiley, 2001.

· Leszek A. Maciaszek: Requirements Analysis and System Design – Developing Information Systems with UML. Addison Wesley, 2005.

· Len Bass, Paul Clements and Rick Kazman: Software Architecture in Practice, 2nd edition, Addison-Wesley, 2003.

· Roger Pressman: Software Engineering - A Practitioner’s Approach, 5th edition, McGraw Hill, 2001.

Student Evaluation

(1) Student evaluation consists of the breakdown shown in the table below.

(2) All material covered in the course (including lectures, books and other cited resources) is examinable.

(3) The teaching staff reserve the right to adjust (lower or raise) a particular student’s marks based on their judgment of the student’s participation in the course and on the articulated knowledge and understanding of the subject matter during the term.

(4) In the team project, a group member’s marks in the project will be weighted by his or her participation and significance levels, judged anonymously by the group peers, as frequently as deemed necessary by the teaching staff during the project – with the group maximum being the weight of one during any single measure.

(5) The grading criteria and detailed conditions, as applied to each evaluation component, will be described on the assignment/project/test/exam as appropriate.

(6) The date for the quiz and class test will be notified (on the course web page and/or in the lecture room) beforehand. Those who do not take the quiz/test will unfortunately receive zero marks (exceptions only as per the university policy).

(7) Late submissions of assignments and projects will not be accepted, so please be forewarned to commence tasks upon assignment.

(8) If for any reason an evaluation component tabulated below cannot be adhered to by the teaching staff, the rest of the marks will be prorated.

(9) For groupwork, as a matter of policy, teams will be formed by the staff, generally based on random assignment. This may not be appealed.

Component	Weight	Configuration	Dates*
Assignment 1: Read Ch.1, 3, 4, 8 – Kotonya & Sommerville.	0 to -5%	Individual	September
Assignment 2: Read Ch. 1-4 – Berenbach, et al.	0 to -5%	Individual	October
Assignment 3: Read Ch. 2, 5 -- Kotonya & Sommerville.	0 to -5%	Individual	October
Assignment 4: Read Ch. 6 -- Kotonya & Sommerville.	0 to -5%	Individual	November
Assignment 5: Read Ch. 7, 9 -- Kotonya & Sommerville.	0 to -5%	Individual	November
Assignment 6	15%	Team work	Sep. 20-Oct 4
Assignment 7	15%	Team work	Oct. 4-Oct. 18
Quiz	15%	Individual	October- November. (exact date to be announced a week beforehand)
Project: Requirements elicitation, analysis, validation, and documentation	30%	Team work	Oct. 18-Nov. 30
Class test	25%	Individual	Nov. 10
Enrichment Study**	20%**	Individual	Last day of lecture

* The stated dates are approximate and are subject to change. Changes will be announced in the class.

** Mandatory for cs9551 graduate students; overall course grade will be normalized to a maximum of 100%.

For cs4473 undergraduate students, the Enrichment study is Optional (bonus of 20% of the course). Yes, you can “shoot” for 120% though the university will only record up to a maximum of 100%. More importantly, if you so choose, you will get a letter of reference of some significance from me to your prospective employer/supervisor AND will learn a great deal through an enrichment study. I highly recommend it! Studies and experience show that those who are self-motivated and do projects “outside the box” are preferred by organizations and for entry into graduate schools.

There will be no makeup Quiz or Test. For students requesting a Special Quiz or Test for religious reasons, they must have notified, by email, the course instructor at least 2 weeks prior to the Quiz or Test.

If you miss the Quiz or Test for any other reason, follow the procedure for Academic Accommodation for Medical Illness. If accommodation is approved by your Dean’s office, the Quiz or Test component will be redistributed to the other evaluation components of the course.

Email Contact

We will occasionally need to send email messages to the whole class, or to students individually. Email will be sent to the UWO email address assigned to students by Information Technology Services (ITS), i.e. your email address @uwo.ca or to your Computer Science Departmental email address. It is each student’s responsibility to read this email on a frequent and regular basis, or to have it forwarded to an alternative email address if preferred. See the ITS website for directions on forwarding email.

However, note that email at ITS (your UWO account) and other email providers such as hotmail.com or yahoo.com establish quotas or limits on the amount of space available to you. If you let your email accumulate there, your mailbox may fill up and you may lose important email from your instructors. Losing email is not an acceptable excuse for not knowing about the information that was sent.

Academic Accommodation for Medical Illness

· for work representing 10% or more of the overall grade in the course:

If you are unable to meet a course requirement due to illness or other serious circumstances, you must provide valid medical or other supporting documentation to your Dean's office as soon as possible and contact your instructor immediately. It is the student's responsibility to make alternative arrangements with their instructor once the accommodation has been approved and the instructor has been informed. In the event of a missed final exam, a "Recommendation of Special Examination" form must be obtained from the Dean's Office immediately. For further information please see: http://www.uwo.ca/univsec/handbook/appeals/medical.pdf

A student requiring academic accommodation due to illness should use the Student Medical Certificate when visiting an off-campus medical facility or request a Record's Release Form (located in the Dean's Office) for visits to Student Health Services. The form can be found here: https://studentservices.uwo.ca/secure/medical_document.pdf

Accessibility Statement

Please contact the course instructor if you require material in an alternate format or if you require any other arrangements to make this course more accessible to you. You may also wish to contact Services for Students with Disabilities (SSD) at 661-2111 x 82147 for any specific question regarding an accommodation.

Ethical Conduct

Scholastic offences are taken seriously and students are directed to read the appropriate policy, specifically, the definition of what constitutes a Scholastic Offence, at the following Web site: http://www.uwo.ca/univsec/handbook/appeals/scholoff.pdf.

For individual assignments, you are encouraged to engage in problem understanding with other class students, staff or third-party resources; however, the solution and the actual details of the work must be your own individual effort.

The standard departmental penalty for assignments that are judged to be the result of academic dishonesty is, for the student's first offence, a mark of zero for the assignment, with an additional penalty equal to the weight of the assignment also being applied. You are responsible for reading and respecting the Computer Science Department's policy on Scholastic Offences and Rules of Ethical Conduct .

The University of Western Ontario uses software for plagiarism checking. Students may be required to submit their written work and software in electronic form for plagiarism checking.

Topics

Lecture topics, readings, etc.***	Default Ref: Kotonya & Sommerville

Introduction	Chapter 1
Requirements Elicitation & Analysis	Chapter 3
Requirements Validation	Chapter 4
Non-functional Requirements	Chapter 8
Requirements Engineering Process	Chapter 2
Requirements Management	Chapter 5
Methods for Requirements Engineering	Chapter 6
Viewpoint-oriented Requirements Methods	Chapter 7
Interactive System Specification	Chapter 9

*** Please note that the topics listed above are a general guideline. Due to the course dynamics, this can vary.

Back to the top of the document.