Mail: stefan.bente@th-koeln.de
Tel.: +49 2261 8196 6367
Skype: stefan.bente
Discord Server
Steinmüllerallee 4
51643 Gummersbach
Gebäude LC4
Raum 1708
Sprechstunde nach Vereinbarung
Terminanfrage: calendly.com Wenn Sie dieses Tool nicht nutzen wollen, schicken Sie eine Mail und ich weise Ihnen einen Termin zu.

Training Units for Requirements Engineering

Requirements Engineering can be seen as a collection of methods, tools, and good practices, which follow a certain canonical sequence. This page presents a pragmatic process model, and training units for its steps. You can use this model as a guideline for your own RE projects, and adapt it where useful.

Process Model

There is no universally agreed process model for Requirements Engineering (i.e. a framework that proposes a sequence of steps). Therefore, I have proposed the following “pragmatic” model, based on literature research and own practical experience.

Feel free to adapt and customize this model in own projects. It also serves as base for the method training units that we will go through in the RE course. These blocks are explained below.

Process Model

Method Trainings

The following sections list five blocks of method trainings.

  • These trainings will be created by the students in the course.
  • Each subteam will take over one block.
  • Content and rough structure is provided as part of the course material (see below).
    • Same goes for some literature to start from.
  • The trainings should focus practical exercises rather than theory. This means:
    • Make sure that the relation between “powerpoint presentation” and “the group works an exercise” is at least 1/3 - 2/3
    • better: 1/4 - 3/4
  • Provide a short cheat sheet for you course mates when preparing the training.
    • Here is the template that you can use.
    • Hard rules: Max. 2 Pages! No change of font size (11 pt) or line height!

Block 1: Context

1) Analysis of stakeholders, system context, and goals

Training: Sponsor & stakeholders
  • Motivation: What do I need this for?
  • Term Definition
  • Guiding questions to find stakeholders
  • Stakeholders vs. stakeholder roles
  • Techniques for prioritizing / classifying stakeholders
  • Necessary data to capture & document
Training: System context
  • Motivation: What do I need this for?
  • Term Definition
  • Difference context / system boundary
  • System context elements, and how to find them
Training: Interview techniques
  • Motivation: What do I need this for?
  • Good practices for preparing and conducting an interview
  • Structuring a questionnaire
  • Documenting and evaluating the results
Training: Goals
  • Motivation: What do I need this for?
  • Term Definition
  • Rules for goal wording
  • Methods for structuring goals (e.g. fishbone diagram)

Block 2: Continuous Activities

2a) Glossary & Domain Model

Training: Glossary
  • Motivation: role of ubiquitous language according to Evans
  • Method "noun analysis"
  • Governance for maintaining a glossary
Training: Domain Model
  • Motivation: benefits of a domain model
  • Domain Model as simple UML Class Diagram
  • Use of Multiplicities
Training: Entity Status Model
  • Motivation: States of a domain object
  • When to use state model?
  • Modelling states as UML State Diagram

2b) Quality Assurance

Training: Quality assurance methods
  • Motivation: What do I need this for?
  • Quality criteria for requirements
  • Principles of quality assurance
  • Continuous quality assurance (e.g. definition of done)
  • Review methods

Block 3: Informal Requirements

3) Informal Requirements

Training: Requirements capturing methods
  • Motivation: What do I need this for?
  • Four types of requirements capturing methods
  • What to use when?
  • Creativity techniques as workshops
Training: Surveys
  • Motivation: When to use surveys?
  • Empirical aspects
  • Questionnaire design
  • Tools
Training: Personas
  • Motivation: What are personas good for?
  • Persona templates - when to use what
  • Do's and Don'ts
  • Techniques for developing personas
Training: Scenarios
  • Motivation: benefits of scenarios
  • Classification: scenario types - when to use what?
  • Examples for scenario types

Block 4: Formal Requirements

4a) Functional Requirements

Training: Functional Requirements
  • Motivation: What is the benefit of such a 1-sentence form?
  • Difference between goals and functional requirements
  • Potential problems (fuzziness) in functional requirements - how to detect & how to fix them
  • Sentence templates

4b) Non-Functional Requirements

Training: Non-Functional Requirements
  • Motivation: difference between functional and non-functional
  • Classification of non-functional requirements
  • How to obtain non-functional requirements
  • Examples

4c) Priorization & Conflicts

Training: Priorization & Conflict Resolution
  • Motivation: What do we need priorization for?
  • Overview on priorization methods
  • Classification according to effort / what to use when
  • 2-phase priorization
  • Conflicts during priorization
  • Conflict classification and resolution approaches
Training: Kano factors
  • Motivation: Kano as a priorization method
  • Term definitions
  • What requirements collection methods (see 3) work well for what Kano type?
  • Check matrix for determining Kano type

Block 5: Detailed Requirements

5a) Use Cases

Training: Use cases
  • Motivation: benefits of use cases
  • Use case diagrams
  • Coffee break / user happiness test
  • Rules and templates for use case scenarios
  • Derivation of use cases from functional requirements, scenarios, and personas
Training: Activity diagrams as addition / alternative to UC scenarios
  • Motivation: when does it make sense to use a diagram?
  • UML Activity Diagram elements
  • Transformation of textual scenario into activity diagram
  • Swimlane types

5b) Agile backlog

Training: Themes, Epics, User Stories
  • Motivation: why Agile?
  • Principles for an agile backlog
  • Term definition: theme, epic, user story
  • User story template
Training: Agile estimation & user story decomposition
  • Motivation: Why should a user story be small?
  • Agile estimation techniques
  • How large is too large?
  • 10 ways of user story decomposition