From: James Robertson (james@systemsguild.com)
Date: Fri Apr 14 2000 - 17:24:38 EST
Hanania,
> The word requirement should have a broader scope than it usually has. I
> don't make a strict distinction between what was told by representatives of
> the user (or client) and what is included in the specifications provided by
> designers. I call everything that the software must accomplish -
> requirements. This includes also (but not only) the specifications of tiny
> internal subroutines.
What you say is undoubtedly true. Some people prefer to separate "system"
(ie. computer) requirements from user requirements. They do this to overcome
the problem of having users look on bemusedly at requirements that are
talking about internal subroutines, etc.
>
> What I can suggest, though, is to add each individual requirement-statement
> an attribute, which indicates whether an end-user can understand and observe
> it. For example, the return code of a subroutine fulfills a requirement
> specified by that subroutine's designer (and is implemented by the
> programmer) but the end user cannot see it. (Note that an end user, who has
> the capability to use a debugger or a driver for looking into the running
> code, by doing that, he or she is playing the role of a programmer, not of
> an end user.)
>
> Such an attribute is useful to filter only user-observable requirements in a
> test that will be run by an end user.
The end users are not the only people who have requirements. There are lots
of non-technical people (marketing, auditors, usability, etc) that have
demands on any product. They may not all be involved in testing. I think
that filtering only for end users is perhaps not enough.
I urge my clients to add the source to each requirement. That is, the name
of the person who originated the requirement. As all the stakeholders are
known to the project, it is easy enough to then separate requirements for
testing purposes.
James
________________________________________________
James Robertson
the Atlantic Systems Guild
james@systemsguild.com
http://www.systemsguild.com
Mastering the Requirements Process by Suzanne and James Robertson
foreword by Jerry Weinberg
published by Addison-Wesley
ISBN 0-201-36046-2
http://www.awl.com/cseng
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:25:10 EST