BISE – PROFILE

Interview with Fred Brooks on “Building EffectiveLarge-Scale Requirements”The Design Science perspective remains by no means undisputed. One of its mostoutspoken critics is Turing Award Winner Fred Brooks, manager of one of the largest earlysoftware projects in the 1960’s and author of some of the most influential early softwareengineering studies, including his classic book “The Mythical Man Month”. Frederick PhillipsBrooks, Jr. is a software engineer and computer scientist. He received the A.B. in Physicsfrom Duke University in 1953, and the Ph.D. in Computer Science from Harvard Universityin 1956. Working with the IBM Corporation from 1956 to 1965, he was an architect of theStretch and Harvest computers and then was Project Manager for the development of IBM’sSystem/360 family of computers and OS/360 software. In 1964, Brooks founded theDepartment of Computer Science at the University of North Carolina at Chapel Hill andchaired it for 20 years. Currently, he is Kenan Professor of Computer Science.

DOI 10.1007/s12599-010-0104-x

Prof. Frederick P. Brooks, Jr., Ph.D.

Interview by

Sean HansenThe Weatherhead Schoolof ManagementCase Western Reserve University10900 Euclid AvenueCleveland 44106, OHUSA

Prof. Kalle Lyytinen Ph.D.Iris S. Wolstein ChairThe Weatherhead Schoolof ManagementCase Western Reserve University10900 Euclid AvenueCleveland 44106, OHUSAkjl13@case.edu

Prof. Dr. Matthias Jarke (�)Lehrstuhl für Informatik 5RWTH Aachen UniversityAhornstr. 5552056 AachenGermanyjarke@dbis.rwth-aachen.de

Published online: 2010-05-05

This article is also available in Ger-man in print and via http://www.wirtschaftsinformatik.de: Hansen S,Lyytinen K, Jarke M (2010) Inter-view mit Fred Brooks zum Thema„Erhebung effektiver Anforderungenim großen Zusammenhang“. WIRT-SCHAFTSINFORMATIK. doi: 10.1007/s11576-010-0226-2.

© Gabler Verlag 2010

Lyytinen: One of the reasons wewanted to converse with you in this spe-cial issue on requirement engineering(RE) is that much of the RE literaturemakes an assumption that fixed require-ments are absolutely vital for design suc-cess. We know that you are critical ofsome of the assumptions underlying thismodel. So why do you think that it is aproblematic model?

Brooks: In my experience, two thingshappen. One is that requirements changeduring the process of building any com-plicated system, because the outsideworld changes. Secondly, one discoversrequirements that one did not know ex-isted even at the beginning of a project.I often quote from a study report doneby an Air Force Science Board Committeeon requirements. They say that the no-tion that you need to have your require-ments done before you do Milestone A iswrong. What you really want to do is toset your overall goals by Milestone A andthen develop the requirements by Mile-

Business & Information Systems Engineering 3|2010 191

BISE – PROFILE

stone B, as you do the design. The prob-lem comes not so much from attemptingto get requirements as from the notionthat you can develop a complete and bind-ing list of requirements.

In the classical Waterfall Model, thereis only one level of feedback from eachnext level down. Thus if you follow thatprocess – and I have been through it sev-eral times – you come out with a listof requirements that nobody knows howmuch it will cost to meet – cost in per-formance, or cost in dollars, or cost inschedule. All the stakeholders pile re-quirements on at the start. The Air ForceStudy Board report was very interestingin one respect. It pointed out that it isnow taking 15 years to develop a sub-stantial military system; 25 years ago itwas taking 5 years, and the difference isthe process. In those five-year systems,they started with some very firm goalsand very firm leaders, but not with veryfirm detailed requirements. Those wereworked out during development.

I am an advocate for Barry Boehm’sspiral model, in which you do some fea-sibility analysis, you do some design, youdo some requirements development, youiterate, and you test things on each itera-tion. You build prototypes as soon as youcan.

In the literature, unfortunately, pro-totyping is seen principally as a meansof evaluating user interface requirements,whereas in fact prototyping is importantfor evaluating function as well.

Hansen: The insight from the Air ForceStudy Board regarding the dramatic ex-tension in the timeline is quite striking.Is your perception that we have movedbackward by putting formal process inplace?

Brooks: The whole agile movementstarts with the assumption that our de-velopment processes got much too heavyand too complicated, and therefore tooslow; that we wanted to move to a modelin which one builds stuff early and testsit continually – not continuously, contin-ually – with use and user feedback. I thinkthat is exactly right. Harlan Mills pro-posed this back in 1971. Consider a real-time system where you have a cycle ofsome sort. You want to build that ba-sic backbone and “stub” out all the func-tions. Then one by one put function in,try it on a user, refine it, and then fleshout another stub. As soon as you havesomething useful to the user, really de-liver it and really start getting feedback

from the field. That is also essentiallywhat the agile movement is now saying.

Lyytinen: To what degree do you thinkthat this an outcome of the fact that, be-cause of cost reasons and many otherthings, you have very formal tenderingand contracting processes and in order todo that you have to have so-called full re-quirements specifications?

Brooks: I think that is a big part ofthe problem. Indeed, I have a chapter inmy book, The Design of Design, comingout this month that is called “Require-ments, Sin, and Contracts”. The argu-ment is that people need formal contractsto protect them from cheating each other,intentionally or unintentionally, and theformal contracts lead to stating require-ments too soon. Then, that may lead toa strategy on the part of the unscrupu-lous to low-ball on the initial formal con-tract and then make it up on the changeorders. I notice that in buildings that isnot what is done. You give the architecta rough set of goals. The architect comesback with a program, which is essentiallya statement of requirements. That is it-erated with the user. Then the architectdoes a conceptual design that is iteratedwith user, using drawings and models.One does not let the construction con-tract until the design is complete. I thinkthe mistake we make often in software en-gineering is insisting that the contract belet before there is a design. That is a seri-ous error.

Hansen: You mention that we freezethe requirements too soon. Do you thinkthere is a “right” timeline for freezing?

Brooks: No, I do not believe there is apoint at which you have a complete andfinal set of requirements. I once workedon a central payroll program for 40 states.Just because of what the 40 state leg-islatures were doing, the externally im-posed requirements were changing all thetime. If we look at many software systemsthat have various kinds of input-outputdevices, the technologies change all thetime – the world keeps changing aroundyou. It is crucial to have a process thatis flexible to change in requirements. Itmust also respond to costs and difficul-ties encountered in development.

The other factor is that for any suc-cessful system the scope of usage is go-ing to be enlarged way beyond what youexpected. Thus there will be added re-quirements as people adapt the systemto new functions. They will discover thatto adapt it really neatly it ought to havesome other capabilities. For example, as

we discovered with building a new Com-puter Science building, lo and behold itaccommodates really nicely conferencesup to 125 people without interfering withnormal activities. In any modification tothe building it has newly become a re-quirement not to undo that capability.So the process of changing requirementsgoes on not only in the entire develop-ment process but for the entire productlifetime. The concept of a fixed require-ment time is a gross approximation thatmisleads us.

Lyytinen: So, how much do you haveto pay attention to the fact that require-ments may change over time? One couldalso argue that sometimes this change isoutside of your control. There are manydrivers, which influence the level at whichyou have to pay attention?

Brooks: An experience I had with ahouse design is that we discovered a re-quirement quite later on, while runninguse cases against a set of drawings – a re-quirement that we had never thoughtabout before. We have meetings of 40people here – where do they put theircoats? We had not thought about thatone. It turned out to be a little triggeron a big decision that already had manypros and cons. That requirement causedus to flip the whole house end for end.Well, that was quite a surprise. You mightsay “You should run all possible use casesahead of time”, but you cannot do that.As one designs, one starts looking at pro-totypes – such as drawings or physicalmodels or Wizard of Oz prototypes (I amtaking “prototype” to be very abstractand general here). As you start runningmore and more detailed use cases againstthem you discover things that you needthat you did not realize you needed.

Sooner or later, if you are going to en-ter a fixed price contract, you do have tosettle on a set of specifications, but noticethat, as I say, in the building industry thatfixed set of requirements is prepared afterthe architect has completed the design.

Lyytinen: Another danger that somepeople point out is requirements paraly-sis. That you just do too much require-ments specification. Are there exampleswhere you might be investing too muchtime on requirements?

Brooks: Well, I have seen two cases.With OS/360, the marketing organizationput together a requirements group andthey came up with a long and ridiculouslist. As project manager I just had to fi-nally say, “We are not going to do that.”

192 Business & Information Systems Engineering 3|2010

BISE – PROFILE

In another case, when I was on theDefense Science Board I was called onto review, along with a Marine generalwho had spent his life in military avi-ation, the plans for a light attack heli-copter. While a colonel was briefing usat the Pentagon he said without chang-ing his tone of voice, “And it has to ferryitself across the Atlantic.” It what? I donot know anything about helicopter de-sign, but I know enough about design toknow that you cannot do that withoutgiving up some other attributes. Natu-rally the General and I both asked, “Whydoes it have to do that?” Because, whenyou think about it, a helicopter only hasdo that twice in its life if you are lucky,and once if you are not. The answer was,“We do not have enough C-5 transportaircraft to carry them all.” So we said,“Well, why not take some of the total pro-gram money and buy a few more C-5s?”“Oh we cannot do that” was the response.In other words, that was not bureaucrati-cally possible. So somebody had put thisunfortunate design requirement on thehelicopter. (The project eventually died.)

Then we inquired about the require-ments process. There had been a com-mittee representing the different usercommunities. As far as we could deter-mine there was neither a helicopter en-gineer nor a pilot on that committee. Sowho were they? There were representa-tives of the various user organizations,in other words, fundamentally paper-people. They had talked to their con-stituencies; each constituency had statedwhat they wanted. There was the usuallog rolling – “I will not naysay your re-quirement if you will not naysay my re-quirement.” So consequently nobody hadsaid, “This requirement does not makeany sense. There is bound to be a bettersolution to how to get them to Europethan that.” That was a very vivid exam-ple to me, even though it was outside myarea of competence, of how the require-ments process can get detached from thedesign process and lead you to this long,long list of unreasonable requirements.

Well, I think our industry has some-what moved away from that notion of along list of pre-specified requirements –that you do all that before you start de-sign – at least I hope it has. So the ques-tion of “Is it possible to spend too muchtime and too much effort getting require-ments before you do anything else?” canbe answered with YES. Now, does thatmean that you do not do as careful anelicitation of initial requirements as you

can? Of course not. Surely you do that,but you have to have a process that as-sumes that the process is not absolutelyright, and absolutely not final.

Lyytinen: Based on your experiences,what are the biggest challenges in cap-turing and managing the requirements sothat they are really useful and sensible formany different stakeholders?

Brooks: I think the biggest challenge isgetting a unified overall vision of whatit is you are trying to do, as opposedto many fragmented personal visions. So,your next question is then, “How do youdo that?” And frankly, I do not know ageneral solution. That is a chief functionof a project leader.

Lyytinen: How did you try to do thatyourself with the IBM/360 project?

Brooks: Well, I had two different Sys-tem/360 experiences of course – the hard-ware one and the software one. In thehardware case, the Spread committeespent six weeks in a motel in Connecticutwith representatives from every divisionof the company – marketing, the militarysystems division, the World Trade com-pany, as well as the different divisions thatbuilt I/O gear and processors, etc. Whatwe hammered out was a vision of a sin-gle new product line replacing the six thatwe had. Those were all running out ofarchitectural gas, namely address space.So, as part of hammering out the productstrategy, we developed a technical vision.As a matter of fact I wrote the documentof 40 technical ground rules for the newcomputers that summarized our vision.It was a short document – two or threepages for 40 rules. Now, we understoodthat the requirements were to cover theentire computer performance and con-figuration range from little to big, withstrict program compatibility, so that wasthe first overall objective. The next over-all objective was that the system had to beeffective across all different applications.Another crucial one was we were going tomake this out of a technology that costabout half as much and we needed tokeep the company revenue at least whereit was, and indeed, grow it. So, we hadto be able to create new applications andmarkets to more than double the amountof computing that people wanted. Thoseare quite clear objectives.

With the software, we had the oppor-tunity because of the compatible hard-ware to say we can build one softwarepackage to support all of the System/360hardware systems and configurations. Wedid not achieve that completely, but

we did go a long way towards it. Weknew both the existing applications andthe new communications-based applica-tions that we had to satisfy. We knewthe languages we had to support – AL-GOL, COBOL, FORTRAN, report pro-gram generator, assembler, etc. We knewthat the operating systems had to sup-port a new vision – that the operatingsystem is in control rather than the hu-man operator. That was an entirely newvision; nobody had really done that be-fore. We also planned to provide multi-programming, another new capability.So the overall vision was a disk-basedsystem, a multi-programmable system,an application-broad system, a language-broad system, a performance-broad sys-tem configurable for different memorysizes from 16 K up to 500 K at least.

Thus we had a few very clear over-all broad objectives and we tried tokeep those forefront, just as the AirForce committee described for success-ful weapon programs. At one point, whenthe programming house was entirely sep-arate from the System/360 developmentproject, the programming house cameback with a software support plan thathad four different incompatible operat-ing systems. You would have to recom-pile your program as your configura-tion grew and you changed memory sizesor processors, even though they werestrictly binary compatible. From an over-all project point of view I said, “That isunacceptable! The overall vision was oneof smooth customer growth; this violatesthe overall vision.” We scrapped a year’sworth of work and started over. But thatis the advantage of having very few, veryclear overall objectives. Those constitutea unified vision.

Lyytinen: Is there anything new thatwe have to do now compared to whatyou had to do in earlier developmentprojects?

Brooks: I think we have a clearer per-ception that the tail is long. When we weredoing the /360 hardware, we predictedthat the architecture would last 25 years.We are now at 45 years today, and Sys-tem/z is newly out there and still execut-ing an upward version of the same archi-tecture. I thought I was being bold in es-timating 25 years, because of course theimplementations turn over every four tofive years. The notion that an architecturehas to last and last is now clearer for us.For example, look at the current FAA airtraffic control system. It has been in place

Business & Information Systems Engineering 3|2010 193

BISE – PROFILE

since the early 1960s and they are still de-signing the next one.

Hansen: Why do think that is the case?Is it a question of path dependence?

Brooks: The effort of re-doing a systemis so much bigger than expected. The ef-fort is not just the cost of redoing, it is thecost of retraining everybody that is goingto use it or maintain it. I was interested tofind out that as recently as five years agothere was still an IBM vacuum tube 650in productive service in Germany. Well,you know it was doing a job. So the valuehas just persisted. The lifetimes we aretalking about are much longer than weexpected, and the maintenance tail of asuccessful project is much longer than weexpected. I think that is a realization thathas dawned on us bit by bit.

I think another one that has dawned onus – well, I remarked on it in 1975 in “TheMythical Man-Month”, but I think we ap-preciate it more and more – and that is

the notion that a successful product at-tracts new applications and the new ap-plications in turn call for added functionand added performance. So, this virtuouscycle with a successful product can go onand on. Now, it can go on and on ridicu-lously. Look at Microsoft Word and thenumber of different options and func-tions in it, which is ludicrous. It is notclear that what improved over the yearsis ease of use.

Lyytinen: Do you have any closingthoughts?

Brooks: The most important singlemessage I can leave you with is that greatdesigns come from great designers andnot from great processes. What processimprovement does – and it is important –is bringing up the floor of practice. It en-ables organizations by systematic meth-ods and better processes to improve poorpractice towards average practice. Whatprocess work does not do is to raise the

ceiling of project imagination and quality.Ceiling raising comes from really giftedpeople who are given opportunities andauthority to do great designs. I have in-vestigated IS designs that have fan clubs.Which of these emerged from normalproduct processes, and which were de-veloped outside of normal product pro-cesses? The striking thing is that most ofthem were outside normal product pro-cesses. Such processes are designed fordevelopment of follow-on products; theywork well for that.

That observation means that the mostimportant thing that a manager can dois to find potential great designers andgrow that talent thoughtfully and system-atically. Thus I would go back to a focuson people and talent, as opposed to pro-cess. That is from a management point ofview, rather than a research point of view.

Lyytinen and Hansen: Thank You.

194 Business & Information Systems Engineering 3|2010