I blogged a while back in Document dependencies, traceability and Impact Analysis – tales from the front line about dependencies within and across documents and how classic traceability matrix approaches fall short in two key aspects; maintainability of the trace matrix when reacting to changing doc content and secondly the challenge with medium to larger projects/programs where a substantial volume of content exists & simply visualizing relationships in a matrix is a serious challenge.
Concept Lists
We introduced ‘Concepts Lists’ in version 2.0 of VisibleThread, it went GA (General Availability) last May. One of the capabilities that Concept Lists were originally intended for; was for the list to hold explicit names of sub-system components and interfaces. The intent being to support identification of dependencies between sub-systems, by scanning the document for items mentioned within the concept list. We are seeing this use case being borne out. It is helping impact analysis by tracing across unstructured documents for touch-points. It is allowing quick validation for consistency, helping analysts conclude whether there is adequate rules coverage in the docs. This is only one of a number of usage scenarios where concept lists add considerable discovery value.
Simulation
So, this week I had a very interesting new use case for concept lists crop up; ‘simulation’. Let me explain: working with a customer, they suggested leveraging Concept Lists to identify evidence of the need for simulation in unstructured documentation. For those who may not be aware, simulating systems is a good way to help communicate ‘strawman’ concepts/working prototypes and validate possible solutions to the business, where there is a reasonably heavy element of user interface present. Vendors such as iRise and Axure among others have been offering good tooling in this space for a number of years.
Typically the people doing simulations of this type have to scan extensive documents, mostly BRDs and simulate based on the content of such docs to help arrive at the simulation itself. They may also frequently have to update the BRD as a consequence of ‘discovery’ during the simulation process. Simulations can be a double edged sword in many instances, in that the audience often is lulled into the sense that the ‘actual’ system exists and so what Alistair Cockburn once referred to as ‘prototypitas’ (effectively a spiral of never ending iterations of a prototype rather than the ‘real’ system) may occur. But I digress and may well blog on that syndrome in a separate post.
Regardless, it is essential that the simulation tallies with the BRD and identifies all of the business rules from the BRD without guesswork, it is also essential that any discovery from the simulated system is reflected back into the BRD. So, in the use case we’re talking about here, the concept list actually comprises items such as ‘page’, ‘flow’, ‘display’, ‘webpage’ etc. (outlined in the graphic above). This particular customer, has a simulation team that is introduced for projects that embody a substantial amount of user interface interaction. So, a judgment is made as part of the analysis process, as to whether they are involved and to what extent.
The key thing that the simulation team needs when engaged, is to understand what business rules will affect simulated flows and the touch points. So in effect, they are scanning for evidence of content that might affect the simulation. By being able to quickly scan a sometimes large set of business rules documents (including a BRD) for all aspects (as itemized above), looking for mentions of ‘page’ etc. it means a far speedier process of identifying considerations for the simulation. This also makes gaps in specifications more easily identifiable especially in larger sets of docs.
Overall, using automation in this fashion with VT leads to a far more systematic, comprehensive & more efficient approach rather than the manual alternative. It also helps to keep the simulation ‘honest’, in other words not violating subtle business rules that may be buried in a doc, be it a BRD or elsewhere. Conversely the BRD when it needs to be updated as a result of discovery during simulation can easily be adjusted since we know the touch points.
On the whole, a very interesting week where a great new use case around concept lists was revealed.
