From: Andrew Gabb (agabb@tpgi.com.au)
Date: Mon Jan 19 2004 - 10:24:48 EST
I agree with Jim and Rita - defining H/M/L doesn't make much sense
without a lot more information - it depends on far too many factors.
One of these factors is process stability (and maturity). If your processes aren't defined and stable, and/or you're weak at RE, you're going to have to put up with a lot more volatility (and your volatility is going to be unpredictable too!). So your threshold for 'Low' may be much higher than those of a more mature organisation. Another is the process (and development model) itself - if you're working on relatively small projects (the stamping ground of most of the agile methods, BTW) volatility is more easily handled, so you're likely to put the levels higher.
Also if you analyse changes to requirements over time in real projects you are likely to see the nonsense of putting too much store in requirements metrics. At best they may be useful indicators, highlighting issues that need further perusal - at worst they are just numbers.
For example - and these are all very common siutations:
# A single reqt is replaced by 3 others (splitting) for reasons of clarification. Is this 1 change and 2 additions or 1 deletion and 3 additions.
# Reqts are merged, eg from local to global, resulting in 10 fewer reqts. Did the reqt count *really* change?
# The spec was reviewed by an RE spec expert resulting in massive changes in wording and structure.
# Typographical changes were made, to avoid possible misinterpretation, but there was no change of substance.
And these are just a few. Trying to cater for these different situations to make our numbers more relevant is difficult, time consuming and requires much more staff training and monitoring - there are few cases where it is likely to be cost effective.
I'm not saying that counting requirements is totally useless, particularly in a mature organisation with consistent processes - just that you have to know what you're doing and how to interpret the numbers. And this will vary on a project by project basis.
Trying to come up with general rules of thumb is worse than useless - some folks may actually believe it and tell the Process Police and Modern Managers. <g>
Andrew
Thomson, James (ANFIS) wrote:
> Folks,
>
> Thanks for your responses but, I'm beginning to lose the will to live with
> this board - it seems to be populated with obsessive theorists rather than
> practitioners. I'd not posted before because I had seen discussions descend
> into agonising over minutiae. All I'm looking for is someone to say - 'we
> use x, y and z'. If they seem ok-ish I can then use these to begin with and
> then adjust to reflect our situation.
>
> I'm sure you're trying to help but - not one person has attempted to answer
> the question. Instead I got (mostly) pontification ; does no-one actually do
> this for a living?
> Am I being objectionable? That's for you to decide - but take a look at some
> of your responses together with my response to them and you decide. If you
> recall I originally asked 'Trying to specify RV metrics and need to know
> what %age of requirements added, modified or deleted should be seen as
> 'High', 'Medium' and 'Low'.
>
> Here's a flavour of the responses and my response.
>
> '%ages depend on many things' - that's a bit of a stunner but rather than
> endlessly debate this I'd like to make a start, even if it's not perfect.
>
> 'I question why you want to use H, M or L at all' - this person then went
> onto give good examples of H, M and L in use!
>
> 'the reason you want use volatility metrics is to give you advance warning'
> - not at the moment it's not. We're a low-maturity company so, it's to
> quantify the scale of re-work we need to do because , at the moment, it's
> hidden and we need to make the business aware of it. It'll also indicate
> deficiencies in quality processes in 'previous' L/C phases
>
> 'not all projects have all requirements stated up front - that's what
> evolutionary methods are for' - thanks for that revelation but, each
> increment delivered needs to have a set of requirements stated up front,
> that's what we'll record changes against
>
> 'you don't need %ages at all' - %ages are used to provide a scale, a phase
> with 10 requirements and 10 changes is not the same as a phase with a 100
> requirements and 10 changes
>
> '%ages can be misleading' - I rest my case
>
>
> jim
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Jan 26 2004 - 09:01:34 EST