At the 12th Australian Workshop on Requirements Engineering in Sydney, I had the pleasure of attending several interesting sessions which I’ll write about over the next couple of weeks.
The thorny issue of managing the complexity of requirements relationships was tackled in a session by Tor Stålhane from the Norwegian University of Science and Technology.
One of the core principals of managing requirements is to record the relationships between requirements to support impact analysis activities and traceability through the different requirements packages. The types of relationships that the Business Analysis Body of Knowledge (BABOK) identifies are necessity, effort, subset, cover and value. Probably the most familiar type of relationship is that of necessity. This is where there is an implementation relationship between requirements whereby if one requirement is to be implemented, the other requirements are also to be implemented. For example, the necessity relationship typically exists between a stakeholder requirement and many solution requirements.
In practice the situation becomes very complex very quickly. When you embark on recording relationships, the emerging network of requirement relationships become highly connected. You will find that virtually every requirement is related to every other requirement which diminishes any value of the network that has been painstakingly built when undertaking impact analysis. If your impact analysis tells you that every solution requirement is impacted by a change in a stakeholder requirement, you have no real basis to prioritise further elicitation and requirements analysis work or to identify areas of risk.
In my experience, tool support has been poor and the maintenance effort very high to maintain these networks to produce results of little practical value in a project context. To make things worse becuase the networks are hard to maintain they easily become out of date which further diminishes their usefulness for impact analysis.
Tor et al. propose using automation during software development to create centrality measures on the network so that key requirements can be weighted and effectively stand out from the crowd. The idea of centrality measures isn’t new in the field of network analysis, but I found the approach novel in that relationships and the centrality measure was generated by software developers viewing use cases through the software development workbench.
The simple idea is that the workbench builds the network of relationships between use cases and code by recording the interaction of the developer with use cases and the code objects such as a classes or methods. That is to say, the network is built by observation which can be automated by the workbench rather than from static analysis which requires a human. In the talk, the example was given for a project where an Eclipse plug-in monitored how each developer in a project used the use case documentation to build the requirements network.
Weighting can be used based on the type of interaction. For example, a creation event for a new class may be weighted higher than an update event. The use of weighting recognises the importance of the different types of inspections that occurs over a project life cycle.
I thought this approach shows great promise for mapping solution requirements to the solution components as it’s driven by the actual process of the solution building. Solution tools have now have reached the level of maturity where the tools model the solution and are adaptable through plug-ins to record transacted behavioral use. For example, source code check in and check out events and what method was being edited when the use case was inspected.
The challenge I see is applying this approach for non-solution requirements where probably the most common tool-sets for requirements management are spreadsheets or word processors. There is no simple or elegant way using a word processor to record what stakeholder requirements were inspected when drafting the solution requirements. Difficult, but not impossible.
If you’re interested to know more about this, look for the paper titled Uncovering information centres in requirements traceability networks by Inah Omoronyia, Guttorm Sindre and Tor Stålhane from the Department of Computer and Information Science, Norwegian University of Science and Technology, Trondheim Norway.
