Slashdot Mirror
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.
The software Engineering model shows us that the most efficent way to create a large product is to follow this model:
.sigs??
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
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
Open sauce requirements are:
place hand on lid of jar
rotate until lid comes off
pour sauce
Free Anne Tomlinson!!
So, let's give requirements specifications a break. They are useful tools.
Easy, automatic testing for Perl.
Just in case you want to know what it is...
_________________________
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
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 @domain.com. 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.
I would divide software projects into three categories:
- Mass-market software
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.Custom software developed for a specific customer
Tweak-ware
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.)
--Paul
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.
Ed Craig "Who cares what you think?" George W. Bush, 4th of July 2001
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.
- Sig this!
--
www.scorbett.ca
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.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
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!!!
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
..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.
My Vote's On This Doofus
great comedy company.
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.
"Bite me, it's fun!" - Crowe T. Robot
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.
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.
That's the way software engineers wish it worked. What actually happens is this:
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).
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.
-PARANOIA is fun. D20 is not fun. The Computer says so.
-The Computer
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?
now we need to go OSS in diesel cars
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?
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.....
-PARANOIA is fun. D20 is not fun. The Computer says so.
-The Computer
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.
- kk
-The Reverend (I am not a Nazi nor a Troll)
-The Reverend (I am not a Nazi nor a Troll)
=(.\')=
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.
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.
Sanity.html - Error 404 not found
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.
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.
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.
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
searching
Feature: abbreviation symbol search recognition
Feature: Fuzzy searching/allow misspellings on searches
Feature: Synonym searching
Feature: Clustering analysis
Feature: Outlier analysis
other
Feature: 'Cleanup' command
Feature: Relevancy/Importance Scoring
Email
commands
Feature: Mail merge
Feature: Bounce/Email redirection
Feature: Spell checking of email addresses
Feature: Send immediately button
attributes
Feature: addition of a 'dealt with' mail state
display
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
composing
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.
other
Feature: Automatic opening of 'bounced' messages to be resent
Feature: Don't create duplicate messages in a folder
To-do
alarms
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
other
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
Calendar
Feature: Scheduling conflict notification
Feature: Group scheduling and scheduling conflict detection
Feature: Task Prioritizer and Scheduler
Feature: Day planner printing
Contacts
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
other
Feature: Geographic/Time zone mapping
Feature: Mapquest.com/Mapblast.com/etc 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
Interoperability
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
Security
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
help
Feature: Help linked to IRC
Feature: visually directed help
Feature: spoken help
training
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
LetterRip
Tom M.
TomM@nospamPentstar.com
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 lost my concept of community when my community lost all concept of me.
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!
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
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 ? :)
É que os desafinados também têm um coração
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 _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.
Does anyone know of any good Open Source UML tools?
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.
We're trying hard to achieve a complete open development process on dev.zope.org. 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.
Use Zope!
When I started the prjoject Kaim (The Kaim website:http://www.csh.rit.edu/~be 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.
Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
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.
.foorc).
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 -
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.
A Government Is a Body of People, Usually Notably Ungoverned
... 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 ...
AZspot
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
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.
Gamma Testing - Where testing is extended to the full user community (AKA Shipping the Program)
...is it "requirements" or "re-quirements"? I think we should be told.
nal 11
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.
Cunning linguists
A piece of software without a coherent purpose is like an airplane in flight without a pilot.
And, the current one:
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
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.
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.
-- IANAEG - I am not an elder god.
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.
You are lost in a twisty maze of little standards, all different.
"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.
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
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
Second Law of Blissful Ignorance