Syllabus

for

REQ

Requirements Engineering

Authors: Samuel Fricker, Alex Schneiter

Module Instance: Autumn Term (Herbstsemester) 2021

Version: V6.0 (Changed lecturers, adapted plan)

Date: August 30, 2021

1. Role in Education Programme

1.1 Overview
In a software development project, a shared understanding of users’ and other stakeholders’
needs and how the software system meets these needs is a central success factor. This course
introduces the students to the fundamentals of requirements elicitation, analysis, validation,
and management that allow achieving that shared understanding and familiarises the students
with state-of-the-art requirements specification. The result is a process and methodology of
co-designing a software product together with its important stakeholders

The course is delivered following an iterative Agile-first approach according to the following
sequence that allows to expand from the minimal core of a product definition in the form of a
vision in four iterations to full stakeholder agreement:
1. Product vision: minimal upfront thinking and research needed for streamlining
subsequent iterative work of refining the vision.
2. User needs: contextual inquiry and prototyping to align and validate the solution
concept against the user viewpoints.
3. Requirements specification: UML-based requirements analysis for creating a
requirements backlog specified with state-of-the-art techniques.
4. Stakeholder agreement: analysis, experimentation, and negotiation for finding a value-
creating win-win agreement with stakeholders.

The introduced concepts and techniques are applicable to other software development
lifecycles as well, including Waterfall requiring an up-front requirements specification phase,
and the hybrid Rational Unified Process, which combines phases and iterations.

Requirements Engineering (RE) Practices:

- RE Terminology and Process
- Development of the Vision for a Software System
- Context Analysis
- Prototype- and Scenario-based Workshops
- Development of a software requirements specification (SRS)
- Reviews of Requirements Specifications
- Prioritisation and Effort Estimation
- Managing Requirements and Traceability

Requirements Specification Languages:

- Shall-, User Story-, and Use Case-Templates
- UML Use Case, Class, Activity, and State Machine Diagrams
- Quantification and Operationalization of Quality Requirements

The following figure summarises the theory, techniques, templates, and work results (product
vision, requirements specification, and stakeholder agreement) addressed in the course.
Figure 1: Story map giving an overview of the course contents.

1.2 Dependencies and Prerequisites

The module Requirements Engineering (REQ) requires no knowledge in software engineering
or software development. However, practical experience in using or developing software and
experience in independent learning help students to accelerate learning.

REQ links to the project courses IP1-IP4. REQ enables students to do the kind of requirements
engineering that IP1-IP4 require. At the same time, REQ builds on the experiences that the
students gain in the project track. This parallelism allows students to transfer of Requirements
Engineering theories, models and techniques into practice. IP2-IP4 assumes that the students
have passed the module REQ.

REQ provides knowledge on embedding usability engineering in the broader context of

requirements engineering. The second phase of the REQ course "User Needs" shows the
connections.

REQ provides students with a basic understanding of practical requirements engineering and
the commonly used elements of the UML specification language. The students perform a
hands-on assignment in groups throughout the course that allows training of such
requirements engineering and modelling.
1.3 Additional Perspectives for the Students
A part of REQ is based on learning objective of the International Requirements Engineering
Board (IREB).

2. Learning, Teaching, and Assessment

2.1 Method
Classroom lectures: REQ follows the principles of problem-based learning: it introduces
concepts that are useful to solve real-world problems, offers practice in solving ill-defined
problems, and reflects together with the students on what they have have experienced and
learned in requirements engineering.

Group Work: REQ motivates teamwork and in-depth discussion among students regarding
certain topics of the course.

Hands-on training in groups: the development of a requirements specification as teamwork.

The hands-on training is done for a topic selected by a team of about 4 students (3 or 5 as
exception).

PLEASE NOTE: Students need to invest a significant part of their 45h unaccompanied self-
studies in the hands-on training project, where the introduced concepts and techniques are
applied.

Independent studies: REQ allows the student to develop an ability to learn independently,
which is a necessary skill requirement for each engineer. The students receive example exams
to prepare for the examinations. The students may voluntarily submit unsolicited exercises and
work results of applying the learned course material at any time for obtaining feedback.

Contact with the lecturers: The contact between students and lecturers typically takes place
during the actual lecture. Typically, such a lecture consists of 2x45 minutes of input from the
lecturer and 1x45 of group work. In case of questions, students can also reach the lecturer via
electronic media.

Media: Active Directory (AD) is used to share content with the students.

2.2. Summary of Student Efforts

Lectures including exam: approx. 15x2h

Accompanied group-work during lectures approx. 15x1h
Unaccompanied self-studies beyond the lectures: 45h

Total effort: 90h (3ECTS)

2.3. Assessment and Grading

Hands-on group work: final submission at the end of the semester. Pre-defined rubrics are
used for grading. Insufficient work is graded with a score of 1.0 (ECTS F). An additional
submission is required in the middle of the semester for which the lecturers offer feedback but
no grading.

Individual examination: each student writes two exams. The first exam has a relative weight of
40%, the second 60%. An insufficient average, i.e., the weighted average of the two exams of
less than 3.75, is graded with a score of 1.0 (ECTS F). Students with insufficient grades close
to 4.0, e.g. 3.75 or higher (ECTS FX), will be invited to an optional oral exam for raising their
grade to 4.0, hence avoid the ECTS F grade.

Diagnostic tests are used for self-assessment of the student’s personal level of knowledge and
are not included in the course grade.
The module REQ is passed, if both the hands-on group work and the individual examination
grade is positive. Each part is weighted by 50%. The grade is rounded to 1/10.

2.4. Course Literature and other Teaching Material

The course is supported by:
- Written Script (German or English)
- Interactive Lectures (German or English)
- Videos of Case Studies (English)

Optional learning support can be obtained by:

- IREB Glossary of RE terms (note: the definitions provided in the course supersede the
IREB definitions).
o English: https://www.ireb.org/content/downloads/2-cpre-glossary-2-
0/ireb_cpre_glossary_en_2.0.pdf
o German: https://www.ireb.org/content/downloads/2-cpre-glossary-2-
0/ireb_cpre_glossary_de_2.0.1.pdf
- References to literature

To accelerate the effectiveness of the lectures, the students are invited to prepare lessons with
preparatory reading. Knowledge and understanding of the course contents may be examined
without announcement.

3. Semester Plan (Draft; Subject to Change, e.g. due to Covid-19 Pandemic)

The lecturers of the course have specific responsibilities.
- Individual Examination: Samuel Fricker
- Hands-on group work: Samuel Fricker

The specific instructions of the responsible evaluator have to be followed. Other consultations
only have informal character.

Please note that the current plan may change due to corona measures.

Week, Lecturer Topic

1 SFR Introduction to the course
(KW38) - Requirements Engineering: fundamentals, motivation, and scope
- Ideas vs needs vs goals vs requirements (functional and ISO/IEC 25010 quality) vs
constraints
- Structure of a requirements specifications and their variants
- Template: story map for release planning
- Template: backlog of things to do
- Burndown chart

Hands-On Training*:
- Set up Groups of 4-5
- Select tools for release planning and managing the hands-on backlog
- Define a release plan for the requirements specification of an own innovative
software product: when will which section be written?

Reading*:
- Script, §1
2 SFR Creativity: background research and the generation of ideas
(KW39) - Market and technology research
- Creativity theory and techniques

Hands-On Training*:
- Conduct market research: what have others done?
- Conduct technology research: what could give us an advantage?
- Generate ideas and select the best one(s)

Reading*:
 - Script, §2
3 SFR Innovation: vision pitches and requirements elicitation
(KW40) - Role and structure of a vision statement
- Template: vision statement covering problem, goals, concept, and differentiation
MILESTONE: - Stakeholders and requirements elicitation for refining the vision
ITERATION I - Vision pitches
Product Vision
Hands-On Training*:
- Define and present a product vision
- Plan requirements elicitation involving real users
- Adapt vision to account for feedback

Reading*:
- Script, §3
4 ASC Elicitation of user needs and definition of value propositions
(KW41) - Goal reasoning
- Contextual inquiry for eliciting the user viewpoints
- Overview and selection of elicitation techniques
- Template: Persona for characterising the jobs-to-be-done, backgrounds, and needs
of a user group
- Template: Value Proposition Canvas for exploring product-user fit with pain relief
and gain creation provided by your product features
- Template: Feature Specification

Hands-On Training*:
- Interview real users for eliciting their viewpoints (online if needed)
- Specify the user viewpoints, incl. their jobs-to-be-done, background, and needs
- Propose the features needed to provide desired value to the user

Reading*:
- Script, §4
5 ASC Analysis: design of a solution concept with a storyboard and prototype
(KW42) - Process reasoning
- Moodboards for state-of-the-art analysis with system archaeology
- Storyboards for visualising the process of where and how the product will be used
- User interface prototypes

Hands-On Training*:
- Design the storyboard of how your product should be used
- For each feature:
o Create a moodboard showing how other solutions do the same
o Design the feature and refine its specification
- Design a prototype for your product that integrates the features

Reading*:
- Script, §5
6 SFR+ASC Requirements checking I: validation of solution concept with a storyboard and prototype
(KW43) - Requirements quality: quality of content
- Prototyping for approximating reality
MILESTONE: - Sampling strategies for determining user representatives
ITERATION II - Validation with a walkthrough of the storyboard and prototype
User Needs
Hands-On Training*:
- Validate prototype by walking though storyboard with real users (online if needed)
- Finalise the user viewpoints
- Finalise the winning solution concept (vision statement, prototype, storyboard)

Reading*:
- Script, §6
EX1 ASC **Exam 1 covering lectures 1-6
(KW44)
Hans-On Training:
**Pitching of Vision, Prototype-based Storyboards, Definition of Users, Validation
Results, and Release Plan
7 SFR Specification I: functional requirements in natural language
(KW45) - Transformational effects in the interpretation of requirements
- Common requirements attributes
- Templates: Cohn’s user stories, shall sentences
- Template: Glossary
 Hands-On Training*:
- For each feature, specify the functional requirements with user stories
- Create a glossary
Reading*:
- Script, §7
8 SFR **Diagnostic Exam on UML
(KW46)
Specification II: functional requirements in UML
- Application of human-computer interaction to requirements specification
- Separation of system and context
- UML diagrams: use case diagrams, activity diagrams
- Template: use case specification with simple active sentences

Hands-On Training:
- Identify external systems and specify their viewpoints, incl. features and interfaces
- Sort your functional requirements according to features
- For each feature, give an overview of the functions with a use case diagram and
specify each of these use cases
- For each use case, specify the detailed functions with user stories. Match them
with the steps of the use case scenarios
- **End of week: Submission of the Requirements Specification

Reading*:
- Script, §8
9 SFR Requirements Checking II: verification of functional requirements
(KW47) - Model theory
- Requirements quality: quality of documentation
Lecturer to be - Template: review form
confirmed
Hands-On Training*:
- Review your requirements specification
- Improve the requirements to account for the review findings

Reading*:
- Script, §6

Project Week

10 SFR Specification III: data and behavioural requirements in UML

(KW49) - Domain models
- UML diagrams: class diagram, state-transition diagram
MILESTONE:
ITERATION III Hands-On Training*:
Requirements - For each feature, specify data relevant for users with class diagram
Specification - For each important class, specify the behaviour of the class

Reading*:
- Script, §8
11 SFR Specification IV & requirements checking III: quality requirements, incl. their validation
(KW50) - Risk-based assessment of requirement criticality
- Quality-impact reasoning with the QUPER model
- Determination of quality thresholds for quantification of quality requirements
o Based on positioning in the market
o Experimental evaluation of quality-impact
- Template: PLANGUAGE

Hands-On Training*:
- Select the most critical quality requirement
- Determine quality threshold with market positioning and experimentation
- Specify the quality requirement with PLANGUAGE

Reading*:
- Script, §9
12 ASC Requirements negotiation I: stakeholder viewpoints
(KW51) - Introduction to the nature of win-win negotiation: finding a value-creating
agreement with the product stakeholders
- Template: identifying and sorting stakeholders with the onion model
- Force field analysis for stakeholder prioritisation

Hands-On Training
 - Identify your stakeholders with the onion model and decide how to involve them
- Specify the stakeholder viewpoints, incl. their background and needs

Reading
- Script, §10

New Year Holidays

13 SFR Requirements negotiation II: prioritisation

(KW2) - Pre-requirements traceability between stakeholders and requirements
- Post-requirements traceability between requirements and project work results
MILESTONE: - Kano model for reasoning about requirements impact
ITERATION IV - Cost-value prioritisation with top-10, grouping, and pairwise comparisons
Stakeholder - Template: Wiegers’s multi-criteria matrix
Agreement - Template: value/cost diagram
- Requirements quality: quality of agreement
- Stakeholder satisfaction analysis
- Release planning with minimal viable product

Hands-On Training
- Prioritise your requirements from the viewpoints of the end-users, investor, and
development team
- Define the release plan for your product focusing on the MVP

Reading
- Script, §11
EX2 ASC **Examination II: Individual Written Exam Covering Lectures 7-13
(KW3)
Hans-On Training:
** Submission of Hands-On Requirements Documentation

SFR: Samuel Fricker. ASC: Alexander Schneiter.

The assignment of lecturers to lectures can change during the term.

* Ideally you can conduct the described tasks until the next req lecture. Always document the results in
your SRS. These are no hard deadlines, and sometimes you will need a bit longer.
** Mandatory, hard deadlines. You can always submit it earlier. If you do not submit on-time you will not
have a positive grade.