Requirements management, according to experts, is generally a pain point in the software development process. Few organizations do a good job documenting, analyzing, tracing and prioritizing their application requirements -- and software projects suffer as a result. But as organizations consider hosting their apps in the public cloud, good requirements management becomes crucial. Hosting apps in the cloud offers many operational benefits, but it also adds an extra layer of complexity, which makes it necessary to do requirements right.
“If you look at requirements management across the board – whether the applications are deployed to a private cloud, a public cloud, on premise or in a Web environment – in general, we don’t do a very good job,” says Theresa Lanowitz, founder and analyst, voke inc. “Requirements management is the Achilles heel of software engineering.”
Organizations that have neglected requirements management in the past are in for a rude awakening when they begin to deploy applications to a public cloud. Moving an application to the cloud can result in capital and operational cost savings because there is no need to procure and maintain the infrastructure on premise. However, that very benefit – a lack of on-premise infrastructure – also amplifies the importance of requirements management. This is especially true for nonfunctional requirements.
“Getting them correct is far more important because you don’t own that infrastructure,” says Lanowitz. “The application is not sitting at your site, which you can go and fix.”
Randy Rice, principal consultant and trainer, Rice Consulting Services, agrees with Lanowitz. Nonfunctional requirements such as reliability, accessibility, security and performance “traditionally weren’t defined very much,” he says. “[The cloud] forces stakeholders to think through what they actually need.”
“We need to look at requirements and say, ‘They are strategic to our organization.’ Without that focus we will just continue to deliver bad software,” says Lanowitz. “But now you deploy to the cloud and performance and security become two big issues from a requirements perspective.”
Requirements validation and contingency planning
Defining nonfunctional requirements and establishing them as part of a service-level agreement (SLA) with your cloud provider are just the beginning. The organization must have a way to validate that those requirements are continually being met after the application is deployed to the cloud, says Rice. A major cloud provider is unlikely to agree to an audit. However, some have dashboards that provide visibility into the application’s accessibility, performance and other nonfunctional requirements. Still other cloud providers may require you to invest in your own tools.
More resources on apps in the cloud
Similarly, organizations need to consider the possibility that requirements will not be met and put contingencies in place accordingly. In a public cloud, you have much less control over the hardware resources, software, data, etc., than you would in a private cloud or on-premise deployment, explains Rice.
“Imagine a scenario where you have a public cloud-based sales application that supports 1,000 sales people. If that application goes down for a day, you’ve lost a lot of sales,” says Rice. “So, a company may have a contingency of another sales application that is from a different provider, with data backed up daily from the main site. It's redundant, but also looks good when major problems arise. Of course, the level of contingency planning depends on the level of risk.”
Getting back to requirements management basics
Organizations may find the prospect of requirements management for the cloud a bit overwhelming. Lanowitz acknowledges this challenge: “Requirements are really difficult. They are at the root of pretty much every failure,” she says.
To help ease the requirements management process, experts advise going back to the basics. This starts with gathering the appropriate stakeholders. “One of the golden rules for requirements gathering is you have got to have the right people in the room,” says Rice.
When you’re deploying an app in the cloud, you’ll need to involve a broader mix of people than you have in the past. For example, you’ll include end business users as well as folks from testing and the data center. “Before, IT and the business were on opposite sides,” says Rice. “Now IT and the business are on the same page, looking to the cloud provider [to deliver on those requirements],” says Rice.
It is particularly important to include end users when defining functional requirements. “We tend to think of our business users as consumers, but with the cloud you have so many more options, and the business users might not be aware of some of the options that they can use to solve business problems,” says Rice. For example, the cloud offers the ability to expand into different environments without consideration for the physical data centers. “A business unit in the past may have requirements and features denied because of a lack of internal resources. With the cloud it becomes much more affordable, and they might not realize what they can do because of the affordability,” explains Rice.
Going through the effort of defining requirements doesn’t do a whole lot of good if there isn’t a central point of control for the requirements. This requires a tool. “So many people define requirements, and they’re scattered in documents all over the place. Over the years, it has become a standard best practice to use a tool to monitor them. It helps to trace and to validate them,” says Rice.
Even though special considerations must be taken into account when managing requirements for cloud-based applications, doing so will likely result in higher quality and less-expensive applications.
This was first published in May 2012