X
Business

Requirements gap: real or perceived?

I used to be involved with the Australian media tech scene and it’s an interesting place from a software perspective. Being as geographically and temporally separated as they are, the country is a perfect microcosm for English speaking technologies to be tested prior to roll out (and I understand Vista was trialed down under in just such as way).
Written by Adrian Bridgwater, Contributor

I used to be involved with the Australian media tech scene and it’s an interesting place from a software perspective. Being as geographically and temporally separated as they are, the country is a perfect microcosm for English speaking technologies to be tested prior to roll out (and I understand Vista was trialed down under in just such as way). Keep your opinions to yourself on that one I think.

That said, the Aussies are fiercely proud of their own home grown software successes. So, hitting my inbox overnight I see news from an enterprise modeling software provider called Holocentric, who has released the first (so they say) business process modeling solution specifically built for system requirements & fulfillment.

This technology is supposed to bridge the "requirements gap" (their words, not mine) between business people and IT systems providers. But hang on, that’s what the requirements process is in the first place isn’t it? It’s about existing in the gap and forming the bridge or indeed bridges.

Rather than focus on satisfying a list of requirements - the approach taken by traditional requirements management solutions - Holocentric says their product focuses on satisfying desired business outcomes through business process modeling. They say that employing a visual model to capture peoples’ roles and derive requirements produces more effective results… and that requirements based upon roles lead to higher quality user acceptance, testing and implementations.

OK OK I buy that to some degree, but any developer worth their salt will argue that you can’t define all requirements within a system based upon roles – there has to be rules too. There will always be some general system level requirements for core functionality that are based upon rules right?

Also, I think you could argue that roles are ‘implied’ in accurately managed requirements and that the requirements themselves by their nature define functions that support roles in the business. But this point could get too conceptual and cyclical if we go any further.

Either way – I guess it’s a case of MIND THE GAP. Sorry, couldn’t resist.

Editorial standards