Notes from the Field

The activities of requirements management, product management, and product marketing are widely recognized as keys to success in the software industry. In the arena of independent software vendors (ISVs) (my primary experience in the software industry), the role of Vice President of Product Management is one of the toughest slots to fill. All of the activities and roles of the position are based on the foundational contribution of requirements elicitation. The questions, "What need does the software address, what features are required, and how does the software need to be designed?" appear simple on the surface, but in reality are some of the hardest questions a software company or development shop faces. Thus, I concur that the authors of "Requirements Elicitation Techniques: Analyzing the Gap Between Technology Availability and Technology Use" are addressing a core issue in the software industry.

It also strikes me as credible that there is a general lack of understanding, and/or appreciation, for the importance of theories and techniques for addressing the requirements issue. As a result, the state of practice is far from state of the art. It is this situation that enables us to see the problem of requirements elicitation in terms of technology transfer.

In fact, I think Ann Hickey, Alan Davis, and Denali Kaiser dramatically understate the issue; they acknowledge this. First, the people interviewed were arguably chosen to favor more knowledgeable software practitioners. After all, they were in attendance at an educational conference on software and product management. Second, the survey used aided responses when it asked if interviewees knew of various theories and techniques. I suspect the unaided awareness would be much lower. Finally, I think it is reasonable to assume that a knowledge adequate to apply the techniques would score still lower. So, although it is important to establish that a knowledge gap exists and is part of the problem, it strikes me that the next point that must be addressed is why. In other words, why do practitioners not consider requirements elicitation theories and techniques as valuable enough to pass their "who cares" test, and why do they not invest in learning and applying them?

I believe there are three themes that need to be addressed in subsequent research and communication of findings. The first is a general attitudinal/cultural challenge of the software industry. As a generalization, most people building software products view themselves and what they do as fundamentally creative. At the far extreme, coders believe what they do is an art form that only true software artists can appreciate. As a result, any attempt to reduce software to mechanistic processes is resisted in ways that only a true coder can untangle. The problem is that most customers do not want to buy a piece of software as art any more than they want to buy a car as art. What they want is software that is dependable, functional, built to specification, and affordable. I think understanding and isolating this dynamic would be very helpful in overcoming the barriers to adoption of elicitation techniques.

Second, I think that the gap between theory and practice also exists because the value proposition of applying techniques is not clearly established or communicated in ways that practitioners recognize. Understanding this gap will help to build bridges to adoption.

The third theme requiring further exploration is the context for applying theories and techniques. For instance, do the same techniques have the same value and applicability for internal information technology development of software versus an independent software vendor building a subsequent version of an existing product? Similarly, what techniques are most applicable for a start-up building its first software product, with all the time and resource constraints that are part of a start-up venture? I think that being able to demonstrate value in context is missing from the current equation and can be demonstrated through research.