On Tuesday 04 May 2010, Philip Potter wrote: > On 3 May 2010 22:06, Harry Putnam <rea...@newsguy.com> wrote: > > That is the kind of `always true' thing one might say. I forgot what > > the term is but it means its fairly meaningless and mainly sounds > > good. But none the less true. > > A tautology? No, it's not. I'm saying you can either do requirements > analysis or you can skip it, but if you skip it you haven't got a > criterion for success. You won't know what you're trying to do or when > you've done it. If you do requirements analysis, you define what you > want to do up front. You know what you're trying to do it and you'll > know when you've done it.
I think it's necessary to have a clear idea of what should be done and how. It applies to each program, whether small or big. It consists of preparing a design and writing a flow chart (not necessary on paper, but in our mind). This would help us getting the program done in a faster and proper way. I thought everyone would be doing the same. Is that not the case? Eventhough I think it's not necessary to post the goal of one's program here, I think he should state clearly what he wants to do as it will help both parties (those who seek help and those who help) and eventually the resolution would be faster. -- Regards, Akhthar Parvez K http://Tips.SysAdminGUIDE.COM UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity - Dennie Richie -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/