Re: Good Guidelines and examples of Good Stakeholder Requests and Product Features

Major,

> "The ability to provide an Encounter identity to the telephony System
> and/or to hold a voice recording identity against each recording
> associated with an encounter."

I have a few remarks on the form of the above sentence.

- First, the sentence no verb.

- Second, "and/or". Does that mean "and" or does that mean "or" ? Does
it mean "and or or" ?

- I'm generally suspicious of any requirement (or request) that calls
for "the ability to". (The worst cases I've come across were of the
form, "The ability to extend system functionality through plugins":
disguised attempts at dictating architecture.)

- *Who* has the ability ? *Who* provides an encounter identity ?

- The word "encounter" appears once with a capital E, once without.

These are matters of form, and it may seem to someone who knows the
domain and the technology well that "it's obvious" what the above means.
But the reason requirements should be written, specific and so on is
that wat *seems* obvious to one person... is rarely so to many others.
The above sentence has too much ambiguity to be a useful statement of
requirements.

I'm only guessing, because I understand little of it, but it looks like
it would be better written as a definition: telling what an Encounter
is, who cares about these things and why.

A good reference, by the way, on avoiding ambiguity in requirements is
"Exploring Requirements: Quality Before Design" by G.M. Weinberg and D.
Gause.


Next, about "guidelines":

> 1. There should never be more than 99 product features for a particular
> module or product;

This strikes me as completely arbitrary. What happens when we reach 100?
Is the project sure to fail ? (Or do we just need to use one extra digit
for numbering, which may indeed be a problem if we have hardcoded every
reference to the "feature" data structure to be a two-digit field...)

> 3. They should be written from the point of view of the system

Maybe, if you take "the system" to mean: "the software, the users of the
software, and everything that affects the interactions between those
elements".

If you mean the *software* system, that strikes me as actively harmful.
"The system" never does anything on its own; it only ever responds to
events that have a human origin, or produces some output directly or
indirectly intended for human consumption. It's not entitled to a point
of view.

Feature descriptions should reference *who* is using a feature and
*what* results are expected. (For instance, in mini-scenario format, and
hoping I've not misunderstood too horribly: "The administrator assigns a
queue to a role. Afterwards, any agent who is a member of that role may
pick up a call from that queue.")

> 4. They should not be written in terms of the solution, or design in
> mind [that is they should not pre-empt a design, or particular
> solution]

Well, a feature *is* a solution. Trying too hard to avoid framing a
feature description in terms of the solution space may result in
awkward, ambiguous language. The above is a sensible concern, though.

> 5. They should not contain too much detail, not too much technicality,
> so they can be clearly be understood by the business, or marketing

There's a difference between "detail" and "technicality". Include as
much detail as necessary, no more - but no technical detail, as that is
a matter of implementation.

> I guess one question is: who is the real audience for the stakeholder
> requests, and the product features? Marketing, or Development?

Perhaps you need to ask the people who wrote them ? (I'm not sure I
understand the question...)

Laurent
.

Relevant Pages

  • [4E] PBH Sneak Preview
    ... Swap any (Encounter Attack, Utility, Daily) Power you have for one of equal or lower level from your chosen Multi-Class. ... they get an ability that kicks in and last the last of the encounter that adds +2 spd and I believe + dmg ... Gnomes. ...
    (rec.games.frp.dnd)
  • Re: Windows 2000 and Word Versions - Compatibility
    ... It never seemed to affect my ability to work. ... which is when that feature has been useful. ... Word MVP web site http://word.mvps.org ... What do you mean by "automatic file save feature"? ...
    (microsoft.public.word.docmanagement)
  • Re: fixed duration projects
    ... feature of Project is its ability to predict the impact of management ... Project is its ability to predict the outcome of MY decisions on how I ... Adding resources will not always shorten the duration - pregnancy ... Fixed duration works well for this ...
    (microsoft.public.project)
  • Re: Hows dot.net doing nowadays?
    ... Actually there are feature more important than others if you look at ... The ability to combined subroutines with the data ... The feature that gives the most trouble is Lisp ability to ... the database engine but Lisp can do it within the language itself. ...
    (microsoft.public.vb.general.discussion)
  • Re: Hows dot.net doing nowadays?
    ... Actually there are feature more important than others if you look at ... The ability to combined subroutines with the data ... you can also do a google search using vb6 unit testing. ... the database engine but Lisp can do it within the language itself. ...
    (microsoft.public.vb.general.discussion)