From a software requirements perspective, the enterprization of mobile applications is affecting design, performance...
and security priorities.
So says Theresa Lanowitz, founder and industry technology analyst at voke inc. "Two things come to the fore. First, from the functional side, now design is very important in your apps. From a nonfunctional side, performance and security are important. This demand for mobile apps is really affecting both the functional and nonfunctional side of requirements." While she says functionality of design is something "people should be doing all along," mobile apps heighten the visibility. Ditto for performance and security -- they should always be important. But again, mobile apps exacerbate the need, she says.
For those in charge of requirements gathering and management, the enterprization of mobile apps opens up a whole new set of questions, says Matt Heusser, a consulting software tester in the Grand Rapids, Mich., area. "What environments are we supporting? Who's using what, and how important is it to them? There is more analysis about the customer than traditionally."
Previously in the enterprise, he says, programmers would develop an application and tell the users it needs IE8 to work, for example. "With BYOD [bring your own device] we develop software for them more like a consumer -- they tell you the device."
Organizations that do not accommodate for BYOD will find that employees will "take their productivity elsewhere," Heusser says. "When they're at the dentist office they'll search the Web instead of doing work."
Getting requirements right remains a challenge in the enterprise, Lanowitz says. "It's still the number one thing they struggle with. Where you find the most defects is in missing or failed requirements. With mobile apps you really have to make sure you're getting requirements right. Requirements are at the root of all failure, and mobile apps will exacerbate that."
Another challenge is the rapid pace of change. "What all companies need to contend with is shifting requirements," says Nari Kannan, founder and CEO of consulting company Appsparq Inc., based in Prospect, Ky., which focuses on cloud and mobile apps. "Requirements are never as solid as they used to be. Fifteen years ago requirements for enterprise applications sort of stayed the same for three to five years. Not anymore, because technology is shifting faster and faster. That means requirements from six months ago probably need to be revisited."
Kannan said the requirements landscape is "shape-shifting as we go along. The rate of change at the mobile level is really faster. You've got to keep requirements synched with all these changes faster, which brings us to Agile development. You prioritize requirements so you go after the important ones first. By the time you get to the other ones, some you may not need, or you may need to add additional ones. It's like a spiral staircase of requirements."
Enterprises face new types of requirements as well, such as social networking, Kannan says. "Features like social networking are needed in the enterprise, but you've got to wall it off so it stops at a company's network, like Yammer." Also, he says, any new internal app needs to be friendly with your own social networking, so integrating between Web-based apps and communication mechanisms like Microsoft Lync."
Security also rises to the fore when enterprise applications are available from smartphones and tablets, Kannan adds. That brings in a whole new set of security requirements, he says, such as remote wipe. "What happens if person loses an iPhone or an iPad? It's harder to lose a laptop than a smartphone."
"Security brings a new voice to the table during the requirements phase," says Lanowitz. Often, she says, organizations don't know how to write requirements for security.
From the design perspective, Lanowitz says she's seeing organizations get it right by "bringing in someone who understands design. Typically users cannot articulate what a good design philosophy is. That means a new skill set is being brought to the organization. This skill is difficult to find in the enterprise." In contrast, she says, commercial software companies will seek professional services to help them understand design through usability tests. Enterprises will also have to embrace this skill set, she says.
In terms of performance requirements, "if you don't have the performance of the mobile app correct, you will have problems as you put the mobile app out." If performance is not good, she says, "people will abandon mobile apps, even if they're for internal employees."
It's critical to take lessons to enterprise from what you expect as a consumer during the requirements phase, Lanowitz stresses. Users "expect it to be easy, well written and work with the real estate on the screen, whether that's a smartphone or tablet. So they expect ease of use and delight of using the mobile app to be there."
Lanowitz offers these tips for requirements management:
- Look at desktop virtualization and what it will mean for the organization from a security and performance perspective.
- Make sure you have security figured out, because it's necessary.
- Good design is critical.
- Consider performance. Does a device have a known performance problem outside of your organization? If so, you don't want that device to be something employees bring in.
- Make sure the infrastructure will be able to handle these types of things, so include infrastructure testing in application testing.
Lanowitz says there are some new as well as some updated requirements definitions and management tools on the market that have "reasonable capabilities for the mobile environment. Using tools to mock up what a mobile app looks like is really important. You're not able to get by with a big Word document; they get very big, very quickly. Mobile apps have to be so concise and so good."
Requirements definition and management for enterprise mobile apps can be done effectively, but it will likely take longer initially. "With that first project," Heusser suggests, "have an eye toward reusability of the requirements process for the second and third projects."