=Paper=
{{Paper
|id=Vol-1217/paper4
|storemode=property
|title=A Multi-Level Didactical Approach to Build up Competencies in Requirements Engineering
|pdfUrl=https://ceur-ws.org/Vol-1217/paper4.pdf
|volume=Vol-1217
|dblpUrl=https://dblp.org/rec/conf/re/SedelmaierL14
}}
==A Multi-Level Didactical Approach to Build up Competencies in Requirements Engineering==
https://ceur-ws.org/Vol-1217/paper4.pdf
A Multi-Level Didactical Approach to Build up
Competencies in Requirements Engineering
Yvonne Sedelmaier, Dieter Landes
Faculty of Electrical Engineering and Informatics
University of Applied Sciences and Arts
96450 Coburg, Germany
{ yvonne.sedelmaier, dieter.landes }@hs-coburg.de
Abstract— Requirements engineering education at universities way that the associated problems become evident for the
is a fairly difficult issue for various reasons. Among the most intended audience.
prominent causes is a lack of authenticity, i.e. too artificial In this contribution, we present the didactical approach that
settings that do not adequately mirror the complexity of real-
we developed for requirements engineering education at
world situations. We present an approach to requirements
engineering education that tries to avoid some of these
Coburg University of Applied Sciences. Core ingredients of
shortcomings, in particular by including requirements elicitation our approach are a realistic and integrated setting, which
with real customers into an integrated didactic step-by-step includes writing a requirements document for a complex
approach. As it turns out, requirements engineering education is application and, as of late, eliciting requirements from real
far more than assembling technical knowledge, but rather customers. In our specific setting, customers play a double role:
involves many non-technical skills that obtain a specific context- in addition to simply providing requirements, they also act as
sensitive flavor in requirements engineering. Our didactic external experts for communication issues. Another main
approach also addresses these skills, while resting on a sound characteristic of our approach is the extensive active
pedagogical underpinning. Indications for the success of our
involvement of students in the learning process. In particular
approach are visible, e.g., in self-evaluations of the participants
which are also summarized in the paper.
the latter aspect has a solid theoretical underpinning in
constructivist didactics. An additional characteristic of our
approach is a strong emphasis on non-technical skills which are
Index Terms—requirements engineering, problem awareness, particularly relevant for requirements engineering, but also gain
methodological skills, competencies, personal skills, real a very specific, context-sensitive shape in this particular
customers.
domain.
I. INTRODUCTION The didactical approach that we conceived at Coburg seems
to be quite successful since students value the importance of
It is commonly accepted that requirements are top success
requirements engineering to a much higher extent and view
factor in software engineering projects, but, conversely, also a
themselves well equipped to deal with requirements
major reason for project failures. Therefore, providing IT
engineering in practice. This finding is substantiated by a series
students with solid requirements engineering skills is of
of evaluations that we performed.
paramount importance. In practice, however, teaching and
In the remainder of this paper, we will first analyze
learning requirement engineering is not too easy. Part of the
difficulties in teaching requirements in more detail before we
problem is the fact that good requirements are essential in
characterize key features of our didactical approach and their
complex real-life projects, but time and resource restrictions
pedagogical foundation. We discuss lessons learned both from
prohibit instructors from running many such projects –
the perspective of instructors and of students, before we give a
typically, there is only one such project during university
short summary and an outlook to future work. Teaching
education. Often, such a project comes late as a capstone
Requirements Engineering
project that ties together everything that should have been
learned before. Unfortunately, learning requirements A. Challenges in Teaching Requirements Engineering
engineering only theoretically does not work well either. Although requirements engineering is a core ingredient of
Students tend to view many important issues in requirements software engineering, it is fairly difficult to teach and to learn.
engineering as commonplaces and fail to see their importance. Teaching and learning software engineering is generally
It seems to be one of the big challenges for instructors to restricted to small toy projects which mirror real world
make requirements engineering education as descriptive as problems only to a limited extent. This is due to several
possible to make the matter more tangible for students. In reasons:
particular, this encompasses mapping the complexity of real- Early on, software engineering education often focuses on
world projects at least in part to a university context in such a teaching and learning how to program a computer rather than
on requirements. Typically, programming assignments are elicit requirements before there is any point in thinking about
small and clearly defined. Students design small pieces of technical solutions. Coming back to the example above, this
software, often in small groups or even on their own. means that there must be information on business processes in
Assignments typically focus on a specific problem, e.g. specific an organization before these processes can be modeled and
element of the programming language such as arrays or loops, taken as a basis for use cases. Frequently, this information is
or particular algorithms. This means, software development not readily available, but must rather be elicited from a range of
assignments primarily focus on the technical aspects of appropriate stakeholders which frequently are not easy to
programming and specific programming languages in a domain identify. Students rarely face the problem of eliciting
that is pretty familiar to students. As a consequence, requirements from multiple groups of occasionally
requirements are supplied by the instructor, expressed clearly, uncooperative stakeholders. Therefore, they do not see a
and easy to understand since no unfamiliar terminology or problem in eliciting requirements.
unusual domain concepts are involved. This easily makes All these challenges trace back to an insufficient match
students believe that there is no need to bother with between scenarios in requirements engineering education and
requirements since they generalize their programming in real life. Given a restricted amount of time, it is quite
experiences to real software development projects: There is no difficult to expose students to examples which reflect real
such thing like fuzzy requirements of stakeholders that use an problems in requirements engineering. Requirements depend
unfamiliar terminology since students never came across such massively on the software that should be developed. Software
stakeholders. Consequently, there is a danger that students engineering in university education mostly deals with
underrate the importance of requirements engineering since developing a toy solution that will not be used in daily life.
requirements engineering techniques do not solve any problem This also applies to requirements in university education:
in their world. Often, students cannot even imagine problems Requirements tend to be simple, and therefore requirements
that are rooted in insufficient requirements. And they do not engineering seems to be unnecessary in students’ opinions. Due
believe instructors who report on their own practical to the lack of real customers students cannot imagine the
experiences with what can go wrong with requirements. complexity of and interrelationships between requirements
Students often think instructors exaggerate. Techniques they within a large software engineering project.
should learn in requirements engineering seem to be boring and
B. Didactical Approach in 2013
useless since students mostly do not know why they need these
techniques. At Coburg University, requirements engineering is a major
Furthermore, programming assignments tend to be isolated issue in an elective course called “Software Modeling” which
without relationship to other tasks. Even if there is more than is offered in the second year of a bachelor program in
one possible way to solve a problem the chosen approach will informatics. Before enrolling into that course, students are
not have any consequences on following tasks. Students do not required to take a compulsory introduction to software
really need to balance reasons for or against alternative engineering in the preceding semester.
solutions. So, it would not matter if requirements were wrong “Software Modeling” has been offered for several years and
or incomplete since students would not suffer from the has been continuously evolving, including its didactical
consequences. approach. The 2013 revision of the didactical approach aimed
Even if, at a later stage, the focus shifts from programming at improving students’ understanding of requirements
to software engineering, and in particular to requirements engineering and has been described in detail in [1].
engineering, the situation remains somewhat problematic: Due For this approach we defined several intended learning
to time or capacity restrictions, the complexity of real world outcomes in detail:
problems can hardly be reproduced in university education. Students shall acquire a more tangible impression of
As one consequence, students usually do not perceive the term “requirements”.
interdependences between requirements. They often suffer Students shall understand the importance of
from the misconception that complexity scales up linearly. requirements and shall be able to act accordingly.
While a single use case is fairly easy to specify, dozens of use Students shall understand characteristic approaches to
cases are not. If the number of requirements grows, so do the the specification of functional and non-functional
interdependencies between them. requirements and their prioritization.
In addition, students are in general given precise Students shall understand the role of communication
assignments and only need to apply known methods to solve a with other involved parties in requirements
given problem. In university education students do not need to engineering.
think about what the nature of the current problem actually Students shall understand the role of business
might be. Students tend to take clear requirements for granted. processes as a source of requirements.
For instance, it is quite easy for students to model a business Students shall be able to collaboratively apply
process and extract use cases from it when the given example is appropriate methods and notations in order so specify
very simple and clearly delimited. In “real” requirements requirements for a sample software application.
engineering, requirements engineers first have to clarify the Students shall understand popular approaches to
problem and then understand and solve it. They first have to complexity and cost estimation for software systems.
Based upon the intended learning outcomes, the sequence of requirements and the difficulties in eliciting
of topics was restructured in order to focus on the given requirements. This teaching goal is assumed to be
problem first before presenting solutions, relevant issues were achieved if students are capable of eliciting
illustrated on the basis of a continuous example, additional requirements from future users, modeling business
practical exercises were introduced, and predominantly passive processes, and writing a requirements document.
learning settings shifted towards more active ones. The course Students should enhance specific communication skills
emphasizes business process models as a source of that are needed in requirements engineering. Students
requirements. Modeling processes puts software engineers in a should be enabled to conduct a customer meeting in a
position to extract requirements indirectly from an goal-orientated way to elicit requirements. How can
organizational workflow instead of, or in addition to, asking students elicit requirements which they did not
future users which functional and non-functional features the “invent” themselves but are to be provided by a real
new software should exhibit. customer? How can customers be prompted for
This didactical approach includes the assignment to develop information which may serve as a basis for
a requirements specification in teams of four or five students. requirements? How can requirements be documented
To this end, students are exposed to a problem setting that they and written down? How can students pass this
were sufficiently familiar with. For instance, the problem challenge within a team (allocation of roles, etc.)?
setting in 2013 was the derivation of requirements for a system A third teaching goal is to strengthen self-reflection,
to support the application, approval, and reimbursement for self-organization, and self-responsibility of students.
business trips. As a first step, students were required to develop This is the basis for competence development [2].
business process models for the problem setting. The basic As a consequence of the new prioritization of intended
input for students consisted of an official leaflet which is used learning outcomes, a gap between them and the didactical
as a guideline for university members whenever they are about design became evident so that some didactical fine adjustments
to go on a business trip. This brochure contains detailed rules became necessary.
for the application and reimbursement of a business trip and
provides some details of how the process works. The teams of II. CHARACTERISTICS AND PEDAGOGICAL UNDERPINNING OF
students extract distinct steps of the process before modeling A NEW DIDACTICAL APPROACH FOR TEACHING
them in a notation of their choice. REQUIREMENTS ENGINEERING
The business process models were subjected to a peer Based upon the experiences with the 2013 approach, we
review. The process models of a peer group then served as a retained the structure of contents, activating learning elements,
basis to extract use cases and fine-grained requirements. and a continuous example which culminates in writing a
Although this approach was successful from the requirements document. Since active learning elements are
perspectives of instructors as well as students, it still revealed commonly considered as a good approach for understanding
some potential for improvement. Even though the assignment abstract topics, we enhanced these aspects in the 2014 iteration.
used a real world scenario, there is still no real customer from Students should play an active role in nearly every lesson
whom requirements must be elicited. And even though students instead of just listening to the instructor. During the lessons
obviously learned a lot in this course, not all teaching goals activation comes in by, e.g., small tasks that students need to
were completely achieved. deal with or by discussions between students and instructors.
To sum up, in 2013 we applied several fundamental One main weakness of the 2013 approach is the lack of
changes to our previous teaching approach in order to achieve eliciting requirements from a real future user or customer. So
our intended learning outcomes. Due to the fact that this new we refined our didactical setting mainly with respect to the
course design helped students to achieve these aforementioned following aspects.
goals, we decided to retain this didactical approach at large,
and to refine it here and there. A. Eliciting Requirements from Real Customers
So, in the 2014 iteration, we first refined our intended One of the major drawbacks of our 2013 didactic approach
learning outcomes. So far, they were a little too abstract and we was the fact that it did not address requirements elicitation.
adapted the importance of some teaching goals again. While, Several years back, we had tried to include this issue by having
for example, writing down given requirements is not the main students elicit requirements from a peer team. Although this
focus any more, we now emphasize eliciting requirements form approach provided some insights with respect to difficulties of
customers before writing them down. eliciting requirements, the whole setting was still artificial –
students tended to be too cooperative in the role of a customer
C. Intended Learning Outcomes since they had no precise impression how real customers might
The course “Software Modelling” aims at three main goals act.
in addition to the existing intended learning outcomes: Therefore, we decided to bring in a real customer in 2014.
Students should understand the role and importance of Since we had chosen a system for managing offered training
requirements for their future careers. Students should courses as application domain, we got in touch with a training
develop problem awareness with respect to provider in order to convince them to act as customers, a plan
requirements engineering and recognize the importance to which they happily agreed. We contacted a training and
consulting company with particular expertise in intra-project arrive at this insight by thinking about this exercise by
communication. This gave us an opportunity to include an themselves.
additional aspect: Besides acting as a customer and reproducing In a next step, students got an introduction to modeling
typical behavioral patterns of customers in doing so, we had the business processes by using BPMN or event-driven process
chance to move to a meta-level right after the elicitation chains (EPCs).
session. On this meta-level, the “customers”, now in their role Then students were split in two groups of, by and large, ten
as communication experts, were to initiate a joint reflection members each. Student teams were given a second assignment,
with the student team on what had just happened in the namely they were supposed to elicit requirements from a real
elicitation session in terms of (un)successful communication. stakeholder, exchange their results, and build business process
In addition to being more realistic, students were expected models on the information they received from the customer
to take the whole exercise more serious since they would not (see sec. III.A.). Process models were developed in a two-step
like to disgrace themselves in the face of externals. approach: first, each team member developed an individual
Furthermore, credibility was expected to increase since model before these individual models were merged and
statements of external experts, based on their immediate consolidated into a joint team model.
practical experience, were deemed to have more weight than In the first exercise a lack of working techniques became
those of the instructor, who is latently alleged to exaggerate evident. Therefore, we modified our second task by giving
and, after more than ten years at university, to have lost more precisely formulated briefings. For example, we added
immediate contact to what’s happening in practice. the following passage:
Students were split in two groups of approximately ten
individuals and devoted a three-hour block for each team’s Exercise 2: Conduct a customer meeting
elicitation session. About half of the session was planned for […]In preparation of the elicitation meeting with the
the actual elicitation of requirements from two customer customer, find an agreement on your intended course of action
representatives, and the other half, without the students (among other things, your strategy to ask questions) and
knowing before, for an on-the-spot reflection of what went well distribution of tasks. Clarify in the run-up the questions, you
and what did not. Students were asked to prepare for the want to ask, the allocation of roles within your team, and the
elicitation meeting by pondering about good questions to ask, exchange of results at the end of the meeting. […]
e.g. for identifying and clarifying business processes at the
customers’ site, and agree on an allocation of responsibilities As an additional reaction to the two phases of the customer
and tasks within their team. meeting (see sec. III.A.), which already included
B. Multi-level Teaching Approach communication analyses on a meta-level, instructors decided to
When students enter this course, they already have some add a lecture session in order to further address communication
theoretical knowledge about specifying functional requirements and working techniques. In particular, this lesson put a focus on
through use cases [3]. working techniques including allocation of roles and goal-
We started the course with a first assignment that should be orientation, approaches for preparing and conducting a
accomplished in teams of four students: customer meeting [4], question strategies, and communication
techniques such as active listening [5]. This lesson was given in
a pair-teaching format: the responsible instructor for this course
Exercise 1: Bidding for a software project with expertise in informatics acted jointly with an instructor
A seminar provider intends to purchase a software system with pedagogical background. As its main advantage, such a
to manage his offered seminars. Imagine you as director of a format offers the possibility to adapt and combine technical and
software development company are asked to make an offer for non-technical knowledge and highlights inter-relationships
such a software system. between two disciplines to students. The customer meetings
1. Think about your next four to five steps you would do, to were analyzed again in a group discussion together with the
prepare an offer. What would you do? students. Central questions were: “What went well? What
2. How would you proceed? Give reasons why you decided would you do better next time?” Students realized by
for exactly this methods and approaches. themselves that they should better prepare a meeting. Thus,
3. Which problems might appear? What do you need to they received information about structuring, preparing, and
prepare that offer? chairing a meeting. Furthermore, they learned about types of
Write down your results on a flipchart. questions and question strategies to elicit needed information.
(Working time: 30 minutes) This seems to be a good pedagogical approach because
Present your results in class. possible solutions are only presented after the need had actually
arisen, i.e. students had already experienced a problem before
Students were supposed to take an active part in the course they learned about possible solutions. Instead of teaching
right from the start. This first exercise mainly aimed at raising abstract and theoretical stockpiling knowledge, for which
awareness of requirements as an absolutely necessary students typically do not know any use case, they could directly
prerequisite for bidding for a software project. Students should transform and apply the “newly acquired” knowledge.
As a preparation for the following session, students were the interaction between the learner and the environment [8]. [8]
also taught how to provide and to accept feedback, especially conclude that “cognitive conflict or puzzlement is the stimulus
in a review process. for learning and determines the organization and nature of what
In parallel to the meta-analysis of the customer meeting, is learned. […] Knowledge evolves through social negotiation
students got an assignment to model a business process in a and through the evaluation of the viability of individual
notation of their choice. This task should be performed at home understandings.” It is necessary that the learner ties up his
by each student individually. Following this, students should already existing knowledge and expertise to further develop it
merge their individual business process models and derive a in his own way. Therefore, each student learns individual
joint group model. The third exercise was to review their things according to his previous understandings, skills, and
merged processes between teams of four or five students. To knowledge even if they experience the same learning situation.
this end, they needed to remember and apply feedback rules. Successful learning happens in learning situations which
Without a-priori information about feedback and review are adapted to students’ previous skills and knowledge.
processes students might feel accused and criticized. Therefore, one of the main challenges in constructivist
Business process models are intended to serve as a source didactics lies in recognizing students’ prior knowledge, then
for requirements. Thus, students should now learn how to create appropriate learning environments, and adapt them
extract requirements from a business process model and write a specifically to the prior knowledge of students. In our
requirements document. For this reason, a metaplan technique didactical approach we gradually build up students’
was used to activate students and collect contents of a competencies by leading them through consecutive exercises,
requirements document as a first overview. Then several and strengthen their analytical skills as well as their self-
specific topics were worked out in class. During the following organization by activating self-reflection processes.
weeks, students were guided through several tasks which are Learning takes place when students consider the topics as
necessary for writing a requirements document. Now that they relevant for their purposes [2]. As a consequence, they are
know the context of single components they were gradually led interested in the issues and motivation for learning arises.
to a complex document which contains all topics they learned Instead of teaching solutions for problems which students
before. Combining elements they develop over the time by cannot even imagine, we make them see and understand the
themselves leads to a complete requirements document. problems right at the beginning. After recognizing the problem
Students had to work on individual and group exercises to they learn possible solutions to solve it and apply their new
repeat the learned contents in active work. Furthermore, they knowledge (learning by doing). In educational psychology
should apply theoretical learned knowledge and transform it these principles are main factors for successful learning [2].
into usable action knowledge.
In order to increase students’ motivation, various exercises III. EVALUATION AND LESSONS LEARNED
were associated with microcredits, i.e. a small bonus that may A. Instructors’ Perspectives on Lessons Learned
be used to improve the final grade in the exam.
As instructors, we were surprised by the lack of students’
C. Pedagogical Underpinning work techniques we observed. Initially, we assumed that
There are indications that we learn students had already exercised basic work techniques or basic
“- 10 % of what we read, communication skills at school. Yet, apparently this was not
- 20 % of what we hear, the case: The first given task turned out to be too complicated.
- 30 % of what we see, This became evident during group work. While it was no
problem for students to assemble in a group, they seemed to
- 50 % of what we hear and see,
have severe difficulties to organize themselves within the
- 70 % of what we say,
group. Instructors expected that there would be a team leader,
- 90 % of what we both say and do” [6] [7].
one student who writes down the results, one who presents
We choose this didactical multi-level approach to gradually
them, one student as time keeper, etc. But teams started to work
build up students’ competencies without overburdening them.
without structuring themselves, let alone assign roles to
Apparently, students are not used to structure their own
individuals. Even though instructors, at least from their
working processes. With our approach we want to foster their
perspective, provided a precisely formulated work assignment,
self-organization and self-responsibility, and develop their
results were fairly unstructured. Students read the assignment
communication skills and working techniques step by step.
once at the beginning of the lesson, and then started to work
Students’ previous knowledge and level of competence must be
without having a second look on the assignment. As a result,
taken into account. This is a precondition to give students the
the results did not accurately fit the assignment. Teams should
possibility to further develop their competencies.
write down their final results on a flipchart and present them in
Designing an appropriate learning environment should be
class. Although students were advised to better use two sheets
based upon constructivist principles. According to
of a flipchart, some of them used both sides of a single sheet.
constructivist didactics, teachers act as coaches and can only
A severe lack of work techniques became also visible in the
give students room for their individual learning experience.
requirements elicitation session: students neither succeeded in
Learning in this theory depends on the individual world and on
allocating roles and tasks within their team, nor did they agree
the things a person learned before. Understanding arises from
on question strategies before the meeting even though they
were provided with some advice what they were supposed to skills they bring into their studies, university teachers have to
do. The provided hints were already a reaction to the perceived change their view on students’ competencies and their learning
shortcomings in the first group assignments. As a consequence, processes.
we made our second exercise more precise and tried to give Moreover, students often do not have any idea which
students more advice on what they could do to master the methods and tools may help to elicit requirements from
challenge. However, it was not enough and obviously did not stakeholders. They do not know basic techniques to conduct a
help students at all. They were not able to prepare themselves conversation which gives them needed information about
for the meeting with the customers as we expected. Even processes in companies and the resulting requirements. During
though nearly all students were interested in participating in a this course, instructors recognized that even if students knew in
customer meeting, some of them appeared completely principle how to cope with the tasks, they looked helpless on it
unprepared. They neither had thought about possible questions and had no idea what to do. Therefore, in addition to specifying
they could ask, nor had they decided about team roles etc. All assignments, instructors added a lesson to follow up on the
in all, these and several other observations led us to the customer meetings. Topics of this lesson were - in addition to
assumption of lacking working techniques. methodological aspects - communication skills, such as
As a consequence, we added a teaching goal during the questioning, and self-organization, such as preparing a meeting.
term that students should improve personal working techniques As described above, pair teaching was chosen as didactical
such as time management, endurance, self-organization, and approach. In this lesson, students should get more action
structured course of action. Apparently, instructors’ original knowledge how they could master the given challenges. Course
intention to concentrate on fostering context-sensitive non- evaluation shows that students found this follow-up helpful.
technical competencies in requirements engineering was too Several students appreciated this particular lesson when they
ambitious since prerequisites were missing. were asked for things they considered necessary and important
Obviously, providing theoretical information about writing in an evaluation.
on a flipchart or organizing a team has no effect on students’
B. Student Evaluation
learning processes. Rather, they need to experience some
situations by themselves before learning becomes possible, An intermediary evaluation of the course was conducted
including the possibility to make mistakes and learn from them. using the Software Engineering Competence Assessment Tool
Apparently, students must reverse a flipchart sheet during the (SECAT) which was developed to evaluate students’
presentation of their work to recognize room for improvement. competencies from multiple perspectives such as teachers,
There is no point in telling them solutions before they lecturers, or other students [11]. In this case, we used a self-
experience the problem. estimation of students’ competencies. SECAT also allows
As instructors, we draw the conclusion to supply even focusing on the assessment of one or more of nine criteria
clearer task assignments with very precise descriptions of what which are allocated to three levels of competence (see fig.1).
to do in future courses. Exercises should even be fairly fine-
grained including precisely formulated steps what to do next.
Therefore, according to constructivist didactics, the third
task was not simply “Write a requirements document”. Instead
of giving students a complex problem in one big chunk, we
took our students by the hand and guided them through the
process. The large task “requirements document” was
partitioned into several smaller exercises, such as “Develop a
use-case diagram”, “Specify use cases”, or “Derive functional
requirements”. Each week students got a new small task.
Adapting microdidactical elements during the lesson is
based on the didactical principle of participant orientation Fig. 1. Levels of competence in SECAT
(“Teilnehmerorientierung”) [9] which is perfectly in line with
constructivist didactics. [10] describes it as “reading“ and
„flexing“. Reading means attentively observing students, while
flexing concerns reacting on recognized requirements and Non-technical skills are high-level competencies in contrast
needs. This generates an iterative process of adapting teaching to functional technical knowledge or the ability to present some
and learning. content. In this case, we focus on problem awareness, context-
In constructivist didactical theory, teachers act as coaches sensitivity, and personal skills. Our teaching goals, namely
for students and foster technical skills in combination with non- improving problem awareness with respect to the importance
technical skills. Therefore, in future courses problem of requirements engineering, fostering communication skills in
statements must be considered in more depth. It is necessary to context of customer meetings, and strengthening self-reflection
work them out in more detail, and the nature of tasks in as a basis of competence development are reflected in these
assignments needs to be well thought-out. Due to the fact that three criteria. Each criterion was evaluated by means of 4 to 10
university cannot change students’ previous knowledge and
questions, according to the importance of the teaching goal (see In last year’s evaluation only 66 percent of our students
tab. 1). agreed.
During the course, most of our students recognized the
TABLE I. NUMBER OF SECAT QUESTIONS ACCORDING TO IMPORTANCE importance of requirements engineering for their future work
OF THE TEACHING GOAL
(see fig. 3).
Criterion Number of Questions
Problem awareness 4
Context sensitivity 10
Personal competencies 8
Creativity 2
Total 24
Each criterion is adapted to the specific situation and
weighted by the number of questions per competence within Fig. 3. Due to the course, I can now better appreciate the relevance of
the criterion. In this case, the main focus lies on context requirements for my work
sensitivity which depicts in the competence “conducting a
customer meeting”. Table 2 shows the competencies which
describe each criterion. As a result of the course nearly all students feel able to
conduct a customer meeting for eliciting requirements (see fig.
TABLE II. COMPETENCIES PER CRITERION 4).
Criterion Competencies
Problem awareness Problem awareness / ability to abstract
Moderation / Presentation
Conducting a customer
meeting
Context sensitivity
Integrating in a team
Empathy
Endurance
Working techniques
Self-organization
Role allocation Fig. 4. Due to the course, I can now better conduct customer meetings.
Personal competencies Time management
Personal engagement
Goal orientation
Self-reflection Due to the course, students feel now able to reflect on
Creativity Creativity / Variety of methods
situations and analyze them (see fig. 5).
82 percent of a total of 20 students took part in the customer
meeting, 88 percent modelled a business process on their own,
and also 88 percent took part in the review process.
82 percent of our students find requirements engineering
more interesting in comparison to the beginning of the term
(see fig. 2). In the following figures, the left end of the scale
means “Completely disagree”, the right end means
“Completely agree”.
Fig. 5. Due to the course, I am now better equipped to analyze and
understand specific conversations.
As a result of students’ self-estimation with SECAT,
competencies in the three main criteria, namely problem
Fig. 2. Due to the course, I now view requirements elicitation more awareness with respect to the importance of requirements
interesting than before the course
engineering, communication skills in customer meetings, and
self-reflection, increased significantly (see fig. 6).
Fig. 6. Average increase of competence criteria
All in all, the evaluation showed a particular increase of
competencies related to addressed intended learning outcomes
(see fig.6 and fig. 7).
Fig. 8. Average increase of competencies per student
Also, even after being reluctant to be exposed to activating
forms of learning, students seem to appreciate this format. In
addition to statements in the evaluation which support this
claim, this hypothesis is further substantiated by other
indicators: 20 out of the 22 students who initially enrolled in
the course actively participated in the course continuously, only
2 dropped out early. In addition, we had a regular physical
Fig. 7. Average increase of competencies over all students
attendance of 17 to 18 students in class throughout the
complete semester, which is an unusually high rate. Since the
Fig. 7 shows the largest increase of competence in course is an elective one without compulsory attendance,
“conducting a customer meeting”, followed by “self-reflection” students would certainly have been scared away if they had not
and “problem awareness”. All values for these criteria are on a seen a real benefit in getting actively involved in the teaching
fairly high level of approximately 3 points. and learning activities that we devised for the course.
Three out of 17 students (number 3, 5, and 10) did not take
part in the customer meeting. Student nr. 10 with value 2.00
neither took part in the customer meeting, nor in the review of IV. SUMMARY AND OUTLOOK
process models. We developed a didactical approach for requirements
Evaluation results suggest that the chosen teaching engineering education. Core ingredients of our approach are a
approach allocated at constructivist didactics with realistic and integrated setting, which includes writing a
consideration of psychological learning principles works well. requirements document for a complex application and, as of
Evaluation results indicate that the approach fosters students’ late, eliciting requirements from real customers. In our specific
competencies as explained in sec. II.C. Even intended learning setting, customers play a double role: in addition to simply
outcomes which were added during the semester, such as providing requirements, they also act as external experts for
working techniques, methodological skills, personal communication issues. Another main characteristic of our
engagement, role allocation, or goal orientation, benefitted approach is the extensive active involvement of students in the
significantly. All students improved their competencies learning process. In particular the latter aspect has a solid
according to their self-estimation with values of at least 2 (see theoretical underpinning in constructivist didactics. An
fig. 8). additional characteristic of our approach is a strong emphasis
on non-technical skills which are particularly relevant for
requirements engineering, but also gain a very specific, The research project EVELIN is funded by the German
context-sensitive shape in this particular domain. Ministry of Education and Research (Bundesministerium für
Self-evaluations of participating students indicate Bildung und Forschung) under grant no. 01PL12022A.
significant increases in competencies that are relevant for
requirements engineering and that we particularly targeted in
the course. Currently, a final self-evaluation of students based REFERENCES
at the end of the course is under way. In addition, we are just [1] Y. Sedelmaier and D. Landes, “Using Business Process Models
about to supplement and contrast the perspective of students to Foster Competencies in Requirements Engineering,” in Proc.
with a SECAT-based evaluation from the instructor’s 27th International Conference on Software Engineering
perspective. Since the written examination associated with the Education and Training (CSEE&T), 2014, pp. 13–22.
course will be held shortly, we shall be in a position to [2] C. R. Rogers, Freedom to learn: A view of what education
correlate evaluation and examination results. might become. Columbus, Ohio: Charles E. Merrill, 1969.
Although evaluation results so far indicate that the [3] A. Cockburn, Writing effective use cases. Boston: Addison-
approach worked well, we still found potential for further Wesley, 2001.
enhancing our didactical approach. [4] J. W. Satzinger, R. B. Jackson, and S. D. Burd, Introduction to
It would be desirable to keep the meeting with a real systems analysis and design: An agile, iterative approach, 6th
ed. Mason, Ohio: Course Technology, 2012.
customer on a regular basis for future courses. This seems to be
the best way to make students understand the impact of [5] U. Vigenschow, B. Schneider, and I. Meyrose, Soft Skills für
Softwareentwickler: Fragetechniken, Konfliktmanagement,
requirements engineering. Unfortunately, organizational and
Kommunikationstypen und -modelle, 2nd ed. Heidelberg:
financial difficulties have to be tackled before future students dpunkt-Verlag, 2011.
may be offered the opportunity for a real customer meeting. In
[6] N. Green and K. Green, Kooperatives Lernen im Klassenraum
a similar vein, it would be helpful if customers were not only und im Kollegium: Das Trainingsbuch, 3rd ed. Seelze-Velber:
available for an elicitation session, but also for, e.g., a review Kallmeyer, 2007.
of business process models or requirements documents since [7] W. Niggemann, Praxis der Erwachsenenbildung. Freiburg:
this might uncover additional communication problems and Herder, 1975.
expose potential for further competence development. [8] J. R. Savery and T. M. Duffy, “Problem Based Learning: An
In future iterations of the course personal competencies Instructional Model and Its Constructivist Framework,” in
such as working techniques and methodological skills should Constructivist learning environments: case studies in
be taken into consideration right from the start. Instructors instructional design, B. G. Wilson, Ed. 2nd ed, Englewood
gained new insights into the level of basic skills of students. On Cliffs N.J: Educational Technology Publications, 1998, pp. 135–
this basis, they should adapt the didactical design to these 148.
additional intended learning outcomes, following the line of [9] U. Holm, Teilnehmerorientierung als didaktisches Prinzip der
participant-orientation (see sec. IV). Our experiences indicate Erwachsenenbildung - aktuelle Bedeutungsfacetten. Available:
that university education must begin to foster basic skills at a http://www.die-bonn.de/doks/2012-teilnehmerorientierung-
much earlier point of time in bachelor programs. 01.pdf (2014, May. 31).
Furthermore, it would be interesting to collect data from [10] D. E. Hunt, “Lehreranpassung: 'Reading' und 'Flexing',” in
several cohorts of students. This would allow testing the Berichte, Materialien, Planungshilfen / Pädagogische
Arbeitsstelle, Deutscher Volkshochschul-Verband,
hypothesis that this approach works well for similar groups of
Sensibilisierung für Lehrverhalten: Reaktionen auf D.E. Hunts
students. „Teachers' adaption - 'reading' and 'flexing' to students“, A.
Claude, Ed, Frankfurt (Main): Pädag. Arbeitsstelle, Dt.
Volkshochschul-Verb, 1986, pp. 9–18.
ACKNOWLEDGMENT
[11] Y. Sedelmaier and D. Landes, A Multi-Perspective Framework
We thank Ewa Sadowicz and Rainer Alt of for Evaluating Software Engineering Education by Assessing
EinfachStimmig, Nuremberg, for their active support. Students’ Competencies. In Proc. 44th Frontiers in Education
Conference (FIE 2014), Madrid, Spain, to appear.