A study by Berry of the dynamics of the requirements engineering process showed the importance of having people both expert in and ignorant of the problem domain of the system under specification. The ignorant people are needed to ask all the so-called stupid questions that expose the experts' tacit assumptions, and the experts are needed to answer these questions. The study is in:
Berry, D.M. ``The Importance of Ignorance in Requirements Engineering,'' Journal of Systems and Software, 28:1, 179-184, 1995 PDF preprint

The study was based partially on retrospective from:
Berry, D.M., Berry, O. ``The Programmer-Client Relationship in Arriving at Program Specifications: Guidelines and Linguistic Requirements,'' Proc. IFIP Working Conference on System Description Methodologies, pp. 275-292, Kecskemet, Hungary, May, 1983

I applied the idea in a later case study reported at:
Berry, D.M., ``Ignorant Questions about Case Study,'' Schloss Dagstuhl Seminar on Requirements Capture, Documentation, and Validation, an attendance-by-invitation-only, limited-number-of-participants seminar, Wadern, Germany, 13-18 June, 1999 PDF   txt.Z
Here is a directory with all the materials that my ignorance-directed comments are based on.

Martin Feather observed that applying formal methods in requirements engineering may be an instance of applying ignorance, because a mathematician is generally ignorant about an application domain before he or she starts modeling it:
Berry, D.M., ``Formal Methods, the Very Idea, Some Thoughts on Why They Work When They Work,'' Electronic Notes in Theoretical Computer Science, 25, 1999, Extended Abstract http://www.elsevier.nl/locate/entcs/volume25.html   PDF preprint

Berry, D.M., ``Formal Methods, the very idea, some thoughts on why they work when they work,'' Science of Computer Programming, 42,1, 11--27, 2001 PDF preprint

In 2001, Haim Kilov kindly pointed out to me that I was not the first to note the importance of ignorance in understanding software systems. It seems that P. Burkinshaw, an attendee of the Second NATO Conference on Software Engineering in Rome in 1969 (Buxton and Randell, 1969) had made the same observation in 1969. I reported this earlier sighting in a letter to the journal that had published my original paper.
Berry, D.M. ``The Importance of Ignorance in Requirements Engineering: An Earlier Sighting and a Revisitation,'' Journal of Systems and Software, 60, pp. 83--85, 2002 PDF preprint

Burkinshaw had observed that adding an ignoramus late in a project can be useful. Thus, he seems to understand Brooks's law, ``Adding manpower to a late software project makes it later.'' Brooks observed that adding a new person will slow down the project because he or she requires being brought up to speed, thus wasting time of those who show him or her the ropes, and because he or she adds to the required communication in the project. However, Burkinshaw's observation is that a new person can serve as an ignoramus. Work is needed to measure which effect is higher, the lost due to the slowdown or the gain due to the ignoramus effect.

It's now time to do some industrial case studies on the effectiveness of the ignoramus in requirements engineering efforts and of what happens if there are no ignoramuses in projects.