Could the process of massively parallel requirements engineering be effective and practical in business? The usual process is roughly that the commercial side of the business presents a set of requirements (from customers or internal), these are assessed by "architects" (or other senior technical staff) who design a high level technical solution then the programmers sort out the details and implement the solution.
There's been a move toward more iterative development models, where less design is done up front, and there's more flexibility to adapt to changing requirements and lessons learned during the development process. This works fairly well for things that are relatively easy to change, like software. However, this still hasn't effectively solved the problem of basic systems design such as "do we use a J2EE apps server", "is the data stored in XML or a relational schema", "do we design for a loosely coupled cluster or a big SMP system". These get decided up-front, and are hard to change afterward because of the sheer of things that rely on those assumptions.
The architecture part can be a slow, difficult and frustrating process that involves a lot of meetings and reviews to try to ensure that the design meets the requirements and isn't fundamentally flawed. I wonder if you'd get better results by parallelising in the way Ross Anderson comments happens in exams. Put the requirements and constraints as a question, get 20+ of your developers to spend 30 minutes answering it in exam-like conditions, then get one or two people (maybe those who set the question) to collate the answers, drawing the best ideas from the whole set and accommodating any pitfalls that candidates may point out.
I suspect that may be in many ways more useful than traditional open "brainstorming" meetings, where company seniority and personalities play a strong factor in whose views get the floor. It also shouldn't be any more expensive than existing procedures, may well be faster and cheaper in the long run if it succeeds in producing better answers.