A Hole in the Curriculum Brian Berenbach Siemens Corporate Research, Inc.
[email protected] Abstract An engineering or science education at the university/college level should be sufficient for the new graduate to successfully integrate into the workplace. Unfortunately, the requirements engineering subject area is not part of the core curriculum at most universities and colleges. When technical staff does not have an elementary understanding of requirements elicitation skills it affects their job performance, costs their companies money, negatively impacts the entire economy, and in some cases leads to fatalities. This paper provides an industrial perspective on what college students should be learning about requirements engineering at the undergraduate and graduate level, and why they should be learning it.
1. Introduction I recently gave a paper on requirements engineering at OOPSLA 2004 [1]. After I spoke I had the opportunity to converse with a corporate officer in a large insurance company. He lamented his inability to hire staff that had any skills in requirements engineering. Some time later I went to a panel discussion on outsourcing. There was much moaning and groaning about reduced opportunities in software engineering, but the topic of requirements engineering never came up. I was somewhat surprised, as that is one of the few work areas that is nearly impossible to outsource. Later, I went back and did a keyword search on “requirements” in the conference papers and was surprised to find only two relevant hits, one of which was my presentation. OOPSLA is a very large conference with multiple tracks and lots of papers so I was taken aback by the lack of interest in the requirements engineering aspect of software engineering. On reflection, I came to understand that there was a relationship between the poor job many companies do in defining product requirements and the lack of recognition of requirements engineering as an important part of the software life-cycle. Other professionals had suggested augmented college curriculum to include requirements engineering as a core subject as early as
1991 [2]. My observations (from an industrial perspective) and my conclusions are the gist of this paper.
2. Requirements Engineering at Siemens As a member of the technical staff at Siemens Corporate Research I have had the opportunity to participate in the definition of requirements for new products in many diverse areas, including, for example, baggage handling, embedded automotive, mail sorting, medical (both financial and clinical), plant control, inventory forecasting, etc. In some cases, the organizations I worked with were either at or endeavoring to achieve a better CMMI rating [3]. Interestingly, not all the systems were pure software. Many were electro-mechanical with some embedded software components. Consequently our RE staff worked with electrical, mechanical and chemical engineers as well as with other Siemens software professionals. The educational background of the staff that we worked with was quite diverse. Even so, team members that had any academic exposure to requirements elicitation and management were extremely rare. In some cases they had received some cursory introduction to requirements analysis material taught in courses such as systems analysis. I conducted an informal poll of my department (software engineering) asking the staff a) whether they had received any training in requirements elicitation at the undergraduate or graduate level, and b) whether they had to elicit product requirements on the job either before or during their tenure with Siemens. The results are summarized in table 1. Table 1 Academic Training vs. Industrial Need
Did requirements analysis on the job No requirements work
No academic training in RE 15
Some Academic Training in RE 8
7
0
You can see that only about 35 percent of the staff that needed training in requirements engineering received all or part of it at the academic level, the remainder had to receive in-house training, which, of course, meant less rigorous training (e.g. 3 days vs. 16 weeks). Another unexpected finding was that of the 30 respondents over three quarters had to do requirements definition at one time or another. One of the participants in the survey commented that it would be skewed as younger employees would have had that training. In fact, it turned out not to be the case. What was most likely to determine whether the staff member had some training was their degree level, with PhD graduates more likely to have had some formal training in RE, usually as part of a systems analysis course sequence. Contrast that, for example, with the core CS course compiler theory (offered by every accredited school offering a CS degree), where very few of the respondents reported ever having had a need to use the material taught. Please do not misunderstand, I have taught compiler theory at the graduate level and believe it is an important part of the curricula, but in terms of job need after graduation, it seems to rank very low compared with requirements elicitation skills. Many of the Siemens companies are using the CMMI as a yardstick to obtain excellence in quality, frequently conducting internal assessments. This increases the learning curve for being effective; not only do employees need training in requirements engineering, but they need to get that training in the context of a CMMI compliant environment. In some cases additional training is also necessary to perform a hazards analysis.
3. Software Community View For many institutions of higher learning with a computer science, engineering and/or software engineering program, requirements engineering does not seem to be a high visibility topic, e.g. you can’t find a course on it in the academic course catalog, for a variety of reasons: ¾
¾ ¾
It is difficult to define research topics in requirements engineering that are quantitative in nature (e.g. would make a good thesis ) It is difficult to define the syllabus for a full semester course on the subject (see 7.4 ) Requirements engineering is not “glamorous”. Most of the candidates who reply to our advertisements are looking for positions where they can be developers or architects. They want to create by writing code or designing software systems.
Sit down and shut up!
Figure 1 Facilitating Analysis Sessions ¾
¾ ¾
There is a pervasive (and, in my opinion, perverse) view in the software community that all you need to write good requirements is a knowledge of the domain. Requirements engineering jobs are sometimes viewed as “dead end” positions. Software professionals tend to view process work and documentation as “boring”.
4. Requirements Engineering as a Profession Product requirements definition, while not glamorous, is a vital part of the software engineering lifecycle. If you compare the task of the software architect with that of the requirements engineering manager, the relative importance of the roles becomes immediately apparent; a mediocre architect can get by with a good set of requirements, but a superstar architect will fail with incorrect requirements. That is, if the requirements are wrong, the product will fail in the market place (if it ever gets built). This may seem obvious to someone IN the field, but it is definitely not apparent to most people OUTSIDE the field, and people outside of the requirements engineering field are the ones making the resource and staffing decisions. Requirements staff must interface with clients, sales, marketing, corporate administration, architects, and quality assurance. The high visibility of senior requirements engineers provides networking opportunities not often available to software professionals with other specialties (e.g. development, testing).
5. Faculty Background Significant efforts have been made to look at the relationship between current curriculum and industry
needs. There appears to be anecdotal evidence that requirements elicitation is primarily the province of experienced staff, e.g. “…almost exclusively more senior people do requirements activities…” [6]. A possible rationale for this statement is suggested in section 6 below. One of the comments that I heard when interviewing staff for my mini-survey at SCR was that university faculty tended not to have the experience or the skills necessary to teach those aspects of requirements engineering that involved human interaction (e.g. facilitation, interviewing), and, consequently, shied away from the specialty. Computer science and engineering faculty generally start teaching right out of graduate school. But only after some significant postgraduate industrial experience can key requirements engineering skills be learned. This lack of experience by college faculty may hinder efforts to develop a well rounded curriculum in requirements engineering.
6. Important Skills We have found at Siemens that the best qualified professionals to participate in the requirements definition phase of a project are those that have or are capable of learning certain skills, including leadership, communication skills and attention to detail. Of course, it is simply not practical for a computer science curriculum to cover all of them, especially at the undergraduate level, and some cannot be learned in an academic setting. Other researchers have reported that some of the most important skills listed below tend not to be taught at the undergraduate level [7].
Requirements databases can be difficult to structure and manage. There may be several related databases (e.g. a database containing corporate security requirements). It can be difficult to visualize the relationship between databases, the hierarchy of a single database, and to trace relationships, both intrinsic and explicit. Introduction to the basic concepts of requirements databases (e.g. hierarchical, tracing, requirements attributes, etc.) at the undergraduate level provides a grounding in requirements technology that can then be reinforced later.
6.3. Requirements Elicitation Requirements elicitation is sometimes taught as part of a systems analysis course, but infrequently as a standalone subject. Unfortunately, the skills required to do elicitation well primarily involve communication, attention to detail, psychology, and, in some cases, courage. Elicitation and facilitation are closely related.
6.4. Knowledge of Process Standards The relationship between operative process standards (e.g. Six Sigma, ISO, and CMMI) and ongoing projects must be known to define correct and complete requirements. Unfortunately, most students receiving a CS degree have little or no exposure to industrial process standards and guidelines. But sir, that requirement will lock the product and make it unusable.
Do it anyway, it is too expensive to fix!
6.1. Facilitate Meetings The facilitation of any type of business meeting can be difficult. Meetings whose purpose is requirements elicitation can be especially difficult to manage because of the varied background of the attendees, ranging from speech making corporate officers to “bit manipulators”. Keeping the meeting focused, limiting speech making and insuring a cordial atmosphere can be difficult. It is very difficult for a new college graduate facilitating a requirements elicitation session to tell a senior staffer bent on making a speech to “sit down and shut up”, even if done tactfully (Figure 1). Training helps.
6.2. Database Organization
Figure 2 Ethics in Requirements Engineering
6.5. Understanding of The Software Lifecycle One of the reasons why more experienced professionals participate in requirements engineering efforts is that they can visualize how the requirements will be used by architects, designers and testers. This knowledge is invaluable when it comes to interacting with project teams as well as formulating good requirements.
6.6. Communicate Well With Management Recent technical graduates may not do a good job of communicating with non-technical staff or customers. In order to be able to make presentations to management, many of the things learned in university need to be unlearned. Foremost among the bad habits is the use of jargon and the tendency to promote a technology rather than solving a business problem. In school, the objective of a presentation is to tout the knowledge level of the presenter; in the workplace the objective is the sale of ideas.
being overwhelmed is the norm rather than the exception. Requirements engineering students really need to learn how to manage scale before they are placed in a difficult situation.
6.10. Multiple Methodologies There are different approaches to eliciting and recording requirements [1] and students should be introduced to a variety of analysis techniques. As in many other software process areas, “one size does not fit all”.
6.7. Effectively Use Tools
7. Addressing the gap in the curriculum
The hyping of tools has led to “tool wars”, with different camps espousing the virtues of the tools with which they are familiar. Tools are just that, an aid to performing a function. Sometimes professionals tend to lose sight of the goal. In the domain of requirements engineering, database and CASE tools are most often used, along with configuration management tools for version control. It is important for students to understand the purpose of each tool without becoming enamored of it, e.g. becoming a tool fanatic or “guru”.
Universities experiment with different approaches to address some of the issues that have been discussed in this paper. I have picked several examples, primarily because I am familiar with their programs. This is in no way to infer that their programs are in any way better than those of any other school of higher learning. Rowan University has focused on communication through engineering projects at the undergraduate level; Carnegie Mellon has created a graduate program for professionals with prior experience; The Technische Universität München has a master’s level specialization in requirements engineering, and DePaul offers a traditional graduate course in requirements engineering.
6.8. Understands Legal and Ethical Issues It is possible to complete a PhD in science or engineering without having had a single course in ethics. To understand why this is not good, we only have to read today’s headlines. There is a perception that students will never become enmeshed in legal or ethical issues after graduation (e.g. what can be ethical about a “do loop”?). Of course this is not the case at all. I found myself in the dilemma pictured in Figure 2 not long after I became a software development manager. In my situation, I refused to follow the project manager’s directive.
6.9. Manage Scale The projects that we see typically have about two to four thousand approved requirements. When use case models are created to elicit requirements, we typically see between one hundred and a thousand use cases. I participated in one project that had a raw count of over sixteen thousand requirements. Formal requirements engineering training, whether as part of an academic program or provided by vendors, is done using “toy” or very simple student projects in order to keep the material manageable and not overwhelm the students. Unfortunately, on real projects,
7.1. Carnegie Mellon Engineering Program
Master
of
Software
Carnegie Mellon University has a master of software engineering program where prior industrial experience is a prerequisite [14]. Students enrolling should have 25 years of experience beyond the baccalaureate. As the program is four semesters full time, students are typically funded by sponsor companies. Students are exposed to different aspects of requirements engineering in several core courses, including formal methods, software architecture, analysis of software artifacts, software project management and models of software engineering. However, the core of the program is the four semester software studio program where industry sponsors provide real-world problems for the students to work on.
7.2. Rowan University Engineering Program The Rowan engineering curriculum was created “ground up” with the purpose of providing graduates ready for the work force (e.g. focus on communication
and leadership skills). The Rowan web site describes the engineering curriculum as follows: “…The focus is on technical excellence, communication skills, and a wellrounded general education. Mathematics, science, and computer science courses are contextually linked to engineering applications. A signature component of the program, the Engineering Clinics, threads the 4 year program of study. The Clinic sequence accentuates a hands-on, team-oriented approach to a highly multidisciplinary education. The importance placed on technical and communication skills make Rowan engineers a valuable asset for the region and the profession.” [4]. The approach that Rowan has taken in their engineering program has been driven by the desire of the university’s benefactor, Henry Rowan, to provide industry with engineers and scientists that have the skills necessary to succeed [8] . Students working in teams get experience in communicating with each other and with management (the instructor and project sponsors act as surrogates for management). Moreover this experience is extended over the full four year course of study.
7.3. Technische Universität München Program The Technical University of Munich (TUM) is one of the few universities that has a formal program in requirements engineering (chaired by Professor Manfred Broy) [9]. Prof. Broy’s students have created research tools in requirements engineering such as AutoFocus and AutoRaid [10] that are tested in industrial settings. TUM (Infomatik) encourages its students to participate in a monitored internship in industry. These internships are unusual in that they are typically for 6-8 months, which give the students enough time to become involved with real projects.
7.4. DePaul University Graduate Course The approach at DePaul University is to focus on training graduate students that have already had a foundation in software/process modeling. A one semester course is offered that provides practical experience in requirements elicitation, specification, management, and tool use [12]. In addition to the technical aspects of requirements engineering, financial aspects are also taught [13]. Professor Jane Huang [5] reported to me in a conversation that a quarter rather than semester structure makes it easier to split out and teach material separately that might not justify a full semester course.
8. Recommendations My recommendations are geared solely to the requirements engineering curriculum; however, some of them may be broadly applicable. Introduce one or more mandatory courses in industrial psychology at the undergraduate level. The psychology department at Humboldt State University, for example, recommends a series of four courses to improve communication and workplace skills [11]. These courses address issues of facilitation, elicitation, and human factors. An engineering curriculum may already be compressed. It might be possible to work with industrial psychologists to compress the necessary material into a single course that is given before or concurrent with student workshops. Introduce a mandatory course in ethics. Ethics can be universally applied, and a course in ethics at the undergraduate level may save fortunes and lives later. I would be very interested in knowing whether the highly educated architects of some recent financial catastrophes (e.g. WorldCom, HealthSouth, Enron, etc.) had taken any courses in ethics as students. Stress the importance of Requirements Engineering by creating formal courses (as opposed to teaching requirements gathering as part of a systems analysis course) and by structuring prerequisites. For example, students taking courses in compiler theory, databases, networks, etc. have projects where they have to build prototypes or small demonstration products. If they had previously taken one or more courses in requirements engineering, they would have a better grasp on how to define the requirements for their projects. This in turn, would give them some limited experience with requirements elicitation and communication with non-technical staff prior to having to define requirements for real industrial products. In a university with a business school it might be possible to extend the workshops to include a business component, e.g. creating strategic business plans, conducting group focus sessions, budgeting and estimating and defining product features. Identify Requirements engineering as a legitimate component of software engineering. Many computer science and software engineering programs teach the software lifecycle without identifying requirements engineering as a unique topic. This in turn, misleads the students into thinking that anyone can gather requirements, and it really is not a field of specialization (unlike being an “Architect” or “Web Designer”, which are really and truly career fields). It is not uncommon to
see subject matter expert (or developers) with limited training being relied on to write product requirements.
[7] Lethbridge, T. C. (2000). “What knowledge is important to software professional?” IEEE Computer, 33(5), 44-50.
Encourage guest lecturers in Requirements Engineering. It is important to place the field of requirements engineering in context. Visiting lecturers can describe real world experiences, and give students a feel for what skills will be important if they find themselves drafted to define product requirements.
[8] M. Dailey, “Henry Rowan: The Real Value of a Man”, Rowan Magazine, 2(2), Spring 1997 pp. 10-16.
9. Conclusions Students may receive degrees in computer science or engineering without any formal training in requirements elicitation or management. When analysis is deemphasized in course work, new graduates may enter the work force with misunderstandings that can percolate up through management (e.g. subject matter experts can do the requirements). Students, especially at the undergraduate level, may not receive training in team dynamics and communication leaving them poorly equipped to facilitate elicitation sessions and lead teams of analysts. Requirements Engineering should to be upgraded to join architecture and design as a formal process area in the software lifecycle, and needs to be taught as such. Coupled with material on industrial psychology, ethics, and with rigorous team projects, students will come into the work force much better prepared to deal with workplace dynamics and product definition.
10. References [1] B. Berenbach, “Comparison Of UML And Text Based Requirements Engineering”, Companion Proceedings of the; 19th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2004. Vancouver, Canada; p 247-252. [2] M. Shaw and J. Tomayko, “Models for Undergraduate Project Courses in Software Engineering”, CMU/SEI-91-TR10 August 1997, p 43. [3] http://www.sei.cmu.edu/cmmi/ [4] http://www.rowan.edu/open/colleges/engineering/about/ [5] http://facweb.cti.depaul.edu/jhuang/ [6] O. Minor and J. Amarego, “Requirements Engineering: a Close Look at Industry Needs and Model Curriculum”, Proceedings of the AWRE’04 9th Australian Workshop on Requirements Engineering, Adelaide, Australia
[9] http://www.tu-muenchen.de/jshpchooser_en.tupl [10] http://www4.in.tum.de/lehre/praktika/autoraid/index.shtm l [11] http://sorrel.humboldt.edu/~campbell/ioinfo.htm [12] http://facweb.cs.depaul.edu/jhuang/se482/ [13] M. Denne and J. Cleland-Huang, Software by Numbers. Santa Clara:Sun Microsystems Press, 2004. [14] http://www.mse.cs.cmu.edu/
