Software engineering is knowledgework therefore it involves some aspect of discovery. As an engineering activity it is therefore also craftwork and involves delivery. We therefore define discovery as work that explores, evaluates, and confirms product options for potential delivery and delivery as work that transforms one or more allocated candidate solutions into a releasable portion or version of the product [8]. Therefore, key activities in software engineering are figuring out the right things to build and building the things right. By discovering the right thing to build, puts one in the best position to deliver the thing right.

This very discovery process is the fundamental activity of System Analysis (also known as Requirements Engineering). More importantly, in this course we understand system analysis as the fundamental activity to understand the customer and the domain. This also includes the customer understanding its own problem and being able to transfer this understanding to the developers. So in the end analysis is fundamentally about understanding. It is not about creating piles of documentation to give the (false) impression that we capture all details of a system. This is very rarely needed (safety software e.g. nuclear power plant, aviation,…) and only applicable in huge projects due to the extreme effort required. If a software developer is interested in such formal specification activities or it is required in its job, it has to receive special training anyway, independent whether the university taught a more formal or a more agile approach to analysis.

This course therefore focuses on a rather agile approach to system analysis with focus on understanding the customer, understanding the domain, understanding the technical side to it and establishing a quick learning feedback cycle to encourage continuous learning. Students learn how to systematically derive analysis artifacts, related to each other with the main focus on modeling with various diagrams.

This course explicitly ignores the business and management side of requirements, UCT/GUI/HCI side of it, as this is beyond the focus of this course and treated in Related Courses. Also, this course is explicitly not teaching any analysis tools (UML, story boards,…) as they often require substantial time to set up and use whereas most of the time simply sketching out a diagram on paper or writing 3 sentences on a card is much more effective, creative and direct.

Lecture Structure

The structure of the lecture follows roughly the process a software project goes through in the analysis phase from very abstract activities such as defining Context Modeling to very concrete ones such as Domain Modeling. The lecture is split into the following chapters:

Accompanying Seminar

In the accompanying seminar to this lecture we apply the methods and techniques presented in the lecture in two ways:

  1. By standalone examples to practise analysis activities to produce artifacts which stand on their own and are not related to each other. These examples are designed as exercises for the seminar, where the solutions will be discussed.
  2. Examples based on an overarching Product Vision of a fake project to practice analysis activities to produce a scope statement (Pflichtenheft) which are related to each other instead of standing alone. The students work in groups of 3 on the scope statement both during the seminar (as time permits) and from home. It has to be submitted on 2nd November 2020 13:10.


  1. Lecture 3 SWS on Tuesday 29 Sep, 18:10 - 20:35
  2. Lecture 2 SWS on Monday 5 Oct, 15:10 - 16:45
  3. Lecture 1 SWS on Tuesday 6 Oct, 13:10 - 13:55
  4. Seminar 4 SWS on Tuesday 6 Oct, 14:00 - 17:15
    • 1st Session
      • Presenting the Product Vision
      • Stakeholder Analysis, User Roles, Personas in the Scope Statement
    • 2nd Session
      • Internal and External Context Diagrams
    • 3rd Session
      • Use Cases
  5. Lecture 2 SWS on Monday 12 Oct, 13:10 - 14:45
  6. Seminar 3 SWS on Monday 12 Oct, 14:50 - 17:15
  7. Lecture 1 SWS on Tuesday 13 Oct, 13:10 - 13:55
  8. Seminar 3 SWS on Tuesday 13 Oct, 14:00 - 16:25
  9. Lecture 1 SWS on Monday 19 Oct, 18:10 - 19:45
  10. Seminar 3 SWS on Monday 19 Oct, 19:50 - 21:25
  11. Lecture 2 SWS on Tuesday 20 Oct, 13:10 - 14:45
  12. Seminar 3 SWS on Tuesday 20 Oct, 14:50 - 17:15

Submission of scope statement until Monday 2 Nov, 13:10

Written (online) exam on Monday 2 Nov, 13:10 - 14:45


70% (online) exam + 30% scope statement (both need to be positive to pass the course)

  • Written (online) exam (70 %), in which the theoretical foundations are reproduced, arranged and applied in practical tasks.
  • Evaluation of the scope statement (30%) in groups of 3, to be submitted until 2nd November 2020 13:10.


[4] Bernd Bruegge and Allen H Dutoit. 2009. Object–oriented software engineering. Using uml, patterns, and java. Learning 5, 6 (2009), 7.

[5] Martin Fowler. 2004. UML distilled: A brief guide to the standard object modeling language. Addison-Wesley Professional.

[8] Ellen Gottesdiener and Mary Gorman. 2014. Discover to deliver: Agile product planning and analysis. EBG Consulting.

[9] Thomas Grechenig. 2010. Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten. Pearson Deutschland GmbH.

[13] Craig Larman. 2012. Applying uml and patterns: An introduction to object oriented analysis and design and interative development. Pearson Education India.

[14] Dean Leffingwell. 2010. Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Addison-Wesley Professional.

[18] Kent J McDonald. 2015. Beyond requirements: Analysis with an agile mindset. Addison-Wesley Professional.

[19] Stephen M. McMenamin and John F. Palmer. 1984. Essential systems analysis. Yourdon Press, USA.

[20] Kenneth S Rubin. 2012. Essential scrum: A practical guide to the most popular agile process. Addison-Wesley.

[21] Ian Sommerville. 2011. Software engineering 9th edition. ISBN-10 137035152, (2011).