Source: Click
Successfully addressing requirements management from a more iterative approach requires aligning business with IT; open communication is key
The process of capturing and tracking project requirements for application development projects directly affects the success of those projects. With better project management and better understanding of projects than ever before, only about 18 percent of projects fail today, according to The Standish Group International, which has been tracking the reasons behind project failure for more than 20 years. Requirements management tools have evolved, and the industry is much healthier today. Indeed, the key to more successful projects is aligning IT and business goals through business requirements management.
It wasn’t that long ago that the waterfall method of application development was believed to be the best way to develop applications — with very detailed, deep requirements that were frozen in place so engineers could work on achieving them. But by the time software engineers presented their results, 18 months or so later, the requirements would have changed, and the new product invariably needed an immediate upgrade.
In the past five years or so, the waterfall method has given way to more agile development methods — smaller development teams and shorter project timeframes, for instance, not to mention capturing requirements and getting them to engineering more quickly, building prototypes, and changing requirements as necessary throughout the process.
This iterative approach to software development focuses on a feedback group and the chunking of larger projects into smaller pieces. Organizations generally don’t want to be as document-intensive as they once were. As a result, they have become more user-centric.
“Rather than create a specification that’s 3,000 pages long, [organizations] want to sit down with businesspeople and find out what they want the process to do,” explains Mike Burba, founder and CEO of Software as a Service (SaaS) startup DevHive, and former head of marketing for Compuware’s application development tool line. Companies are looking to do things in a more structured way. And requirements management tools offer a feasible way to do exactly that.
“Managing requirements is a big part of successful projects,” notes Jim Johnson, chairman of The Standish Group. But, he cautions, “Just keeping track of requirements doesn’t make you a successful project.”
Making Decisions
Take this example, for instance: Your company has 4,000 different feature requests for one product. You keep those feature requests in approximately 55 Microsoft Excel spreadsheets. Some features are difficult. Some take more work than others. Some could take a year to complete. Customers call every morning to see if you’re going to include their particular requirements. What do you do?
It’s impossible to please everyone, so how do you determine whose requirements to include and whose to put off? One of the most significant causes of project failure is poor coordination between business requirements identified by the business and what’s understood by development teams creating the software, according to Melinda Ballou, a program director for research firm IDC.
Unfortunately, traditional requirements management tools don’t guarantee that the requirements you wanted going into a project are what you really need. That reality has given rise to requirements definition tools, or requirements development tools, such as those from iRise, Blueprint Software Systems, Axure Software Solutions, Compuware, and Serena Software, that offer visualization and simulation of requirements so developers have something physical and visual to point to.
“In the new requirements management world, these tools are not only making sure that what’s specified is delivered, but on the front end are making sure that you specify the right thing,” explains Rene Bellei, president of Ryma Technology Solutions.
Validating that a requirement is valid is of utter importance. “If requirements management tools want to help organizations reach their highest level — which is anticipating future requirements — then these tools need to be able to validate all the inputs in a way that helps an organization anticipate what future requirements are going to be needed,” Bellei says. “These tools need to have strong information distribution mechanisms and collaboration mechanisms.”
Aligning Business and IT
“We’re seeing a great deal more interaction between IT and business,” DevHive’s Burba notes. “The idea is the tools facilitate the process of capturing requirements in a user-centric way.”
Story boards and use cases, for example, are some modern ways for businesspeople to write and talk about a process in a structured way. “That structure is important to make sure there are no misunderstandings, omissions, and so forth,” Burba adds.
The key here is the process of getting the requirements in line with both the business and IT. “If you can maintain a small scope and inner process, you have a much better chance of success,” notes The Standish Group’s Johnson.
Requirements management tools don’t directly help projects succeed, but they do facilitate the requirements gathering process and make it more effective. These tools, for example, capture the business processes that need to be automated and then provide for writing something that can be picked up by a developer and referenced as the software is being developed.
Changing Roles
“Products that allow for communication between business analysts and IT that in fact let them see what is being generated are quite alluring, and there tends to be better uptake for that,” IDC’s Ballou notes. “There has to be better communication and collaboration between business and technologists who create the software.”
In addition, the role of the business analyst needs to be elevated. “Sometimes people put in those roles are the ones that didn’t cut it as developers,” says DevHive’s Burba. “Companies that do well (with requirements management) make that role of business analyst a prestigious role.” The business analyst should act as a guardian of the requirements throughout a project, staying involved from conception to completion.
It comes down to this: Who’s managing the requirements — product management or software engineering? Traditionally, requirements management has been viewed as a software engineering job. “For companies wanting to be agile, product management has to have the bigger role,” notes Dave McCann, CEO of startup company Electronic Evidence Discovery (EED) Inc.
Ryma Technology Solutions offers a requirements management tool for product managers that helps organizations anticipate requirements instead of simply react to them. The company’s flagship product, FeaturePlan, captures market feedback and tracks it through the requirements management process. It lists new requirements as they’re entered, existing requirements as they’re changed, and estimates for market requirements as they’re requested from development.
Ranking Requirements
McCann turned to FeaturePlan while serving as senior vice president of FileNet Corp. (which IBM acquired in October 2006), when he realized that the organization’s requirements process was out of date. “We were using a 1990s process in the Internet world,” he notes.
Since McCann joined FileNet from Telelogic, he assumed his team would choose Telelogic DOORS for the company’s requirements management needs. After scanning the marketplace, however, his team determined that DOORS and IBM Rational RequisitePro had been surpassed, and that nothing could beat FeaturePlan, he says. “It’s a much better and modern offering for requirements management in the Internet era.”
Because FileNet’s customers were requesting requirements on a faster basis and using e-mail to bring those requirements in to the company, “FeaturePlan won hands down,” McCann says, largely because of the product’s more modern, lightweight, easy-to-use, intuitive model. “FeaturePlan spans both the want-to-use-it-once-in-awhile user and the product manager, helping you do feature ranking.” Once that’s done, the product allows for feeding the resulting data back into the engineering group.
One feature that stood out for McCann is the product’s capability to apply a sales flag to the features his development team is not going to include in the next product release. Customers want to be kept abreast of what the company is and is not going to include in the next release of a product. FeaturePlan, McCann explains, has “some good ranking abilities that are useful for allowing us to do ranking and then to publish the status of the features we’re not doing and what we are doing in this release.” This way, he adds, “we can give the customer a straight answer.”
The key here is communication. Not only can poor communication cost hours of time, but it can also be expensive — $5 to $10 million a year, McCann says. When he was at FileNet, McCann had 55 product managers and product staff, as well as 150 staff in the field — all of whom wanted to have input into requirements. The company was spending $80 million a year on development and $20 million a year on marketing and was looking to gain a 2- to 3-percent increase on efficiency on that. By improving communication through the use of FeaturePlan, “we gained way more,” McCann notes.
Having some kind of requirements rating system is vital to managing requirements so they make sense, according to The Standish Group’s Johnson. A rating system will help an organization determine if a certain requirement is risky or not and whether or not it offers business gain.
Accept Software and Telelogic offer products with capabilities similar to those of FeaturePlan. Accept 360 degrees’° Ideation module lets users capture, evaluate, and prioritize ideas and product requirements in a single system that can link ideas to business strategies. Telelogic DOORS, through integration with its Focal Point Web-based decision-making tool, provides for prioritization, decision-making and visualization of requirements. Although Telelogic’s user interface for some of its requirements management products is a bit dated, the company intends to address that in upcoming product releases, according to research firm Butler Group.
Taking Steps
To stay competitive, other software vendors are going to have to make similar moves. “Society is moving at such a fast pace with technology that it shifts rapidly every five to seven years,” EED’s McCann says. Some of the requirements management tools out there haven’t changed much in the past 14 years.
“We’re delivering products faster and faster,” says The Standish Group’s Johnson. “We’ve created a velocity like we’ve never seen before… because we’ve learned how to do it better.”
Despite that, Ryma’s Bellei points out, “It’s not about doing more projects faster and better; it’s about doing the right projects.” He encourages organizations to “focus on a smaller amount of projects that bring a higher return on investment.”
Other steps organizations can take to better their requirements management initiatives include understanding requirements in the context of quality, evaluating and adopting business requirements tools that map to the need of an IT organization, and ensuring that key business stakeholders are available to communicate requirements. “It’s impossible to generate requirements if key stakeholders aren’t around to communicate that and people have to engage in guesswork,” IDC’s Ballou points out.
Looking Ahead
The next thing that’s going to happen, according to DevHive’s Burba, is that requirements will become the foundation of project management. “We’re already seeing a move toward this,” he says. “What they don’t do is start with requirements or link back to requirements that were driving the project … . One of the real problems of projects is getting early warning indicators. If you’re not tracking the amount of requirements that are getting done, you don’t really know.”
Another important aspect that needs to be addressed is security. “There is a pressing need for effective processes that encompass areas like security up front, because of vulnerabilities and the impact on businesses of better practices, from a performance perspective,” Ballou says.
She expects to see a convergence of virtualization and more graphical and intuitive gathering of requirements. In addition, she believes developers will start to tap into social networking — something along the lines of MySpace or Google Groups — to improve communication. “I think [social networking] can play a role in IT and development to increase collaboration,” she explains. She also anticipates closer integration and leverage between requirements and other lifecycle management phases, such as testing.
Because IT organizations are growing and not shrinking, they are having to consider more stakeholders. “The amount of requirements and the amount of information that these organizations will have to deal with is phenomenal. Without proper tools, it cannot be done effectively,” says Ryma’s Bellei.
He further believes that the future will be driven by the requirements of IT organizations. “The needs and problems are going to become more and more complex because of the size and distributed trend that this comes with,” he explains. “Requirements management tools will have to evolve to help companies manage the amount of projects.”
One of the keys moving forward, according to The Standish Group’s Johnson, is not to be afraid of failure, because failure in software content really promotes changes that are good. “Unless you have a number of failures,” he says, “you’re not going to have any successes.” As Thomas Edison said, “Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.”
IBM’s acquisition of Telelogic last year is just one interesting development in the requirements management realm. Now, IBM owns Telelogic DOORS as well as Rational RequisitePro — two major contenders that have been vying for market leadership. “The irony is that the No. 1 and No. 2 players have both been acquired by IBM, and there’s a lot of overlap between products,” notes EED’s McCann. Watch what happens there, and keep an eye open to see if Microsoft makes a move into the requirements management arena
