By: Philip Howard, Research Director - Data Management, Bloor Research
Published: 25th July 2013
Copyright Bloor Research © 2013
One of the interesting things about being an analyst is about discovering holes. By that, I don't mean anything to do with golf, but technology holes: places where there are gaps in the market. With hindsight, for example, it is easy to see that there was a glaring hole in the data warehousing market before Netezza and its appliance-based imitators stepped into the breach. There was a similar hole in the spreadsheet management market before the likes of Cluster Seven and Prodiance (now part of Microsoft) came to market. Well, I think I've discovered another such hole though, in this case, it has yet to be filled.
We all know that the biggest cause of failed IT projects is what used to be known as "specification mismatch" - the gap between what the user wanted and what IT delivered. And, of course, it's primarily caused by the fact that the relevant people don't speak the same language and, generally, think in different ways (for example, business entities versus tables). There are lots of products that have business glossaries and other such capabilities, but these are really only skirting around the edge of the problem. The real issue lies with the requirements themselves: how do you capture these in such a way that they can be easily understood by both the business users who are commissioning the project and the IT department that has to implement it? And then, how do you ensure that your requirements are actually what gets implemented?
Well, there are answers to those questions. Sort of. You can implement requirements management. According to Wikipedia this is "the process of documenting, analysing, tracking, prioritising and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform." The problem with these products is that they are large, complex and expensive. Not that they don't do what it says on the tin but they represent pretty heavyweight solutions that will be most suitable for very large and/or complex projects.
The alternative approach is typically to use Visio, Word and PowerPoint. This is a bit better than drawing by hand on a whiteboard but it's hardly high-tech: it's very much a low-end solution. On the other hand, it's about all that's available if you aren't prepared to go in for the significant investment involved in requirements management.
So, here's where the hole is: it must be possible to create a product that can capture requirements and detail how they should be fulfilled, which can be understood by both technical and business users, and represents a genuine automation of this process rather than an automation of white-boarding without going to the extremes of a full-blown requirements management system. Such an application probably needs to be based on some sort of flow charting, but just supporting flow charting (you can do that in Visio) won't be enough.
I think such a product can and should be created and I'll be returning to what such an offering might look like in a further article.
Posted: 26th July 2013 | By Herman Driessen :
Thanks for raising this issue! It is certainly not easy. It reminds me of a verse " what is lacking can not be counted" (Eccl 1:14-15). It is certainly challenging!
Here are a few suggestions:
1) when requirements have a poor word like "many" in its text, then we have found a hole.
2) when requirements have a word like "may" in the text, then we might have hit a (hidden) option, that may or may not be part of the scope.
3) when we hit a plural like "messages", without stating how may messages, or how many types of messages, then we may have hit a hole. We need to clarify these potential holes in a requirements review session.
4. When we would hit for example the word "sensor" in a requirement then our curiosity should be tweeked. Are attributes of this sensor addressed in the requirements? (like its location, its sensitivity, its accuracy?, its performance)
These and more considerations started the development of "Requirements Assistant" (RA), while I was working at Hughes Aircraft Company. It uses text as input, ( natural language).
For more information: www.requirementsassistant.nl or www.emphasysgrp.com/requirementsassistant.
Not done yet! We are still improving RA! Looking forward to more ideas on addressing completeness, or holes.
Hope this helps the discussion.
The messages above were all contributed by IT-Director.com readers. Whilst we take care to remove any posts deemed inappropriate, we can take no responsibility for these comments. If you would like a comment removed please contact our editorial team.
All fields must be completed to submit a comment. Email addresses are passed through to the author so they can contact you directly if needed.
Published by: IT Analysis Communications Ltd.
T: +44 (0)190 888 0760 | F: +44 (0)190 888 0761