I've been working with a customer to help them define a custom agile process. One of the first things I've been doing is looking at where software requirements come from and how they're prioritized.

Along the way, I've realized that "requirements" is a terribly convoluted word. To many of the people I've been talking to, "requirements" refers to that sheaf of paper that somebody (not them!) hands to the development team. One person said, "I can do requirements if I have to, but I'd rather that someone with proper training and a technical background do them."

If you're reading this, you probably know that I think one of the essential factors in software success is direct communication of requirements between customer and developer. I've an extensive presentation on the subject, as well as a publicly-available simulation. Oh, and I'm the project coordinator for Fit, Ward Cunningham's tool for improving customer collaboration.

So, yeah, I've got a bee in my bonnet about customer/programmer collaboration. Bzzz.

Right. Well, I'm agile and stuff so I changed my tune. I started asking about "ideas," not "requirements." Where do software ideas come from? How do they get communicated to the programming team? How are they prioritized?

What an interesting difference that made. "Requirements" is a big fancy word. Only people with special training can make "requirements." But ideas--anybody can come up with an idea. And everybody does. Only some of those ideas are heard by the programming team, and even fewer are actually turned into working software.

By the time an idea is a requirement, the most interesting part of its life is over. I wish I could share the full story of one idea I heard about. It started as an idea to fill in a gap in a service offering. It got turned into Excel spreadsheet, got sent out to various contractors, got turned back into a different spreadsheet, and then handed over to a spare programmer. Now it's a requirement, and I'll bet the written requirement doesn't include any of this fascinating history. No "requirement" has a life so interesting. But I'll bet that many ideas do.

Where do the ideas in your software come from? Where do your requirements live before they have their guts sucked out by the spider of Process? How many steps and how much lost memory lie between the idea's creator and its realization as software?

Take a moment to consider your software. The ideas in it stretch back like threads to all parts of your organization. Where do they lead? Why did these threads survive when others were cut? Who doesn't have any threads? I can't promise that anything will come of this exercise, but it will certainly be interesting.