Course syllabus

Jump to today

Updates

2021-08-19: Removed or updated outdated links, added annotated timeline.

DAT231 / DIT285 Advanced requirements engineering lp1 HT21 (7.5 hp)

Course is offered by the department of Computer Science and Engineering

Important information

First lecture: 2021-Aug-31: 13:15 - 15:00, on Zoom only. Please ignore room bookings for the time.

Please make an effort to attend the first lecture, since there we aim to assign project groups based on the following survey: https://forms.office.com/r/K8KSRstqUU.

Important links

CoViD situation

Vice-Chancellor's decision C 2021-0926 stipulates that our department shall go back to campus education. In order for us to follow this decision, and at the same time not impact non-Swedish students, I have decided that: a) All lectures will be online (Zoom links will be provided via canvas and this page). The online lectures were very well received last year! b) (supervised) Project work will be possible both on campus and remotely. Please clearly state your preference in the initial survey during the first lecture, so that we can assign groups accordingly.

 

Contact details

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

Course purpose

Understanding requirements is key to successful software engineering: Building software that is fit for its purpose relies on understanding the exact problem that must be solved.

The purpose of this course is to learn challenges, principles, and practices to identify, analyse and manage requirements from relevant sources, both at the start and during a software development project. The course regards these issues in specific development contexts, i.e. specific constellations of customers and suppliers as well as constraints related to the domain and development lifecycle that characterise developing a piece of software.

This course is on advanced level and takes a holistic view on the state of the art of requirements engineering as part of successful software engineering, technology, and management. Students are expected to familiarize themselves with recent, relevant research in the field, to critically reflect on the implications of new findings, and to develop their abilities and expertise as software professionals.

The course teaches challenges, principles, and concrete practices related to the following subfields of requirements engineering (RE):

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

Beyond a brief introduction into concrete notations of requirements, the course focuses on holistically managing requirements-related knowledge on relevant scopes, including:

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

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

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

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: https://www.itu.dk/~slauesen/Reqs/GuideSL-07-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

Assessment

The course work falls into two parts: project work in teams and lectures. The final grade is based on both parts, which are assessed separately.

The grade for project work in teams is based on participation in mandatory workshops, various hand-ins according to course plan and includes an individual component.
To some extent (depending on context up to three occasions), failing to participate in mandatory events or to hand satisfactory hand-ins can be compensated based on rework by individuals or groups during the course. After the course, these options are much more limited and likely, the project part of the course has to be retaken.

The grade for the lecture part is determined through a take-home exam, i.e. a written report based on literature, lecture content, and project experience.

Form of teaching

This course aims to complement theoretical knowledge with practical experience, thus lectures and project work aim to support each other. Both parts will be assessed during the course. Participation in workshops as well as sufficient participation in group work is mandatory, as these provide crucial input towards the learning outcomes by providing concrete insights with respect to RE challenges and practices.

Lectures (together with mandatory literature) will provide background knowledge about challenges and practices as well as general information about their applicability.

Project work allows to experience a subset of these challenges and practices in a concrete context. Through group reflection and iterative feedback, students will thus acquire the learning outcomes in the knowledge and understanding as well as in the skills and ability section.

When preparing the take-home exam, the students will combine these learnings to train towards the judgement and approach learning outcomes. Optional further readings can support this activity.

Communication and Resources

Official communication will be via Canvas. Please make sure to setup proper email forwards and to visit the course page regularly.

For group communication and supervision, we will rely on email and (optionally) on slack.

We will provide gitlab workspaces on chalmers servers.

Changes made since the last occasion

  • Revised Syllabus
    • Renamed course for emphasizing differences to related Bachelor-level courses
    • Updated and clarified learning objectives
    • Adjusted grading scale, so that students of CTH and GU programs will be graded on the same scale: Pass with distinction (5), Pass with credit (4), Pass (3) and Fail (U)
    • Increased teaching staff to provide better supervision to student groups

Learning objectives and syllabus

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, ...)

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.

If a student, who has failed the same examined component twice, wishes to change examiner before the next examination, a written application shall be sent to the department responsible for the course and shall be granted unless there are special reasons to the contrary (Chapter 6, Section 22 of Higher Education Ordinance).

In cases where a course has been discontinued or has undergone major changes, the student shall normally be guaranteed at least three examination occasions (including the ordinary examination) during a period of at least one year from the last time the course was given.

 

Course summary:

Date Details Due