Follow Slashdot stories on Twitter


Forgot your password?

Gathering Requirements In Open Source Projects 76

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.
This discussion has been archived. No new comments can be posted.

Gathering Requirements in Open Source Projects

Comments Filter:
  • by FortKnox ( 169099 ) on Monday October 23, 2000 @04:22AM (#683683) Homepage Journal
    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??
  • Immediate thought: if the OSS community has successfully developed applications using methods that would make the bigger, "professional" closed-source operations go under, doesn't this suggest something is different about the OSS projects? If there weren't, why aren't the OSS projects auguring in like the "professional" ones would?

    First thought: OSS projects aren't written to satisfy a client's requirements, they're written to do a job. I've seen too many commercial projects where whether it worked or not was secondary to whether it met the requirements document ( the two are not synonymous ). OSS tends to consider requirements secondary to working, and natural selection by the users prunes off branches that don't work in ways people find useful.

  • "If an airplane is in flight, and the pilot suddenly dies, what gets lost? Direction. Control. Focus. And, potentially, the lives of innocent passengers. This is the parallel which I intended to convey."

    Clearly. But the parallel doesn't exist, so stop trying.

    Requirements gathering is a step towards creating a finished product. Piloting is an ongoing process. You can't suddenly lose your requirements like you can lose your pilot (you can suddenly find out they are wrong, but that just means you didn't do it right to begin with). If you are iterating (creating a new version or whatever) you can leave that step out and you might get in trouble--but once you do it, it is done.
    An abstained vote is a vote for Bush and Gore.
  • Open sauce requirements are:

    place hand on lid of jar
    rotate until lid comes off
    pour sauce
  • Contrary to some of the postings here that would have you believe that requirements specifications are nothing more than glorified feature lists and necessary only when dealing with a client, requirements specifications do several things, all extremely valuable:
    1. They represent the best-available information about the system to be built and represent it in a readily-accessible form (natural language, e.g., English). Not everybody involved on a project speaks code, and even those that do don't always speak it in the same way or to the same degree. A requirements specification allows everybody -- business folks, senior analysts, junior coders, and other project participants -- to understand the requirements for the system and participate in their definition.
    2. The requirements specification serves as a very-high-level representation of the system to be built which is easier and quicker to change than other representations. Like it or not, English and other natural languages are more expressive than most programming languages. You could write the code first and then change it until it's right, or you could write the requirements first and change them until they're right and then write the code -- once. The latter course is usually faster (for non-trivial systems) and yields software of higher quality.
    3. When software is being developed by or for multiple parties, the requirements specification holds the best present agreement among those parties and helps drive the parties to consensus. Trying to get large, disparate groups of people to agree on something as complicated as a large software system is a daunting task. It's a process that usually takes months, but you can reduce that time (to fewer months) if you capture requirements as they're agreed to and put them in a specification so that they aren't forgotten and rehashed over and over again.
    4. The requirements specification serves as an agreement among parties. In other words, "If it's not in the requirements, it won't be in the system."

    So, let's give requirements specifications a break. They are useful tools.

  • Extreme programming (XP)

    Just in case you want to know what it is []...

  • Let's not forget "Block Sender", shall we?

    And regardless of cost, the first company that makes an email client (for Mac) with the following will have my undying loyalty:

    Better than Block Sender would be a feature that accepts ONLY messages sent by those listed in your address book, or from a list of Hence, users with private email accounts who like to break things when Spammed could implement the option and save themselves a hell of a lot of stress.
  • Having worked on a number of large-scale software projects, I will unequivocally state that not having written requirements is just begging for trouble. Or, what is worse, having a written requirements document that is vague in one or more critical areas -- which gives you a false sense of security.

    I would divide software projects into three categories:
    1. Mass-market software

    2. Custom software developed for a specific customer
    Software aimed at a mass market of many customers faces the problem that each of them has his or her own specific needs. The software engineering tradeoff here is development time and money versus how many customers really want/need feature X. Secondary factors are how much this contributes to code bloat, slow speed, and more bugs. Open source software faces these questions, but the answers are a little bit different relative to a commercial environment. Many users of the software may want/need feature X, but if none of them are coders and thus can't contribute directly to the work on the feature, it won't get done. (I admit that the more people want something, the more likely it is that one of them can/will contribute code to the project, but this is a second order effect.) As a result, if the core team does not set up at least a semi-formal requirements process, feature X will never make it into the project and down the road, users may stop using the software due to the lack of such a feature, leaving the project to slowly wither away. Alternatively, without a written rquirements process which the user base may respond to, the core team may spend a lot of time and effort on a feature that is relatively unimportant to the vast majority of users.

    Software written for a specific customer also needs a requirements process, as in my experience three-fourths of the problem is that the customer doesn't really know what is really needed. As a case in point, I spent about three weeks working with a client on a web-based log-in process. I spent a week or so reviewing the current state of things, which was that they had gone ahead and done six months worth of development without a real requirements document. Guess what I found? A critical part of the log-in process was gathering user information so that they could decide which sales rep should follow up on this customer contact, but they had not yet decided whether this should be handled on a geographic basis or a product-line basis, and depending on which way things went, they wanted to ask different survey questions and have the user information sent to different people. After another two weeks of feeding-time-at-the-zoo meetings, we pulled the plug on our involvement with this until they straightened out the requirements. Open source software doesn't face this as much, but even so, there can be considerable friction within a OSS project's core team if the requirements are not written down so that they are clear. The result can be acrimonious exchanges and even splits among the development team, creating bad blood that didn't need to be.

    Tweak-ware is possibly the only place that might not need a written requirements set, IMHO. This is a piece of software written by a programmer for his or her own use, with little expectation that it will become something used by many people. In this case, what's in the coder's head will suffice, as you know what you want. However, I would argue that the formal process of writing it down in English (or other non-computer language of your choice) is a great aid to clarifying your thinking on the subject. (My background is in Economics, and the worst professional insult you can say about an economist is, "Oh, him? He's a hand-waver," meaning that he doesn't write down his work in a formal paper that can be properly peer-reviewed and analyzed, but just stands at the front of a seminar room and waves his hands before a blackboard. You can get away with a great deal of vagueness waving your hands in front of blackboard that just won't fly when you write it down on paper.)

  • The problems with this methodology begin in step 1.

    Even in the rare case that you're interviewing people who will both use the result and sign off on the requirements, USERS LIE!

    You can describe an exquisite detail the workings of a system which is completely inappropriate for what they have to accomplish, and they will sit there, look you in the eye and say, "Yes, that's exactly what we need."

    Either that, or if you describe a system which does do what they need, they will deny it with all the conviction of a politician caught with his hand in the till.

    Rapid prototyping is the only approach that works, and even then, you need to use a polygraph.

  • The objective is not more consumers, for whom software is provided for as minimal an effort as is judged possible.
    The objective is users, who can be co-opted into debugging, and then gradually converted into developers, documenters, even coders.
    It's not a budgeted, scheduled event for sales and marketing. Marketing is very close to irrelevant to voluteer based development.
    Mostly it's not even a corporate effort, although such efforts are appreciated (and their lack in corporate environments is noted, and often resented).
    Does anyone think that getting RMS barbered, suited and necktied will make him appear more friendly to Unfree software or its users?
    Does anyone think suits will attract developers?
    Open Source is developed by and for its developers. The rest of us may use it, or not, as we (or our masters) choose.
    As for schedule slippage, it's ready when its developers are convinced it's ready, but don't joggle elbows.
  • *for this post, success is defined as a project of reasonable length (say 3 months so far) ever reaching a stable release.

    In the beginning, there were software projeccts, with a few people on them, written in C, and the success rate was good. Perhaps 70%

    Then, the software engineers said: "You must have requirements, designs, and models!!!!" More people were added to the project to do these things. The projects switched to languages designed to support the added developers - C++ or Ada if DOD. Success rates dropped. Perhaps 50%

    Then, the software engineers saw the droping success rates, and said: "You all clearly don't understand the customer! What you need are deeper requirements, multiple designs, and UML!" Hordes and "Tiger teams" of developers were added to fill these requirements. Languages were switched to support the hordes (oftern to JAVA). The success rate as measured now stands at 40% (even the industry aknowledges this).

    The OSS came along, did no specs, of the top of the head designs, no models, and used a relativley small number of people, working mostly in C. And the success rate (as defined above for major projects) climbed to about 70%. Some would argue higher.

    Now, when will we as a software developing comunity pitch out the "Software Engineers"? Their methods are strong negative predictors of success!

  • It seems to me that many OSS projects start as an individual effort, which are mostly as well organized as necessary. When a project is good enough that it finds an audience and then collaborators it is then time to standardize the methods and to apply the organization necessary for proper project management. OSS projects aren't the "something out of nothing" that occurs in most of the industry. Someone doesn't walk into the office and say, "Why don't you code me a new widget." whereupon you ask what kind and how big and start designing. They are the evolution or progression of a proven seed project. When they reach a critical mass it's time to apply the organization. Until then it's usually not worth the trouble. If a suitable project then fails to apply the formality when necessary, it probably fails.
  • One of the best ways that I've found to gather requirements is to write your test scripts first. It may seem odd to write tests before you actually code anything, but figuring out how to validate the software really helps you to understand exactly what the requirements are, and can force you to think a bit harder about the problem itself. This makes it lots less boring than sitting down and writing a bunch of stale documentation.


  • Requirements are a way for non-technical users to communicate with and participate in open source projects. As such, they are very important. It's true that many users do not have the ability to comment fully on the wishes for software. Which is the problem with requirements for open source? How do you elicit comments? How do you help people assess and express their computing needs? It's seems to me what's missing in OSS is the middleware -- the interface between developers and customers.
  • The problem with requirements development as it is practiced in most organization is that there is a "user advocate" that is a proxy for the users of the system. The user advocates job is to become the "average user" of the software and reduce the requirements burden/cost to the real user.

    The problem is that the user advocate is a poor substitute for real users therefore the requirements aren't always good.

    Shipping early and often is much better than a formal requirements development process because it gets early code into real user's hands quicker.
  • Let's face it, Open Source requirements are almost always in the mind(s) of the programmer(s), not on paper.

    That's certainly true. If I were in charge of a huge software project, I would engrave the project's objectives on stone tablets hung in each programmer's cube. If a programmer dares to stray from the objectives... WHACK!!!

  • by ivan256 ( 17499 ) on Monday October 23, 2000 @07:03AM (#683699) 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.
  • I would imagine that for the Slashdot collective, projects starting with gathering the requirements are definitely in the minority. It's unlikely for that to change due to the organic growth that most of these projects take on, where either the client or the developer don't really know what they want from the start, or that the idea simply has to be hammered out, sometimes in conjunction with, sometimes prior to, the requirement gathering. The other major consideration is, of course, the BOTTOM LINE. Nobody is going to pay you high hourly wages for gathering requirements if they can help it. Plus, it allows them an out when you mess up some aspect of the development. This is a bit of a sinister outlook, but probably one many have dealt with.

    1. My Vote's On This Doofus []
  • I'm lucky; in my two jobs as a software tester, I've actually gotten written descriptions from the developer of what he thinks he did. Requirements? Come on. I've read about software requirements, but I've never seen them. Often, the rationale in the developer description is, "Because [the president] said so."

    Our group had been planning for a long time to rewrite the bug database. Unbeknownst to us, a new developer's "sink or swim" induction was to rewrite it. Was he privy to any of our requirements? No. Now, we're reluctantly using it.

    Tom DeMarco, Tim Lister, Ed Yourdon, Larry Constantine; Grady Booch, James Rumbaugh, Ivar Jacobson. Software engineering scholars? No, science fiction authors.

  • When thinking about this sort of thing it's important to keep a wide perspective. The purpose of gathering requirements is to ensure that the right stuff get written. If you're coding the changes yourself for yourself, you'll know when you've gotten it right - so you don't need to have written requirements. If you're coding stuff for other people, then you need to gather all the information you can so you can get it right.

    When doing all this development life cycle stuff you need to keep the *why* in mind, or you rapidly end up with a lot of bureaucratic BS which wastes everybody's time and effort.
  • The part entitled Discourse Analysis and Disadvantages of Using the Net seemed to have some logical problems. Aside from the logic --she lists a series of disadvantages and then goes on to say that there are disadvantages as well-- it doesn't seem to take into account that people can and do interrupt each other using interactive networking tools. Many people collaborate interactively on the net for various development projects using, for example IRC which does allow you to interrupt people and even punish them. Hmm. I guess I'm not too sure what she meant by Discourse Analysis anyway. As a Rhetoric major, such terminology makes me suspicious of a writer's intentions. These little stumbling blocks seem to underpin a larger instability in the piece which is trying to apply commercial software development concepts to open source models. There doesn't really need to be a convergence between the two. If they don't completely overlap each other there won't be any crisis.
  • The fact that a project is open source or not seems to be irrelavant. I would think that the size of the project would be the biggest consideration as to whether or not something is fully planned and documented prior to implementation.

    Example: Where I work, we don't plan out anything. Then again, our projects are not that large and it's a niche market we're going after. If we took the time to flowchart everything it would kill any profits. Besides, there is a big difference in keeping track of 100,000 lines of code, than it is to manage 1,000,000 lines.

    Another factor would be the size of your team. If you are looking for a large team to get a project done quickly, the flowcharts and documentation would be a good thing, just to make sure everybody has the same idea. If it's just you and a friend or two, chances are you're already thinking on the same wavelength.

    Also, the complexity of the project and the target audience size also must be taken into consideration. If you have a large audience, then planning would definitely help organize the needs of all the end users. Especially is what you are developing is a product designed for other developers.
  • Mod that up! Spot on.

    Last year I finally got shot of a two year project to replace one in-house piece of operational software with another. Getting shot of it in this case meant dropping the project and buying something off-the-shelf.

    Now, it's interesting to look at the requirements we were asked to fulfill, and the features of this off-the-shelf software, and see whether they match.

    Therein lies the problem though, because the requirements were never documented properly. Basically my fault all along, but the project was allowed to mushroom into a nightmare because management knew how to run a software project even less than I did.

    Having said all that, with open source projects, often there aren't any requirements from users. Especially in the 0.9 release. The first programmer probably knew roughly what he was trying to achieve and then put out the software when it did something. The community then has a need (its own implicit requirement) and finds xyz package that fits the need at least partially.

    For example, I never specified the requirements of Samba, but when I heard about it, I realised it would make a neat solution enabling me to get rid of flaky PC NFS client software.

    As an open source project gains momentum, requirements start to emerge, ad hoc, from the user community in the form of suggested enhancements, etc.

    Turning back to Samba, we can see sometimes there can be conflicting requirements (especially their relative priorities) which a single project doesn't feel able to meet. Hence the code fork.

    In a strict development cycle, there is a concept of a "user", the aim is to meet as many of their requirements as possible given the resources. In open source, I see that concept of "user", as well as customer/owner/stakeholder, etc., as hard to define.

    For some interesting reading check out the famous "Mythical Man Month" by Fred Brooks, and various texts by Steve McConnell. I get the impression there is no agreed "best practice" in open or closed source development. It's still something of a black art.

  • by jamused ( 125583 ) on Monday October 23, 2000 @05:23AM (#683706) Homepage
    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 [] 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).

  • I submit, for your viewing pleasure, the following:

    Slashdot Requirement Specifications

    The slashdot system will consist of the following:

    1. A dynamically created webpage allowing for the transmittal of Linux updates, Geek news, and long-winded Katz soliloquies.

    2. A system by which the readership may comment on aforementioned updates, news, and blather.

    3. A moderation system allowing separation of relevant discussion from comments about FP, hot grits, and cock-length.

    4. A system by which a given comment may be commented on, creating a 'discussion-thread'. Or, in the case of low mod-ed comments, 'flame-wars', 'spam-fests', and '1337 h/\x0r d00dsp33k p4r7ys'.

    5. A method of news-submittal, allowing for the creation of a digital 'slush-pile' that may be promptly ignored and forgotten by the administrators of said Slashdot.

    6. A sufficiently large user base to crash linked sites, a process hereafter termed 'The Slashdot Effect'.

    This document may be later appended for increased detail of required functionality to be provided by site Slashdot. The procedure for adding to this document shall be the aforementioned system of commentary.

  • Q: Could Linux have ever been the result of a commercial project requirement? BSD? Apache?

    Q: Could any commercial requirement ever have resulted in what we have today as Linux? BSD? Apache?

    IMHO, certain things simply could not be developed in a commercial requirement scenario, and most certainly not if there was no open source movement. Your thoughts?

  • On mass-market software, which is the closest fit to most OSS projects, let me ask this: how does a lack of a formal requirements process stop users from e-mailing the author saying they'd find a particular feature useful? Where did this obsession with the idea that things are either formalized or non-existent come from?

  • If the project is small enough that one person can do it, and also could have written the code you submitted for themselves had they thought of that and liked the idea, they would. OTOH, larger projects which need a team of people thrive on contributions. I think we're simply going to see some both, and probably a lot more of the smaller personal projects that indeed do scratch an itch. I know I'm doing a few of the latter myself, although a coming one is destined to be much larger than I can alone ultimately handle, so I will have to decide how to deal with that when the time comes.

    As for good clean code, opinions do differ. I've debated with a programmer who persistently releases code without comments that I find hard to read, and he was of the strong belief that his style was the very best. To him, comments just got in the way of seeing what the real code really does. While I still personally insist on good comments that explain and add to the code (as opposed to redundant comments, which are evil), his arguments have made me at least be careful about overcommenting. The point is, what constitutes good code, and good programming, and good design, is in fact something so many of us all have different opinions about. These differences are one of the factors that causes more than one project with the same apparent end goal (not to be confused with different virtual requirements, e.g. KDE vs Gnome).

    If you want to tell me your opinion of my coding/programming style, one sample is here []. If you disagree with my style, then I'm almost sure to disagree with yours. But isn't that the way it's supposed to be :-)

  • by Anonymous Coward
    What makes you think that OSS projects don't augur in like the "professional" ones. Head on over to Freshmeat, and count how many of those releases are in beta. Now, how many of those in beta have previous release. Now, how many of those in beta, with previous releases, have ever had a stable, release build? I'd imagine that the answer is close to the claimed 10% success rate that the "professional" process produces.
  • So, there are requirements for open source? I thought you just did your product and then gave the source away for free. Am I missing something?
  • by JohnnyX ( 11429 ) on Monday October 23, 2000 @03:47AM (#683713) Homepage Journal
    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...
  • Having been involved in several development projects, I must say that requirements are a good thing....that is, unless you're in a situation where a client really doesn't know what they want. I'm so sick of hearing the 'That's what we said, but not what we meant' line. Grrrr.....
  • You definitely need specifications that both the development team (most likely project management though) and the client agree on. This prevents the "but can we add just this one more thing" head ache down the road. Plus, if its a contract job with a dead line... it really saves you ass.
  • Specific issues include, but aren't limited to:
    • Where/how should we host the project? Something internal? Something like SourceForge?
    • What management structures/tools are helpful? At minimum we'll need a source-code repository and a mailinglist/newsgroup, right? Anything else considered critical?
    • What are some effective control stuctures? Who should determine what makes it into an official release? By what procedure? Who should be able to add code to the tree? What kinds of resources do we need to commit to this project to make it effective?

    -The Reverend (I am not a Nazi nor a Troll)
  • I thought you just did your product

    Even if the product you are creating is initially only for yourself you should sit down and work out what you want - effectively gathering requirements from yourself.

    After all - how the hell can you start a project with anyone in mind if you have no idea what the project is going to acheive.

  • by Anonymous Coward on Monday October 23, 2000 @03:54AM (#683718)

    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.

  • IMO there is no difference between projects that conform to SDLC principles and the open source development model. It seems to me for the most part alot of open source projects deal with small programs and the effort of a single person or small group. People would say that these small programs are written to "scratch an itch". But the presence of the itch indicates there is a problem/need or an opportunity. Then the people with that problem/need/opportunity decide how they want to deal with it programmatically. After they come up with a design they go ahead and create a prototype. When they're done they release a public beta for everyone else to try out.

    I would think larger open source projects (Gnome, KDE, etc.) would require a more formal SDLC because they're so much larger in scope and encompass more technologies and objectives. Otherwise small open source projects and large formal projects both require planning - they just differ in the degree of involvement.

  • So most open source projects don't have many requirements. They are only an itch scratcher.

    My requirements: Scratch here. If you want to scratch there, you will have to modify the source. If you want a full body massage, I can't help you.

    This doesn't sound so much like a call to list requirements as a call to expand the requirements of your project. You will always benifit from listing requirements and following a UML style programming model, but if the project is small enough, a list in your head is just fine.

    Now, making your project expandable, thats something else entirely.

  • by Anonymous Coward
    It's a controversial point, because it doesn't necessarily mesh well with Raymonds 'laws of natural software evolution.'

    There is a historical tendency for ill-trained programmers to think that the code itself should serve as the documentation. The only thing that 'saves' Linux from the fate of being a swamp of badly defined kludges is that it's based on a 'reference design' that consists of ye-olde Unix. This 'validates' a certain amount of Raymondism, but it doesn't facilitate far reaching evolution forward. Big software projects can't crawl forward at the whim of random programmers. There have to be architects who see the big picture.
  • by Anonymous Coward
    CmdrTaco says: "How many open source applications have ideas like these spawned?"

    Sorry, that't the wrong question. The right question is: "How much does a requirements process help OSS projects?" IMO, based on a LOT of years of development, a requirements process is indispensible for any program that will be used by more than a few people or is more than moderately complex. Whether it's OSS, closed source, cathedral, bazaar, or whatever is irrelevant; if you don't know where you're headed with this type of project, you're not going to like where you end up, period.

  • It would seem to me that strictly defined requirements are more important for commercial software than for free software.

    However, I think that this is an area where free software has an advantage. As the typical free software project starts off as a twinkle in it's authors eye, and can be written as he sees fit, this means the software is not stifled by an inflexible morass of definitions. Also, it is an aid to creativity - the author(s) are free to think and write as they wish, at least at the projects inception, which is probably the most important point of all.

    However, where the commercial model wins is with an overall sense of direction. Sure, it may not be as adaptable or nimble as the free software development process, but it is like a juggernaut - nothing will stop it from reaching it's destination, not quality or sense or changed cicumstances. I am not saying that free software development does not have a direction, though. But I consider it's sense of direction to be, if you like, an emergent property, not necessarily explicitly stated. Of course, this is slightly parodic, but I feel it has a grain of truth somewhere ;)

  • I don't think it is the programmers who drop the ball on using this methodology. I wish places I have worked did. What happens is management deems that the process takes too long and says can't you just plug out something kinda like this?

  • by Vokabular ( 114672 ) on Monday October 23, 2000 @04:40AM (#683725)
    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 ;)

  • I've done a feature request solicitation on the Evolution contact manager (similar in appearance to Outlook 2000).

    We had well over 100 unique feature requests, with probably a third of them fairly significant advances over any contact manager out there (I've examined and reviewed about 20 different contact managers so I've got a good idea of what's available).

    I've planned to put a survey up on Sourceforge, but unfortunately the survey design available is really weak. (I'd like to have a feature name, with breif description, a pop up link for a more complete description, and have the feature ranked via likert scale on how desirable the feature is. Also, I'd like additional radio buttons for marking wheter they would consider this a 'killer feature', plus an area to suggest additional features and categories, plus a bit of demographic information to find a correlation between professions and 'killer features'. I'd also like a field for those who would like to be contacted when the feature is available, or those who would like to volunteer to help implement stuff. ...)

    If you'd like to look at the list of feature requests here they are, if you have any additional requests please email me...

    (note that some of these features have already been added to Evolution, ie GPG support, but I haven't updated the list for a while... so deal (grin))

    Filters and Searching

    filters to have available

    Feature: Duplicate message filter
    Feature: 'Common properties' filter construction
    Feature: Time based email filter/vFolder
    Feature: hide message based on an attribute
    Feature: Auto-generate vFolders based on frequent words/topics
    Feature: Auto-creation of a folder for each new contact/Auto-association of messages with a contact


    Feature: abbreviation symbol search recognition
    Feature: Fuzzy searching/allow misspellings on searches
    Feature: Synonym searching
    Feature: Clustering analysis
    Feature: Outlier analysis


    Feature: 'Cleanup' command
    Feature: Relevancy/Importance Scoring



    Feature: Mail merge
    Feature: Bounce/Email redirection
    Feature: Spell checking of email addresses
    Feature: Send immediately button


    Feature: addition of a 'dealt with' mail state


    Feature: Summary display of 'new text only'
    Feature: plain-text headers
    Feature: Display html as plain text
    Feature: Full-justified email
    Feature: Allow display of message body in proportional font
    Feature: allow custom colorization of messages for categorization and prioritization of mails


    Feature: Intelligent reply for mailing lists
    Feature: HTML Stationary
    Feature: html or image signature file
    Feature: User based signature file
    Feature: Rotating signature file
    Feature: Macro/Graphical reply builder from user defined generic paragraphs
    Feature: Smart email recognition
    Feature: Outgoing mail prioritizer
    Feature: 'Smart' auto-completion of email addresses
    Feature: Default domain for unqualified addresses.


    Feature: Automatic opening of 'bounced' messages to be resent
    Feature: Don't create duplicate messages in a folder



    Feature: Customization of alarm type, frequency and duration
    Feature: Alarms can trigger shell commands
    Feature: Alarm daemon
    Feature: Ability to define a standard set of alarms


    Feature: Follow-up/Reply reminder
    Feature: Associate/attach mail message or thread to a to-do or calendar item
    Feature: Follow-up
    Feature: Partial completion of to-dos
    Feature: To-do sub-tasking
    Feature: Task Delegation


    Feature: Scheduling conflict notification
    Feature: Group scheduling and scheduling conflict detection
    Feature: Task Prioritizer and Scheduler
    Feature: Day planner printing


    contact addition

    Feature: Add contact category to master list
    Feature: Frequent contact list
    Feature: Recent contact list
    Feature: Duplicate/Smart contact recognition
    Feature: Automatic addition of new contacts to address book


    Feature: Geographic/Time zone mapping
    Feature: query
    Feature: Caller ID launches associated contact
    Feature: Contact/Employee skill and attributes
    Feature: User defined pull down lists (and list elements)
    Feature: User defined free text fields


    Feature: Interoperation with proprietary groupware servers (MS Exchange, Lotus Exchange, etc.)
    Feature: Palm Pilot synchronization (and other Personal organizers)
    Feature: Export filters
    Feature: Import filters
    Feature: Fax support
    Feature: Remote/local Synchronization
    Feature: Access web based mail boxes via Evolution


    Feature: Automatic remote backup of mail
    Feature: Seamless GnuPG, PGP and other encryption support
    Feature: Trusted/Routing Flag
    Feature: email tracking
    Feature: Get public keys from a key-server

    Help, training, user education


    Feature: Help linked to IRC
    Feature: visually directed help
    Feature: spoken help


    Feature: Command summary card
    Feature: User level settings
    Feature: Interviewer

    Advanced/Not Yet Classified Features

    Feature: Command Line widget
    Feature: Multicopy/paste
    Feature: Voice integration/dictation support
    Feature: Key bindings
    Feature: User configurable display attributes for mail states
    Feature: One to many relationships for todos, contacts, projects, emails, etc.
    Feature: Day planner viewing
    Feature: Interface clones
    Feature: Action/Time log
    Feature: Report Generator
    Feature: Time log
    Feature: Document management and tracking
    Feature: Mailing address and label printing
    Feature: Smart message retrieval
    Feature: Resume message downloading
    Feature: Voice commands
    Feature: Autoupdate
    Feature: See contents of multiple folders at the same time

    Tom M.
  • one of the biggest gripes Ive had about the open source community. The OSS community has developed quite a few large scale applications, and without the aid of proper planning and requirment collection. If a professional organization did this they would be eating ramen noodles in a few months. Ive always thought the OSS community needs some sort of standard for requirment collection. I for one, have so many ideas come into my head at once that i _need_ to document ideas and requirments. Now imagine that with what could literally be dozens to hundreds of people.

    "sex on tv is bad, you might fall off..."
  • I used to think it was important for open source projects to have a good document describing the direction, feature goals, and planned behavior. Well, I still do, but I think now that there is a more pressing need...

    README files! I've been browsing freshmeat and SourceForge just for the hell of it and what some projects actually neglect to mention anywhere on their homepage or in the README file, is what the general purpose of the program actually is!

  • I believe that requirements are a good thing for everyone. In case the deadlines are not met and the requirements fullfilled, the client company is in a position to either sue or negociate the continuation of the project. And on the other hand, the contractor is paid according to these functionalities. That raises the question of feature freeze which is most of the time completely overlooked by the client who believes that it works because he pays for it, completely disregardind the potential need for a redesign. Generally, the conditions under which the changes may occur should be predefined. It is a good practice though to be able to write requirements which are not fuzzy and all terms defined in a glossary somewhere hence the need for professional requirements writers who can be able to translate information from a non-technical background (business flows) to technical terms. It is very common though that clients mix application prototyping with application development, jump the gun and create a death march project at a huge cost. After all, you build houses out of plans, you just don't start piling bricks randomly... This simple analogy should help everyone understand what a reasonable approach should be. But do we have enough time to be reasonable nowadays ? :)
  • by platypus ( 18156 ) on Monday October 23, 2000 @05:34AM (#683730) Homepage
    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 [].
    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.
  • OK, so modeling is all nice, but since most OSS-projects are on a tight budget, it is impossible to use most of the UML tools available. Just as an example, take a look at Rational Rose [], which costs $4290 !

    Does anyone know of any good Open Source UML tools?

  • by jehreg ( 120485 ) on Monday October 23, 2000 @05:38AM (#683732) Homepage
    You see, this is a personal pet-peeve. I started the Black Hole Firewall Project [] 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 [] and I announced the project on

    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.


  • by Shane Hathaway ( 210174 ) on Monday October 23, 2000 @05:44AM (#683733) Homepage

    We're trying hard to achieve a complete open development process on []. We call it the Fishbowl []. 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 [] 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 [] 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.

  • As an outsider, I find the difference of opinion on the purpose of open source to be very interesting. If the purpose is to be successful with the masses, open source projects will have to become easier to use. If the purpose is to entertain yourselves, there's no point discussing Apple and Microsoft, they're irrelevant. You can "sell out" or you can be a cult, but you can't be both.
  • by IceFox ( 18179 )
    When I started the prjoject Kaim (The Kaim website: nja min/benjamin/works/kaim/ [].) we didn't create any formal docs on the design, but several weeks were spent deciding what features would go in and what would be left out for 1.0 This of course has changed a tiny bit, but for the most part it has stayed the same.

    I would imagine that a lot of other open source applications work this way. They may not have design docs for everything, but they have a list of feature that are wanted for 1.0. The prolems arise when the developers start adding every feature under the sun when they think about them, rather then getting what they have in good shape.
  • You've made an excellent point. For a developer writing the software for himself, a spec isn't needed. But even though 99.99% of free software is not commercial, there is still a customer beyond the developer. If the developer is just scratching and itch, and the coding follows wherever the itch happens to lead him at the time, then the software will never be more than hobbyist software.

    But without a spec, how can anyone log a bug? For example, version 0.2 of a program cannot use the config files for version 0.1. Is this a bug or is this deliberate? I have no clue, and there is no documentation to say otherwise, beyond a cryptic entry in the ChangeLog (ept: 102300 - .foorc).

    I haven't written any specs for my own software. I have no problem with this, and I proudly call it "hobbyist" software. But I've gotten to the point that a couple of developers are thinking of joining the projects. If I want them to be more than bugfixers, then I had better get busy writing some sort of specs/reqs.
  • ... it is funny to see things go full circle ... although this is about "open source" requirements, I want to share my perspective from large business systems I have developed/supported ...

    Back before the 90s, and late 80s even, systems were thrown up with little requirements gathering or some kind of steering committee comprised of business users, operational staff, and programmers all formulated the requirements together ...

    By the 90s, however, architecture and implementation functions were separated, and those building the system merely were the technical authors - the requirements were dictated by analyst groups ... now, the whole picture is hilarious - at least from the perspective of large business systems - when it made sense to separate the implemetation from the architecture - (70s - 80s - due to fact that new systems were built often, and the lifetime of a system was only a few years ...) - and indeed, there was a push to do this ...

    Now, the situation is sometimes comical (at least to my programmer perspective :)), to see architecture and implementation separated, but the systems are 20-30+ years old, and there is noone that knows the "business rules" and/or requirements of the system - the rules are "embedded" within sphaghetti tangled code that has been trampled all over for 20+ years ... but now, an analyst that has no ablility to read code whatsoever makes critical business decisions on requirements ...

    And please dispel with the notion that the present systems structure has nothing to do with the formulation of new business requirements - in a perfect world, perhaps, but cost is a big factor and cost can only be measured with a good grasp of the existing system framework structure ... at least for "large" systems, no one is rewriting these ... only adding another "hack" to achieve some essential critical business function that needs to be implemented yesterday ...

    Maybe as hardware costs keep diminishing ... but as that continues, I have observed diminishing skills of new programmers ... management always tries to opt for the "magic bullet", that just buy some shrinkwrap, plug in a few variables, and voila ... there is no substitute for knowing how to program ...

  • We have Free and Open Source Software. It works for the coding. But where is the FS/OSS analogue for project management and SQA? If FS/OSS is to truly leave the realm of hobbyist and academic software, then it needs to dump coders and get engineers.
  • 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.
    If you have customers, listen to them, or make them buy what you already have.

    If you don't have customers, then the question is kind of silly isn't it?

    Doesn't this seem pretty much independant of Open Source/Free Software/Proprietary/ Whatever?

    In fact, the open source "pay for enhancements" model of software business could hardly be more customer focussed. Rather than some imaginary customer dreamed up by the marketers, here you have a real customer, willing to pay real money, for specific features.

    Does this model work for Joe Sixpack? Probably not. Should we care?

  • Many of the more successful OS/FS projects do have specs - RFCs, reverse engineered protocols, and so on. Think Samba, BSD IP stack, Apache, the Linux kernel, even the GNU tools. Requirements capture only really begins to cut in when you're *not* reproducing functionality that has been done (possibly worse, possibly better) elsewhere.

    A second observation I have is that tool support for requirements analysis and even design is hopelessly weak. Noone in the OSS arena is going to shell for Rational's offerings (RequisitePro, Analyst Studio, and SoDA) but without using a database to track your requirements and models and document them for you, the mechanics of keeping track of things will end up taking more of your time than actually getting the work done.

    If you actually have tools it can be worse (sigh) - as you spend time trying to document the undocumented and undocumentable legacy systems you are saddled with.
  • Or are you just happy telling others how they should write code?

    Requirements are more of a political/organizational tool than anything else. An *RD makes sure that Marketing and Engineering have their arses covered. One can't complain about features being left out. Maybe the customer enters into the equation, maybe not - depends on the company. While there is some politics in OSS, it's not nearly as much as in a traditional corporate environment. And not enough to justify anything like a *RD.

    And for the initial coder who's just "scratching the itch", it's non-existent.
  • Define 'stable'. Often those "beta" releases are, in terms of how well they operate, as stable as or more stable than the production releases of commercial software. My rough estimate, from experience, is that at least a third of "professional" projects fail or are abandoned before reaching even the state of the typical "beta" project on FreshMeat, and at least half the remainder never reach "beta" quality even in their production releases. Internet Explorer 5.5, for example, generates an "Illegal Operation" error and dies about 3 times as often as Netscape 6 Preview 3 crashes on me, and NS6pr3 doesn't destabilize the whole rest of my system when it goes down. Similar stats apply for MSWord vs. StarOffice, and I despair of ever getting the Lotus Notes 5 client stable on an NT4SP6 system. And if you had to use NCR's C++ compiler, after not too long you would pray for the opportunity to be able to use an unstable development release of GCC because it'd handle the code better and not die as often. Bluntly put, if you abandon labels and examine equivalent functionality and stability levels, professional commercial software starts to look really shabby by comparison.

  • Take alook at
  • I totally agree, and would add that there's normally a further implicit specification for command line *nix projects:

    Operate silently if successful.

    getopt() et al style of command lines.

    Output to stdout, Errors to stderr, useful exit codes etc.

    All of these add up to help make *nix (command line), quite an easy place to build a utility that fits in.


  • The way a lot of these projects start and a way to get a good discussion of the limits and requirements of a project is to start threads in relevant news groups. Of course the high signal to noise ratio and explosion of groups can cause problems but you can get a good core of feedback and suggestions.

    This discussion can then move to IRC and mailing lists. However regular updates in news groups can keep attracting new blood and fresh information.
  • I think a better approach would be to have permit the announcement of new projects even if they do not have code already.
    Users could set a flag or a cookie if they think that those announcements are "noise".

    My $0.02

  • it "requirements" or "re-quirements"? I think we should be told.
  • Step #1: Become a communist.

    Step #2: Convince yourself that bad software is acceptable in the short run because 'more eyes mean faster development' so things have to get better.

    Step #3: Buy some old hardware. It might be tough to make yourself run slow equipment but Open Source stuff just doesn't have drivers for anything new.

    Step #4: Hit some dimwit venture capitalists up for a little cash.

    Step #5: Announce your IPO.

    Step #6: Develop a business model. Be sure to avoid any possibility of making a profit (see #1).

    Step #7: Realize that good will doesn't buy groceries for the family.

    Step #8: Close down the business.

    Alternate Step #8: Reorganize as a Microsoft shop and sell Office Solutions.

  • Many users complain that my sig should be changed; however, it comes in handy when it serves as an example. Here's a potential future one:

    A piece of software without a coherent purpose is like an airplane in flight without a pilot.

    And, the current one:

  • Many Open Source projects use a modified form of RAD methodology. The ability to use development code naturally generates the "this is nice, but what if we added ...?" comments.

    RAD methodologies tend to work well if you have people who can respond quickly and properly. The Open Source world has a large number of such people.

    Can we do better in giving users a more standard way of delivering feedback? Yes. But you don't need to change the development methodology to get achieve that.

    My opinions are my opinions, and probably do not reflect those of my employer, space aliens, or your friend Bob.
  • by handorf ( 29768 ) on Monday October 23, 2000 @04:08AM (#683751)
    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
    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.
  • Oops, I forgot to give my point (doh!), well - the point was, that doing a requirements gathering can result in numerous innovative features that might not otherwise be discovered, that the original programmer would love to have if only he had thought of it.

    With a few decent tools, the process can be relatively painless to do, and yet provide great benefit to the end user.

    (I'd suggest adding a link to the desktop of each linux distribition that solicits feature requests, and have a Wishlist/and a feature request voting as a menu item for every program [yes, I know that the bug tracking software has a wishlist, but a naieve user is unlikely to find it...]). With the proper tools, I feel that Free/Open software can grow at even a greater rate than it currently does.

    Tom M.
  • by Paul Johnson ( 33553 ) on Monday October 23, 2000 @04:51AM (#683753) Homepage
    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.


  • 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....

    The Extreme programming (XP) guys would disagree with you.

    The longer you think about a problem, the more the
    client's requirements change. You may be desining
    something that is changing is you design. The question then becomes wether all the design is
    actially worth the money that's being spent on it.

    And pretty all the "design first, code after" is based on the idea that the later you are in a project, the more a bugfix will cost.

    This idea has not been re-verifyied in a long time. Maybe modern programming techniques and
    business requirements have changed the equation.
  • by InitZero ( 14837 ) on Monday October 23, 2000 @04:51AM (#683755) Homepage

    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?


  • "A piece of software without a coherent purpose is like an airplane in flight without a pilot."

    (my emphasis) An airplane in flight is, by definition, in use. A piece-of-software-without-a-coherent-purpose is not necessarily so. Remove the "in flight" and you get:

    "A piece of software without a coherent purpose is like an airplane without a pilot."

    Huh, big deal. It's taking up some space but that's not a huge problem. It can be cannibalized for parts, used for training exercises, examples to others, etc.
    An abstained vote is a vote for Bush and Gore.
  • 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 [] 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
  • Damn, that's how it was before I changed it and posted. I knew that the extra "in flight" would get me in trouble. I only wanted to point out that the airplane wasn't sitting idle on the ground.

    Also, think of it: If an airplane is in flight, and the pilot suddenly dies, what gets lost? Direction. Control. Focus. And, potentially, the lives of innocent passengers. This is the parallel which I intended to convey.

Promising costs nothing, it's the delivering that kills you.