As software development teams become increasingly distributed and global, gathering requirements for a project can be challenging, but a Toronto-based company launched on Monday a software designed to overcome that hurdle.
Blueprint Software Systems Inc. released Blueprint Requirements Center 2010, which replaces its predecessor, Requirements Center 2009, for managing the requirements process with more than 100 new features.
Challenges faced by requirements authors, typically business analysts and project managers, are driven at a business level by factors like mergers and acquisitions – prevalent today – and globalization, said the company’s vice-president of product marketing, Tony Higgins.
In turn, this means the IT department must be agile and find ways to support distributed software development and outsourcing arrangements, and integrate applications coming out of these mergers and acquisitions.
“Requirements have always been the bane of software development throughout the years, there’s no end of statistics that point to requirements as the weak link in software development projects,” said Higgins.
Typically, requirements authors will resort to legal-type text documents, “one of the poorest forms of communicating,” according to Higgins. That is complicated by distributed teams with members of different cultures and backgrounds, he added.
Among the new functionality is a business process diagramming capability so requirements authors can understand the business processes they are trying to automate in the software they are building. “We can sketch up business processes very quickly, very easily, to make sure everybody is on the same page,” said Higgins.
Another feature tracks changes so users can compare two versions of sets of requirements, and automatically output that into document form “as if someone had authored those documents manually,” he said.
According to Howard Kiewe, senior research analyst with London, Ont.-based Info-Tech Research Group Ltd., requirements gathering can definitely get complex given the fact that stakeholders and developer teams are often distributed, and perhaps coupled with an outsourced or offshore component.
That said, the process of requirements gathering has always been challenging given that projects can morph within the length of the development cycle, noted Kiewe. The tedious chore of maintaining records to date often falls to the wayside, he said, “and they get stale… and start to lose their value.”
“For that reason, a good requirements management tool is something that can maintain the requirements in an active and updated state with as little effort as possible,” he said.
Specifically, requirements can change as a result of a narrower project scope, or external market pressures on the organization, explained Kiewe. Certainly, he added, any team with more than 10 members will probably look to automate the process.
However, Kiewe pointed out that organizations looking to adopt a software to manage requirements gathering should consider whether the overhead needed to purchase and maintain the tool does not outweighed the benefits. “That’s where you really have to look at each one and see if it fits in with your business process or your development process,” he said.
