X
Business

Borland’s virtual reality requirements simulator

You know that thing where developers complain about clients and requirements? I think it’s probably one of the most emotive areas of software application development in some ways; it’s the point at which I think we ought to be able to empathise with the difficulties associated with spiraling and possibly irrational client demands, project skew, application lifecycle management nightmares and the reality of coding black holes in general.
Written by Adrian Bridgwater, Contributor

You know that thing where developers complain about clients and requirements? I think it’s probably one of the most emotive areas of software application development in some ways; it’s the point at which I think we ought to be able to empathise with the difficulties associated with spiraling and possibly irrational client demands, project skew, application lifecycle management nightmares and the reality of coding black holes in general.

With this is mind, I’ve been in discussion with Borland this month over the company’s TeamDefine requirements simulation product that was recently launched back in May of this year. Claiming to be offer customers a glimpse of what a software product might look like and, more importantly, how it might function, before development even commences – Borland would no doubt love to see this new offering billed as some kind of project skew panacea. But the likelihood of that being so must surely be open to question.

Watching what the company describes as a quirky little YouTube product video is an interesting enough diversion I suppose, but remember – Borland no longer claims to focus on developers, instead it chooses to focus on, “The people who manage developers and the software delivery process in general.”

TeamDefine is apparently targeted at the business analyst. Although I never seem to meet these people, many vendors from the BI to the ALM space talk about them all the time. These are the people that are supposed to be able to use this kind of product to translate initial software project concepts into working models through storyboards and interactive simulations.

“Stakeholders can’t interact with textual documents and often can’t identify gaps or errors until they engage with working software in real time. The user experience – how the end user will interact with the software – is hard to understand when looking at requirements in the form of textual documentation.” (Source: Just Do It: Modernize Your Requirements Practices, Forrester Research, Inc., April 15, 2009)

I quote the above for passing interest – although I am slightly worried about any Forrester Research report that has to spell out what a user experience is, aren’t you?

Anyway, back to Borland, the company says that TeamDefine can render an interactive simulation that “shows” a requirement in a way that Microsoft Word documents can’t. The company argues that this will lead to more “dynamic” conversations, more valuable feedback and faster consensus between business and development teams.

Hmm, sounds like marketing speak to me. Personally I’d say that all my conversations are pretty dynamic. Is Borland telling me that I am dull?

OK I’m being snide, requirements is a huge issue. Helping customers bridge the gap that exists between what they think they want and what they ought to have is hard work. The product I’m talking about here is apparently a browser-based simulation authoring environment. It has been built to allow any team member to drag-and-drop screen elements and assemble connections to data and logic. The end result, hopefully, is a functional simulation of the proposed application.

I’m loath to quote corporate press statements too many times, but I quite like a snippet from this one. “Requirements definition is definitely a team sport here at Borland,” said Michael Klobe, development director at Borland. I don’t know - maybe I’ve been spending too much time in America, but I quite like that attitude.

However many automated requirements solutions Borland and others pump out - it won’t ever really fix the problem will it? I think it would be overly cynical to suggest that to try anyway is fruitless, so these tools must be of some use. Maybe we should just side with developers and say that it’s not the software that’s wrong, it’s the customers and their stupid requirements.

Don’t agree with me? Put that one down to ‘operator error’ then.

Editorial standards