0

I would like to measure requirement volatility but the problem is that our specification is not consistent in size of requirements. Sometimes, one requirement describes a whole workflow. Sometimes it just states X=10. Would it make sense to still count them and track changes? Actually with those big requirements, the volatility will be higher (5 changes to 1 large requirement, which could be 5 changes to 5 requirements). So maybe it could help to visualize lack of granularity?

Improve this question

3 Answers 3

Reset to default
1

Right now I guess you know nothing (but perhaps have some hunch that there is a lot of volatility) - so any measurements you make will be an improvement. Unless you have lots of capacity to do a complex data capture / analysis, just do something simple -- and you will learn something, even if it is not 100% accurate.

To get started quickly and cheaply, I would recommend just counting changes per requirement, even if they do not all match in size. After a reasonable period of time if it turns out that the largest requirements have the most changes (which would not be a surprise) and you are struggling to infer anything from the data then you can think about whether it is worth putting a bit more refinement into it: the next refinement step might be to "T-shirt size" requirements, then you can look at stats for (say) the L and XL requirements and compare that to overall stats or for the M and S requirements.

You could then create some sort of "requirement volatility index" where you multiply number of changes by the requirement "size" (1, 2, 5, 10 for S, M, L, XL perhaps) and sum the products -- it won't be 100% spot-on but it will give you some visibility of the issue and it will be cheap.

Improve this answer
1

Break the requirements down.

5 changes to 1 large requirement, which could be 5 changes to 5 requirements

You specify yourself an example of a big requirement made of 5 smaller requirements... so why not just treat it as 5 requirements?

Try to follow the INVEST mnemonic when creating/tracking requirements.

Improve this answer
6
  • Well, these are not our requirement, those are provided by customers.
    – John V
    Oct 9, 2018 at 15:44
  • 1
    @JohnV And? Is there some reason you can't then slice up those requirements (either on your own or collaboratively)?
    – Sarov
    Oct 9, 2018 at 15:53
  • We are talking about real world, you cannot do that for free or on your own account...
    – John V
    Oct 10, 2018 at 6:40
  • 1
    @JohnV "on your own account" - I disagree. What does the client care about how you visualize/deconstruct requirements, as long as their requirements get done? You can always track them separately, if necessary, and record that 'Story 27 is part of Requirement 8'. "cannot do that for free" - True, but the same can be said for measuring. By that logic, since you can't measure velocity for free, why bother?
    – Sarov
    Oct 10, 2018 at 13:10
  • 1
    @JohnV If a lot of effort is needed to understand a requirement enough to split it, then you absolutely must put in that effort anyway because working on requirements that are completely not understood is not a good place to be...
    – Sarov
    Oct 12, 2018 at 15:40
0

I would start with a visual analysis. Bin the requirements by size (tshirt or similar), then plot (x=size, y=Nchanges) for each requirement.

The resulting plot will convey any interesting or surprising trends, and you can figure out how to reduce it to scalars if you need to do a more quantitative analysis.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.