DAT231 / DIT284 Requirements engineering lp1 HT20 (7.5 hp)
Course is offered by the department of Computer Science and Engineering
In order to be assigned to a project group, fill out the pre-suvey.
- General timeline and overview of lectures and workshops
- Project description and assessment criteria for project
- Considerations with Respect to CoViD-19 (this course is remote only)
- Gitlab workspace (staging and work area for material on canvas)
- TimeEdit with scheduled events
DAT231 / DIT284 Requirements engineering lp1 HT20 (7.5 hp), course facts:
- Course is offered by the department of Computer Science and Engineering
- Credit points: 7.5 hp
- Schedule: TimeEdit and annotated timeline
- Course plan (DAT231): Link to the syllabus Chalmers.
- Course plan (DIT284): Link to the syllabus GU.
- Teaching team:
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
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)
- Soren Lauesen (2002): Software Requirements: Styles and Techniques. Addison-Wesley (Chapter 1, 4, 6, 7, 8) (Chapter 3-1, 3-2, 3-3, 3-6, 3-6, 3-10)
- 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
- 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.
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.
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.
The student is examined by individual active participation in all workshops, the completion of a group project and a written individual take-home exam.
The syllabus page shows a table-oriented view of course schedule and basics of course grading. You can add any other comments, notes or thoughts you have about the course structure, course policies or anything else.
To add some comments, click the 'Edit' link at the top.