Open source projects sometimes have intense streams of user feedback, and sometimes corporations would simply pay to make certain features planned and implemented (by hiring their own developers or the original developers).

If your project has 100 users, you probably can develop whatever is most fun to code.

If your project has 100k users, most probably you already have a list of pain points most users want fixed in the next release, and a list of top N features that users request in your issue tracker and keep asking about on forums.

With this feedback, you can write requirement documents for your core team, create roadmaps to help independent contributors understand your vision, and hope that some of the 100k users will send in patches.

I’ve been following open source since I first heard about linux in about 1995, and I can’t remember ever hearing the word ‘requirements’ used in that context.

Eric Raymond has a good essay, The Cathedral and the Bazaar, in which he talks about ‘scratching your own itch’. If you’re trying to solve a problem that you’re facing personally, you don’t have to refer to requirements documents to figure out if you’ve solved it or not.

That same essay also talks about listening to your users, which is good advice for everyone, not just open source projects. Open source projects tend to be meritocratic, so ‘he who writes the code, makes the rules’, more or less.

In corporate in-house software development it is common for requirements to be determined through a formal process resulting in the creation of a number of requirements documents.

To my experience this is much more common when doing contract-based development, especially when having an external company doing the development for your company, and there is the legal need for a contract. But lots of other companies control their inhouse development by their own people in a different way:

• informal communication

• prioritized requirements/bugs/issues/tickets lists (and that is definitely not an invention from the “agile” community)

This is the same way most open source projects work – since there is no need for a formal contract, no one bothers to work out big, detailed, formal requirement docs, just small, painless lists of missing features, or tickets collected in an issue tracker to be solved.

If the problem is a common one like, say, writing a compiler or a browser, the requirements are pretty much given in the form of language standards, target operating systems and target hardware, etc.

For things like GNU Emacs, which is many things to many besides excellently fulfilling its original goal of being a text editor, I think the requirements made sense because of the immense scope to extend it. Chats, emails, newsgroups, code editing, version control come to the mind. There is a research scientist working on Emacspeak. I think similar things can be said of browsers and other things that allow extensions.

If the software is catching up a function that is available only in non open-source software, the requirement is pretty much given again.

EDIT:

When the open source software goes on to maintenance and fewer original requirements remain unmet, most of the requirements can come from bugs, need to adapt to new platforms such as multi core CPUs and other hardware that offer better performance when exploited, and such.

In a fully research based project like the GNU Hurd, I’d think the requirements come from research results and papers.

To sum up,

• when starting out, the requirements for software that attempts to solve common problems can come from standards documents

• for software that is catching up to other existing software, the requirements are likely to be to produce all or most of the existing software’s feature set and some other features that the developers/users find interesting to have

• for research projects, papers and other publications could set the requirements

• when in maintenance, bugs, need to adapt to newer environments can be major source for requirements

I don’t know for sure, but once suggestion is to use an Agile-like methodology, where requirements are raised as tickets (or “cards”), using something like JIRA, with each ticket representing a feature or requirement. Each ticket could then be decomposed into other tickets representing smaller units of work.

As for actually figuring out what an application or piece of software should do, the simple answer is “talking to the other developers.” 🙂 “Talking” in this case could mean an e-mail distribution list, forum, or even IRC, anything that allows people in different timezones and geographical locations to chat.