TabTimes recently published “7 tips to consider when developing and designing mobile business apps“.

Ad: iForm Reporting with Google Docs

Not a bad collection of things to consider. However, I’m amazed that an article like this can be crafted without once using the term “requirements“. But this is not an isolated case. Everywhere I look, advice concerning mobile app strategy and development is void of any discussion about business requirements.

Certainly, a few of the 7 tips offered by TabTimes touch on requirements in a peripheral way. But failing to identify the true business requirements without ambiguity can trigger a cascading series of missteps for a mobile team.

But that’s not all…

Many teams decide at the outset that they need to “design” an app when they really need to design a “solution”. While this is also touched on in the TabTimes article, the very idea that an “app” needs to be designed and developed rules out many implementation strategies that may address the true business requirements without ever building anything.

A good example of alternative mobile implementation strategies is Wufoo or perhaps iFormBuilder.

These front-end mobile form tools are sometimes ideal frameworks for rapidly designing and deploying mobile business solutions. Coupled with a cloud data layer, clever form design, and custom reporting, businesses can often put a secure mobile solution into production in a fraction of the time and almost zero development cost.

All too often we assume “business apps” is the axis we need to pursue. We’ve become so app-centric that it clouds our requirements management process and our judgement.

Just sayin …