|
When I work on a "project" (something "large", usually),
I discuss requirement (I try to rephrase requirements in my own
language, and ensure that the client understands my rephrased
version - chances are, I may catch some subtleties this way)
I stop discussing when I have enough of the "big picture" to
understand what the client needs. (even if it's in-house, it
does not matter)
Then I design and plan. I show the results of my planning
to the client.
Sometimes, the client says "it's too expensive - it takes too long".
Then I discuss requirements again, outlining alternatives. "we could
have a basic print in version 1.0 and have all the other options for
printing in next release".
I re-iterate until the client accepts my terms (It will cost $ XX.YY
and or it will be ready YYYY MM DD)
Sometimes, I cheat. When I have to make planning on things that I am
not familiar with, I make a quick and dirty "test app" to get aquinted
with a concept as a programmer, givving me a better idea of how long
it could take to program. (often, I guess. I never spend as long as half
a day for things like that). I don't call that "prototyping", maybe
I should. I never show these to my boss - client. Its just a proof of
concept for myself.
I usually have more design to do after the planning is accepted by
my client (aka boss). I quickly jump in to the code. I usually wait
until an important feature works for real before showing it to
anyone.
|
|
|
|
|
Sure in a perfect world, we'd have all our requirements before we designed and coded. But something usually comes up that our design just can't quite handle, and at least some part needs to be refactored.
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
Get a list of requirements, prioritise them, start designing, then code, 2 weeks later throw code away as user didnt know what they really needed, go round this loop until another job appears on the horizon 
|
|
|
|
|
Okay, it's true some customers are too lazy to properly think out exactly what they want, but supposing in an ideal world where they go to great effort to specify what they want, you will still get at least a few new requirements during development. This is because it's simply impossible to forsee everything ahead of time. Your development process has to be flexable enough to handle this.
|
|
|
|
|
Navin wrote:
we'd have all our requirements before we designed and coded
 I have always seen that the reqirements change from meeting to meeting and I design my applications with this in mind. Sometimes its a game trying to predict what the new change will be and already have the ability (maybe even a partial implementation) to add it to the application without much effort.
John
|
|
|
|
|
John M. Drescher wrote:
I have always seen that the reqirements change from meeting to meeting and I design my applications with this in mind.
Good, its all about second guessing the clients||designer, if a non programming analyst is involved they must be second guessed as well.
Regardz
Colin J Davies
* WARNING *
This could be addictive
The minion's version of "Catch ![Green Alien | [Alien]](https://codeproject.freetls.fastly.net/script/Forums/Images/alien.gif) "
It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
|
|
|
|
|
John M. Drescher wrote:
I have always seen that the reqirements change from meeting to meeting
Surely this is a project management issue not a coding issue.
You should not have agreed to take on a project until a contract (even a verbal agreement is a contract of sorts, but written is better) has been decided on of what you will deliver and how much you or your department will get paid. If the customer changes their mind then it is a change request that will come at a cost.
The customer will soon learn that it is more effective to get it right the first time...;P
|
|
|
|
|
J.B wrote:
The customer will soon learn that it is more effective to get it right the first time...
... or to find programmers who are willing to cope with changes in requirements.
|
|
|
|
|
Nemanja Trifunovic wrote:
or to find programmers who are willing to cope with changes in requirements.
Who will perpetually chase these requirements and go over budget and over-time. But oh yes it is an IT project so that is just normal...
|
|
|
|
|
Nemanja Trifunovic wrote:
or to find programmers who are willing to cope with changes in requirements
Good thing I am a very easy going person and fit very well into this category...
John
|
|
|
|
|
<<if the="" customer="" changes="" their="" mind="" then="" it="" is="" a="" change="" request="" that="" will="" come="" at="" cost.="">>
Ah, if only it were so easy. And I *totally* agree with you! However, you'd find yourself hard pressed for customers if you pulled that stunt too many times. Why? Because there are companies out there that will take a loss to gain business - therefore, so must your company - lest word of mouth eventually drive your customer base away toward your competiters. It sucks but that's what happens often enough.
|
|
|
|
|
Yes you are correct, but this is called managing the customer and most importantly their expectations.
It only takes one alternative competitor who cannot 'deliver' to wake them up realizing that although you lay down hard rules, you will deliver on your promises.
|
|
|
|
|
True, enough! 
Let's hope my company's management learns this.
|
|
|
|
|
I voted for #2, but prioritizing a list of requirements is hardly sufficient groundwork for a design, if I want to get more than a few hours into design before needing to re-assess what the hell we're trying to do. A "list" is just my first stage of requirements gathering. Then come wire diagrams and use cases (depending on the project), and iterations on versions of those simple docs, involving meetings and emails and cubicle visits. I think this is what smart people call requirements analysis, I'm not sure. But I do know it is amazing when you write out the details of "obvious" requirements (like how the login page should work) and suddenly big issues pop up -- usually from those people who originally thought the whole project was simple and obvious. I like it when this happens, especially if I haven't even opened Visual Studio yet.
Brad Williams
|
|
|
|
|
it should have been "Get requirements, design, code, repeat as necessary"
Of course, the processes has to be re-iterative. There's no way you can forsee everything. Some issues only occur when you start implementing, although there shouldn't be too many big changes
|
|
|
|
|
... it is necessary to start a new project. Sometimes problems can be solved without starting a new project and battles can be won without actually fighting the enemy. 
|
|
|
|
|
...you can tell the customers to look for another company. Thats the best way to get rid of projects... 
|
|
|
|
|
and a whole lot of ££££
I am that is
|
|
|
|
|
|
Hey Norm, how are you. I've been looking for a calendar control for like 2 weeks now and I finally came across yours. My problem is that i dont know c/c++ so i dont understand the code. I was wondering if you could email me the already compiled ocx/dll control..? If it's possible, please do so to diegohb14@hotmail.com. I appreciate your time and help.
Diego
|
|
|
|
|
Have you seen the price of eggs lately?
i.e. Some of us do projects for a living where the client is not the enemy but actually the people who buy our eggs.
regards,
Paul Watson
Bluegrass
South Africa
Christopher Duncan quoted:
"...that would require my explaining Einstein's Fear of Relatives"
Crikey! ain't life grand?
Einstein says...
|
|
|
|
|
Paul Watson wrote:
Have you seen the price of eggs lately?
Einstein says the price of egg equals the number of consultants it takes to lay the egg times the number of new egg projects.
|
|
|
|
|
Anonymously wrote:
Sometimes problems can be solved without starting a new project and battles can be won without actually fighting the enemy.
That's all well and good if you are part of an inhouse development team, but for those of us who make our living from providing software solutions to problems a new project is a good thing.
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
Michael P Butler wrote:
... you are part of an inhouse development team ...
How do you know?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
