Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Open Source Under the Microscope

cnet interview

What are some of the differences you've found, apart from the obvious ones? For example, in software engineering, there's a widespread view that it's necessary to elicit and capture the requirement specifications of the system to be developed so that once implemented, it's possible to pose questions as to what was implemented, compared with what was specified.

We do not see or observe or find in open-source projects any online documents that software engineers would identify as a software requirements specification. That poses the question: What problem are they solving, if they haven't written down the problem? While it's true that there's no requirements specification, what there is instead is what we've identified as a variety of software informalisms.

What do you mean by "informalism"?

That word is chosen to help compare to the practice advocated in software engineering, in which one creates a formal systems specification or design that might be delivered to the customer. Informalisms are such things as information posted on a Web page, a threaded e-mail discussion or a set of comments in source code in a project repository. It may be a set of how-tos or FAQs on how to get things accomplished. Each is a carrier of fragments of what the requirements for the system are going to be.

If they're put together in such a haphazard way, can they really be considered requirements? Yes and no. Clearly, they're distributed, but in order for people to contribute to the project, those people need to understand where those requirements are and how they relate to each other and how to pull them together. Part of how the community works is that each of the participants discusses what the system should do in whatever informalism they feel is the most appropriate to them.

posted Wed 7 Jan 2004 in /software/management | link

Copyright (C) 1999-2007 Martin Pool.