[AccessD] Use Cases

If you really want to go down this road, Dan (and I recommend it), then it
goes like this:

1. Use Cases
2. Functional Specs
3. Module algorithms

(approximately)

Any given Use Case can use other Use Cases (i.e. Use Case: Delete Parent
Record involves Use Case "Delete all child rows first", and perhaps also
"write deleted rows to an audit trail table). Then Use Case "Recover from
dumb-ass delete" involves recovering from the audit trail and reconstituting
said row(s).

Regarding tools that can do this automatically, Rational is probably the
finest. Download a trial and then copy its formats, and if your firm cannot
afford the price, then copy the outputs and turn them into templates and go
from there. This is a cheap and sleazy alternative, to be sure. Far better
to convince yourself or your contractee to bite the price and then you have
a beautifully integrated solution.

It all begins with Use Cases. That leads to Functional Specs. That leads to
Module Algorithms (which exactly parallel Func Specs and by Inheritance Use
Cases). Specify what the software should do (Use Cases). Then write the
FuncSpecs for each Use Case. Then write the description of each algorithm
required to deliver a given Func Spec.

This may seem overkill for trivial apps (less than 20 tables), but I don't
care. What I care about is verifiable sign-offs: If the software does what
is required, then pay me (a crude way of phrasing it, but that's the bottom
line). If it fails to deliver what was required, then I'm back in the
woodshed making it work.

There are two issues here, and I recognize this. One is, Does it do what was
required? The second is, Does it do it elegantly? These MUST be
distinguished, IMO. Suppose that my solution involves four keystrokes and
some typing, while the user wants one keystroke and no typing. The point is
that the software works, whether it takes one or twenty keystrokes. The rest
of the discussion concerns UI, which can always be simplified, but the point
is that it works. We can clean up the UI later: the immediate point is
correctness. Once that point is achieved, then we can think about how to
make it cleaner and smoother.

All this is strictly IMO, of course.

Arthur

On 12/7/07, Dan Waters <dwaters at usinternet.com> wrote:
>
> Use Cases!
>
> Hi Arthur - Just yesterday I introduce use cases to a customer for the
> first
> time (for me!).  This looks like a good path to get what users what
> accurately and quickly.
>
> Any thoughts or advice on using this tool?  An resources you could
> recommend?
>
> Thanks!
> Dan
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
> Sent: Friday, December 07, 2007 4:29 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] field limit in forms
>
> You reminded me of an app I wrote for KPMG (at that time called Peat
> Markwick), a fancy accounting firm in Canada. I wrote it and tested it and
> delivered it and the first thing the boss did was a Cecil-Taylor style
> "hit
> a hundred keys with your forearm", crashing his entire forearm upon the
> keyboard. Literally! He banged down on the keyboard with his forearm,
> hitting a few dozen keys simultaneously or if not simultaneously, then at
> pretty close proximity). The app exploded, and he glanced askance at me,
> implying that I was at fault for not anticipating this. I had the temerity
> to ask, "How many alcoholics work for you?" This was an incorrect play.
> You
> live, you laugh, you love, you learn (as another Canadian called Allanis
> Morrisette might phrase it). Now I have a clause in my contracts, which
> says
> "No amount of intelligence can anticipate the extent of users' stupidity."
>
> I don't care what users want to do. I care what the specifications of the
> job require. I work from Use Cases, and if the Users go beyond the
> documented and agreed upon Use Cases, then all bets are off. The
> alternative
> is, what if the user randomly crunches his forearm down in the middle of a
> "File Save As" operation. I will not write code to defend against such
> atrocities unless paid by the hour to do so, and even then, I'll quickly
> get
> bored and abandon the operation. Even Microsoft doesn't defend against
> this.
> For example, in the middle of a "Save As" operation, you happen to hit
> Ctrl+Alt+Delete and then terminate the app. Is this my fault? If you think
> so and can defend against it, you're a far better programmer than I, and I
> will therefore retire and refer all my clients to you.
>
> A.
>
> On 12/7/07, Drew Wutka <DWUTKA at marlow.com> wrote:
> >
> > She must live in Fantasyland, the mythical world where uses do what you
> > want them too, not what they want to do....
> >
> > ;)
> >
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>