Hundreds of eighth-grade science teachers have quoted “speed equals distance over time.” In mobile application development, speed to market is affected by the amount of deviation from the original idea over time. Project divergence over time equates to more overtime to meet an inflexible launch date. Given the aggressive development life cycle of most mobile applications, it is reasonable to assume that scope creep (PDF) is the single biggest challenge. Keeping your project within the original boundaries – and reducing or eliminating scope creep – requires more diligence in the “planning” stage of the standard development life cycle (SDLC).

The power of the napkin

Better planning will result in less coding. Not necessarily fewer lines, but less time translating requirements into a marketable mobile app. Regardless the SDLC model, requirements and architecture are the crucial building blocks for all mobile apps. The requirements define exactly what the app is going to do, while the architecture outlines how it’s going to do it. No matter the level of complexity of your app, requirements should always be clear and concise. The most popular iOS apps most likely evolved from napkin doodles (Figure A).

Figure A

Napkin Doodles

Napkin doodles, loose notes, and random thoughts are the cornerstone of your next great mobile app. Take some time to organize your thoughts and create sketches of the interface, navigation, and program flow. A simple wireframe can reveal problems and thwart issues before the first line of code is written. Use case outlines and diagrams are an integral part of the requirements gathering process. All of the information – formally documented or loosely defined – fuel the blueprint and define the architecture of an iOS app.

If project requirements are the building blocks of an iOS app, then project architecture is the definition of how the blocks are to be positioned or stacked. The iOS App Store is hosting many apps with similar functionality. These apps are differentiated by the various approaches each developer used to translate requirements into architecture. In traditional software development, architecture is the process of designing a system that satisfies the requirements. This effort is greatly reduced if the requirements are thorough, descriptive, and well documented.

Three steps

Going from napkin doodles to application architecture and design can be less daunting if you follow this three-step process:

  • Identify and list the functional requirements. Using the “right-to-passage” Hello World app as an example, functional requirements might include:

· Must capture user name.

· Must support device rotation.

· Must display user name with welcome message.

  • Create a list of non-functional requirements. Non-functional requirements would include anything that is not a task performed by the mobile app. For example:

· Must be fast.

· Must be released in time for the holidays.

  • Create a UML use case diagram and present it – along with supporting documentation – to the project stakeholders (Figure B).

Figure B

Use case diagram

With everyone in agreement – and a clear understanding of what the app is going to do – you can move to the architecture and design phase with less risk of scope creep. If a new OS is announced during the development of your app, a decision needs to be made as to whether or not to leverage any new capability or functionality. Depending on the SDLC methodology, it might make more sense to continue with the current release and start planning your next release to incorporate the new system or device capabilities.

More often than not, apps fail because there is not enough planning before code writing. Other development efforts fall short because there is no structure or methodology applied after the requirements have been gathered and documented. Of the eight mainstream SDLC models – Agile, Evolutionary, Rapid Prototype, Slamdunk, Spiral, Stage Gate, Sync-Stable, and Waterfall – we hear the most buzz surrounding Agile and Waterfall.

Agile and Waterfall

Traditionalists like the organization and thorough documentation required for a Waterfall project (Figure C). A Waterfall project is synchronous. For example, one completed phase cascades into the next. However, the Waterfall method does not align well with the speed at which mobile technology and innovation moves.

Figure C

Waterfall project

The SDLC Agile method, on the other hand, lends itself to the fast-paced and ever-changing mobile environment. The iterative process of the Agile method satisfies the need to remain nimble and sensitive to changes in the technology throughout the lifecycle of a project. The Agile method for software development is a “plan as you go” approach that welcomes change throughout the process (Figure D).

Figure D

Agile method

The iterative process of the Agile method is more receptive to a napkin doodle as input than the rigid procedural process of the Waterfall method. Great ideas can come at any time. Grab the closest writable surface – such as a drink coaster or napkin – and sketch a quick proof-of-concept. Few projects start as a detailed set of schematics, but rather as a collection of unorganized random thoughts, notes, and illustrations. Your next great iOS mobile app can originate from a simple set of napkin doodles.

Also read: