Requirements, Woodpecker and Metrics

68408_f520

Every Software that we create is like creating a new Universe, with its own set of laws, just like we have the laws of Physics controlling our Universe. Though our Universe has been created with much finer, subtle and intelligent laws, which Human race is still trying to uncover.  However, not all the software inherit the characteristics of the physical Universe.

According to a survey by CIO.com

  • 49 percent projects suffer from budget overruns
  • 47 percent had higher than expected maintenance costs
  • 42 percent failed to deliver the expected business value and ROI

A very grim picture!!what could be the reason behind such poor stats for IT projects? Software unlike our universe, do not follow the laws of gravity, mass, electromagnetism etc. Hence the probability or likelihood for a software to move from a state of low entropy to higher entropy is very high in the absence of these laws of physics. Where as in other fields it’s not the case due to lot many things being governed by the laws of physics, for example while constructing a bridge, one can always calculate the kind of forces that will be acting on bridge, and design and construct it in a way that the structure is capable of handling all such type of stresses. However same is not the case with Software, in the digital universe its nearly impossible to ascertain the forces that will be acting on the software, this property allows the software to be constructed whichever way we want!!!! That’s the precise reason why even Gerald Wienberg has said, “If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization“.

Is there a way to control this high state of disorder in the Software World?

The answer is yes, thought we cannot eliminate it, but certainly it can be reduced to some extent.

One small way which i found helpful was establishing some control and measurements right at the start, at the requirements phase itself. According to a survey by Standish Group 80% of the issues in the project can be traced back to the requirements, most of the projects fail due to issues with the requirements. Here we are not going to discuss, as to how to effectively capture the requirements, there is a lot of good material already available on this subject (and some universities in Europe provide specialization in Requirements engineering), I’m talking about a way to measure them, not much literature exists on how to effectively measure the requirements. An effective requirement entropy control strategy should consist of both, a good requirement capturing mechanism along with a good requirement measurement process.

Here are some metrics which can be used, however, please note, you must develop some automated mechanism of capturing these, else it may become an overkill. A simple tool in an excel sheet will also do.

1) Requirement Stability = (Total Number of Requirements-No of New Requirements-No of modified requirements) /Total Number of Requirements

If this metric is between 0.8 and 1 it means that the requirements are highly stable, else they are unstable, great metric to showcase to customer, especially when you know that requirements have issues.

2) Requirement Ambiguity = Number of Unique requirements where all reviewers presented same interpretation/Total Number of Requirements

If this metric is between 0.8 and 1 it means that the requirements are clear in terms of what output is expected from the system, else they are ambiguous (reviewers should include business people who give the requirements, business analysts, build people etc)

3) Requirement Correctness = Number of correct Requirements/Total Number of Requirements

4) Requirement Consistency = Total number of requirements – Number of deterministic requirements/Total Number of requirements

This metric help us determine if all the requirements can be mapped to an output

These metric can definitely help reduce the entropy in the initial stages of the project, as soon as these metric start to turn yellow, proper alerting mechanisms can be put in place to highlight to relevant stakeholders in order to bring them back to green. This has not only helped me evaluate the overall requirement stability in many projects, but they also come handy when customers raise issues with Code, Quality, Cost of poor quality etc. Most of the code or quality issues always have a correlation with the way requirements were captured or documented. So next time when you are having a lessons learned presentation, a good idea is to start with requirements metrics, and then subsequent phases. Additionally its a good step to save the building from the first woodpecker also!!! :-)

References

http://www8.cs.umu.se/education/examina/Rapporter/JaveedAli.pdf

http://www.sersc.org/journals/IJSEIA/vol6_no1_2012/2.pdf

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress | Designed by: search engine optimization company | Thanks to seo service, seo companies and internet marketing company