Warren Steger, Author at Applied Information Sciences

We’ve recently worked on several mobile app development projects for tablets and phones running iOS, Android and Windows. Thanks to these projects, we’ve identified some key do’s and don’ts for managing your product backlog requirements for mobile application development efforts.

Here are some of the common business features and technical requirements/constraints for both consumer-facing apps and corporate internal apps that could show up in the product backlog:

Responsive UX Design (screen size, orientation, device features, etc.) – for this you will need to identify a limited set of target device configurations for acceptance
Required corporate branding/corporate style guides
Choosing between a native app style UI that is device specific vs. a common style cross-platform UI
Stringent speed/performance targets for initial app loading, screen navigation, response to user actions
Connected vs. Disconnected Operations requirements – you need to clearly define what features work when there is no connection
Data security and Personally Identifiable Information (PII) protection
Support for multiple OS and multiple versions of an OS
Support for multiple types of mobile browsers
Integration with companion apps on the device
Cloud/web service integration to access corporate systems of record
App Store submission requirements (i.e. Google Play, Apple App Store and the Windows Store). Each store has its own unique sets of UX requirements, minimum performance, storage management, legal/copyright, privacy notification requirements, content age appropriateness designation, etc.
App version management
Code-sharing across device and OS platforms
Graceful degradation of the app functions in case of failures
Process improvement support, especially for corporate vs. consumer apps that are targeted for mobile workers
Security and device management for corporate apps

The items in the list above may all need to be considered when you first start working with the product owner to both build the product backlog for the mobile app and help define the overall scope and timeline for the project. For consumer apps deployed through app stores in particular, the timeline for publishing to the stores — and factoring in the review and acceptance process — needs to be considered up front. Read More…

Warren Steger

In today’s mobile society, the current and future generation of “mobile” devices (i.e. smartphones, tablets, “phablets,” special purpose devices, etc.) and the applications that can be hosted on them provide a significant opportunity to improve the way we work. This is especially true for those workers whose job involves traveling during the day to work directly with customers “in the field.” In this post, I’ll share some recent experiences we’ve had in working with mobile field workers as part of an analysis effort to define requirements for a tablet-based application.

Approach:

The specific approach we used for this project was to “follow” or “shadow” the workers as they performed their activities and collect observations about:

The tasks they performed,
The devices and applications they used to support those tasks, and
The types of information and work products (forms, documents, etc.) they either collected or produced in course of performing the tasks.

We worked with both staff personnel and supervisor personnel, and we looked at both scenarios where customers would come into a field office and scenarios where the field staff would meet customers at a field location directly. We then followed the observation sessions with one-on-one interviews to review the observations and ask more specific questions.

Based on our experiences, we identified what we would consider to be some key recommendations for business analysts, product managers, or others seeking to elicit requirements for mobile worker applications. Read More…

Warren Steger

At AIS, we work with clients to help define the overall vision, scope and detailed requirements for the applications they want to build. I recently had the opportunity to work on a project where a client wanted to reach a new set of users through a Windows Store app that was based on an existing iPad app.

We had a very short timeline and limited budget to work with. That was the bad news… The good news was that we were able to use Microsoft Team Foundation Server (TFS) — in this case the TFS 2010 version — in conjunction with Visual Studio 2012. This gave us the opportunity to leverage new PowerPoint 2013 storyboarding stencils for defining the app’s User Experience (UX), and TFS for efficiently creating and managing our product backlog. We also used Visio 2013 for visually defining the overall functional scope and high-level release plan for the app.

In this post, I’ll share how we used these tools to rapidly define the requirements for the app, and talk about some topics related to converting the iPad app information architecture to a Windows Store app information architecture. Read More…

Warren Steger

In order to meet ever-increasing customer demands and compete on a global scale, many organizations need to be able to fold new systems and/or new features into existing systems quickly and cheaply. These organizations — and perhaps yours — have portfolios of existing systems and infrastructures that were implemented literally decades ago.

These “legacy” systems, while well-architected for the demands and market conditions of the past, have often become increasingly complex through the years and more costly to maintain. What’s more, these systems are based on technologies that simply don’t provide the flexibility and disciplined agility that modern programming languages and frameworks can. Read More…

BlogPosts by Warren Steger