Steve Johnson of Pragmatic Marketing writes: "Over the years, I have found that I always have an internal screech when someone uses the term “requirements gathering”. The term itself makes it seem like the requirements are lying there, and the Product Manager just has to grab them and pop ‘em in a document." --- Hear, hear. The resulting discussion among a community of Product Managers (whom I've often thought are pretty much the real managers of requirements) is interesting for its diversity of views.
Steve Yegge blogs that "Business Requirements are Bull***" (well, this is a family website). His point is that inventing "requirements" for an unwanted product is not likely to do any good. He argues that if your project feels the need for a Gathering Requirements Phase, you've already lost the plot. The alternative, Yegge says, is to invest in what you know: to build the product that that you are personally excited about buying or using right now. --- But can one person be representative of everything? Perhaps a bigger sample of stakeholders might in some circumstances be better?
Mary Connor of the iMIS Community blogs that she felt let down by "the fundamental impracticality or impossibility of the methods being taught" on a use case course she attended. She observes that human language-based requirements (e.g. in English) are "wildly difficult to disambiguate". Use cases don't on their own solve the problem, and applying exhaustive iteration until a perfect set of verifiable requirements is obtained - all supposedly "before any specification or development proceeds" wouldn't work as managers never budget for such iteration. --- I guess this is heavily dependent on the domain; sounds as if in MIS, each iteration combines a bit of discovery with a bit of development and a bit of testing - an agile life-cycle, in fact.
R Beckmann in the Requirements Networking Group asks "where to start?" and suggests the sequence 1) find out the stakeholders; 2) determine why the new system is required; and 3) do some digging on the existing environment, because "the new system is likely intended to replace an existing system or perhaps it is a major enhancement." --- It is interesting that Beckmann basically assumes a "brown-field" environment - the new system starts life (indeed, starts its gestation, long before it is born) already tightly constrained by interfaces, stakeholder expectations and many other factors. Now those are requirements.
Brian Marick on his Testing Foundations website says of the task of Discovering Requirements: "Requirements are descriptions of what customers desire. This task is one of discovering those desires, especially making implicit desires explicit, and clarifying the ambiguity that invariably surrounds them."
to identify the real problems a discussion between the client and the software developers is required. Our thoughts on building solutions to these problems is when discovery of the requirements begins. Why discovery? Because they exist, but none of the parties are aware of them. A lot of times, I have realized that I have worked as a catalyst for discovering these requirements. The client usually has most of the data and process information, but is too involved in the day-to-day activities to see the problems and requirements.
(c) Ian Alexander 2009