Requirements management: Changing paradigms
December 20, 2012 —
(Page 1 of 5)
Related Search Term(s): Borland, cloud iRise, Jama, Polarion, requirements, Seapine, TechnoSolutions
In this new paradigm of cloud computing, mobile software development and agile distributed teams, it’s more challenging than ever before for software development teams to manage requirements. These days, organizations maintain Web apps, desktop apps and mobile apps. Business logic often overlaps in each. But due to their specific nature, each type of app can come with its own set of requirements. Also, each can present development teams with certain pressures regarding how to collect and maintain requirements.
Sometimes these are the same pressures, but they can be different depending on the type of app. “Business rules—the statements or facts by which businesses run—are universally the same for a business regardless of the platform on which the application is being developed,” said Ashu Potnis, vice president of product management and technology at requirements definition and management tool provider TechnoSolutions. “What differs is the user interface and system behavior. However, copying requirements and business rules into multiple projects is a not a good idea because now you have the same business rules in multiple places. They quickly go out of sync with each other.”
According to experts, the pressure that these individual application teams are experiencing is really around visibility. “There is an overlap that occurs,” said Derwyn Harris, cofounder and solutions architect at Jama Software, which specializes in requirements management.
“The fact that I’m building for mobile or for the Web or for the desktop doesn’t really change my process. It’s still going to require the standard process that we go through to define requirements and build out stories if we’re agile. The approach is fairly universal. There isn’t necessarily a different pressure on these different types of applications.”
The pressure of collecting and maintaining requirements really comes, Harris said, when an organization is trying to maintain these different applications in parallel. “So, at that point in time, the pressure is really more about how do we stay in alignment to ensure that we’re taking advantage of functionality that all of these applications utilize,” he said. “So it really comes down to visibility—ensuring that all the different teams have visibility into what the other teams are working on.”
Harris said that development team members can use a requirements management tool such as Jama Contour’s Review Center to send a set of requirements to both the team and stakeholders to review and provide feedback so that everyone stays on the same page.
For all types of apps, missed and misunderstood requirements are often two of the major issues when it comes to product and/or project requirements. “These two problems tend to get exacerbated with distributed teams,” Potnis said. “Also, with the fast iterative process of agile teams, requirements become front and center. In fact, each agile iteration is started by first selecting the user stories or use-case scenarios to be accomplished in that iteration. And user stories and use-case scenarios are, essentially, requirements.”