In his seminal work, "The Two Cultures", C.P. Snow found that science and technology policy-making was extremely difficult because it required the combined expertise of both scientists and politicians, whose two cultures had little understanding of each other's principles and practices.

During the last three years, we have conducted over 50 real-client requirements negotiations for digital library applications projects.  Those largely involve professional librarians as clients and 5-6 person teams of computer science MS-degree students as developers.  We have found that their two-cultures problem is one of the most difficult challenges to overcome in determining a feasible and mutually satisfactory set of requirements for these applications.

During the last year, we have been experimenting with expectations management and domain-specific lists of "simplifiers and complicators" as a way to address the two-cultures problem for software requirements within the overall digital library domain. This talk provides overall motivation and context for addressing the two-cultures problem and expectations management as significant opportunity areas in requirements engineering.  It discusses the digital library domain and our stakeholder Win-Win and Model-Based (System) Architecting and Software Engineering (MBASE) approach as applied to digital library projects.  It discusses our need for better expectations management in determining the requirements for the digital library projects and products over the first two years, and describes our approach in year 3 to address the two-cultures problem via expectations management.  This talk concludes by summarizing results to date, which were largely successful, and future prospects.

Barry W. Boehm, TRW Professor of Software Engineering and Director, Center for Software Engineering, University of Southern California.

C. P. Snow's book "The Two Cultures," published shortly after World War II, compared the cultures of technologically oriented and politically oriented people.  There was a gulf in the perceptions and understandings of these groups that can be compared today to the cultural divisions between software professionals and users.  Some psychological tests have indicated that software professionals tend to be introverted, intuitive, thinking, and judgmental.  Software users are more extroverted, sensing, feeling and perceiving. Professionals are oriented toward software knowledge while users are application oriented.  Neither culture has a good feel for what is easy or hard for the other culture to do. 

The differences between the groups lead to misunderstandings between them.  This was demonstrated during a digital library project at USC when students carried out a series of computer science course projects for the university's librarians.  There was a good background for a Win-Win situation between these groups, because the librarians wanted the library to be digitized but had no budget, and the students needed experience on a large, complex software project.  Some of the difficulties resulted from failures of the two groups to understand what was easy and what was hard for the other group.  Librarians did not understand the difficulty of accomplishing natural language queries and digitizing pictures.  The software developers were not properly concerned with the need to control access to protect property rights and to prevent access by users who had not agreed to the usage requirements of the library.

Over the years of the project it was noted that users were more satisfied for the same level of system performance if their expectations at the beginning had been low than if they had been unreasonably high.   The project team used the Model Based (MBASE) conceptual framework and used the WinWin Spiral Model for development. WinWin was an extension of the Spiral Model that was concerned with software development.  The WinWin extensions identified stakeholders (Librarians and Developers) and each group's "win" conditions.  The librarians wanted productive software that would be developed without bringing down their operational computer systems.  The student developers wanted good grades and were operating under the constraint that their project had to be completed within a semester.  During one of the years the first semester teams were made up of 86 graduate students, 30% of whom had industry experience.  They were largely unfamiliar with each other and with library operations.  A subset of the original applications was selected for upgrades for the second semester that included reformed teams from 30 continuing students.  The first semester was a required course for the students, but the second semester depended on the curriculum path that had been selected by the student.  

There were 15 digital library applications selected -- each with two-sentence problem statements.  The teams were required to develop Initial Operating Capability (IOC) packages in 12 or more weeks including a 1-week beta test.  Life Cycle Objective (LCO) conditions were to describe at least one feasible architecture, satisfy requirements within cost/schedule/resource constraints, provide a viable cost-effective business case, and get stakeholder concurrence on key system parameters.  During 1996 four of 16 projects failed LCO criteria and during 1997 four of 15 projects failed to meet the criteria.  There were investigations as to why these projects failed.  In 1996 a large photographic archive project focused on automating operations, but seriously underestimated the amount of effort required to digitize the photos.  A student film archive project focused on cataloguing and query questions from a set of natural language queries.  Another project to convert legal periodical records into a new set of common formats underestimated the difficulty of creating a general set of record translators across a wide variety of periodical characteristics.

A review of the 1996 and 1997 results led to an experiment in 1998 to "pre-position" expectations by providing a list of simplifiers and complicators (S&C's) to library clients.  The librarians supplied their own list of S&C's that were provided to the student teams.  An example is an Asian film database product where generic complicators were natural language processing, digitizing large archives, and integration of "Legacy" systems.  Generic simplifiers were uniform media formats, standard query languages, and use of standard Commercial Off-The-Shelf (COTS) software.  All of these have specific risks and trade-offs, and in many cases simple solutions for the developers would lead to unusable results for the librarians.  Careful review of these problem areas at the beginning of 1998 resulted in only one project failing its LCO criteria.  The failure was a natural language project where the expectations review group did not recognize how difficult the implementation would be. 

It was concluded that managing the expectations is a critical technique in requirements engineering.  This creates more wins and fewer losses in the perceived value of completed projects.  The problem is that software developers and users don't really understand what is easy and what is hard for the other to do.  The Simplifier and Complicator definition approach reduced expectations and also management and requirements problems, resulting in fewer problem projects and better understanding between the developer and user cultures. 

You may contact Professor Boehm by e-mail at  boehm@sunset.usc.edu and obtain more information at the URL http://sunset.usc.edu.

This was the seventh meeting of the year, and was attended by 22 people. 
Mike Walsh, LA ACM Secretary