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.
Engineers vs. Programmers (Score:3)
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
Re:that has been..... (Score:1)
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.
Re:New sig is just as wrong as the old one (Score:2)
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.
Re:Requirements? (Score:1)
place hand on lid of jar
rotate until lid comes off
pour sauce
Requirements rule ! (Score:2)
So, let's give requirements specifications a break. They are useful tools.
Re:Extreme Programming (XP) (Score:1)
Just in case you want to know what it is [extremeprogramming.org]...
_________________________
Here's a feature for you- (Score:1)
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.
No requirements == disaster (Score:2)
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
Re:Engineers vs. Programmers (Score:2)
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.
Re:Time for open source to grow up (Score:1)
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.
A little history (Score:2)
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!
Critical Mass (Score:2)
Requirements gathering doesn't have to be boring (Score:1)
--
Requirements are for non-technical users (Score:1)
Ship Early and Often is Better Than Requirements (Score:1)
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.
Right on one thing. (Score:2)
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!!!
Most OSS projects will never do this and.. (Score:3)
Secondary Consideration (Score:1)
My Vote's On This Doofus [mikegallay.com]
as a tester, I wish they did (Score:1)
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.
Requirements Gathering (Score:1)
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.
Discourse Analysis eh? (Score:1)
It depends (Score:2)
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.
Re: Commercial projects have requirements? (Score:2)
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.
Software Engineers vs. Reality (Score:5)
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 [xprogramming.com] that will help me as a developer to meet those changing needs without running myself ragged, than dumping a year or more of my life down a rathole producing software that only makes people unhappy (if it gets used at all) because it was coded exactly to a completely outdated snapshot of what the users thought they needed before they and the world moved on.
Software development ought to be an ongoing conversation between the developers and the customers, not a one-way order from the customers to the engineers to produce a widget machined to the following specifications for delivery on such-and-such a date. Software development isn't there yet as an engineering discipline, and it's not even clear to me that's the direction that we ought to be going, since it gives up one of the most valuable and interesting properties of software (that it's "soft" and flexible).
Slashdot Specs (Score:2)
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... (Score:2)
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?
Re:No requirements == disaster (Score:1)
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?
Re:Most OSS projects will never do this and.. (Score:2)
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 [ipal.org]. 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 :-)
Re:that has been..... (Score:1)
Requirements? (Score:1)
It's not that they aren't a "Good Thing"... (Score:3)
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...
Requirements..... (Score:1)
Specifications (Score:1)
First off, adk the right questions. (Score:2)
-The Reverend (I am not a Nazi nor a Troll)
Re:Requirements? (Score:1)
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.
Time for open source to grow up (Score:3)
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.
There is really no difference (Score:1)
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.
scratch an itch (Score:2)
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.
Re:Open Source Project Management (Score:1)
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.
Wrong question (Score:2)
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.
Re:Requirements..... (Score:1)
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 ;)
Re:Engineers vs. Programmers (Score:1)
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?
The "when" of the requirements (Score:4)
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 ;)
Evolution Requirements/Feature Requests (Score:2)
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
that has been..... (Score:1)
"sex on tv is bad, you might fall off..."
I don't care anymore. (Score:1)
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!
The legal side of requirements (Score:1)
Open Source vs. Commercial (Score:4)
OSS and commercial software are orthogonal, so it's not possible to construct contradistinction between the two (...whereas open source
For a good example go to http://dev.zope.org [zope.org].
Zope _is_ open source _and_ commercial, and they put a lot of thought into how they want the development process to progress. Heck, read about the "fishbowl" in the above link, there are also thoughts about the progression of the planning of development.
Not to say this all works perfect (which is also always the case for closed-source projects), but open source doesn't mean that the software grows like cancer in any direction possible.
OSS UML Software (Score:2)
Does anyone know of any good Open Source UML tools?
Open Source is allergic to requirements (Score:3)
At least, I tried to announce the project on Freshmeat... No code, no announcement. I could not believe it. How could I get the general population to know that the project existed, and that we had a site ready to take in user requirements ?
I wrote to Slashdot as a question on how do new projects out there get general requirements from users if they have no code yet. I got no response from the Slash crew, and the question was never posted.
So, we quickly figured out that "Open Source" meant "give us an existing software for free", not "make *this* because we want it". To me, that means that the Open Source / Free Software dream of having commercial grade software is just a pipe-dream because the open/free software will either come from a company that will open/free its existing software, or from a guy/gal that wrote something cool and decided to share it.
I don't think that there is a Open Source coder out there that can stand being involved in a project that is structured from the get-go. Requirements? Planning? Design? BAH! Gimme CODE! Well, say that, and stay in your little dream world of "Apache made it big, man! Open Source r00lz!".
The rest of us will be waiting, hoping to see commercial-grade applications being correctly designed and planned. But, obviously, these will just have to happen spontaneously, since there is no way for the general population to say what they want or need.
Jehreg.
dev.zope.org (Score:3)
We're trying hard to achieve a complete open development process on dev.zope.org [zope.org]. We call it the Fishbowl [zope.org]. It was started this year and so far has been quite successful. It is a way to open to the community not only the software but also the development process. Everyone has the opportunity to contribute at each phase.
Perhaps the most interesting part is the Proposals [zope.org] page. It allows anyone to contribute and discuss ideas for the development of Zope and related projects.
Some of the technology behind it, such as ZWiki [zope.org] and the CVS infrastructure, are not yet complete, but most don't see that as a barrier.
I think many open source projects would benefit from a similar methodology.
Re:Time for open source to grow up (Score:1)
Kaim (Score:1)
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.
Re:You Only Need An SRS If You Aren't The Customer (Score:2)
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.
Requirements Gathering ... (Score:2)
... 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 ...
Re: Commercial projects have requirements? (Score:2)
Re:Time for open source to grow up (Score:1)
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?
Open standards compliance is *the* requirement. (Score:2)
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.
Do you actually write code? (Score:1)
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.
Re:that has been..... (Score:1)
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.
Re:OSS UML Software (Score:1)
Re:Open standards compliance is *the* requirement. (Score:1)
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.
Stony.
One thing USENET is good for (Score:2)
This discussion can then move to IRC and mailing lists. However regular updates in news groups can keep attracting new blood and fresh information.
Re:One thing USENET is good for (Score:1)
Users could set a flag or a cookie if they think that those announcements are "noise".
My $0.02
Jehreg
Yeah, but.. (Score:1)
Requirements (Score:1)
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.
I think my sig says it best (Score:1)
A piece of software without a coherent purpose is like an airplane in flight without a pilot.
And, the current one:
Rapid Application Design (Score:2)
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.
Commercial projects have requirements? (Score:3)
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.
Re:Evolution Requirements/Feature Requests (Score:2)
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.
LetterRip
Tom M.
TomM@nospamPentstar.com
Simple itch implies many requirements (Score:3)
When people read these high level requirements they can immediately see a range of low level requirements. Different people will come up with slightly different versions of these requirements, but that is OK as long as the high level requirement is fulfilled. Analysis and design can proceed in an orderly fashion.
Because different people have different requirements the project isn't going to fulfil everybody's exact requirements. But thats OK, because anyone who wants the extra functionality can either add it themselves or get someone else to add it.
In contrast, in Cathedral projects the requirements document effectively becomes the contract you work to (and of course it frequently gets renegotiated). Whether you are producing the software for an independent customer on contract, or an internal customer as part of product development, your success as a software engineer is defined in terms of meeting the requirements. Open source projects do not have a need to determine whether the developers have "succeeded" or not, so they have less need of an exhaustive requirements document.
Paul.
Re:Engineers vs. Programmers (Score:2)
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.
Re: Commercial projects have requirements? (Score:4)
I have YET to be involved in a project that actually starts with the requirements gathering.
I just finished a four-year project to replace my newspaper's character-based publishing system with a WYSIWYG full-page layout solution. We spent eight months working on a Project Specification Document (PSD) before we laid down a single line of code.
The PSD was two volumes and over 700 pages. From the moment it was written, it was misleading, incomplete and, sometimes, downright inaccurate. Even with its problems, it was one of the best tools we had and I can't imagine doing a project of any size without a blueprint. That document kept us on track and often remided us of stuff we otherwise would have forgotten.
Yes, I did say of any size. For small projects, a line or two at the top of a script is enough. As the scope increases, so should the blueprint.
I wouldn't want a contractor to build my house without a plan but some folks do exactly that when it comes to their software. Specifications? We don't need to specifications.
Before I started my current job, my planning was half-hearted if done at all. I mocked people who would have meetings before starting a project. I felt that the time saved by not planning and by not holding meetings would more than cover any extra time needed to fix small screw-ups along the way.
The first few months I spent here were painful. meetings every day. Documentation all over the place. Very little 'work' actually getting done. Three years later, I have a lot more respect for doing things the right way.
The Open Source movement could greatly benefit from more Open Planning. Right now, for all our talk of openess, the organization is closed if not the source. Could you imagine how many more volunteers could get their hands dirty if there was a list of things that needed to be done and a roadmap as to how to get there?
InitZero
New sig is just as wrong as the old one (Score:2)
(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.
You Only Need An SRS If You Aren't The Customer (Score:5)
The purpose of a Software Requirements Specification is to enable the developers understand the customer's problem domain and learn what the needs of the customer are. Since most Open Source projects are written by the customer(s), it is usually redundant for them to create an SRS [gatech.edu] that describes the needs of the user.
Although an SRS is not truly necessary when creating a product where the developers are the customer it can still be beneficial for a variety of reasons including
Second Law of Blissful Ignorance
Re:New sig is just as wrong as the old one (Score:1)
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.