6

We elicit requirements from our product stakeholders by creating and refining user stories in monthly sprint planning meetings. This includes defining use cases, acceptance criteria, and identifying constraints, and the final result is a sprint backlog of user stories. The high-level customer requirements are refined into lower-level product requirements through design reviews among the development team throughout the sprint. The design reviews result in UML diagrams, software interfaces, and, in general, a human language description of various software requirements.

We are increasing our metric-awareness as an organization so that we can better identify potential areas of process improvement (and so that we can eventually be appraised at CMMI level 3).

What kind of useful metrics are there to collect in the elicitation and refinement of customer requirements?

Improve this question
0

2 Answers 2

Reset to default
2
  • How long you spend developing requirements. This is to see if the overhead is worth the benefit.
  • Average time to implement a requirement (requirements per hour or day). Some tasks are unavoidably complex, but in general, better-defined requirements don't take as long to implement.
  • How often requirements change between requirements development and the end of a feature's implementation. This measures both how well you understood the requirement and if you're breaking them down into small enough pieces.
  • Lag time between requirements development and start of implementation. This measures how well you're focusing on the most urgent needs.
Improve this answer
2
  • Thanks. This gives us some excellent starting points. Some of these metrics we were already collecting through our application life-cycle management software. I would like to expand on the second bullet point: If some requirements are low-level enough, I could imagine that in some cases it would be difficult (if not impossible) to differentiate the time spent on individual requirements. I could imagine collecting a different metric, such as the average number of requirements being implemented per hour.
    – David Kaczynski
    Commented Aug 14, 2012 at 17:28
  • That's a good point, and would account for the variability due to complexity as well. I'll edit that into my answer.
    – Karl Bielefeldt
    Commented Aug 14, 2012 at 17:31
3

It is hard to tell what metrics to collect for an unknown project with unknown goals. I would strongly recommend you to take a look at some kind of goal definition approach (such as GQM). Using this methodology you might come with metrics that best suit your needs.

Basically, GQM (goal, question, metric) defines a process where: you first define your measurement goals, those goals lead you to some questions, and those questions require metrics to be answered. So, in the end, you have metrics that really support your goals.

Hope it is helpful.

Improve this answer
1
  • I am trying to ask in general terms what kind of metrics could be collected for requirement development, not just for our project, but you bring up an excellent point in that the metrics to collect specifically depend on the goals of the project. Thank you, and I look forward to learning more about GQM.
    – David Kaczynski
    Commented Aug 14, 2012 at 20:05

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