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.