Mapping to Focus Areas
Below, you find the module's mapping to the study program's focus areas. This is done as a contribution to all relevant focus areas (in ECTS, and content-wise). This is also relevant for setting the module in relation to other modules, and tells to what extent the module might be part of other study programs.
| Focus Area |
ECTS (prop.) |
Module Contribution to Focus Area |
| Architecting and Coding Software |
4 |
Knowing, selecting, and applying the appropriate methods for gathering requirements for software systems, as the first step in the software development life cycle
|
| Empowering Business |
2 |
Being able to understand and analyze a given business domain; gathering stakeholder information for functional and non-functional requirements, and so assessing the business impact of IT decision making
|
Learning Outcome
- As a requirements engineer or a business analyst on Master level, I can …
- analyse stakeholders, constraints, and goals for a planned IT system,
- 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,
- prioritize these requirements for software design and implementation,
- and document the requirements as a specification for a waterfall or agile project
- by doing the following:
- 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 Content
The module consists of two parts, which are executed in parallel.
- In the method training part, the students learn to decide when to use which method in which context.
They also reflect on how to recombine and adapt methods for specific situations
- Parallel to the method training, the students conduct a real-life case study (ideally in collaboration with an
industry partner).
The method trainings follow a process model consisting of the following steps:
- Analysis of goals and system context (Ermittlung Ziele und Systemkontext)
- Requirements engineering techniques, personas, scenarios (Erhebungstechniken, Personas, Szenarien)
- Domain glossary and domain model (Fachliches Glossar und Domänenmodell)
- Functional requirements (funktionale Anforderungen)
- Non-functional requirements (nicht-funktionale Anforderungen)
- Priorization and conflict resulotion (Priorisierung und Konfliktlösung)
- Use Cases
- Quality assurance and editing (Qualitätssicherung und Redaktion)
- Agile backlog creation / management (Erstellung und Pflege eines agilen Backlogs)
- Self-study of methods in a flipped classroom approach, using videos
- Discussion and exercises for the content
- Project work on a real-life case study
- Reflection
Learning Material Provided by Lecturer
- Videos on requirement engineering methods
- Script for those methods
- Literature
Literature
- Broadbent, Ellen (2004): The New CIO Leader: Setting the Agenda and Delivering Result. Harvard Business Review Press
- Calabria, Tina (2004): An introduction to personas and how to create them. Step Two Design
- Cockburn, Alistair (2000): Writing Effective Use Cases. Addison WesleyBoston
- Cohn, Mike (2004): User Stories Applied: For Agile Software Development. Addison-Wesley Professional
- Cooper, Alan (1999): The Inmates are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity. SamsIndianapolis, Ind
- Ebert, Christof (2014): Systematisches Requirements Engineering: Anforderungen ermitteln, dokumentieren, analysieren und verwalten. dpunkt.verlag GmbH Heidelberg
- Evans, Eric (2003): Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional Boston
- Evans, Eric (2015): Domain-Driven Design Reference - Definitions and Pattern Summaries. Selbstverlag (unter Creative Commons Lizenz)
- Gürtler, Jochen; Meyer, Johannes (2013): 30 Minuten Design Thinking. GABAL Offenbach
- Leffingwell, Dean; Widrig, Don; Yourdon, Ed (2003): Managing Software Requirements: A Use Case Approach. Addison Wesley Pub Co Inc Boston
- Leffingwell, Dean (2010): Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley Upper Saddle River, NJ
- Meuser, Michael; Nagel, Ulrike (2002): ExpertInneninterviews - Vielfach erprobt, wenig bedacht. In: A. Bogner, B. Littig, & W. Menz (Eds.), Das Experteninterview: Theorie, Methode, Anwendung. VS Verlag für Sozialwissenschaften.
- Pohl, Klaus (2008): Requirements Engineering: Grundlagen, Prinzipien,Techniken. dpunkt.Verlag GmbH Heidelberg
- Pohl, Klaus; Rupp, Chris (2011): Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level. dpunkt.verlag GmbH
- Rupp, Chris; SOPHISTen, die (2014): Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil. Carl Hanser Verlag GmbH & Co. KG München
- Schienmann, Bruno (2001): Kontinuierliches Anforderungsmanagement . Prozesse - Techniken - Werkzeuge. Addison-Wesley München ; Boston u.a.
