Beitrag zu Handlungsfeldern
Nachfolgend ist die Zuordnung des Moduls zu den Handlungsfeldern des Studiengangs aufgeführt, und zwar als anteiliger Beitrag (als ECTS und inhaltlich). Dies gibt auch Auskunft über die Verwendbarkeit des Moduls in anderen Studiengängen und über die Beziehung zu anderen Modulen im selben Studiengang.
| Handlungsfeld |
ECTS (anteilig) |
Modulbeitrag zum Handlungsfeld |
| 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
Inhaltliche Beschreibung des Moduls
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
Zur Verfügung gestelltes Lehrmaterial
- Videos on requirement engineering methods
- Script for those methods
- Literature
Weiterführende Literatur
- 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.
