We can find a half dozen ways to break mobile applications before breakfast, and that's before considering how...
the software interacts with social, local and geo-aware features. The problem comes in figuring out what to fix. Figuring out what to support after the fact can be expensive, time consuming and is not essential to the process.
The classic fix for this is getting the supported product list up front, which is fine if you issue the device. Companies that rely on customers to bring their own device, or BYOD, may find that the supported list and what the customer brings are at odds, causing another round of churn. This article focuses on exactly that problem: overcoming the "planning paradox" for mobile application requirements, with a focus on product compatibility.
Which devices do we support?
A Web-based mobile application can be viewed by anything from tablet devices that act like desktop browsers, to ancient cell phones with a 40 character by 20 character text interface. Anyone can view the page. The questions are: "Will it work for them?" and "Should it?"
It should be a straightforward question but the answer is often complex. My best advice is to try to find a product owner, or PO, the "single wringable neck" on the project who has both the authority to make decisions and the responsibility to live with them. That product owner can draw from a number of sources to find the adoption rate. The PO might, for example, look at the devices in use on other projects, demographics on product market share, or bandwidth use, ideally sliced up by customer demographic.
Product compatibility: Reframing "support"
The best requirements process is often a series of conversations among the developers who have to build the software, the testers who exercise it and the customer who funds the project. That customer has to trade off time, features and device combinations; and, for him, a yes/no support strategy leads to a dilemma.
There is another way: Create multiple levels of support for different devices and combinations. The simplest approach is a three-level strategy:
- Level one: The PO expects all fundamental work flows to be exercised before release.
- Level two: This product combination will not be tested, but if someone in the field has a problem, we will help them work through the issue and fix the defect.
- Level three: Not tested. Not supported. Too bad.
Another common level is to test and support specific use cases through the software, which ensures the basic functions are possible, while ignoring cosmetic errors.
Other quality attributes
Mobile devices introduce a huge collection of other "nonfunctional" requirements. Here are a few examples:
- How should the software perform when the network is slow?
- How should the software perform when the network has 5% packet loss? How about 10% or 30%?
- If the software requires a persistent connection, what needs to happen when the user steps into an elevator, or when the device goes to sleep, or when the application is interrupted by a phone call?
- The standard screen resolution for smartphones is 320x300 pixels, but tablets are larger and next-generation mobile devices can support HD screens. What should the user see in all that extra white space?
- We integrate with Facebook, Twitter or Google login. What do we do when that service is down, and how can we test it?
To get the answers to these questions, I suggest a meeting between the product owner, developers and testers, to not only create requirements, but to also create examples that drive development. George Dinwiddie calls these meetings the three amigos, a term with widespread acceptance within the Agile software movement.
The biggest challenge to mobile requirements may be in building the process to withstand change.
Like so many things in life, teams that ignore these questions early on will eventually have to answer them to the customers they support. Putting the answers into requirements allows the team to choose the answers, instead of allowing the testers to declare them ("It is what it is") or the end customer to find them.
While many analysts are comfortable predicting what features the customers will use, other quality factors may be more challenging. In fact, more and more companies are taking a "fail fast" approach, launching the product with limited functionality and letting the complaints of the users steer the fixing process.
If your team wants to take this kind of approach, you'll want to consider an entirely new set of requirements: the tools and process to track complaints and use. This includes how many people are using what device, the details of the complaints combined with high-level metrics on how people are blocked and the dollar figures those blockages represent.
Failing fast is fine; it can even be good, but be sure to plan to build the tools you'll need to pick the mess up off the floor and fix it.
Be prepared to change
A few years ago, my team got a panicked call from an executive saying that a potential investor's son got an iPad for Christmas and the site looked terrible in it. At that moment, all the explanations in the world, all the logic, all the adoption percentages did not mean a thing. We suddenly needed to support the iPad, period, full stop.
These sorts of changes in mobile application requirements are more like normal business than the exception. New form factors are popping up every week.
In other words, the biggest challenge to mobile requirements may be in building the process to withstand change. By taking a look at compatibility up front, considering nonfunctional requirements and building tools to measure failure, your team gets to production faster and also pivots to meet actual customer needs, not projected ones.
That sure sounds like a winning combination to me.
Matt Heusser asks:
Has the fail-fast approach been effective for your company's software development team?
1 ResponseJoin the Discussion