Course syllabus for Advanced requirements engineering

• a bachelor degree in Software Engineering, Computer Science, Information Technology, Information Systems, or equivalent;
• a completed course in programming (e.g., TDA548 Introductory software development, DAT043/DAT050 Object-oriented Programming, TDA452 Functional Programming, or equivalent);
• a completed project course (or bachelor thesis) in applied software development or software engineering (e.g., TDA367 Object-oriented programming project, or DAT257 - Agile software project management).

One of the main challenges in software development is to make sure one is developing the right system, i.e. to understand the requirements that need to be fulfilled. The purpose of this course is how to learn how to find and collect requirements from relevant sources, both at the start and during a software development project, following established principles and formats for documenting and maintaining requirements..

After completion of the course the student must to be able to

Knowledge and understanding

• Identify a common RE challenge in a given software development context.
  
• Choose an appropriate RE practice in a given software development context.
  
• Compare suitability as well as advantages and disadvantages of given RE practices in a given software development context.
  
• Explain the current state of practice and research in requirements engineering.

Skills and abilities

• Plan suitable RE practices in a team with respect to a given software development context.
  
• Effectively apply a suitable RE practice in a team in a given software development context.
  
• Analyze the effect and quality of the outcome of a set of or individual RE practices in a given software development context.

Judgement and approach

• Assess new requirements engineering knowledge (challenge, principle, practice) and relate them to the framework in this course.
  
• Suggest suitable actions to overcome a lack of requirements knowledge in a software development context.
  
• Consider inter-team, program level and social/ethical implications of a set of RE practices in a given software development context.
  
• Critically assess the effectivity of a set of RE practices from the perspective of the student's master program (e.g. Software Engineering & Technology/Management, Interaction Design, Game Design, Data Science, ...)

• Requirements analysis
• Elicitation
• Analysis 
• Documentation
• Negotiation
• Verification and validation
• Requirements management
• Change management
• Traceability
  

• Team level: knowledge within a software development team and accross several teams working in the same area.
• Program level: knowledge within a particular product team or across a set of related product teams (e.g. agile release trains)
• Enterprise level: knowledge related to managing a portfolio of products.

The course is organised as a series of lectures, workshops as well as project assignments.

• Soren Lauesen (2002): Software Requirements: Styles and Techniques. Addison-Wesley

• Berander, P., Andrews, A.A. (2005): "Requirements Prioritization", In: Engineering and Managing Software Requirements, Eds. A. Aurum and C. Wohlin, Springer, ISBN 3-540-25043-3.
• Berntsson Svensson, R., Gorschek, T., Regnell, B., Torkar, R., Shahrokni, A., Feldt, R. (2012); "Quality Requirements in Industrial Practice - an extended interview study at eleven companies", IEEE Transaction on Software Engineering, vol.38(4), pp. 923-935.
• Carlshamre, P.; Sandahl, K.; Lindvall, M.; Regnell, B.; Nattoch Dag, J. (2001): "An industrial survey of requirements interdependencies in software product release planning", IEEE Int. Conf. on Requirements Engineering (RE01), Toronto, Canada, pp. 84–91
• Davis, A., Dieste, O., Hickey, A., Juristo, N., and Moreno, A. M. (2006). Effectiveness of requirements elicitation techniques: Empirical results derived from a systematic review. In Proc. of 14th IEEE Int. Reqts. Eng. Conf. (RE), pages 179–188, Minneapolis/St. Paul, MN, USA.
• Gorschek, T. and Wohlin, C. (2006). Requirements abstraction model. Requirements Engineering, 11:79–101.
• Inayat, I.; Salim, S. S.; Marczak, S.; Daneva, M. and Shamshirband, S. (2015): "A systematic literature review on agile requirements engineering practices and challenges", Computers in human behavior, 51:915–929
• Knauss, E. (2019). The missing requirements perspective in large-scale agile system development. IEEE Software, 36:9–13.
• Maiden, Neil; Ncube, Cornelius; Robertson, Suzanne (2007): "Can Requirements Be Creative? Experiences with an Enhanced Air Space Management System", 29th International Conference on Software Engineering (ICSE'07)
• Murugesan, A., Heimdahl, M., and Rayadurgam, S. (2019). Requirements reference models revisited: Accommodating hierarchy in system design. In Proc. of 27th IEEE Int. Requirements Eng. Conf. (RE), Jenju Island, South Korea.
• Regnell, Björn and Brinkkemper, Sjaak (2005): "Market-Driven Requirements Engineering for Software Products", In: Engineering and Managing Software Requirements, Eds. A. Aurum and C. Wohlin, Springer, ISBN 3-540-25043-3
• Ruhe, Günther and Saliu, Moshood Omolade (2005): "The Art and Science of Software Release Planning", IEEE Software, November/December, pp. 47-53
• Glinz, M. (2007). On non-functional requirements. In Proc. of 15th IEEE Int. RE Conf. (RE), pages 21–26, New Delhi, India.

• Soren Lauesen, Guide to Requirements SL-07: Problem-oriented requirements v5, 2017, ISBN: 978-1523320240, available online: https://www.itu.dk/~slauesen/Reqs/GuideSL-07-online.pdf
• Links to an external site.
• Cockburn, A. (2001). Writing Effective Use Cases. Addison-Wesley.
• Davis, A. M. (1993). Software Requirements: Objects, Functions and States. Prentice Hall.
• Gause and Weinberg (1982). Are your lights on? Dorset House Publ.
• Leffingwell, D. (2011). Agile Software Requirements. Addison-Wesley.

• Callele, D., Neufeld, E., Schneider, K. (2010): "An Introduction To Experience Requirements", IEEE Int. Conf. on Requirements Engineering (RE10), Sydney, Australia, pp. 395–396

The above paper describes how to communicate requirements about the desired user experience in game design

• IEEE (1990). IEEE standard glossary of software engineering terminology. IEEE Std 610.12-1990, pages 1–84.

The student is examined by individual active participation in all workshops, the completion of a group project and a written individual hall exam.