Anforderungsmanagement (AM), SS22

Anforderungsmanagement setzt zu Beginn des Software-Lebenszyklus an. Es geht um die Erarbeitung von möglichst präzisen, aber immer noch natürlichsprachlichen Spezifikationen für ein Softwaresystem, plus deren nachhaltige und dauerhafte Pflege. Der Fokus liegt dabei darauf, eine Brücke zwischen Fachseite und IT zu schaffen. Ein Anforderungsdokument muss von beiden Seiten gut zu verstehen sein, und dazu so präzise, dass Entwicklungsteams auf der Basis coden können.

Studiengang und Modulbeschreibung: Master Computer Science (Studienrichtung Software Engineering) (siehe auch Modulbeschreibung auf der Studiengangs-Seite)
Begin/End and Organization: As workshops throughout the semester, 01.04.2022 - 08.07.2022
Format: Hybrid (https://th-koeln.zoom.us/j/82586381519?pwd=dVNXb0txeWgvR2tuWEM2UXRKUDdYUT09)
ILIAS Course for the Module: https://ilias.th-koeln.de/ilias.php?ref_id=987028&cmdClass=ilrepositorygui&cmdNode=wc&baseClass=ilrepositorygui
Module Registration Procedure: Please just join the ILIAS course mentioned above. Deadline for registering is 01.04.2022. Please keep in mind that in addition you also need to register for the exam in PSSO. The deadlines for this you find on the information pages of TH Köln.
Discord Server for fast Communication: Discord has been proven as a very effective platform for information sharing, discussions, and consultations. Therefore, Please join the ArchiLab Discord Server at https://discord.gg/YYNYb5whU8. Navigate to channel #rollenzuweisung and click on am. Then you see all channel(s) relevant for this module.

Learning Outcome

In this module, you learn how to analyse stakeholders, constraints, and goals for a planned IT system. You obtain requirements for an IT system using observations, conversations, and documents; all of which will be based on natural-language, and may contain implicit, potentially incomplete, and contradictory information, structure and formalize these information as requirements in a complete und consistent way. You need to prioritize these requirements for software design and implementation, and document the requirements as a specification for a waterfall or agile project.

As a requirements engineer or a business analyst on Master level I can collect and formalize requirements for a software system,

by me ...

knowing, selecting, and applying the appropriate method(s) für requirements engineering, analysis, documentation, testing, and management,
consciously deciding which method(s) are applicable in a given context with its stakeholder and boundary conditions,,
acting as a multiplicator with regard to requirements engineering methods, and instructing colleagues and teams on their usage,,
moderating the requirements engineering process with customers and development teams,,
documenting the results as a specification,,
and keeping my stakeholders informed by concise presentations,,

so that I can instruct a (potentially external) development team in implementing the software system according to the requirements specification.

Module Structure

The module consists of two parts, which are executed in parallel.

In the method training part, you learn to decide when to use which requirements engineering method in which context. You also reflect on how to recombine and adapt methods for specific situations.
Parallel to the method training, you conduct a case study, where you (in a small sub-team) create a requirements document for a given software system.

Method Trainings

The method trainings follow a process model explained on a dedicated page. Each subteam needs to pick a training block, and prepare the training. I will support you doing so.

Case Study

In this course, each team will pick its own idea for a case study. So, your task in your subteam is: Think about an idea for a startup.

You will face the following situation in this course: You, together with a couple of collegues, play the National Lottery together. You never gave that much thought, but now you have actually won a staggering multi-million jackpot! After having bought houses and expensive cars, you jointly decide to invest the remaining 1 Million Euro into a startup that you will found together in your subteam (the teams A … E from 1) above).

You will discuss the ideas for that startup in your subteam, finally agree on one per subteam, and collect some ideas for it. This idea will be turned into a requirements document during this course.

Tool for documenting requirements

We will use Jamstack-based webtool for documenting the various artefacts belonging to a requirement specification.

The artefacts will be described in Markdown, with a YAML front matter containing metadata.
This is compiled into a website based on static HTML.

Each subteam will be provided with a repository containing the tool, as an empty framework (without content). An example (unfortunately in German) can be found here:

This is the webtool: https://divekit.github.io/divekit-roadmap/
And this is the repo it is generated from: https://github.com/divekit/divekit-roadmap

Number of Requirement Artefacts to be Written

When working on the requirements specification for your case study, you (as a subteam) should prepare the following number of artefacts. The numbers are supposed to reflect realistic numbers (within limits). The numbers are my (rough) estimates based on experience. We assume that the software to be written fits in size to a startup (so in the ballpark of 1-2 person years).

Artefact type	Min. number per subteam	A realistic number would be …	How do to compile these artefacts?	Available in RE Tool
Stakeholder	4 (each of the customer team should appear in a specific role)	more than that, as many aspects aren’t covered here (e.g. funding)	talk to sponsors	yes
Stakeholder Role	4	probably more than that (see stakeholders)	define role(s) for your stakeholders, then analyse the other data (interview, workshops, survey)	yes
System Context Element	8	10-30	Just analyse all data sources (add if something comes up later)	yes
Goal	8	not more than 15-20 (“less is more”, as goals should be concise)	primary sources are the project description and the sponsor interview, maybe also workshop	yes
Interview	1	depends very much what kind of information collection works best; >1 … 10	conduct & evaluate interviews	yes
Glossary	16	10 - 30	whenever a business term comes up, define & add it (continuous activity)	Mon 9.5.
Domain Model	1	1	base it on your glossary (most important terms defining your domain appearing here)	Mon 9.5.
Workshop	1	0 - 10, really depends on the product, and the design approach	plan & conduct as per training	Mon 16.5.
Survey	1	0 - 1, depends where this makes sense; might be useful e.g. in case of an internal tool, or for a specific user group	plan & as per training	Mon 16.5.
Scenario	8	20 or more	base on the information you have, esp. workshop and interviews	Fri 20.5.
Persona	8	10	rule of thumb: create two personas per stakeholder role, based on your information collection	Fri 20.5.
Functional Requirement	24	50 - 75	take the essence from your scenarios and the overall information collection, align with goals	Fr 03.06.
Nonfunctional Requirement	4	10 - 20	don’t invent stuff - filter what was actually said in your sources	Fr 03.06.
Priorisation	1	1	apply to functional requirements	Fr 10.06.
Use Case	8	30 - 50	base them on the scenarions and the functional requirements	Fr 01.07.
Use Case Diagram	2	ca. 10	cluster the use cases appropriately	Fr 01.07.
User Story	16	ca. 100 (assumption 4 developers team, 1 year time)	assumption: this the first product backlog, so make UC small, and prioritize!	Fr 01.07.
Formal Review	16 (1 per artefact type)	2 - 5, depending on the design approach and the organizational culture; usually, requirements are compiled into one document	each customer team makes a formal review of the artefacts (see list above)	Fr 01.07.

Grading

The grade for this module will is composed in the following way:

25%: Method training
55%: Contribution to case study / requirements document
20%: Expert talk at the end of the module, about the module content and the case study

(more detailed criteria will follow)

Workshops

Fri 01.04.2022, 10:00 - 14:00: RE kickoff

In this workshop, I will provide you with a motivation for RE. We will sort out all organisational details in order to get the module going. You can read about the content in this slideset.

Goal of the day

You are ready to start.

Agenda

10:00 - 10:30: Motivation - why Requirements Engineering?
10:30 - 11:30: Organizational details, subteam setup, responsibility for trainings
11:30 - 12:30: Defining startup concept
12:30 - 13:30: Lunch break
13:30 - 14:00: Todos & next steps

Fri 08.04.2022, 10:00 - 17:00: Context (block 1)

Trainings and todo definition for block 1 (Stakeholders, System Context, Goals). You can read about the content in this slideset.

Goal of the day

You know how to analyze the context of a planned software system, and the todos for your team in the RE case study have been clarified.

Agenda

10:00 - 10:30: Introduction - Terminology
- Introduction to terminology of the early phase in large software systems
10:30 - 11:00: Write a brief summary of your startup's business idea
- We will open breakout sessions, one per team
- Go as a team to our Startup Idea Miroboard (https://miro.com/app/board/uXjVOAEYJ4Q=/)
11:00 - 12:00: Stakeholders
- Definition "stakeholder"
- Necessary data
- Key questions to identify stakeholders
- Stakeholder classification (for defining priorities)
- Group exercise, define stakeholders for the startups
- Breakout sessions, go as a team to Context Miroboard (https://miro.com/app/board/uXjVO--nDyo=/)
12:00 - 13:00: Lunch break
13:00 - 14:00: System Context
- Definition system context
- Group exercise, define system context for the startups
- Breakout sessions, go as a team to Context Miroboard
14:00 - 15:30: Goals
- Definition "goal"
- 10 Rules for goals
- Group exercise, ASSUME what goals the system could have, as a preparation for the sponsor interview
- Breakout sessions, go as a team to Context Miroboard
15:30 - 17:00: Interviews
- How to conduct an interview (with sponsor or stakeholders)
- Purpose, preparation, do's and don'ts
- Group exercise, prepare interview questionnaire for sponsor interview
- Breakout sessions, go as a team to Context Miroboard

Task until next workshop

Finalize the interview questionnaire
Make an appointment with your startup founders, send questionnaire beforehand
Conduct and record the interview
Document the system context elements
Make a list of relevant stakeholders
Document your stakeholder roles, and assign stakeholders to them
Collect and complete the relevant goals, as far as they are known
Plan, conduct, and document your stakeholder interview
Revise the goals you assumed, with reference to the interview

Fri 29.04.2022, 10:00 - 17:00: Continuous activity (block 2)

The training for Block 2 deals with continuous activities, like glossary, domain model, status model, and quality assurance.

Agenda

10:00 - 10:30: Organizational details
- Some introductory details to be clarified (Prof. Bente)
10:30 - 12:00: Text analysis and glossary compilation
- Presentation
- Application to own case study, in subteams on Miro board
12:00 - 13:00: Lunchbreak
13:00 - 14:30: Domain model as UML class diagram
- Presentation
- Application to own case study in subteams on Miro board
14:30 - 15:15: State Diagram
- Presentation
- Exercise in subteams on Miro board
15:15 - 16:15: Quality Assurance
- Presentation
- Application to own case study in subteams on Miro board

Task until next workshop

Enter the glossary in the RE Tool
Finish the domain model, based on your glossary, and document it in the RE Tool

Fri 06.05.2022, 10:00 - 17:00: Requirements capturing methods (block 3)

Informal requirements (block 3) comprise artefacts like scenarios and personas, which are not very highly formalized, and techniques to collect data for them. In this workshop, we start with the

Agenda

10:00 - 10:30: Artefact list for the case study
- In this table the artefacts to be created for the case study have been defined.
- We will go through this list, and discuss it.
- You can define these artefacts in your training during the workshops, and complete them afterwards.
10:30 - 12:30: Requirements capturing methods
- Brainstorming
- Brainstorming Paradox
- Mind Mapping
- 6-3-5 Method
- Walt-Disney Method
- Six Thinking Hats
- Subteam exercise - which workshop technique is best suited to be conducted with your customer?
12:30 - 13:30: Lunch Break
13:30 - 16:00: Surveys
- Introduction to surveys
- Subteam exercise - define a target group, and design a survey for them to fill information gaps about your customer's product

Fri 20.05.2022, 10:00 - 17:00: Informal Requirements workshops (block 3)

Workshops conducted, todos for evaluation and documentation clarified

Fri 03.06.2022, 10:00 - 17:00: Formal Requirements (block 4)

Trainings done

Fri 10.06.2022, 10:00 - 17:00: Formal Requirements priorization (block 4)

Completing requirement lists, and prioritizing them

Fri 01.07.2022, 10:00 - 17:00: Detailed requirements (block 5)

All trainings done, todos defined