Re: Just one more anecdote

From: Hugo Kornelis <hugo_at_pe_NO_rFact.in_SPAM_fo>
Date: Sat, 06 Aug 2005 17:07:16 +0200
Message-ID: <lfj9f199hmn8ikup31e6h5g28togi1tv8p_at_4ax.com>


On Sat, 06 Aug 2005 09:30:02 -0400, Kenneth Downs wrote:

(snip)
>Of course the big advantage to bringing up the tough arguments is your
>position is strengthened by disagreement - some will find weak spots you
>can shore up and others will find hidden strengths.

Hi Kenneth,

Agreed - if you amend it to read "your position is strengthened, OR you learn something new". But there's a gain in both cases.

I've been over that for the storing of derived data, at other times and in other places. I didn't want to bring it up now, because a discussion over the merits of storing derived data would distract from the actual discussion we were having.

(snip)
>There is probably an entire sub-thread just on this topic, people who think
>in terms of forms.
>
>I once had a customer who thought entirely in terms of the paper forms he
>handled, one particular form more than most. This was the form that he
>used to bill, so it was crucial to him. I noticed he conducted all
>conversation in terms of the form. This was a government form, of course.
>
>Once I realized that I stopped talking tables and spoke to him in terms of
>the form. Nevertheless, I was still translating everything he said into
>table design.
>
>Is this similar to the examples you are giving?

Yeah. Save I don't reserve this approach for people who have trouble thinking in other terms than forms; I use iit as standard. Everything I need to know from end users, I ask in the form of concrete example, using realistic data in the form that the user is most used to (often, but not always, a form).

(snip)
>> - The NIAM methods are the best methods I've seen so far for extracting
>> user requirements and business constraints (for the data model only;
>> processes are unfortunately not covered by NIAM). The same methods can
>> be used with other diagramming techniques, of course - but the NIAM
>> diagram has the closest match to the NIAM mehods.
>
>OK.
>
>How do you handle processes? How do you related processes and automation,
>if at all?

The NIAM method as published has a chapter on processes. I guess that the proposed method is in theory very good and error-proof. But in practice, it's plain useless. So I don't use it.

One of the things I am working on is the development of a method for analysis of processes and automation that adheres to the same basic principles that form the foundation of NIAM, but that will also be actually usable in practice.

First results appear to be promising. But (before you ask) I can't reveal any details yet.

>> - I am used to it :)
>
>Authoritative!

Ain't that the truth!

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)
Received on Sat Aug 06 2005 - 17:07:16 CEST

Original text of this message