Gathering Requirements In Open Source Projects

webword writes: "There is an article in the July 2000 issue of Crosstalk (The Journal of Defense Software Engineering) about gathering requirements in Open Source projects. This is especially interesting because most commercial projects are driven by the requirements gathering processes (or the 'SDLC') whereas most Open Source projects are written to 'scratch an itch'. Let's face it, Open Source requirements are almost always in the mind(s) of the programmer(s), not on paper. However, if the requirements are captured, and shared, the quality and speed of development will improve." How many articles like this have we seen? How many open source applications have ideas like these spawned? I remain skeptical.

Engineers vs. Programmers

The software Engineering model shows us that the most efficent way to create a large product is to follow this model:
1. Gather Requirements
2. Make a Design Spec
3. Model the project (i.e. UML)
4. Code
5. Test
6. Goto 3
Most programmers, however, learn to program on their own instead of in school. They see this methodology as time consuming and unneeded. If they have it in their head, why spend the time to make a large design doc with requirements gathering? It just wastes time, right?
Wrong (if you are working in a team)... Design specs allow the entire team to strive towards the same goal, and even if you are 'itching a scratch', you might as well create something organized so that others that will use your open source will know what you are trying to do, and how you are trying to do it.
Which leads me to think that design docs should also be open source, because when you change the code, it usually means that you require a slight design change (unless it is a bugfix, or something minor).
Try coding something large with a good design specification first. Put lots of time into it -before- you code, and see how much easier it is to code.... Just try it....


-- Don't you hate it when people comment on other people's .sigs??

Most OSS projects will never do this and..

..it doesn't matter either way. Go look at freshmeat and see how many open source projects are there. Most of them never have any code contributed by anyone. This may very well be because of the lack of documented requirements, but the simple fact is that most people don't like other people hacking in their program. I can't even count the number of times I've submitted feature patches to open source projects, yet I have never gotten my code accepted by the author. Now, maybe I write bad code, but judging by the code from some of these programs, mine is much cleaner. Usually you don't ever even get acknowledgement from the author. There are exceptions to this, the Linux Kernel being one of them. Anyway, the point of all this is that most open source developers don't like other people working on their little itch, they want to do it themselves. So having a "requirements phase" wouldn't help any anyway.

Software Engineers vs. Reality

1. Gather Requirements
2. Make a Design Spec
3. Model the project (i.e. UML)
4. Code
5. Test
6. Goto 3

That's the way software engineers wish it worked. What actually happens is this:

1. Gather Requirements
2. Make a Design Spec
3. Discover ambiguities in Spec, goto 1
4. Model the project (i.e. UML)
5. argue incessantly about the one true way to model the project, goto 4
6. Code
7. discover what the model requires is either unecessary, impossible, or both, goto 1
8. Test
9. discover requirements have changed, because either conditions have changed or what you were asking the users to do (come up with a complete definition of how the software is supposed to work without any software in front of them to poke at), goto 1
10. Attempt to Goto 3, but discover that the code has drifted from the model and nobody kept the model up-to-date

This is why I'm no longer very interested in CMM Level 3-style Software Engineering. Some of the disfunctional behavior in the second list is avoidable, but some of it is inevitable as death and taxes. Venting at the stupid users for changing their minds once they see the software working (or sort of working), or at the stupid managers for letting them, doesn't actually accomplish anything. Even if you "win" the political battle of getting the users to accept the software as written to the spec, it's a Pyrrhic victory.

I've come to see that it's far better to grant the users the right to change their minds as their needs (or just their understanding of those needs) change in return for the right to use processes like Extreme Programming [xprogramming.com] that will help me as a developer to meet those changing needs without running myself ragged, than dumping a year or more of my life down a rathole producing software that only makes people unhappy (if it gets used at all) because it was coded exactly to a completely outdated snapshot of what the users thought they needed before they and the world moved on.

Software development ought to be an ongoing conversation between the developers and the customers, not a one-way order from the customers to the engineers to produce a widget machined to the following specifications for delivery on such-and-such a date. Software development isn't there yet as an engineering discipline, and it's not even clear to me that's the direction that we ought to be going, since it gives up one of the most valuable and interesting properties of software (that it's "soft" and flexible).

It's not that they aren't a "Good Thing"...

It's just that eliciting requirements, and documenting them, is boring. If a project is started to scratch a programmer's "itch", that programmer is unlikely to write down a good description of the itch. Usually, people mean to write it down, but that's usually a lower priority than the documentation, making it a very low priority indeed.

If an open source project is meant for a wider audience, like a word processor, or a personal finance package, it's imperative that requirements are gathered and documented, so as to avoid a plethora of "cool" features that aren't important to the vast majority of users.

Yours truly,
Mr. X

...ah, requirements...

Time for open source to grow up

The fact is that open source needs to focus more on the customer side of things if it is ever going to get corporate and public acceptance, and the $$$ that these things bring with them. Sure, that's not what Linus was thinking when he started writing Linux, but now that the goal has changed from "scratch an itch" to "providing the best OS ever", customer research is the key to making sure that it really is the best for its users, not just the dozen or so people coding it.

What many of the larger open source projects need is to take a leaf out of the marketing people's book. These people know that in order to sell a product you need to find out what they want and then either provide it, or convince them you're providing it, which is a different thing. The use of focus groups and other tools means that these people can find out what people want, and indeed the science of marketing has come a long way since its beginnings.

The trouble with open source projects is that they have the image of only catering for rocket scientists and other propellerheads, rather than Joe Sixpack at home. People hear all these acronyms and technical terms and think that it's not for them, even if all it really means is it supports 3d gaming. Linus, Alan and the other elite "gurus" need to focus on the image for a while, making sure that Linux is seen to match what real people want, not the unwashed hordes of long-haired system admins wearing Grateful Dead t-shirts.

Until the developer-customer interface is improved, companies like Microsoft will always win the hearts and minds of people who don't understand the difference between "TCP" and "IP", because they add value in the form of simplicity, which is what customers want. It's time for Linux to grow up, and stop scaring off potential customers.

The "when" of the requirements

As a researcher in this field, I'm happy to see recognition, if not necessarily interest, in requirements in open source projects. As so many have pointed out, these projects come about as a result of someone's "itch", and as such there is no real customer to drive requirements early on.

We're left with a situation where we want to retrofit requirements to the project, which is completely backwards from what you will normally find in commercial, software-for-money type projects. I think this is a wonderful idea; different design methods call for different requirements methods.

The question then becomes: Why should I, an open source developer, bother stating requirements, especially after-the-fact? I think what we're starting to see, at least in my narrow view of the world, are strong correlations between good requirements definitions and the ability to safely modify, repair, explain, and reuse complex software. That is, by properly stating what your software "does", you can help ensure it's longevity and usefulness to people using it without access to the initial developers.

Perhaps a re-thinking of the meaning of "requirement" is needed for open-source projects. Whereas a requirement has traditionally been a pre-development statement of what the software will do, open-source requirements are perhaps more likely to be in- and post-development statements of the same thing...and perhaps they will be more accurate for being such ;)

Open Source vs. Commercial

The whole premise is faulty....
OSS and commercial software are orthogonal, so it's not possible to construct contradistinction between the two (...whereas open source ...).
For a good example go to http://dev.zope.org [zope.org].
Zope _is_ open source _and_ commercial, and they put a lot of thought into how they want the development process to progress. Heck, read about the "fishbowl" in the above link, there are also thoughts about the progression of the planning of development.

Not to say this all works perfect (which is also always the case for closed-source projects), but open source doesn't mean that the software grows like cancer in any direction possible.

Open Source is allergic to requirements

You see, this is a personal pet-peeve. I started the Black Hole Firewall Project [slashdot.org] a few months back, and we had a number of coders ready to listen to users out there. But we did not want to start coding until we had requirements from the general population. So we started the project on Sourceforge [sourceforge.net] and I announced the project on Freshmeat.net.

At least, I tried to announce the project on Freshmeat... No code, no announcement. I could not believe it. How could I get the general population to know that the project existed, and that we had a site ready to take in user requirements ?

I wrote to Slashdot as a question on how do new projects out there get general requirements from users if they have no code yet. I got no response from the Slash crew, and the question was never posted.

So, we quickly figured out that "Open Source" meant "give us an existing software for free", not "make *this* because we want it". To me, that means that the Open Source / Free Software dream of having commercial grade software is just a pipe-dream because the open/free software will either come from a company that will open/free its existing software, or from a guy/gal that wrote something cool and decided to share it.

I don't think that there is a Open Source coder out there that can stand being involved in a project that is structured from the get-go. Requirements? Planning? Design? BAH! Gimme CODE! Well, say that, and stay in your little dream world of "Apache made it big, man! Open Source r00lz!".

The rest of us will be waiting, hoping to see commercial-grade applications being correctly designed and planned. But, obviously, these will just have to happen spontaneously, since there is no way for the general population to say what they want or need.

Jehreg.

dev.zope.org

We're trying hard to achieve a complete open development process on dev.zope.org [zope.org]. We call it the Fishbowl [zope.org]. It was started this year and so far has been quite successful. It is a way to open to the community not only the software but also the development process. Everyone has the opportunity to contribute at each phase.

Perhaps the most interesting part is the Proposals [zope.org] page. It allows anyone to contribute and discuss ideas for the development of Zope and related projects.

Some of the technology behind it, such as ZWiki [zope.org] and the CVS infrastructure, are not yet complete, but most don't see that as a barrier.

I think many open source projects would benefit from a similar methodology.

Commercial projects have requirements?

You could have fooled me. I have YET to be involved in a project that actually starts with the requirements gathering. Either:
a) The client has NO IDEA what they want
or
b) The client wants to get the maximum amount of work out of you for the least amount of "effort" (e.g., whatever they're getting billed for), so they keep the requirements nebulous on purpouse to gouge you for your time when you don't meet your end of the contract.

Both of these are only problems when you have spineless management on your end, but I have yet to see a project manager that won't crumble when the client whines.

Sorry... bitter day.

Simple itch implies many requirements

Open source projects happen because someone has an "itch to scratch". But often that itch pretty much defines the requirements for the project. Take Apache as an example: you want a web server. That immediately rolls the HTTP standard into your requirements document. Its going to have to be configured somehow, so that implies some kind of configuration system.

When people read these high level requirements they can immediately see a range of low level requirements. Different people will come up with slightly different versions of these requirements, but that is OK as long as the high level requirement is fulfilled. Analysis and design can proceed in an orderly fashion.

Because different people have different requirements the project isn't going to fulfil everybody's exact requirements. But thats OK, because anyone who wants the extra functionality can either add it themselves or get someone else to add it.

In contrast, in Cathedral projects the requirements document effectively becomes the contract you work to (and of course it frequently gets renegotiated). Whether you are producing the software for an independent customer on contract, or an internal customer as part of product development, your success as a software engineer is defined in terms of meeting the requirements. Open source projects do not have a need to determine whether the developers have "succeeded" or not, so they have less need of an exhaustive requirements document.

Paul.

Re: Commercial projects have requirements?

I have YET to be involved in a project that actually starts with the requirements gathering.

I just finished a four-year project to replace my newspaper's character-based publishing system with a WYSIWYG full-page layout solution. We spent eight months working on a Project Specification Document (PSD) before we laid down a single line of code.

The PSD was two volumes and over 700 pages. From the moment it was written, it was misleading, incomplete and, sometimes, downright inaccurate. Even with its problems, it was one of the best tools we had and I can't imagine doing a project of any size without a blueprint. That document kept us on track and often remided us of stuff we otherwise would have forgotten.

Yes, I did say of any size. For small projects, a line or two at the top of a script is enough. As the scope increases, so should the blueprint.

I wouldn't want a contractor to build my house without a plan but some folks do exactly that when it comes to their software. Specifications? We don't need to specifications.

Before I started my current job, my planning was half-hearted if done at all. I mocked people who would have meetings before starting a project. I felt that the time saved by not planning and by not holding meetings would more than cover any extra time needed to fix small screw-ups along the way.

The first few months I spent here were painful. meetings every day. Documentation all over the place. Very little 'work' actually getting done. Three years later, I have a lot more respect for doing things the right way.

The Open Source movement could greatly benefit from more Open Planning. Right now, for all our talk of openess, the organization is closed if not the source. Could you imagine how many more volunteers could get their hands dirty if there was a list of things that needed to be done and a roadmap as to how to get there?

InitZero

You Only Need An SRS If You Aren't The Customer

The problem with requirements elicitation is that it usually implies that the project isn't a spontaneously scratched itch, but instead a commercial or near-commercial product. Eliciting requirements usually means you have a customer and that the development team or developer-customer liason has exhaustively questioned all the potential users.

The purpose of a Software Requirements Specification is to enable the developers understand the customer's problem domain and learn what the needs of the customer are. Since most Open Source projects are written by the customer(s), it is usually redundant for them to create an SRS [gatech.edu] that describes the needs of the user.

Although an SRS is not truly necessary when creating a product where the developers are the customer it can still be beneficial for a variety of reasons including

1. Being a reference point for the entire team when implementing features and wondering what behavior should be exhibited on certain events.

1. It is a good way to handle feature creep since it is a formalized list of features. Only things in the SRS are implemented and if a new feature comes along that everyone wants, it should be retroactively added to the SRS.

1. It gives developers an idea of the size and scope of their project.

1. Priority levels for different features can be set by using the
2. must-will-should rule. Any feature description preceded with a must is absolutely necessary, any feature preceded with a will is important but not absolutely necessary while features preceded with should are typically wishlist features.

Second Law of Blissful Ignorance