|
Typically its the marketing department, or the business development department and it is called requirements gathering. The deliverable form here is usually something like an MRD (Marketing Requirements Document) or a BRD (Business Requirements Document) that says 'there is a market opportunity that needs to be filled and if we are to do the work to fill it we need a product in the market by this date that had features x, y, and z).
|
|
|
|
|
Fascinating.
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
I voted for "Continuously during the lifetime of the project"
I write specs as I need them (ie, I have to show them to someone) because I'm a single developper, so all my projects are small.
My methodolgy for project management, is an accelerated form of "code'n'fix". Except I know what the project's goal is, which isn't always the case with regular "code'n'fix".
For starters, I talk to the person who asked something to my manager, with a notebook and a pen, to figure out what they need.
Once I'm sick of talking to them, I go to my office and start coding. Once in a while, a question comes up, so I pick up the phone or send an e-mail (depending on how urgent and complicated the question is, and how clueless the "client" is). After a couple weeks (or a couple days), I submit a program. They say it matches exactly what they need. After a couple tries using it, they call back asking for some changes, and here we go again.
Yeah, I guess that should mean there's not much specs in the end, but before I call the project "finished", I always write a Word document explaining why I made the project and how to use it. And I add in the appendix some emails and some drawings just to pretend there was some planning involved. That's the closest to specs I'll ever produce for that project.
And I actually think that it's not that bad, at least for small projects where there's no communication between developpers involved
"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra
|
|
|
|
|
What is a small project. Every time I hear that somebody wants me to work on a small project, I turn and run. Most times the small projects take up all your time.
Hogan
|
|
|
|
|
To me, a small project is 1 week or less. You're right in that it makes one more project for me to maintain (bug fix, change request, and all that), but I'm lucky enough not to suffer too much from scope creep. JUST KIDDING! Of course there's scope creep. I just try to ignore it.
"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra
|
|
|
|
|
right hogan..
usually small projects are planned to be over in lesser than a month but alas! they do not....
Ashish Sehajpal
|
|
|
|
|
Quoted For Truth
"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra
|
|
|
|
|
No plan survives first contact with the enemy. - Helmuth von Moltke
Not having a spec means not having to change the spec.
No project is ever truly complete.
Specs aren't written by the people who have to implement them and know they won't work.
|
|
|
|
|
That's fine if you are billing hourly. If you're doing a fixed price bid you need all the little details hammered out ahead of time.
When a change comes along from there you write an addendum to the original spec and get paid for that too.
|
|
|
|
|
Addendums can become bigger than the original as scope has a nasty habit of changing.
Ask the low bidder on a government contract. 
|
|
|
|
|
thrakazog wrote: fixed price bid
Those are for suckers. 
I've never yet met a situation where "all the little details" could be "hammered out ahead of time"; all have required a delightfuil amount of R&D... that's where the fun is.
If you have time to hammer out all the little details, you might as well just write the darn thing.
|
|
|
|
|
PIEBALDconsult wrote: Those are for suckers.
Agreed.
However fixed price bidding is a requirement from some of our customers. Some places want to know exactly what things are going to cost them so they can work it into the budget. So if we want the work we have to play the game. There are times when we do end up with a fair amount developed before the plan is agreed to. Those are the risks of business I guess.
|
|
|
|
|
it says it all... and as long as i don't want the client to tell me a dev is not what he was expecting, i write specs first, make them approved, then code. since then, every scope change is a change request...
|
|
|
|
|
toxcct wrote: i write specs first, make them approved, then code.
I dont know your area of work, but how can the customers know what they want when they are not able to do it in the first place?
Here, we write software for the interpretaion of data generated by complicated measurements. We need an interative sceme with much R&D (on both sides) in between.
The (maybe company internal) customers requirement is "In need that data visualized.". I visualize it.
The customer says "I need another visualisation like $THAT, but different. And I need to access $THOSE data for comparison."
We dont want to write fixed specs, impement them and then notice how the customer can not possibly use our software.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
jhwurmbach wrote: I dont know your area of work, but how can the customers know what they want when they are not able to do it in the first place?
because that's exactly what i working for.
i'm not a software "editor". My compagny produces unit software, that is, a single order for a software that is supposed to fit a business gap...
so I believe they (the client) know better than us (the developers) their business.
That's the functional specs, and there a rarely problems to have them validated.
for the Technical design, as you say, the client say "i want something like $THAT". it's where our job is important in advising the client in what the technical part will met their need.
once each part is ok with the specs, they are officially validated, and then developers can start working...
|
|
|
|
|
OK - thats probably a whole different market from the R&D-driven engeneering we do here.
So you are closely modeling the things the customer is ATM doing with "pen & paper".
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
|
It also means that there is no definition of when the work is done. 
Dale Thompson
|
|
|
|
|
Which is correct.
|
|
|
|
|
Not having a spec means you do all the work yourself. Since there's no spec, nobody can help you.
Not having a spec means you get into arguments with the client about what they said and what you heard.
Not having a spec means your team forgets what they're actually trying to accomplish.
Not having a spec means your team forgets the decisions graph that lead up to the requirement and its design.
Specs are written so that other people can write unit tests and acceptance tests against the specs.
Specs are written to figure out what needs further specs.
Specs are written so that everyone involved in the business can make sure that the spec works for their particular work process.
and so forth.
Marc
|
|
|
|
|
The Before-Design specs come from the users - and as a rule, they rarely know what they're talking about.
In this respect, it's on par with forcasting the weather for one's vacation in 2012. The only thing you can be sure of is that there will be some.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
And even then, it's nearly impossible to capture all the changes, and more importantly, the reasons for those changes!
Marc
|
|
|
|
|
Reasons?? We don't need no stinkin' reasons to change the specs 
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Or to change the specs back to how it was in the initial design! 
|
|
|
|
|
Chris Maunder wrote: We don't need no stinkin' reasons to change the specs
' ' just about sums it up
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
