The BABOK has just been made available on Google Books.  Good on the IIBA for promoting the business analyst role by making such a great resource available for all!

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.

I’m speaking on Tuesday about the role of the Business Analyst in realising organisational benefits from projects and programmes of work.

Should be a good conference and a great opportunity for BA’s in Brisbane to get together and network.

If you haven’t signed up for the conference yet drop me a line on the contact page to help you get a two for one rate for delegates.

Who is the Surfing Analyst?  I am a practicing business analyst working for 10fifteen as a senior partner.  Our business is about helping both individuals and businesses better perform business analysis.   My job is wide ranging and exciting as I have opportunities to provide consulting to customers as well as training to fellow practitioners.  Through my work I’m exposed to the challenges of both sides of the customer supplier relationship.  Customers tell me what they want (or should that be ‘what they demand’) from their business analysts and fellow practitioners share with me the at the coal face issues. Needless to say the customers and suppliers don’t always see eye to eye.

Times are rapidly changing the world of business analysis.  Strangely late compared to other roles in information technology, it is only now being professionalised.  Certification has been the norm for a while in many of the other information technology roles, and is only starting to gain traction now for business analysis in the minds of customers and practitioners.   I think the lag in the professionalism of the practice is mainly due to issues of ambiguous definition of the role ‘Business Analyst’.

As an activity in training, I ask delegates to come up with their own definition of a business analyst.  The responses range from ‘technical writer’, to ‘financial guru’ through to ‘customer facing developer’.  Whilst I don’t think any of these definitions is wrong, it does illustrate that the business analyst is some kind of chimera beast that is both an amalgam of many elements as well as being its own unique beast.

The growth of professional organisations such as the International Institute of Business Analysis (IIBA) has definitely progressed thinking on what it means to be a business analyst.  In my mind, the impact of definition cannot be under estimated in terms of solving fundamental problems which I think stem from the customer supplier engagement.   I can feel the topic for my second post forming in my mind right now.

What I would like to do with this blog is to share my experiences working as a business analyst as well as to invite relevant topics for discussion with you, the reader.  Unfortunately, this is one way conversation at the moment until I get the comment system working.  In the meantime I do encourage you to contact me via the 10fifteen contact page.

And yes, the Surfing Analyst does surf!  Not often enough but as time and travel permits.  I’m eying up an exquisite 9′10″ long board as the next acquisition for the quiver. I’ll keep you posted!