Forum for Academic Software Engineering Volume 5, Number 22, Fri Sep 15 09:29:36 CDT 1995 Topics: CFP: ICSE96 Education Workshop Report: Requirements Engineering Education A------------------------------------------------------- From: ludewig@informatik.uni-stuttgart.de (Jochen Ludewig) Subject: CfP for FASE-Newsletter THIRD INTERNATIONAL WORKSHOP ON SOFTWARE ENGINEERING EDUCATION (IWSEE3): CALL FOR PAPERS The workshop will be held in Berlin, Germany, on March 29th, 1996, just after the 18th ICSE. Teaching Software Engineering remains difficult, because the subject itself lacks a clear definition, and the principles of Software Engineering are not widely recognized, neither in industry, nor at universities. Experience should play an important role, but does not fit too well into curricula. The third Workshop on Software Engineering Education will focus on experiences with traditional and new approaches for teaching Software Engineering to students or practitioners. Participation and Topics ======================== The number of participants is limited. Applicants are asked to submit a short paper on one of the following topics: 1. Methods and Tools in Software Engineering Education: None, one, or many? To date, all methods and tools suffer from serious deficiencies, which make it difficult to use them within academic courses and projects; on the other hand, students should have hands on experience. 2. Application Knowledge and Projects in a Software Engineering Curriculum: How much do we need? How much can we afford? Software Engineering is not a goal in itself, but must be applied. Therefore, students should not only work on toy problems, but on real tasks from real applications. But time is limited, and there is no "typical" application. 3. Cooperation of Industry and Universities for teaching Students and Employees: Models and Experiences While industry wants the universities to deliver experienced software engineers, few sites provide opportunities for good practical training. Universities do much teaching, but find it difficult to offer special courses for people from industry. 4. Software Engineering at the University: Within or without Computer Science? Traditionally, Universities treated Software Engineering as a branch of Computer Science. Since the engineering aspect has been emphasized, there is a tendency to offer separate curricula for Software Engineers. Program Committee ================= Anthony Finkelstein, City University London, Great Britain Pankaj Jalote, I.I.T., Kanpur, India Jochen Ludewig, University of Stuttgart, Germany Laurie Werth, University of Texas at Austin, U.S.A. (to be confirmed) Deadlines and Procedure ======================= The program committee will select four to five papers for each of the topics, and ask their authors for a revised version, and for a presentation at the workshop. In order to stimulate discussions, contributions which exhibit a clear and well founded position are preferred. The deadline for short papers, which should not exceed 2000 words, is October 15th, 1995. Notification about acceptance, and requests for revised papers to be included in the proceedings will be issued by December 31st, 1995. Revised papers are due on February 1st, 1996. Please submit short papers by e-mail, if possible, in standard ASCII or in LaTex. Otherwise, send four copies of your paper. Further Information =================== If you have not done so yet, subscribe today to the IWSEE3 mailing list by sending email to: mandlpa@informatik.uni-stuttgart.de (Subject: IWSEE3) Please help us to compile a useful list of participants by providing the following information with all submissions: Mr. or Mrs., last name (first name and middle initial in parenthesis), complete address (including phone, telefax, and e-mail, if available), your organisation, and your main professional involvement. http://www.informatik.uni-stuttgart.de/ifi/se/workshops/IWSEE3.html A------------------------------------------------------- From: jm@cs.toronto.edu (John Mylopoulos) Subject: Report: Requirements Engineering Education We now have a copy of the report on Requirements Engineering education. It is co-authored by Linda Macaulay (UMIST) and includes a report on the discussion at RE'95, attended mostly by academics, also the results of a questionnaire conducted by Linda to find out from industry what they would like to see taught in RE courses. The report will be published in the Automated SE journal and possibly in the RE electronic newsletter. Regards -- John Mylopoulos ----------------- Requirements Engineering: An Educational Dilemma Linda Macaulay John Mylopoulos UMIST University of Toronto 1. Introduction The emergence of Requirements Engineering (hereafter, RE) as an identifiable, coherent research area -- evidenced by a bi-annual symposium (RE93, RE95), an IEEE international conference initiated in 1994, a recently founded IFIP working group, an international journal and numerous international workshops -- suggests that we should be re-examining the role and place of requirements engineering in computer science and engineering university programmes. After all, university education remains a primary vehicle for the transfer of knowledge from the research community to industry and government. Requirements are variously described by practitioners as `intangible', `moving targets', `inherently inconsistent', `ever-changing' and a host of other adjectives which fill the average university lecturer with horror. In a similar vein, Requirements Engineering is described by experienced researchers as a `wicked problem' [Bubenko95]. In contrast to this, university courses normally have a prescribed syllabus and strive to provide students with a solid foundation of knowledge, which will guide practice and will direct future learning. The educational dilemma in teaching Requirements Engineering is to provide the student with this solid foundation in the subject matter while at the same time exposing the student to the inherent uncertainties, inconsistencies and idiosyncracies associated with real requirements problems. The purpose of this article is to review the status of RE university education and the industrial needs for RE skills. Also, where possible, to raise issues, explore alternatives and identify solutions concerning the teaching of RE at the undergraduate and graduate level of software-related university programmes, including but not limited to computer science, computer engineering, information systems, information science, industrial engineering and management studies. The material of the article is based on results of two brief investigations into RE education. The first investigation consists of views expounded during a half-day working group meeting held at the RE'95 conference in York UK, and highlights current practice in RE education as described by thirty or so (mostly academic) participants. The second investigation is based on a brief survey of industry to ascertain what they perceive as needs in RE education. The results of the investigations include a variety of topics taught within the ten university courses mentioned here, and an even wider variety of topics mentioned by the eighteen industry respondents to the questionnaire. It is interesting that some of the industry respondents even express doubts about Requirements Engineering being a suitable topic for university courses. The final part of the paper is a attempt to draw together some of the issues associated with RE education. 2. Current Practice in RE Education The discussion during the meeting of the working group on RE education at RE'95 gives an interesting cross-section of RE education at universities in Europe and North America. Topics that were covered during the discussion included the state of practice in RE university education, potential improvements in areas such as teaching objectives, teaching philosophy, topics taught, textbooks, projects and teaching tools. The following is a series of reports from ten universities: Dan Berry (Technion, Israel): Has taught an RE course which was part of Carnegie-Mellon University's Masters of Software Engineering (MSE) programme. The entire programme was run in conjunction with a studio where students deal with real clients and real software problems. Student projects involved building a software system solution for the client, and getting feedback on their solution. The courses of the whole programme were geared to and timed with different lifecycle phases, RE being one of them. The RE course focuses on two major skills: (i) "ignorance hiding" -- in most situations, the requirements engineer has little or no knowledge of the domain she is dealing with, yet has to deliver a requirements specification which describes the problem and identifies a class of possible solutions; (ii) "model building" -- use notations such as data and control flow diagrams and entity-relationship diagrams, to build models which capture some aspects of the problem, serve as means of communication among different stakeholders (such as requirements engineers, developers, client and end users). Two years ago, CMU changed the structure of its MSE programme so that each course covers a general concept, e.g., architecture, needed in all lifecycle phases. As such, the RE course disappeared with some, but not all of its material absorbed into other courses. It's too early to assess the success of the new approach. Joanne Atlee (University of Waterloo, Canada): The University of Waterloo is introducing a three-course SE sequel at the undergraduate level where students are taught RE, design and implementation, testing. Projects chosen involve either information systems or real-time systems. Moreover, projects are threaded together so that students work on a single problem during all three courses. Ian Sommerville (Lancaster University, UK): They offer a specifications course at the undergraduate level which covers formal specifications and requirements specifications. Students generally prefer the requirements specification aspects of the course (e.g., using data flow diagrams), but have trouble distinguishing requirements from design. Regina Gonzales (University of Colorado, Boulder, USA): Colorado will be offering an engineering science course option, where they will be covering topics ranging from system issues (including requirements) to software component issues (such as high level design, detailed design and testing). Currently, RE is covered in a cursory way at the undergraduate and graduate level software systems engineering courses and is given a little more attention in a formal software engineering course. Some workshop participants argued that such a "top-down" approach doesn't work well with students because of their inexperience and the "intangibility" of software. Linda Macaulay (UMIST, Manchester, UK): UMIST offers two courses on requirements engineering, one undergraduate, the other graduate. The first course is taught during the final year of the undergraduate programme. Students have been already exposed to a full-year project where they do requirements, design and implementation for a particular system. During the undergraduate course, they are taught to evaluate different techniques, and address requirements engineering issues, such as the acquisition of domain expertise, communication with the clients, understanding organizational, user and business needs. The graduate course is taught jointly with Peri Loucopoulos. This course lasts for ten, one day sessions and covers the methods for requirements specification and analysis. Broadly speaking, the course follows the requirements lifecycle covering problem analysis, requirements capture, documentation of requirements, requirements specification and CASE, data and process modelling and advanced conceptual modelling languages. There are a series of group assignments in which students attempt to apply the techniques learnt to a particular case study. The same case study is used throughout the course. Ian Bray (Bournemouth University, UK): A second year course is offered where students are expected to complete a requirements specification using state machines, Petri nets and text. Pere Botella (Technical University of Catalunya, Spain): Undergraduates have to complete a software specification course, and learn how to write a consistent and complete specification but have difficulty understanding communications problems. For a professional Masters degree, on the other hand, which involves students with professional experience taught by a professional requirements engineer, student appreciation of such problems is much higher. Ian Denley (University College, London, UK): A requirements course, focusing on human-computer interfaces, is offered as part of a one-year Masters programme. Students are taught knowledge elicitation, task analysis and communication skills. Emphasis on how to analyze a domain. Bashar Nuseibeh (Imperial College, London, UK): Second year students work on small group projects involving requirements and design, where teaching assistants play the role of clients (in the problem domain) as well as (software engineering) consultants. During their third year of study, students complete a software engineering course devoted mostly to project management and requirements engineering, and then spend 6 months working in an industrial setting. Finally, in their fourth year, the students work on a large group project which, last year for example, involved porting a large program from one platform to another (from Macintosh to Unix). Among other things, this teaches reverse engineering as well as software maintenance skills. Nazim Madhavji (McGill University, Canada): They have an undergraduate SE course, feel that an RE course is more appropriate at the graduate level. =46or their undergrad course, graduate students serve as clients, and depend on the software delivered by course projects. The ten courses described above illustrate a wide variety of treatment of RE within universities. Even in this limited sample some courses emphasise the analysis of the problem domain (for example, University College, London) while others emphasize development of the software requirements specification (for example, Technical University of Catalunya, Lancaster University, and Bournemouth University). However, many of the courses stress the importance of case studies, project work and exposure to real clients (for example, Technion, UMIST, Imperial College, University of Waterloo, and McGill University). 3. An Industrial Perspective on RE Education In order to find out what industry requirements are for RE education, a short survey was undertaken of 32 companies whose representatives attended the RE'95 conference. A total of 18 responses were obtained from 17 companies. There was a diversity of industry types including telecommunications, atomic energy, defence research, electronics, banking, aerospace, nuclear fuels and software consultancies. The companies were from the USA, Canada, Finland,the UK, Italy, Sweden and Belgium. The respondents were all involved in the requirements within their own company. A questionnaire was sent by email and by surface mail. Recipients were asked to imagine they were interviewing someone for a job which involves a significant portion of requirements engineering and to answer the following eight questions: 1. Can you give a brief job description and job title? 2. What personal qualities would you expect that person to have? 3. What degree title(s) would that person normally have? 4. What methods, tools or techniques would you expect that person to be familiar with? 5. Would you expect the person to possess specific domain knowledge? 6. If that person was a new graduate, what additional training would you expect that they will require? 7. How long would you expect a new graduate to take before becoming effective in the job? 8. Do you have any advice on what should be taught in a RE course? A summary of their responses in given below: Question 1a: `If you were recruiting someone to do requirements engineering what job title would you use?' Software Engineer, Researcher, Requirements Engineer, Requirements Analyst, Systems Analyst, Systems Engineer, Systems Engineer for Business, Requirements Modeller, Assessor of Safety Control & Protection Systems, System Designer, Requirements Engineering Process Manager. Question 1b:'What job description would you provide?' '...Experience of Requirements...' '...Ability to undertake feasibility studies, functional studies, interviews, meetings, preparation of draft documents, network management modelling; Anything from understanding business needs to writing detailed system specs, for example, requirements elicitation, workshop facilitation, business modelling (process, data or object oriented), prototyping...' '...To manage requirements traceability throughout the project lifecycle providing impact assessment of changes and reporting on deficiencies in requirements coverage through the design and test phase...' '...Meeting the needs of the projects you work on, achieving customer satisfaction, seeking ways to improve processes, taking responsibility for your own development...' '...Close interaction with stakeholders including the use of scenarios, a range of modelling techniques selected to suit the particular problem: the problems/goals it is addressing, the nature of the people involved and the constraints and opportunities arising from the environment in which the project is conducted and managed...' Question 2:'What personal qualities would you expect that person have?' Make himself or herself understood, listen, stay calm and assured under fire, quickly assimilate information, talent for sorting and analysing information, write clear, well structured documents, make presentations, chair meetings, run a group; Also patience, perseverance, be able to live comfortably in a constant state of ambiguity, both independence and team working skills, negotiation skills, flexibility, open-mindedness, sense of humour; Good interpersonal skills, analytical, logical and open-minded. Question 3: 'What methods, tools or techniques would you expect that person to be familiar with? CASE tools, process modelling, object-oriented modelling, interviewing, workshopping, viewpoint analysis, prototyping, information analysis, requirements traceability tools, appreciation of configuration management with respect to requirements, formal specification languages, structured systems analysis, HCI issues. Several respondents mentioned the need for knowledge of a range of techniques and the `pros and cons' of their use. Question 4: 'What degree title would that person normally have?' About half listed B.Sc., MSc or PhD in a computing subject or numerate subject. Others listed business-related studies or psychology. Question 5: 'Would you expect the person to possess specific domain knowledg= e?' About half the respondents said 'yes', the other half thought it was desirable but not essential. Question 6: 'If that person was a new graduate what additional training would you expect to give them?' Training in interpersonal communication skills; Work experience in product development; Shadow experience analysts; Get them involved in difficult projects; Courses in concurrent engineering, product planning and marketing; Training in one or two techniques. A number of respondents expressed doubts as to whether this was a job for a new graduate. Question 7: 'How long would you expect a new graduate to take before becoming effective in the job?' Most respondents said '...to learn the ropes, 6 months;...to work independently 12 to 18 months; ...to become a recognised 'domain expert' 2 to 4 years...' Question 8: 'Do you have any advice on what should be taught in an RE course= ?' Rather a lot of advice was forthcoming. Below we list representative extract= s: '...The fact that requirements do not just come from interviewing a customer and that's it, requirements phase over...Where do requirements come from?...How are they discovered? Assimilation of requirements from all sources. How to develop the system in parallel with requirements discovery.. Requirements identification (i.e. the writing of atomic requirements). Structure of requirements documents. How to talk to a person who is a potential source of some requirements. How to estimate from unreliable, high level, requirements. Requirements management - agreement, no contradiction, key words, grouping, cross referencing, etc. Identification of non-functional requirements. How to handle change in requirements. How to map to designs (and analysis items?), code modules, test cases, use cases, documents, etc. How tools might help. Development of a RE process which fits into the development lifecycle...' '...Modelling of real-world problems (real-size). Formal techniques, OOA, Entity-Relationship...' '...Requirements Engineering is not an isolated front-end activity prior to product development phase but part of a large process and RE is connected by feedback loops to other (development) processes. Perhaps researchers should investigate the "interfaces" which connect the RE process to other systems development processes and try to identify what are the relevant inputs and outputs of the RE process and how to support both the interfaces and the RE-process by methods and tools. Traceability of requirements throughout the "lifecycle" is very important and should be supported by the tools of the whole development chain...' '...Motivation for the importance of requirements analysis, clarification of problems around the choice of tools and techniques. It should be made clear that the techniques are not an end in themselves, but only a means of coming to grips with the complexities we're facing. Use of case studies...' '...I think a lot has been done on the tools, methods ; my experience is that insufficient time and importance (in terms of percentage of final mark for a course) is spent on teaching people to communicate with one another, giving important presentations, and group/team working - methods such as CORE, Soft Systems, SSADM, Yourdon, IEM are useful but must be used wisely - the methods themselves don't guarantee success...' '...The needs of industry are increasingly focused on people,not technology (so experience of building original software tools or knowledge of complex computational methods is of little value). More emphasis on communication skills and teamworking, how to get the best out of people; collaborative ways of working e.g. prototyping with users; RAD (Rapid Application Development) techniques; DSDM (Dynamic Systems Development Method)...' '...Essential elements of a Requirements Engineering course: The nature of "requirements" - the reasons why they necessarily change and emerge throughout the life of a system, also the impossibility of separating them neatly from solutions. Emphasis on lifecycles that include requirements engineering activities throughout the life of the system and are highly iterative. Requirements engineering for continued development of systems ( traditionally referred to as maintenance) given at least as much importance as initial development. Management and traceability - create, develop and maintain descriptions of the system (and plans for its realisation) and justification for this approach in terms of current problems/goals and stakeholder views. Real analysis of requirements must be through the medium of evaluation of alternative solutions (or designs) at differing levels of detail. This could be possible through the construction of various kinds of models (executable/static, abstract/concrete, formal/informal, illustrating different aspects of the problem or solution space). A variety of systems modelling techniques, with particular emphasis on how the models are validated and used to elicit further requirements. The creation of use scenaria for requirements generation and validation. The creation and use of (possibly re-usable) domain models..." "...How conflicts are identified and resolved - trade-offs, including cost constraints, risk management, evaluation of options...' 4. Discussion This section attempts to draw some general requirements for RE education, based on the material presented in previous sections. These requirements can be classified along three dimensions: (i) in terms of what industry feels universities should be teaching; (ii) in terms of the skills that students need to develop to be effective in requirements engineering activities; (iii) in terms of the concepts, techniques and tools that students need to acquire so that they can be said to be knowledgeable in Requirements Engineering. In general, industry's expectations focus largely on giving students a broad perspective -- rather than a narrow, technical and isolated one -- on requirements. This expectation can be met through recurring themes that complement and integrate day-to-day teaching in a RE course. A list of such themes might include: Non-Isolationism. Requirements engineering is not an isolated front-end activity to a software lifecycle process; rather, it is an integral part of the larger process connected to other parts through continuous feedback loops. Evolution. The nature of requirements is such that change will necessarily occur; accordingly, requirements specifications and subsequent software lifecycles should be designed with change in mind. Multiple sources. There are many sources of requirements which need to be explored and their input assimilated; there is no such thing as an all-inclusive source. Traceability. There will be a continuous need to justify requirements and relate them to their sources; also to relate design and implementation decisions to the requirements they originate from. Conflicts. There will always be conflicts in requirements which will need to be accommodated and trade-offs that address these conflicts will need to be justified Desirable skills to be taught in a RE course include: * Interviewing skills to facilitate the acquisition of information * Groupwork skills, including participating in meetings and the ability to work in a collaborative way * Facilitation skills, such as the ability to lead a group * Negotiation skills to support consensus building * Analytical skills to support the analysis of an organizational situation prior to any proposals for solutions * Problem solving skills to support the search for alternative solutions. * Presentation skills, including the ability to write coherent documents using word processors and other presentation tools * Modelling skills including business, process, data and object modelling, using a variety of notations. Finally, the fundamental and practical knowledge required for the requirements engineer includes: * Knowledge of and experience in using CASE tools * Knowledge of formal languages and conceptual modelling and experience in using general modelling techniques, including formal languages and conceptual modelling * Knowledge of and experience in using particular modelling languages and the ability to choose the best one among them for a given problem * Knowledge of and experience with management and traceability tools * Knowledge of concepts, tools and techniques in human computer interaction * Knowledge of techniques in product planning and marketing It is clear from the above discussion that the education of a requirements engineer will require something considerably greater than a standard twenty hour lecture course. Understanding of the recurring themes of non-isolationism, evolution, multiple sources, traceability and conflicts require a certain level of knowledge and maturity which can only be gained through experience in dealing with practical problems. Given its importance as a topic within Software Engineering, we expect to see more and better courses and textbooks on RE. it remains to be seen how well these address the educational dilemma of teaching fundamentals while at the same time conveying the importance of pragmatic considerations in tackling requirements problems. References [Brackett90] Brackett, J., "Software Requirements", SEI curriculum module, SEI-CM-19-1.2, 1990; also in Dorfman, M. and Thayer, R. (eds.) Standards, Guidelines and Examples on System and Software Requirements Engineering, IEEE Computer Society Press, 1990. [Bubenko95] Bubenko, J., Keynote Address, Second IEEE International Symposium on Requirements Engineering, York UK, March 27-29, 1995. [Davis93] Davis, A., Software Requirements: Objects, Functions and States, Prentice Hall, 1993. [Finkelstein94] Finkestein, A., "A Course on Requirements Engineering", position statement, in [Jarke94]. [Flynn92] Flynn,D., Information Systems Requirements: Determination and Analysis, McGraw Hill, 1992. [Gause89] Gause, D. and Weinberg, G., Exploring Requirements, Dorset House Publishing, 1989 [Jarke94] Jarke, M. (Ed.) Proceedings of an International Workshop on System Requirements: Analysis, Management and Exploitation", Dagstuhl, Germany, October 3-7 1994. [Loucopoulos95] Loucopoulos, P. and Karakostas, V., System Requirements Engineering, McGraw Hill, 1995. [RE93] First IEEE International Symposium on Requirements Engineering, San Diego CA, January 4-6, 1993. [RE95] Second IEEE International Symposium on Requirements Engineering, York UK, March 27-29, 1995. [Sommerville92] Sommerville, I., Software Engineering, McGraw Hill, 1992 (4th edition). E------------------------------------------------------------------- FASE Volume 5 Number 22 Send newsletter articles to fase-submit@d.umn.edu or fase@d.umn.edu Send requests to add, delete, or modify a subscription to fase-request@d.umn.edu Send problem reports, returned mail, or other correspondence about this newsletter to fase-owner@d.umn.edu or kpierce@d.umn.edu You can retrieve back issues by anonymous FTP from from ricis.cl.uh.edu. You can access them through WWW at URL http://ricis.cl.uh.edu/FASE/ Keith Pierce, Editor Laurie Werth, Advisory Committee Department of Computer Science Dept. of Computer Science University of Minnesota, Duluth Taylor Hall 2.124 Duluth, MN 55812-2496 University of Texas at Austin Telephone: (218) 726-7194 Austin, Texas 78712 Fax: (218) 726-6360 Telephone: (512) 471-9535 Email: kpierce@d.umn.edu Fax: (512)471-8885 Email: lwerth@cs.utexas.edu David Eichmann, FASE Archivist Asst. Prof. / RBSE Director of R & D Web: http://ricis.cl.uh.edu/eichmann/ Software Engineering Program Phone: (713) 283-3875 University of Houston - Clear Lake fax: (713) 283-3810 Box 113, 2700 Bay Area Blvd. Email: eichmann@rbse.jsc.nasa.gov Houston, TX 77058 or: eichmann@cl.uh.edu RBSE on the Web: http://rbse.jsc.nasa.gov/eichmann/rbse.html