Doing the Requirements Work
Andrew P. Black
Oregon Graduate Institute of Science & Technology
The four graduate computer science departments in Oregon are working together to define and launch a Master of Software Engineering degree (M.Sw.Eng.) program. We see this as a professional program, like dentistry or law, and thus different from our existing Master of Computer Science Programs.
In trying to quantify this difference, we have stumbled across the realization that designing a Software Engineering program, or indeed any academic program, has a lot in common with designing software. One starts with the requirements, derives pre- and post-conditions, and then proceeds by stepwise refinement to break the whole program into more manageable pieces, except that we call these pieces courses rather than procedures.
Of course, this is an idealized view of program design. Reality diverges from the ideal in academic program design just as it does in computer program design. But the idealized view is very useful, because it forces us to examine our academic biases. Is our desire to include or exclude something from the program based on the requirements of the customer, or is it based on our hard-wired programming as academics?
In 1995, a self-appointed "Software Engineering Advisory Group" consisting of representatives of high-tech companies from the Portland region commissioned the computer science departments at the Oregon Graduate Institute, Oregon State University, Portland State University, and the University of Oregon to design a joint M.Sw.Eng. degree program. They were clear that this was a new degree, rather than a software engineering specialization in our existing Master of Computer Science degree programs, and they were clear that it was joint--either because they did not want to have to choose between competing programs, or because they wanted us to combine resources to build excellence. Beyond this, the departments were effectively left to make a proposal.
Our response was developed over a period of about a year, and describes a program that is innovative in structure but conventional in content. Because we expected enrollments from a significant number of part-time students, we divided the content into modules of about one credit each, and planned to eventually make our courses available to the whole state using distance learning technology. However, the content was based on the CMU SEI program: it was largely Software Engineering Technology. We included a 12 credit studio that was intended to give participants something close to an experience of real software development. We also included "Personal Competencies" in the curriculum, meaning things like working as a team, leadership, communication and presentation skills, but not without considerable discussion (and not very much agreement) among ourselves. Should we teach this material, or should we just require it? Should we give credit for it? How do we distinguish between university graduate level for credit courses in, say, leadership, and "executive education" courses offered by a commercial seminar company in a local hotel ballroom?
In parallel with this internal discussion, we started working with the Oregon Survey Research Laboratory at the University of Oregon to understand how to survey our market and to ensure that the program that we are designing meets the needs of the software industry that commissioned it. In addition to written surveys, they recommended the use of focus groups of different constituencies; the first focus group met in February.
Focus groups are not representative, and therefore what one learns from them must be tempered by the composition of the group. This particular group all worked for technology "push" companies; computer companies and companies whose products contained software as major components. They all volunteered to attend the session, so we should expect them to be interested in our goals. They all had management experience, although some were now in senior technical rather than management rôles.
Without more preliminaries, I would like to summarize what the members of this focus group told the survey team. (Note that M Sw. Eng. Council members were deliberately not present). First they were enthusiastic about the idea of a new program, largely because existing BS and MS programs in Computer Science are not giving them what they want. No one was clear what software engineering really was, although there was general approval of the notion that as Physics is to Electrical Engineering, so is Computer Science to Software Engineering.
The enthusiasm for the new program is based on the feeling that existing educational programs are not supplying what industry needs. "This is an opportunity to correct some of these things that we don't cover in a Bachelor's program. If its more of the same though, I'ld say: why bother?" Rather than looking for people who understand theoretical concepts, they want employees understand how a project works, how the product goes together, what a product life-cycle looks like, and how one would actually deliver software on time. They want graduates to understand that software is not something that is used once and then thrown away, but an artifact that lasts for 20 years and must be maintained over that time.
Building a product is a process that involves many technologies; one of the technologies is computer science, but employees must be familiar with them all. They must know how to take a product from start to finish, not just in one discipline, but in everything that it touches. What exactly does this mean? Attributes that were identified included "high quality", team players, desire, stamina, business principles and processes, time management, the ability to deal with constantly changing technologies, decision and thought processes, vendor management, contract law and negotiation, and understanding of ISO processes. Communication skills are fundamental, and in the broadest sense: English, html, writing specifications and project plans, talking to a group, and designing a set of slides for a presentation were all mentioned. Finally, they included a "certain core of software Engineering".
Several of the participants noted that this skill set was very much like the post-condition for an MBA: the technical side was consistently de-emphasized and the management, personal, communication and organizational and structural side of the industry was called out. Some went so far as to agree that an MBA for the software industry was what they were looking for.
For those of us who thought that Software engineering was primarily a technical discipline, involving requirements analysis and design, reading and writing specifications about which one can prove theorems, testing and coverage and measurement, and so forth, these findings are something of a surprise. Even those of us who took a process-oriented view of Software Engineering might be surprised at the degree of disregard that the participants held for the "technical stuff". One of the participants guessed at the reason for this:
[Why is] the feedback ... so oriented towards something that sounds like a mini MBA? It's because that's the part that doesn't happen very automatically for very many people. It took me 10 years to even start to get a glimmer of the way people who were running the business I happened to be working for at the moment thought about the world at all. It's still a really really alien thing for me.
The technical stuff, on the other hand, comes easily to the people in our focus group, because they are all technical people themselves. One participant said:
I don't care if they know software. I can teach them that. I can teach them to program, but I can't teach them how to do project management.This is not because it is impossible to teach project management; rather, this particular engineer does not feel equipped to do it. He wants new employees to have the skills that he lacks, or aquired painfully by trial and error, and tends to undervalue the skills that he has, which are the technical skills.
My conclusion is that while it is essential to include many of the skills that are taught in an MBA program, an M.Sw.Eng. degree is not just a technical MBA. It does include the technical stuff too. I'm tempted to add: if the industry doesn't believe that they need the technical stuff, then that is an excellent reason to teach it! As academics it is our duty and obligation to look ahead beyond the next product release, and to imagine how software will be constructed 20 years from now.
Nevertheless, the emphasis on the "soft stuff" cannot and must not be ignored. If we advocate structured walkthroughs as a way of advancing code quality, we have to teach our students the technical side: how to relate code to specifications, what to look for when examining a loop, what variants and invariants are, and how they can help. But we also have to teach them how to convince their colleagues that the whole process is worthwhile, and how they can spend hours dissecting each others' code and emerge at the end not just on speaking terms but as a stronger team than when they started.
The design of the M.Sw.Eng. degree is a statewide effort involving many people, and the focus group on which this position paper is based is an effort of that whole group. However, the conclusions that I draw from this data are my own, and may differ from those of the M.Sw.Eng. Council.
I would particularly like to acknowledge the work of Stuart Faulk and John Conery of the University of Oregon and Lois Delcambre of the Oregon Graduate Institute. Bruce Schafer has chaired the Council with alacrity. Stephen Johnson of the Oregon Survey Research Laboratory at the University of Oregon worked with them to design and initiate the surveys of which the focus group reported here is a part. More focus group meetings and other market research will be undertaken in the future.