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.”
#!
See the requirements, act on the requirements
In general, the solution to the requirements issue, according to Potnis, is to communicate them using visual techniques. Use less text and more diagrams, screen mockups and application simulation to get your point across. “Our TopTeam Analyst, for example, helps business analysts and requirements engineers by automatically converting textual requirements into activity diagrams and flow charts, as well as providing a full complement of visual tools,” he said. Some of TopTeam Analyst’s visual tools include screen mockups, application walkthroughs and simulations, and business-process modeling.
With TopTeam Analyst, Potnis said users are able to create project branches similar to the branching process that is common to source-code control systems. Along with branching, he said users can also share the same requirements and business rules into different projects and thus avoid duplication.
Whether developers are creating Web apps, desktop apps or mobile apps, speed and time-to-market are the biggest pressures they face when trying to collect and maintain requirements. “The biggest challenge right now that’s facing companies—big, small, public, private, government, ourselves, our peers, all companies in every country that we work in—the No. 1 issue facing them today is time to market,” said Pete DuPre, chief solutions architect at development toolmaker Borland, a Micro Focus company. “When you break that down into the different types of apps that they’re trying to commercialize, the need for speed in the tools and the processes that they’re using is the number one challenge facing teams today.”
DuPre said that the dynamics of mobile, social and cloud are driving the need for organizations to change and react more rapidly to incoming changes from the business. “For the requirements definition and management troops in every one of these organizations, the challenge is how are they going to collect daily change requests, respond to them, and manage all of those requirements,” he said.
What the mobile, social and what DuPre calls the “post-PC era” has caused is the need for organizations to put the requirements elicitation, definition, and management processes and technologies under the microscope, he said. “Organizations need to ask themselves if they have the processes, tools, partnerships and the expertise that they need for their organization to be able to react to changing requirements and changing market dynamics as fast as the consumers who are typically using these Web and mobile apps,” he said.
Companies can use a requirements-management tool such as Borland’s Caliber to make sure they can react quickly to satisfy their business users as fast as those requirement changes come in.
When it comes to Web, desktop and mobile app requirements management, the “obvious consequence of maintaining different variants in requirements, specifications and codebases is an increased development complexity and cost,” said Stefano Rizzo, VP of strategy and business development at Polarion (an ALM software provider). “But, besides increasing complexity of requirements and specifications, mobile apps imply an even shorter requirements and specification life cycle. The time that a requirement lives before being involved in a change process is shorter than ever.”
The challenge that software teams need to face, Rizzo said, is in maintaining reliable traceability throughout the application life cycle—from requirement to specification to test to code—in order to quickly analyze the impact of a change and be instantly ready in make the change happen.
Another big challenge to collecting and maintaining Web, desktop and mobile app requirements stems from the fact that apps tend to have different development schedules and timelines. “Even though they have these often overlapping requirements, they’re often working on their own heartbeat and their own really different schedule,” said Jeff Amfahr, director of product management at Seapine. “So keeping those in sync can be pretty tough. Having some ability to manage requirements that you might have implemented on some platforms and not on others—which will affect all of them—is a big challenge that we see often.”
#!
Amfahr said that a lot of times, different types of apps have development teams who are working off really different methodologies and approaches. Supporting those different approaches and styles is another big challenge he sees organizations facing.
“Where sometimes the desktop application team is following maybe a waterfall or a modified iterative process—and they’re pretty happy with that and they’re cranking along on that—you’ve then got the mobile teams using some Scrum approach,” he said. “So they want user stories and the Web team wants more flushed-out requirements. So, again, although they may be the same requirements, the way they want to see them and the way they want to interact with them can be pretty different.”
A good requirements-management tool should let teams link a lot of different things together that are related but may not be exactly the same thing. It should let teams automatically flag related requirements when they need to be updated. Amfahr said that Seapine’s TestTrack RM tool gives all the teams the ability to share requirements with one another, as well as provide support for linking things.
“Again, it might be the same requirement, but the desktop team needs a lot more detail about how it’s going to be working, whereas the mobile team wants that broken into six very small user stories because they’re going to be releasing this over three separate releases,” Amfahr said. “Although it’s the same big requirement, you’ve got these six small ones the mobile team’s working on. So the tool has really good support for linking those things so people can know this is all related to each other, so, as things change, all those things can be updated.”
One of the biggest challenges of managing requirements for mobile app development is the context in which those apps are used. “You’re not developing or designing an app for a user who is sitting at a desk,” said Peter Indelicato, senior product manager iRise (a visualization software company). “You could be defining and developing an app for a doctor who’s running through a crowded hallway in a hospital, for example, trying to type something onto an iPhone or an iPad while they’re being bumped, shoved and yelled at by patients and other doctors.”
The context for the usage presents interesting challenges when it comes to managing requirements, Indelicato said, because those requirements that come out of that contextual usage are tougher to find than your typical requirements. This is because you’re not talking about a situation that most developers are familiar with, which is somebody sitting at a desk.
“For a doctor running through a hallway, there might be some very important requirements about the size of the controls on the iPhone app or the text size, for example, because he’s reading it while he’s running,” he said. “Those types of requirements rarely come up when you’re reading a textual use case in a meeting room or if you’re looking at some static mockups up on a projector. Those types of requirements don’t come up because you’re out of context.”
What’s critical and challenging for business analysts, designers and product owners to be able to do, Indelicato said, is to run the simulation on the device itself, meaning on the actual iPhone so that the end user (the doctor in this case) can get the most realistic experience possible. “And by realistic, I don’t just mean the app that’s on the phone. I mean actually using it in the environment that the end application is intended to be used in,” he said.
“One of the key ways to satisfying requirements, in the case of developing mobile apps, is to take the simulation, run it actually on the device, and then give that device to one of your intended users to see them use it in the context of that mobile environment. And of course they give you feedback, you observe what works and what doesn’t, and then you iterate.”
Indelicato said that one of the components within the iRise Enterprise Platform is a tool called iRise Mobile. The tool lets you run your simulations on the device itself, for example, on an iPhone or an iPad.
#!
Requirements in a cloud world
Cloud development and agile development allow for much faster updates to software. No longer do teams need 18-month development cycles to collect requirements and build out apps. Feedback to apps is also received much faster now. These new paradigms affect how often requirements are collected and how they are addressed in various ways.
Mastering short iterations and being able to successfully collect customer feedback are two key success factors for development teams, according to Polarion’s Rizzo. “Cloud-based apps and mobile apps reach an increasingly larger number of users,” he said. “Beside providing tools to their users that allow an easier communication between users and developers, development teams are now starting to worry about the ‘Big Feedback’ problem.”
Customers and their feedback must be part of the development environment, Rizzo said. Customer feedback must be collected and analyzed in the same platform where requirements and development artifacts reside. “Modern ALM platforms such as Polarion Requirements allow feedback and change-request population by users directly into developers’ backlogs,” he said. “This is where they can be analyzed, evaluated, selected and implemented.”
The quicker development cycles of cloud and agile development now require faster review and approval cycles, TechnoSolutions’ Potnis said. By using TopTeam Analyst, he said users are able to create review packages and send small sets of requirements for review via TopTeam’s Online Review and Approvals system. “Users can also request digital signatures via TopTeam Analyst,” he said. “This avoids having to author large, monolithic business requirements documents or product requirements documents.”
With cloud and agile development, the requirements collection phase often overlaps with ongoing development, which is a big change from the traditional way when developers had a lot of time to get the requirements, collect feedback and validate those requirements via storyboarding and other approaches. “I think the big change is that you now need to gather that feedback based on sometimes the actual software or small pieces of the software, small parts of the requirement that somebody has,” said Seapine’s Amfahr. “Making the right parts of the requirements visible to the customer, the end user, or whoever is in the stakeholder role there, is pretty critical. Again, in the past, you sort of got them all, everyone agreed to it, and then you went off and worked on it. Now you’re exposing more of that in the middle.”
#!
Get feedback from everywhere
It’s also important that business stakeholders are brought into the process smoothly so that the quick, iterative style of development seen in cloud and agile development can be maintained. “This is critical. Stakeholders should and must be involved,” said Jama’s Harris. “It’s ironic that this is a problem because, really, the Agile Manifesto was not so much saying we need Scrum or we need Extreme Programming or we need a new methodology. It was saying that we need a new mindset around how we interact with the stakeholders and how we get the software out there.”
Stakeholders can be given access to a development team’s requirements-management tool such as Jama’s Contour. “There’s flexibility built into the solution. Certainly, in the best-case scenario, you want your stakeholders to be able to simply log in, and they can do that in Contour,” Harris said. He added that stakeholders can see a project, as well as what stories have been built and what requirements those are tied to. It all depends on how much visibility the development team wants to give them.
Making stakeholders aware of the process and giving them a chance to see it in order to help re-prioritize things as you’re going along is the value of the shorter cycles in cloud and agile development. But, according to Amfahr, it’s not just about letting stakeholders see the requirements, it’s about letting them see everything about the requirement, which includes the cost of changes. This lets them help the development teams to make better decisions around what to do.
“Visibility of the requirements throughout the application life cycle is critical,” Amfahr said. “It’s about letting [stakeholders] see things like, how big are these requirements? What’s the cost of these requirements? What’s the cost of the other things that go with it so they can have a better conversation around them?”
Customers often now use Facebook, Twitter or other social-media sites to mention problems they have encountered with apps. Because of this, it is vital for organizations to monitor social media to make sure that any problems about a user’s experience with an app aren’t missed. “This is absolutely and unconditionally important. An organization that doesn’t have active and proactive monitoring of the social network has its head in the sand,” said Borland’s DuPre. “If you’re not doing it, then get out of the way because your competitors are going to go right through you. It is a head-in-the-sand, novice mentality not to do so.”
As with any discipline, social reputation is important in application development, Rizzo said, and the practices about how to filter and evaluate social feedback are the same as they are in other fields of human activities. “But the key difference is that, once filtered and selected feedback is collected, we have to put it properly into the development life cycle,” Rizzo said. “As social media lives on mobile, cloud and Web platforms, it will be very important for developers to use requirements-management platforms open to mobile, Web and cloud.” One of these modern platforms, he said, is Polarion Requirements.
It’s also important that organizations assign the appropriate person or people to monitor social-media feedback on your apps. “In today’s connected social world, it is important to stay on top of the chatter and get feedback from wherever you can,” Potnis said. “And obviously someone needs to monitor these sites; it should be the product manager or someone from his or her team.”
If necessary, these problems need to be quickly corrected, and the resulting requirements should be able to easily make it back into the development process. With TopTeam Analyst, Potnis said you can track these feature requests because it is fully configurable. “These social comments can then be traced into your product or application requirements for allocation into the next development iteration,” he said. “This way, you have full traceability from request to test case, and nothing falls through the cracks.”
A stakeholder, whether he or she is in project management, a business analyst or represents the voice of the customer internally, should be the one monitoring social-media feedback, according to Amfahr. But his advice to development teams is to be careful about listening to social-media feedback because it’s really easy to get sucked into listening to niche customers and niche users. You can spend all your time chasing individual customer needs and not your most important customers’ needs, he said. “Use a good tool that lets you not only get that social-media feedback, but see how frequently you are hearing it and from what kinds of customers.
“It’s not just about making sure you’re responding to social-media feedback, but making sure you put it into a bigger context,” Amfahr continued. “Feedback needs context: Who’s doing it? How often are you hearing it? From what kinds of users are you hearing it? Being able to pull all that feedback in and pull it together is important. I think that’s a big difference between using a tool like TestTrack RM rather than Microsoft Word; you can put that context around it.”
