For very many years, IT professionals have tried to attain a certain degree of software reuse. The idea is simple – if you can reuse, then you can build “better, faster, cheaper“, and in so doing benefit from greater efficiency. One of the large drivers that has helped to reach this is the Open Source community that openly shares small and large projects and in several cases entire systems. Evidence of this success is all around us, almost to our own detriment where ‘custom software’ now looks comparatively expensive!
But in the analysis field, the reuse of requirements is still very limited. There are countless cases where the same functionality is re-specified and re-planned from scratch, and the end result in many cases is quite similar. How many more times must I define and draw up requirements relating to security??!! 90% of it is the same each time. Within the microcosm that I work, there is an element of reusing requirements and sharing between colleagues, but it typically doesn’t extend much further.
Yuri Cherna (USA) has recently published his results on this topic, and the findings are interesting. It shows that 93% of respondents believe that requirements reuse is important but very few people are actively doing this. The main drivers that respondents cite as to why reuse is important are … no surprise here … cost reduction, reduced life-cycle times and better quality. But the biggest hurdle preventing greater reuse seems to be culture and the way we work. Most teams are just not geared towards effective reuse – they don’t have the correct structures and processes in place, sharing between teams is often stifled due to office politics, and there’s typically no driving incentive to innovate or become more efficient.
With changing times, and tighter budgets, analysts need to come together (and management needs to come to the party as well) to create an ecosystem that favors reuse and rewards innovation – without these drivers we’ll simply not be able to keep up.
