Re: Tip


"I.P. Nichols" <NoSpan@xxxxxxxx> escreveu na mensagem
news:474ad3e3$1@xxxxxxxxxxxxxxxxxxxxxxxxx
"Marco Sangali" wrote:
I didn't tak anything nearly like this.

OK, now I understand...

What I'm saying is that when they send me the requirements, they often
come with errors, incoherences, omissions, and that's because they tend
to think in their business in a less abstract and rigorous way than we do
to make a system to support their business.

Nor should they IMO.

Agree, and it was what I said in the first post. It's not their job.

What I do is go talk directly to the people who are
actually going to be affected by the software asking questions like, "Tell
me what you do and how you do it". Only after I can grasp how their
proceedures work to I begin a plan for how my software will be structured
to fit with in their framework.

I always try to do something like that, but not always I have access to
end-users; OTOH, I have had some cases where the person who would actually
use the system made a central requirement and changes his idea only when
they see it working on a prototype - many times just talking and explaining
doesn't work.


IMO it's the starting your software design without knowing the problem
which is the fault of the developer.


To me, it's the other way around - I start designing a protype to guarantee
I understand it, and then I evolve it. There are exceptions, of course, but
only when the requirements are very clear (i.e., interfaces to other
systems). When it comes to understanding requirements, I fully agree with
Fred Brooks in "No Silver Bullet", in which he states "I would go a step
further and assert that it is really impossible for a client, even working
with a software engineer, to specify completely, precisely, and correctly
the exact requirements of a modern software product before trying some
versions of the product."

Regards,
Marco



.

Relevant Pages

  • Re: Decouple SQL queries from class in OOP design
    ... >>> It should be separate from the business rules. ... > software design, and in particular of Object Oriented software design. ...
    (comp.object)
  • Re: Data Layer architecture
    ... software design, all underline one key software design rule: ... I am not thinking for every business layer class to have a corresponding data layer class and other crazy stuff. ... It is ugly and adds of bunchy of ugle sql code or procedures mixed up with business logic implemented in C#. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: how to run application(exe) in browser
    ... That might be a stranger to you, but I had to submit documents proving my ... business was established at the location I said it was. ... Joe Malware Hacker could not have gotten a certificate that said DC Software ... Software Design is trustworthy. ...
    (microsoft.public.vc.mfc)
  • Re: Spyware and Adware affect every internet user
    ... [Software Design] ... business. ... And the word was Content-type: text/plain ...
    (comp.security.misc)
Loading