When developing a framework for minimum viable product (MVP) apps, nontechnical app inventors need to involve skilled developers early in the planning stages of app development. With clear guidance from the app inventor as to the app’s purpose, intended usage scenarios and operating environments, app developers can advise nontechnical app creators on the technical specifications of the proposed app’s constraints and dependencies.
Constraints
In business, budget, time, and scope limitations are generally considered to be constraints. In the context of technical specification documents, however, constraints define the differences within user and hardware interface requirements.
-
Usage constraints are defined based on user classes and used to control the visibility of app features. Developers specify which type of mobile application framework (MAF) content should be delivered for particular app features when defining this type of constraints.
-
Feature level constraints are defined based on the roles and privileges of user classes for app management and security reasons.
-
Hardware constraints are defined in order to account for their implications on user experience. For instance, if a mobile app user loses Wi-Fi connection, features of the app may need to become unavailable. App developers will want to avoid a scenario where users have to restart the app when experiencing a poor Wi-Fi connection.
Hardware Dependencies
Dependencies are external components called by mobile, web and IoT apps. Any aspect that an app must rely on in order to meet its objectives qualifies as a dependency. In the case of mobile and web apps, hardware dependencies relate to the devices that run or communicate with the apps. When defining the hardware dependencies of your MVP app, special consideration must be given to whether the capabilities and features of devices to be supported align with your app requirements.
Mobile apps developed for Android must grapple with the fragmentation of Android’s mobile ecosystem. Android devices come in all shapes, screen sizes, performance levels and varieties—over 1,000 brands of devices exist on Android’s OS. Whether certain devices have step counters and motion sensors, for instance, may be critical hardware dependencies for mHealth app developers. Strategic compromises must be made when deciding which devices to design and code app layouts for. Many app creators overcome this lack of software and hardware standardization by optimizing their app design for the most commonly used Android devices.
Although Apple iOS hardware dependencies are much more uniform, differences in capability still exist between iOS devices. Older and newer generation devices boast a variety of hardware features. Once hardware capabilities have been decided, app developers can easily address device-related UI concerns with Apple’s Adaptive User Interfaces.
For IoT, hardware dependencies relate to the smartphones that run the app, and other pieces of hardware like iBeacons or BLE interfaces that the app communicates with. Hardware-integrated IoT solutions combine mobile apps with outlying hardware and connect the two through the app. Mobile apps servicing industrial organizations and enterprises are increasingly integrating with pieces of hardware to replace traditional forms of hardware controls—eliminating friction between hardware and software—and enhance product value by providing added capabilities, mobility, and efficiency.
Third Party Dependencies
Application program interfaces (APIs) are a set of routines, tools functions and protocols that allow apps to “talk” to one another, sharing data and taking action on behalf of the other without developers having to share the entire code of each app involved. “Share on Facebook” and “log-in with Facebook” APIs are some of the most commonly used by mobile app developers. Using APIs, app creators and developers can expand the functionality, user-friendliness or even speed with which an app is released onto the market.
Third party dependencies implicit in API, however, can threaten app performance and security depending on how they are coded into apps. Poorly written code can all too easily become a danger to users when APIs are involved. Changes to APIs’ policies and behaviors or failures can also threaten the speed and reliability of apps that are dependent on them for their core features. Nontechnical app creators should work with their app developers to define how these risk factors will be addressed when defining the functional requirements of the app.
—
All of the actions detailed above will help nontechnical app creators have more informed conversations with their developers when defining these more technical elements of the app development specification process. For more insights into preparing a technical specification document check out our blog series and download our app specification sheet template.