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.