DTU Course 02264

The DTU course "Requirements Engineering" (02264) has been taught annually since 2009. It has evolved into its current form over the years, and gave rise to the RED family of tools.

At DTU we are committed to practical, hands-on teaching. For RE that means, we have to have a realistic case study and a realistic tools. However, existing tools are really not very well suited for teaching. They take a great deal of effort to use, and all modeling concepts are integrated in a meta-model that is truly comprehensive and consistent: field name on the user interface correspond directly to attribute names in the meta-model, and those names are also used in the teaching material. Using RED, thus, reinforces the educational content automatically.

The course page for DTU 02264 “Requirements Engineering” are found here. It contains PPT slides, case studies for student group work, exercises, and exam questions (with answers), but is reachable only for DTU students. However, it makes no sense to make RED open source but not the course material. So we are gradually publishing that content as open source, too.

In the long run, there will be a course page with all the relevant content. As a first step, we are here publishing the slides as the main building block of a RE course.

Course outline

The course is organized into 13 chapters to (roughly) correspond to the 13 weeks of terms at DTU. The Lecture Material can be downloaded and is licensed under the Apache 2.0 license.

• Chapter 1: Introduction is mainly to provide an overview and motivate students to participate. The famous SE disaters we discuss will serve as illustrative examples throughout the course.
• Chapter 2: Requirements Elicitation covers the claassic processes and and techniques of collecting and creating requirements.
• Chapter 3: Interaction Design and Validation covers the elicitation of requirements in UI-centric software. This topic is ideal to quickly immerse students in their case studies.
• Chapter 4: Stakeholders and Goals covers the more high-level or "political" angles of system construction, which are so often the source of trouble.
• Chapter 5: System Context and Structure covers the classic context view, and refines it to a high-level structural decomposition. This facilitates initial validation, division of labor, and scoping of work.
• Chapter 6: Requirements QA covers a borad range of techniques from time-tested classics like inspections to advanced techniques. Placing this chapter early is critical to allow the third level of feedback (see below).
• Chapter 7: Specifying Features covers use cases, textual requirements, templates, scenarios and stories. We make a point of providing a toolbox of alternatives to choose from, depending on constraints.
• Chapter 8: Specifying Quality Attributes covers non-functional requirements using the latest ISO terminology.
• Chapter 9: Function and Process Modeling covers lower level specification techniques bordering on design. The models are tied to the structural models and behavioral models of chapters 5 and 7, respectively.
• Chapter 10: Information Modeling covers the data aspect, and ties in with structural models and behavioral models of chapters 5, 7, and 9, respectively.
• Chapter 11: Transition to Design covers the next steps of the logical life cycle and introduces the stitching technique, one of RED's prominent features.
• Chapter 12: Requirements Management covers the ongoing challenges of handling requirements in long-lasting projects.
• Chapter 13: Closure reviews the previous chapters, establishes the connections once more, and extrapolates existing trends into the future to raise the students' awareness for new and advanced topics.

Chapters 1 and 13 are covering only one lecture of 90 minutes each. Chapters 2 to 12 are designed to cover 1 week of the term time, which includes two lecture slots of approx. 60-90 minutes, practical exercises in class of about 3h, and homework worth 10-15h per week on average. Together, the course earns successful students 10 ECTS points over a 13 week term.

Course organisation

The course is restricted to specification and validation, it does not enter the software production phase. Clearly, this makes it very important to give very large amounts of feedback, and the course does this in thress ways.

1. Peer Instruction The first level of feedback is given by the students themselves: they work in groups of 4 to 6 on their respective case studies, and discuss their questions and issues in the group first. Additionally, Teacher and TAs supervise the group work sessions and offer advice directly.
2. Plenary Feedback After every group work session, the teacher selects 2-3 groups with interesting or common problems or approaches. The groups present their work result and discuss it with the class.
3. Cross Group Inspections Throughout the term, there are two occasions where students are re-shuffled into new, temporary review teams across continuous groups to conduct Fagan-style inspections on each other's work.

Case Studies

Over time, many different case studies have been used in this course, ranging from claassic "boring" ones (coffee machine, ATM, travel booking) to visionary devices like the infamous tricorder. They all work, and it does not really matter.

There is no need for "real" clients to represent the case to the students, i.e., volunteers from an application domain. In fact, real clients usually do much more harm than good as they introduce bias towards domain if not company specific issues. Their availability is usually inadequate, and lack understanding of the needs of academic teaching. the downloads section contains some sample data files.