From: @dishwasher1.mpce.mq.edu.au
Date: Wed Feb 23 2000 - 14:36:42 EST
Ian Alexander wrote:
>To be specific, item (1) is not requiring a fresh new ability from the
>system administrator ('The SA=20shall become capable of a new skill in
>statistics handling') but is coming from that role:
> Actor: Activity: =20 Constraints: Acceptance Criteri=
on:
> SA enable/disable statistics < 5 seconds=3F (show that it work=
s)
>You might feel that this way of organising the User Reqt might be less
>ambiguous than
>a shall-sentence in English, and I might agree with you, but there are lots
>of people out
>there who like their textual reqts as they are, and why not - the
>convention is well established.
I agree with this point of view. After all people will use our systems, so=
they
are the source of=20the requirements. Removing the user (and the usability
constraints) from the requirements can be very dangerous. There are a lot=
of
systems out there having the necessary functionality but providing it in su=
ch
an akward way, this functionality becomes unusable. A functional requirement
becomes verifyable within a task context. The response time of the system=
is
only part of the story. The time needed to accomplish a task is what matters
(and the systems response time is part of this elapsed time).
A=20system may well have the needed funtionality but if this system is not
supporting the task of the user (to be effictive and efficient), the system
will fail and become worthless.
Incorporating requirements in such a way is not telling anything about the=
look
and feel of the userinterface but is telling a lot about how the system wil=
l be
used, so they are not UserInterface Raquirements but genuine requirements=
to
make the ystem usable.
Rik Manhaeve
hendrik.manhaeve.708@b-rail.be
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:25:09 EST