Course syllabus

Course-PM

DAT231 / DIT284 Requirements engineering lp1 HT20 (7.5 hp)

Course is offered by the department of Computer Science and Engineering

Important links

In order to be assigned to a project group, fill out the pre-suvey.

Contact details

DAT231 / DIT284 Requirements engineering lp1 HT20 (7.5 hp), course facts:

Course purpose

One of the main challenges in software development is to make sure you are developing the right system, i.e. to understand the requirements that need to be fulfilled. The focus of this course is how to find and collect requirements from relevant sources both at the start and during a software development project. Different methods for this as well as different underlying principles and formats for documenting and maintaining requirements are covered.

In particular the course covers the problems that arise when requirements engineering is conducted in a fast-paced, cost-sensitive industrial reality. The following topics are included in the course:

  • Stakeholder Identification and Management
  • Requirements Elicitation
  • Writing Requirements and Requirements Specifications
  • Quality Assurance of Requirements
  • Prioritising Requirements
  • Connections and Alignment between Requirements Engineering and other Software Engineering activities
  • Requirements Engineering in In-Project vs. Market-driven Development
  • Requirements Engineering in Agile and Iterative/Incremental Development

Schedule

TimeEdit

Course literature

This course relies strongly on literature. The expectation is that relevant literature is read before a particular lecture. Thus, for each lecture, we state which papers or chapters are relevant.

It is very difficult to provide a single course book, especially in such a quickly moving environment. Requirements Engineering differs a lot between contexts, thus a book can either be deep and focused on the interplay of practices, or broad and provide an overview, but rarely both. We have decided for a deep, hands-on book, which we complement through mandatory papers and optional readings (both other papers and books).

Mandatory literature (i.e., knowing it is expected for passing the course)

Course Book:

Complementary Papers:

  • 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.

Optional further reading

Additional books:

  • Soren Lauesen, Guide to Requirements SL-07: Problem-oriented requirements v5, 2017, ISBN: 978-1523320240, available online:http://www.itu.dk/~slauesen/Papers/RequirementsGuideSL-07v5-online.pdf
  • 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.

Additional papers:

We provide references to additional papers throughout lecture slides. The intention is that those are accessed when needed, e.g. to make a particular point in the take-home exam.

However, some works might be worth mentioning in addition to the lectures.

  • 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.

Course design

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

Changes made since the last occasion

  • New procedures for re-examination, including for take-home exam
  • Re-activated course book [Lauesen, 2002] – please read it
  • Refined assessment criteria for project
  • Increased teaching team
  • Integrated Inter-cultural communication (ICC) training into course
  • Corona-adjustments (avoid co-located events)
  • Improved way to randomly assign groups

Learning objectives and syllabus

Knowledge and understanding - after completion of the course the student must to be able to

  • explain why requirements engineering is a key to successful software engineering,
  • describe the challenges involved in requirements engineering,
  • explain the importance of identifying stakeholders and their knowledge, context and goals,
  • explain the difference between functional and quality requirements,
  • describe how to conduct bespoke (in-project/single-customer) requirements engineering in terms of common processes and techniques,
  • explain how market-driven differs from bespoke (in-project/single-customer) requirements engineering,
  • describe how requirements engineering in agile projects differ from traditional requirements engineering.

Skills and abilities - after completion of the course the student must to be able to

  • skillfully elicit software requirements,
  • clearly document software requirements according to industry standards and state-of-the-art,
  • prioritise requirements,
  • assure the quality of requirements and requirements specifications,
  • be able to assess current requirements engineering practices in a software project or a software development company.

Judgement and approach - after completion of the course the student must to be able to

  • suggest relevant improvements on requirements engineering processes in a convincing way,
  • trade-off the choice of requirements engineering methods and processes given a certain project context.

Examination form

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

Course summary:

Date Details Due