Advanced Topics in Requirements Engineering
Requirements engineering is an integral part of every (software) development process. The specification gained during requirements engineering defines the baseline for the product and acts as a starting point for (formal) verification and testing. The process of obtaining requirements themselves, ensuring that a requirements fulfill certain properties (e.g. having no inconsistencies or errors) and using requirements in formal verification and testing is an active research topic.
|Instructors||Vincent Langenfeld, Daniel Dietsch|
(Block-Seminar at end of term)
|Course Catalog||Program Analysis
Process of the seminar
- Contact the instructors to obtain a topic. You may suggest a topic by yourself, pick one of the suggested topics, or find a topic suitable for you in a discussion with your supervisor.
- You write a proposal in which you explain what you are going to present in your talk.
- You write an abstract of your talk.
- You submit your abstract and your proposal via email to the instructors (deadline: 30.11.2016).
- Your proposal is reviewed by two other participants.
- You write two reviews about other participants' proposals and send them via email to the instructors (deadline: 14.12.2016).
- You receive reviews of your proposal.
- You submit your slides via email to the instructors (deadline: tba).
- You have a short meeting with the instructors in which you get feedback for your slides.
- You give a ca. 30 min talk.
- You attend the talks of all other participants.
Proposals of the talk
The proposal should consist of around five pages in which you explain what you are going to present in your talk. The proposal may contain e.g.:
- short overview for the reviewers (the reviewers will probably not know your topic)
- structure of your talk
- aspects of the topic that you present (why?) and ignore (why?)
- examples occurring in the talk (why these examples? Is there a running example that can be used for demonstration?)
- which definitions are presented formally? (why?), which definitions are just mentioned informally? (why?)
- which notation is used? (why?)
- which theorems are presented, which of them will be proven (why?), which proofs will be omitted (why?), will you use motivating examples in the proof?
Abstract of the talk
- one paragraph that summarizes what you present in the talk
- We will send an invitation for the seminar to all students and members of our chair. This invitation contains the abstracts of all talks.
- The goal of your talk is that the audience (master students, familiar with computer science in general, probably no experts in the topic) has the possibility to learn something new about an interesting topic. How well you achieved this goal will determine the grade of your talk.
- In a seminar you have to show that you are able to present some topic to other people. You do not have to show how well you understood the topic for yourself. How well you understood the topic has no direct influence on your grade, but only how well you presented the topic to the audience.
- You may use and copy any source of information (but do not forget to cite it). If you think your talk is just a "remix" of existing talks tailored to your audience, you might have done a great job. But do not let yourself be fooled by well-structured and fancy talks found in the web, each talk was tailored to a specific audience.
- If you agree we put your slides on this website. Keep in mind that if you have copied images in your slides this might not be possible anymore (copyright restrictions). Of course, it will not have any effect on your grade whether we may publish your slides or not.
Review of the proposal
- Give a short summary of the talk based on the proposal (to detect misunderstandings right at the start).
- Be generous with your criticism. It is very unlikely that a student will get a bad grade because you revealed some problems in his/her proposal. However, it is very likely that a student will get a better grade if he/she was able to resolve a problem in his/her talk, thanks to your review.
- Give reasons for your criticism (e.g., "It is not possible to understand Lemma 2 because term foo was not explained."). You are also allowed to give your personal opinions, if you do so mark them as such (e.g., "Theorem 1 is very difficult to understand, in my opinion you should give an example first.").
- The following questions might be helpful to write your review
Is the proposal sufficiently well written to be readable?
Is the appearance and structure of the proposal appropriate?
Is the comprehensibility of the talk supported by relevant examples and figures?
Is the proposed structure of the talk sensible and balanced?
Are all propositions made by the author correct?
Is the line of reasoning concerning the presentation complete and accurate?
Has the author argued his/her case effectively?
Does the author use the common notation and terminology? Where would you suggest something different?
Is the schedule of the author sensible? Do you think the talk will fit into the 30 min time slot?
Your overall grade will be composed according to the following proportion.
- 10% grade of your proposal
- 20% grade of your reviews
- 70% grade of your talk
Some of the papers are only available via the network of our university (e.g., via vpn). If you have some problem accessing the papers, please ask us.
- Antoine Cailliau, Axel van Lamsweerde:
Handling knowledge uncertainty in risk-based requirements engineering. RE 2015: 106-115
- Sascha Konrad, Betty H. C. Cheng:
Real-time specification patterns. ICSE 2005: 372-381
- Jussi Kasurinen, Andrey Maglyas, Kari Smolander:
Is Requirements Engineering Useless in Game Development? REFSQ 2014: 1-16
- Tobias Morciniec, Andreas Podelski:
Using the requirements specification to infer the implicit test status of requirements. RE 2015: 362-371
- Amalinda Post, Jochen Hoenicke, Andreas Podelski:
rt-Inconsistency: A New Property for Real-Time Requirements. FASE 2011: 34-49
- Gursimran Singh Walia, Jeffrey C. Carver:
A systematic literature review to identify and classify software requirement errors. Information & Software Technology 51(7): 1087-1109 (2009)
- Prahladavaradan Sampath, Silky Arora, S. Ramesh:
Evolving specifications formally. RE 2011: 5-14
- Rehan Rauf, Michal Antkiewicz, Krzysztof Czarnecki:
Logical structure extraction from software requirements documents. RE 2011: 101-110
- Jean-Raymond Abrial, Michael J. Butler, Stefan Hallerstede, Thai Son Hoang, Farhad Mehta, Laurent Voisin:
Rodin: an open toolset for modelling and reasoning in Event-B. STTT 12(6): 447-466 (2010)