Provide a high-level description of the envisioned application.
Describe the user base of the application and different roles users might have in the application.
For example, a mobile app to support heart failure research might be used by Emory patients, physicians, and researchers. There might be only one type of use for patients, but there may be two types of use for Emory people—a healthcare provider and researcher role. Perhaps there is even a study administrator role.
Describe how the app will be distributed.
To continue with the current example of a heart failure research app, the app would likely need to be distributed through public marketplaces, because at least one segment of the user base is the general public, Emory patients. Emory might also post a link to the publicly-available app in its own Emory Mobile App Catalog, so internal Emory people can also find the app there.
List all platforms and variants on which the app must be available as best known today.
In the case of the heart failure research app, the app would likely need to work on both iOS and Android because the Emory patients treated for heart failure use both platforms. Additionally, there would need to be a web app component for the healthcare provider and researcher roles to implement some of their use cases.
List any applications that are similar to this application in either overall envisioned functionality or parts of that envisioned functionality.
For example, in our app, we want to collect information about meals people take and there is diet application that also collects information about food people eat and we like the way they do that particular piece of functionality and would like to have something similar in our app.
Attach any existing documentation (including pictures) to this page.
List the use cases for each role defined above.
For example, the heart failure app may have use cases for the following roles or actors: Patient, Health Care Provider, and Researcher. The use cases might be the following and should be described with at least one paragraph of detail each.
Patient: register, manage user profile, record/edit meals and snacks, record weight, report problems
Health Care Provider: review patient status, respond to problems
Researcher: review study dashboard, review patient status
Key Data Structures
List the key data structures and known fields for each.
For example, the heart failure app must manage: user profile, meals, weight measurements, problems, patient summary report, study summary report. Known desired fields should be listed to help assess the complexity of the object model and user interfaces.
Critical Back-end Application or Validation Logic
List all of the application and validation logic that must reside in back-end services to present data and logic uniformly to all clients and collect application data.
The heart failure app has two kinds of mobile app client and a web client so all of the data and critical business logic should reside in back-end web services so that all three client can execute the logic uniformly. Also the app must store the data it collects in a central database and should not store data on the device to both collect data for the study and comply with Emory's HIPAA compliance and audit policies.
The heart failure app must invoke data persistence services to store and display user profiles, meals, weight measurements, problems, patient summary reports, and study summary report. Additionally it must retrieve validation data to validate input from its back-end services.
Complex, Unique, or Unusual User Interfaces
List all complex, unique, or unusual user interfaces that may require special treatment in a preliminary cost and effort estimate. This would be any user interface that was not simply accepting form input or display data read from backend services for a single object. So any user interface that involves a complex flow or features of the mobile device like photo scanning, bar code reading, voice recording, video recording, etc.
The heart failure app needs users to input everything they eat in order to assess their fluid and sodium intake. While entering food one eats at a meals sounds relatively simple, apps that do this very well cost millions of dollars to implement. They have a refined UI flow, make extensive use of bar code and QR code scanning, external public and private databases for matching, validation, and nutritional value. Implementing this feature well in a single app would be cost prohibitive. The project or Emory should look for an existing apps or foundation that could be used, licensed, or otherwise integrated. Alternately, the project could lower or change its expectations for how this data is acquired.
Effort Estimate to Develop the App
Provide an estimate of hours to implement each enumerated use case on each platform as well as common, back-end services to support them.
Effort Estimate to Maintain the App
Provide an estimate of hours to maintain the App through platform updates without functional changes including the cost of app marketplace resubmissions for redistritbution.
Cost Estimate to Operate the App Environments
Provide an estimate to operate the production, development, and test environments of the app and its back-end services as well as the cost of distributing non-production versions of the app to all development and testing users.
Total Cost Estimate
Summarize the total cost of the initial build and on-going annual maintenance and operations.