[ieee 2009 fourth international workshop on requirements engineering education and training (reet...

Teaching Requirements Engineering To the Bahá’í Students in Iran Who Are Denied of Higher Education

Didar Zowghi

Faculty of Engineering and Information Technology University of Technology, Sydney

[email protected]

Abstract

The increasing interest in Requirements

Engineering (RE) in recent years has motivated many academics to provide students with a broad knowledge of the fundamental principles of RE. In RE Education and Training (REET), it is imperative to cover a wide range of topics and teach a variety of skills. Major challenges of REET have already been well recognised and documented in the literature. Moreover, wide spread use of web-based education has caused an explosion of published literature related to distance education. When students are not collocated with the instructor and they themselves are geographically dispersed clearly exacerbates some of the well-known challenges of REET. In this paper I share the experiences gained in teaching an online postgraduate RE subject for the first time to students located in Iran. These students have been denied of basic human rights, specifically access to University education. I used role playing as a pedagogical tool to give students a greater appreciation of issues and problems associated with RE in quasi-real settings. This paper describes some of the challenges encountered and the lessons learnt with some suggestions on how to address, among other issues, the problem of distance between students and the instructor.

Keywords: Requirements Engineering Education,

Role Playing, distance education

1. Introduction

Requirements engineering is recognised as a multi-disciplinary, human-centred and communication rich process in software development. The RE methods, techniques and approaches to date have drawn upon a variety of disciplines, and the requirements engineers are increasingly expected to be well versed with these disciplines [19]. Requirements engineers need to be able to communicate effectively with a wide range of people, with different backgrounds and personal goals

frequently not good at articulating what they really want from a computer-based system.

One of the fundamental RE-related problems faced by project teams is the communication barrier that exists between developers and customers. Often concepts and categories that are known to one community of participants can be entirely opaque to members of the other participants. The fact that this opacity exists is rarely noticed in the course of elicitation unless specific attention is paid to it. Requirements engineers must be able to speak to the customers about the problem that is being solved by a computer-based solution in a language that they can understand. Furthermore, they must be able to ask the participants the right questions at the right time during the course of elicitation to capture the real needs.

Another important issue that requirements engineers face in practice is the ability to choose the most effective analysis and modelling techniques suited to solving the problem at hand. To be able to make such an informed decision, practitioners need to be familiar with a range of modelling and analysis techniques. Most of the modelling notations (e.g. UML) are commonly taught in universities and graduates from software engineering or computer science courses are expected to be fully familiar with analysis and modelling techniques.

Finally, the poor quality of the end product of requirements engineering (i.e. systems requirements specifications, SRS) such as missing, ambiguously presented or misinterpreted information, poor representation, untestable statements of requirements and redundant information are among the most critical problems facing requirements engineers. Requirements engineers must have a range of writing skills such that they can produce precise, concise, consistent, clear and unambiguous statements of requirements.

To cover all of the above skills adequately and in reasonable depth over one semester long RE university course given the limited time and available resources is very challenging. In 2002, I was motivated by this challenge to design and deliver such a subject for the first time to second year undergraduate students at the University of Technology, Sydney (UTS). The course

2009 Fourth International Workshop on Requirements Engineering Education and Training (REET'09) 978-0-7695-4103-7/10 $26.00 © 2010

was carefully designed such that it would result in learning outcomes that address the fundamental skills discussed above. The educational community is increasingly shifting from lecture-format subjects to formats that require students to exercise the ideas they are learning either in team projects, problem solving, or direct involvement with actual development [21]. As such, for requirements elicitation, I used role playing as a pedagogical tool to familiarise students with the range of issues and problems in RE practices. The course delivery and lessons learnt were described in [22]. In subsequent offering the course was reviewed and revised and more experiences gained and published in [23] and [28]. In 2006, I was asked to design a more advanced RE course for the post-graduate students at UTS. Once again I used role-playing not only for elicitation but also for specification and validation activities. This course so far has been offered 3 times and based on informal peer review, self evaluation and most importantly students formal feedback surveys and informal comments it seems to have adequately achieved many of its objectives.

In 2008, I was invited by the Bahá’í Institute for Higher Education (BIHE) to teach an online RE course to their Master of Software Engineering students situated in different cities in Iran. The BIHE was founded in 1987 in response to the Iranian government's continuing campaign to deny Iranian Bahá'ís access to higher education [24]. Faced with unrelenting religious persecution involving complete violation of basic human rights, including systematic denial of access to higher education, BIHE developed courses delivered at the outset by correspondence and later for security reasons on-line, using available information and communication technologies. In addition, an affiliated global faculty (AGF) has been established comprised of hundreds of accredited professors from universities outside Iran who assist BIHE as researchers, teachers and consultants.

In this paper I describe the RE subject that I designed and delivered to Bahá’í students in Iran and the experiences and lessons learnt from this unique privilege. The rest of this paper begins with a short historical overview of REET followed by the teaching techniques employed in this course. The next section describes the course overview followed by sections on the course evaluation, challenges, lessons learnt and conclusion. 2. REET: Historical Overview

Macaulay and Mylopoulos’s investigation is probably the first published report of RE training and education [17]. They examined the issues in RE

education by two brief investigations: first among some of the academic participants of the RE’95 conference in York and then through a brief survey of industry. Their attempt in formulating some general requirements for RE education provides a classification along three dimensions: a) What industry feels that universities should be teaching, b) skills that students need to develop for more effective RE, and c) concepts, techniques and tools of RE that students need to know about. More recently some aspects of RE curriculum has been covered in the SEWBOK [9].

In most of the software engineering university programs it is generally assumed that the requirements have already been elicited and captured in a document and students’ experience often begins from early design stage. Moreover, up until a few years ago curriculum at postgraduate level did not adequately cover all of the above mentioned RE skills in reasonable depth.

The paucity of widely accepted RE curriculum and lack of adequate coverage of the RE education and training issues in the relevant literature provided the motivation for organising the first REET panel in RE04 [25]. The purpose of this panel was to review the status of RE university education and the industrial needs for RE training. I was interested to increase an overall awareness, explore alternatives and identify solutions concerning the teaching of RE. The overwhelming participation and depth of the discussions in that panel encouraged us to organise the first and second International REET workshops in conjunction with RE’05 and RE’07 respectively [26]. The REET workshop series (including REET’08 [27]) and among others, REET related panel discussions at RE conferences have become the best sources of research on this topic.

3. Teaching Techniques

Problem solving approaches are traditionally covered as analysis and modelling techniques that has been taught under “systems analysis and design” in Information Systems and Software Engineering. Communication skills come in two forms: (a) Oral communication skills are needed that would equip students to interact with the clients or users in a language that they can understand. Moreover, interviewing skills are essential that would enable requirements engineers ask the right types of questions from the stakeholders in elicitation and validation of requirements. Students also need to learn and practice negotiation and prioritisation skills with relevant stakeholders. (b) Written communication skills are essential such that students will learn how to write


specification that exhibits quality attributes such as being precise, concise, unambiguous, consistent, complete, and thus correct.

To achieve these aims we sought an approach based on active involvement of the students in related RE activities and one that requires personal interaction between students as well as between students and instructors. Role playing and group work was thus used as pedagogical approaches.

Role playing has been used in many disciplines for a number of years. Examples include nursing [8], medicine [2] and clinical psychology [20], engineering [7], and management [13]. Role playing has also been used in computing and information technology such as in teaching hardware design [15], formal methods [11], and object-oriented design [1]. Role-playing has been frequently used as a requirement elicitation technique between a requirements engineer and the stakeholders [16] along with simulation, prototyping and storyboard [18]. This technique has been claimed to be a suitable mechanism for learning requirement elicitation [6][22][23].

Goguen [12] regards requirements as “emergent”, meaning that they may not already exist, but rather emerge from frequent interactions between the requirements engineer and the customers. Use of scenarios, storyboards, and role playing has been found to enhance communication between analysts and users and thus promote the ‘emergence’ of the requirements [18].

As with any educational approach, due to experiences of using this technique for several years I was fully aware of the issues and concerns associated with role playing such as the learning curve involved for the participants and time and resources that needs to be invested to set up a role playing environment for learning. Nevertheless, I believed it would allow direct interaction between students as well as between students and their instructor. Moreover, it would create an environment that is as close as we can get to RE in real setting and thus would give a better appreciation of the equally important interpersonal skills in RE to that of technical skills. 4. Course overview

Students undertaking this subject were in their first year of Master of Software Engineering. Class consisted of 22 students, all members of the Bahá’í Faith1 residing in different locations and cities in Iran. All have completed their BSc with BIHE and most of them had some work experience in software

1 www.bahai.org

development either working for small companies or contracting independently. They were well aware of the problems and challenges of online education and reliance on limited information and communication technologies available.

BIHE courses are categorized into four delivery models, and range from classroom to fully online. The fully online courses, referred to as Delivery Model courses, use online functionalities such as discussion groups, assignments, readings and lecture notes, quizzes, and live lectures (conference calls) to replace in-person lectures. Delivery Model courses are frequently taught by AGFs (instructors from outside Iran) but could also be taught by an existing BIHE faculty inside the country. The instructor is responsible for the course curriculum2 and conducting the class.

The instructor is assisted by a Teaching Assistant (TA) and Course Technology Assistant (CTA). The TA is usually located in Iran and is responsible for logistical, student, and some academic issues as determined by the instructor. The CTA is responsible for setting up the course on Moodle3, periodic monitoring and reporting of course health and activity to course faculty and administration, and assisting the instructor with course updates and Moodle issues. BIHE has established standards (required) and best practices (suggested) to enhance the quality and interactivity of online courses [29].

This was the very first time that I was collaborating with BIHE and more importantly my first attempt at teaching online. So, I had a very steep learning curve to face. Given that I had a great deal of RE teaching material from the courses I delivered face to face at UTS, I decided to reuse most of what I already had, admittedly, without paying enough attention to the differences between a physical and virtual class room and to the special needs of online teaching and E-learning. Initially I had to learn how to use Moodle as well as getting to know my assigned CTA (residing in USA) and my TA (residing in Tehran). I also asked all students in the first week to use a Moodle forum to provide a brief introduction about themselves, their background, IT experience and what they hoped to gain from this course. This was an important step to break the ice and give me a better understanding of who my students were.

Instructors are required to deliver bi-weekly, live lectures. The lectures can be delivered using Skype, or Microsoft Live Meeting. Courses should include

2 The instructor specifies the course curriculum by submitting to BIHE an Online Course Syllabus Preparation Form. The syllabus form serves as the basis for setting up the course online. 3 Moodle (http://moodle.org) is an open source course management system. It is the software used to run the BIHE course site.


assigned activities per week that encourage active, direct and participatory learning when appropriate, such as discussions and group work. I decided to deliver weekly lectures because I wanted to give students sufficient time to review the course material regularly. I learnt how to use Live Meeting since Skype deemed unsatisfactory due to poor performance as the number of students increased and also exhibiting feature limitations for E-learning. All lesson delivery used audio only since the limited bandwidth available to students in Iran did not allow the use of video. PowerPoint slides and supplementary reading material such as copies of published papers and book chapters were made available beforehand on BIHE web site.

4.1 Course Content and Assessment

The main learning outcomes for this subject was to introduce students the three fundamental skills: a) interviewing and groupware skills for requirements elicitation and validation, b) analysis and modelling skills for problem solving, and c) writing skills for requirements specification. Six major topics were selected for the semester. Apart from the first and fourth, the rest of the topics are the same as those recommended by the SWEBOK under “software requirements analysis”.

1. Foundations of RE 2. Requirements elicitation 3. Modelling and analysing requirements 4. Requirements specification 5. Validating requirements 6. Requirements management

In addition to weekly lectures on the above topics, upon the request of BIHE I also delivered an introductory lecture on how to conduct a literature review in order to prepare students for carrying out the last assignment.

Topics covered for requirements elicitation involved an overview of a range of elicitation techniques and approaches with a specific emphasis on interviewing skills as they were meant to use interviews for elicitation in their assignments as described below. They were also taught about ‘use cases’ as a technique to describe functional requirements.

Analysis and modelling was covered using UML and we had formal lessons covering both object-oriented as well as structured analysis techniques and methods such as Data Flow Diagrams and Entity Relationship Diagrams. The rationale behind teaching both of these approaches to systems development was that students would get a better appreciation of a range of modelling approaches. Furthermore, they are expected to know all of these techniques to a

reasonable depth for their future subjects as well as their professional careers.

For requirements specifications I used most of the well known guidelines in the RE literature on how to write high quality sentences of requirements by providing “good” and “bad” examples in each case. This was absolutely essential as all students came from non-English speaking background and emphasizing on sentence structure and usage of non-ambiguous words was much appreciated.

Lessons on requirements validation included an overview of the importance of validation and the role it plays in increasing the confidence that specified requirements would satisfy the needs of the stakeholders. Different techniques and methods for validation and inspection were reviewed and exercises were developed to give students a thorough understanding of the subject. This was essential for performing the 3rd assignment.

Finally, for requirements management, I used real data from one of my own case study research to illustrate the issues and challenges in requirements change management. As well, I gave a separate lesson covering the functionalities of the commercially available requirements management tools.

The assessment for this course was based on four major assignments and a written final examination. The first three assignments were conducted in groups of 3 students and the final assignment was individual effort. The first assignment was to develop requirements model by using use case modelling technique, where students were given a case study description to analyse and then conduct interviews with the stakeholder. My TA in Iran agreed to play the role of stakeholder as described in section 5. Students were also given a use case template (a modified version of Cockburn’s use case template [10]) as a guide for this assignment.

The second assignment consisted of the development of a Software Requirements Specification (SRS) document, based on the preliminary description of the problem, the elicitation activities during stakeholder meetings for the first assignment and one further meeting for discussing non-functional requirements and any outstanding issues that needed to be resolved with the stakeholder. Students were asked to develop their SRS using the IEEE template[14] and to revise the SRS in accordance to the feedback from stakeholder meetings. I also introduced students to the Robertson’s Volere Template [30] and gave them a choice if they wished to use it, and one group decided to use this template instead of IEEE. Throughout the SRS development process students were instructed to manage requirement by means of a traceability matrix and revision history incorporated as part of their final SRS submission.


The third assignment focused on requirements validation and students were asked to conduct a formal inspection of a SRS document. The SRS documents that students produced from the second assignment was used for this purpose by allowing students to inspect the SRS developed by a different group. Students were given comprehensive guidance for this exercise and a number of well known checklists and inspection process descriptions and the details of the corresponding roles to play during such a formal meeting were made available for this purpose.

The final assignments aimed to familiarise students with the RE research literature and learning to conduct a critical analysis of such literature for specific topics. I provided a number of different questions addressing specific topics in RE and also distributed some of the well known RE research overview papers to them and asked them to conduct an online search to find relevant papers, read them, summarise them and draw conclusions from them in an attempt to answer the research question.

In the first two assignments, the stakeholder meetings process played a vital role. This process is described below.

5. Stakeholder Meetings Process

Stakeholder meeting process was structured,

communication rich, information centric and result oriented. Although all students were expected to act the role of requirements analyst during the elicitation, modelling and specification activities for the first two assignments, teams were instructed to assign three distinct roles to their members: group leader, administrative assistant, quality assurance. The description of the responsibilities for each role was provided in the assignment sheet. They were also instructed to rotate playing these roles during the stakeholder meetings so that they all experience all roles. The process of conducting requirements elicitation consisted of three stages: (1) Pre-stakeholder meeting activities (2) Stakeholder meeting (3) Post-stakeholder meeting activities. An overview of stakeholder meeting process is presented in Figure 1. 5.1 Pre-Stakeholder Meeting It was important that students gained a thorough understanding of the case study in order to contribute effectively as a team member. The TA who played the role of stakeholder was initially briefed to discuss the existing business artefacts (e.g. workflow, business flow) in meetings, to improve the student’s understanding of the current and proposed system.

Students were expected to be well prepared for the stakeholder meeting. Before the meeting, they should have prepared the meeting agenda and have their questions ready. This is important so as to ensure that meeting was conducted productively. They were given a template for the agenda preparation and for taking minutes of the meeting. They were asked to contact the stakeholder to arrange their meetings. They were allowed in total 3 meetings of half an hour in duration. Since students were geographically distributed, it was not always possible for meetings to be conducted face to face and some meetings took place on Skype.

5.2 During Stakeholder Meeting The role of a stakeholder was to provide all the relevant information about the needs and wants of the project sponsors to the development team. He also provided knowledge about the current system and information about the application domain and to some extent entered into negotiations with the team. The development team had the responsibility to send the agenda and questions to the stakeholder, document the minutes of the meeting and send it to the stakeholder within 48 hours after the meeting for confirmation. 5.3 Post-stakeholder meeting After each meeting, the team typed the minutes of their stakeholder meeting and emailed it to the stakeholder. The stakeholder then responded by either confirming that the minutes were accurate and of a true record or indicated the possible mistakes and inconsistencies found in the minutes. The comments in the meeting minutes were then sent to the team via email. In the following stakeholder meeting session, the development team would need to clarify the issues raised by the stakeholder.

Communication amongst team members and between the team and the stakeholder team had to be coordinated, especially in an environment where


regular contact between team members may be limited. The communication methods made innovative use of electronic resources (such as email, Skype and chat rooms) to facilitate this communication. Project planning involved sub dividing tasks and allocating them to individual team members and then monitoring the performance of tasks.

6. Evaluation

Since this was my first experience in online teaching, I was keen to assess the effectiveness of my teaching, the strength of the material taught and assignment in achieving the course objectives. I was also eager to find out the overall satisfaction of the students with the course and whether it matched their expectations expressed in the first week. I used a variety of data collection techniques at various stages of the course. I decided to do this early rather than wait till the end of the semester so that I will have an opportunity to address any issues before it was too late. So, after the first and second assignment was completed, I asked students to write their reflections on the assignments, specifically the stakeholder meetings process and identify any challenges or issues they faced. I was overwhelmed by the positive responses and the maturity of the comments provided.

Students seemed to enjoy and were motivated by the challenges of the active approach. They appreciated that there are many aspects to RE, and that some of these issues should be present in most, if not all, software development projects. There was a greater recognition that social problems are thorny and just as important as technical issues in RE.

In addition to feedback from students, I also asked my TA to provide evaluation of the overall course content as well as the processes we followed for the conduct of the course and the assignments in general. Given that my TA is highly experienced and qualified academic (who has returned to Iran after completing higher education in the UK), and is very familiar with BIHE and the status of students, I valued his comments and advice. His comments were very positive in nature and was encouraging to know that course content and methods of delivery were found to be effective. Finally, as is my common practice, I wrote reflective notes on weekly basis about the experience so that I can improve any weaknesses that I observed in the future offering of this course.

By analyzing the assignment and the examinations grades of students, it appears that most students gained the intended knowledge at least to that of comprehension level or above, corresponding to Bloom’s taxonomy of levels of intellectual behaviour

important in learning [5]. Overall, my evaluation reveals that all the objectives of the course corresponding the evaluation criteria (as stated in the outline) were achieved.

7. Challenges

Challenges and issues I faced in teaching this subject are many but due to limitation of space I can only share some of them. It is not my intention to claim that they are new or unique in REET but I believe the circumstances and the environment surrounding this experience were certainly new for me. I hope that they can inform those educators who may be faced with similar situation in the future can benefit from reading about these issues. They can be divided into three categories: Technological, language and social issue.

In almost every online session, we faced several technological difficulties. I could never use video channels during lecture; I was told that this would affect the quality at the receiving end. Initially many students had difficulty connecting to Live Meeting but later on this problem was resolved by technical support staff residing in Switzerland. There were always at least 5 students who could not hear my voice even though they were connected to the Internet and could open Live Meeting. We overcame this challenge in two ways. Those students who had difficulty with audio would either go to the home of their fellow students who could connect and hear my voice or if they were geographically too far away, would connect to another student via Skype. The other solution was for one student whose bandwidth was better than others (I don’t know why) to record the lecture and make it available online through an open source software. The recording was available for download up to one week using this software. On several occasions, I downloaded my lecture recording and listened to them for quality check!

It was very difficult to engage students in the classroom discussions. Frequently I would pause and ask students if they had anything to say or if there was something they needed further clarifications. But very few of them would express their comments and questions and it was always the same students; those who were more confident English speakers. Given that the classes were all meant to be conducted entirely in English and the fact that I am not familiar with Farsi words for technical terms, I was at first reluctant to allow students to speak in Farsi. But as time went by I allowed students to ask their questions in Farsi too. The challenge for me was to comprehend what was being asked given my limited technical vocabulary. By the end of the semester, my vocabulary improved and


students gained more confidence. Some students who were reluctant or too embarrassed to ask their question online, would post their questions on Moodle weekly forums that was created at the beginning of semester. This proved to be very effective and valuable both for students and instructor. There were also students who occasionally requested to have a Skype meeting with me and given the circumstances I would agree and talk to them individually to clarify issues.

Not being in a physical classroom with my students meant that I was completely unaware of their attentiveness, attitudes, emotions and understanding. This issue was very difficult for me to deal with. I had to seek my answers by checking the discussion forums regularly to see who is participating and posting notes myself to encourage further participation. The BIHE also provided periodical AGF course performance report. The report indicated the amount of online activity of each student and instructor for each course including assignments, quizzes, and discussions. Live lectures and messages sent through Moodle were not factored into the report. Therefore I could not rely entirely on this report to measure each students’ participation and attentiveness.

The final issue was in relation to the final assignment which was a literature review of the RE publications. I was told that students of BIHE do not have access to public university libraries in Iran not to any digital libraries such as IEEE or ACM. Unfortunately this discovery was made later on in the course. So, in order to overcome this difficulty, I asked them to find the articles they wanted to read through Google Scholar and send me the citation information. I then downloaded the papers and send them copies by email. Later on my TA announced that he now has access to the IEEE digital library and was able to assist me with this task.

Bahá’í students in Iran have faced persecution and denial of basic human rights for 30 years. They have learnt to cope with their unfortunate circumstances by showing perseverance and resilience. I felt truly privileged to have the opportunity to render a small service to these hard working and studios students. It was a pleasant experience for me to be thanked after each lecture by every single student, something that I have never experienced in teaching face to face for over 20 years!

8. Lessons Learnt

In this section I describe some of the significant lessons learnt while teaching this subject to share my experiences with academics and practitioners interested in designing and teaching online RE courses.

Role playing can be very effective in helping participants gain a richer understanding of multiple perspectives in RE and of the “co-dependent arising” of interdependent RE activities. Although there are many positive aspects of role playing observed, there are also known concerns that need to be addressed. For example for the assignments 1 and 2, the TA played the role of the client. This is contrary to the typical situation in real practice where the client is not meant to be really technically knowledgeable. In this case, students knew that the client knows about limitations of technology and is well aware of the requirements. In several instances (that was reported to me by the TA in our weekly Skype meetings), students tried to ask him to help with the structure and contents of the use cases and SRS. The TA was briefed to watch out for the situations that he has to change hats during the stakeholder meetings. In is thus plausible that this issue may have had implications on the requirements determination in the long run. That is, students will rely on the knowledge of the instructor in specifying the right requirement rather than thinking more carefully on whether or not the requirements articulated by the stakeholder indeed make sense.

Also, it is a well-known fact that some requirements are discovered as a result of the exploration of the domain and business needs and occasionally requirements are invented during the process of RE. For the main assignments, students in general did not gain experience with these two types of requirements (emergent and invented). However, the TA tried his best to play the role of uninformed stakeholder as he has had experience with such stakeholders in his professional career. So, overall, we believe that students were ultimately exposed to situations where stakeholders were not absolutely sure about their requirements and as a result of interactions and elicitation sessions, they also experienced some emergent and invented requirements, albeit to a limited extent.

For group work activities, students were allowed to choose their team members. This meant that most teams consisted of people who lived in the same vicinity and perhaps already knew each other. Getting people who do not normally work together to do so, creates new synergies which should promote greater creative thinking as well as developing better interpersonal skills and team work. But given the circumstances, I did not feel strong about selecting team membership myself as it would have severely impacted the students’ ability to meet face to face.

Students were invited to play the roles in their teams almost immediately after they formed their team. Role taking is a skill that has to be built up just as playing soccer begins with simply learning to kick the ball.


Students need to be taught to warm up to the process before they can play the role effectively [3][4]. Unfortunately living in another country did not allow me to observe students during role playing. So, I really don’t know how well they played their role during meetings other than some informal feedback received from my TA. So, in the second offering of this subject I intend to ask students to conduct a warm up session for role playing before teams start the real work. Character profiles, team settings, and role playing operations have to be discussed with students at a greater length. Time must also be spent on monitoring the role play performances and debriefing students on their individual performances.

Two of the important activities of RE process are negotiating and prioritising requirements. Although these topics were covered at length during lectures, mainly due to lack of time, I did not set any exercises that would enhance students’ ability to negotiate and prioritise requirements. Moreover, to exercise negotiation and prioritisation of requirements, the notions of budget and schedule for the project should have been introduced for each system which was clearly beyond the scope of this subject’s curriculum. The only occasions where negotiation was exercised was when requirements were being prioritised for inclusion in the IEEE template as essential and optional requirements. On these occasions, the TA assisted by facilitating discussions to state the relative importance of requirements by simple negotiation.

9. Conclusion

RE teaching and training presents many interesting challenges to those engaged in this endeavour. Distance education provides additional issues to consider for REET. Moreover, teaching students who have been denied of higher education all their lives and who have limited technology and resources to use for distance education provides further difficulties in effective delivery of subject matter.

Among the major challenges is preparing students for effective requirements elicitation, validation and specifications. This paper has stated my position in regard to the core skills that every requirements engineer needs to acquire in order to perform RE related tasks more adequately. I continued to use role playing as a pedagogical tool to provide students a fuller appreciation of the range of technical as well as non-technical issues involved in some of the RE practice.

We have found the RE subject outlined in this paper to be very effective where students gained a better understanding of the process of RE and its related

activities. Moreover, ‘hands-on’ experience with techniques, methods and approaches for requirements elicitation, analysis, modelling, validation, specification and management helped to encourage the much-needed mind-set. Students repeatedly reported how useful they find role playing in giving them a fuller appreciation of what skills needed for more effective RE. They also reported on how much they learnt about the challenges and difficulties people face when engaged in RE. These benefits are still very important even if the students never have to be involved in RE directly in their future professions.

One of the educational dilemmas in RE education is to introduce students to the inherent uncertainties and idiosyncrasies associated with real RE problems [17]. I believe that the curriculum for this RE subject was indeed able to provide that solid foundation in RE but could not fully expose students to the uncertainties that occur in real practice.

The case studies that students worked on did not cover a broad coverage of all types of software development projects such as COTS versus in house, versus customised software development. In future offering of this course I intend to broaden the coverage of RE practices to more classes of software systems and projects.

Another area of future works that I am keen to undertake is to explicitly relate the lessons learned to an appropriate education theory in order to further build up REET body of knowledge. Issues and benefits identified in this paper have the potential to significantly contribute to the REET literature. For example, role playing can be considered a useful method of teaching RE to non-English speaking background students. Furthermore, case studies combined with role playing can serve as an effective communication tool in RE teaching and learning and give a better appreciation of uncertainties of requirements related problems. All these I believe could be better analysed through the lens of an appropriate education theory.

Finally, the challenges I faced, although many but not impossible to address and partially overcome in most cases. In future offerings of this course, I intend to provide online quizzes periodically to increase engagement and participation of students. I hope that with advancement of technology, most of the technical issues will be resolved. More importantly it is my hope that the course content, teaching method, challenges and lessons learnt could be of some value to anyone who may be involved in REET under these difficult yet unique circumstances that I experienced.

10. Acknowledgement


I would like to gratefully acknowledge support provided by the BIHE, specifically valuable assistance provided by my TA in Iran, Mr. Shahram Atrain. 11. References [1]. Andrianoff, S. K. and Levine D. B. Role playing in an object-oriented world, SIGCSE Bulletin, February-March 2002 [2]. Benbassat, J., Baumal R., A Step-wise role playing approach for teaching patient counselling skills to medical students, Patient Education and Counselling 46, pp 147-152, 2002. [3]. Blatner A., and Blatner A., Imaginative Interviews: A psychodramatic warm-up for developing role-playing skills, Journal of Group Psychotherapy, psychodrama & Sociometry, 44(3), 115-120, 1991. [4]. Blatner, A. Role Playing in education, www.blatner.com/adam/pdntbk/rlplayedu.htm, 2002 [5]. Bloom, B.S. (Eds), Taxonomy of educational objectives: The classification of Educational goals: Handbook I, cognitive domain. New York; Toronto: Longmans, Green, 1956. [6]. Callele, D. & Makaroff, D. 2006, ‘Teaching requirements engineering to an unsuspecting audience’. Proceedings of the 37th SIGCSE Technical Symposium on Computer Science Education SIGCSE '0, Houston, Texas, USA, ACM Press. [7]. Chapman G.M., and Martin J. F., Computerized business games in engineering education, Computers Educations Vol. 25, No ½, pp. 67-73, 1995. [8]. Christiaens, G. and Baldwin J.H., Use of Dyadic Role-Playing to Increase Students Participation, Nurse Educator, Vol. 27, No 6, pp 251-254,2002. [9]. Bourque P., Dupuis R., Abran A., Moore J., and Tripp L., The guide to Software Engineering Body of Knowledge (SWEBOK), IEEE Software Vol. 16, No. 6, Nov/Dec 1999. [10]. Cockburn, A., Writing effective use cases, Addison Wesley, 2000. [11]. Dean, N. and Hinchey, M.G. Introducing Formal Methods through role-playing, SIGCSE Bulletin, Vol 3, 1995 [12]. Goguen, J. & Linde, C., Techniques for Requirements Elicitation, Proc. Of the 1st Int. Symposium on Requirements Engineering (RE’93), pp152-164, San Diego, USA,1993.

[13]. Greenberg, J., The role of role playing in organisational research, Journal of management, Vol. 19, No. 2, pp 221-241, 1993. [14]. IEEE Standards 830, IEEE Recommended Practice for Software Requirements Specification, IEEE Computer Society, 1998. [15]. Jones, J. Participatory Teaching Methods in Computer Science, SIGCSE Bulletin, Vol. 19, no 1, 1987, pp. 155-160 [16]. Lloyd, W. J., Rosson, M. B. & Arthur, J. D. 2002, ‘Effectiveness of Elicitation Techniques in Distributed Requirements Engineering’, Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02), IEEE Computer Society. [17]. Macaulay, L. and Mylopoulos, J., Requirements Engineering: An Educational Dilemma, FASE Vol. 5, No. 22, 1995. [18]. Millard N., Lynch P., Tracey K., Child’s Play: using techniques developed to elicit requirements from children with adults, in Proc. Of the 3rd Int. Conf. on Requirements Engineering (ICRE98), Colorado Springs, USA, April 1998, pp 66-73. [19]. Nuseibeh, B. and Easterbrook, S., Requirements engineering: a roadmap, In: Future of Software Engineering, International Conference on Software Engineering, Ireland, 2000 [20]. Pomerantz, A., Who plays the client? Collaborating with theatre departments to enhance clinical psychology role playing exercises, Journal of Clinical psychology, Vol. 59(3), pp 363-368, 2003. [21]. Shaw M., Software Engineering Education: A Roadmap, In: Future of Software Engineering, International Conference on Software Engineering, Ireland, 2000. [22]. Zowghi D., Paryani S., “Teaching Requirements Engineering through Role Playing: Lessons Learnt", proceedings of the IEEE International Requirements Engineering Conference (RE’03), Monterey Bay, USA, September 2003. [23]. Al-Ani, B., Yusop, N., "Role-Playing, Group Work and Other Ambitious Teaching Methods in a Large Requirements Engineering Course", IEEE International Conference on the Engineering of Computer Based Systems (ECBS), Brno, Czech Republic, 24-26 May 2004. [24]. Bahá’í Institute for Higher Education (BIHE), http://www.bihe.org, viewed in June 2009.


[25]. Zowghi D., “Requirements Engineering Education and Training”, Panel at the IEEE International Requirements Engineering Conference (RE’04), Kyoto, Japan. [26]. Zowghi D., and Cleland-Huang J., (Eds), “The Proceedings of the First and Second International Workshop on Requirements Engineering Education and Training (REET2005 and REET2007)”, in conjunction with RE05 in Paris and RE07 in New Delhi, Aardvark Global Publishing, March, 2008, ISBN: 978-1-4276-3012-4 [27]. Zowghi D., and Cleland-Huang J., (Eds), “The Proceedings of the third International Workshop on Requirements Engineering Education and Training (REET2008)”, in conjunction with RE08, Barcelona, Spain, published in IEEE Digital Library. [28]. Yusop N., Mehboob Z., and Zowghi D., “The Role of Conducting Stakeholder Meetings in Requirements Engineering Training”, Second International Workshop on the Requirements Engineering Education and Training in conjunction with RE07, Delhi, India, October 2007. [29]. BIHE Instructor Handbook version 1.4, available from BIHE, 2008. [30]. Robertson S., and Robertson J., Mastering the Requirements Process: Addison-Wesley, 1999.


[ieee 2009 fourth international workshop on requirements engineering education and training (reet...

Documents