Requirements

The requirements for the MTM application are reasonably complex, since the final delivered product is intended to be broken down by platform (iPhone, Android, and a server-side component). As such, the requirements listed here are broken down into components as well:

• Server-side requirements are needs and features of the server software
• Shared mobile requirements are needs and features of both the iPhone and Android applications
• iPhone requirements are needs and features of only the iPhone application
• Android requirements are needs and features of only the Android application
• General requirements are needs and features of the MTM project as a whole

Each individual requirement is given as a bullet point in its associated section; sections may be broken down further to assist in organizing the full set of requirements for the system.

Server-side requirements

The LCTA is currently in the process of redesigning and modernizing the website used to track information for the trails system. The new site, recently released after development by a private contractor, is based heavily on WordPress and its related engines and plugins. The MTM team has access to this web host and can develop against it. As such, the server-side MTM application must:

• Provide a common server API for remote data transfer
  • Allow fetching of sufficient data to provide a Google Maps overlay with trails information, including trail markers, landmarks, and related documentation
  • Allow the upload of geotagged text and photos, both for editing landmark information as well as reporting issues with the trails
  • Adhere to RESTful principles
• Support, but not require, remote authentication of users against a server-side user database, and alter privileges within the mobile application as a result
  • Allow administrative review and control of server-side data, including reviewing submitted problem reports and information and administering the set of trails landmarks.
  • Support high scalability and availability
• Provide a management interface for reviewing submitted trails information and problem reports through a Web browser
• With a metropolitan population of over 250,000, the potential for a large number of simultaneous mobile hits on the server is reasonably high; as such, the server should handle a reasonable flow of traffic from dozens (or even hundreds) of simultaneous mobile users without issue.
• The trails system does not “close” per se; the server should seek to maximize the time it is available to mobile users.

Shared mobile requirements

• Integrate with the Google Maps API for simple maps that support pan and scale operations
• Provide Google Maps overlays that clearly mark trails and important points of interest
• Display, in a user-friendly and natural fashion, any relevant information at landmarks
• Provide a facility for submitting photos and textual information to a central server through a defined API for problem reporting and community information editing purposes
• Allow any posts to the central server to be geotagged with a physical location
• Allow administrative users to authenticate to a central server, once authenticated, grant additional permissions to that user
• Present as common an interface as is possible across multiple mobile platforms

iPhone requirements

• Be available on the App Store, free of charge, to any user with an iPhone or iPod Touch running iOS version 4.0 or newer
  • The MTM team is not requiring a specific iPad version of the software be released; however, iPad development will occur in parallel with the iPhone and the iPad may receive releases with the iPhone.
  • The team is also focusing on a relatively recent iOS version (4.0) following reports that over 90% of iOS users keep up-to-date with new revisions of the operating system.
• Adhere to Apple’s Human Interface Guidelines (HIG)
• Follow common programming practices and principles in the Objective-C language as provided in the iOS ecosystem
• Adhere to the development contract and programming guidelines for the iOS platform (e.g. use no private APIs, manage memory carefully, etc.)

Android requirements

• Be available on the Android Marketplace, free of charge, to any user with an Android device running Android version 2.1 (Eclair) or newer with a GPS and Data capability
  • The MTM team is deliberately not focusing on a specific hardware model, so long as that hardware runs a “vanilla” version of Android 2.1 or newer. Rose-Hulman has granted the team several Android phones to test with, so generic Android 2.1 support should be possible
• Adhere to Google’s human interface and programming
• Follow common programming practices and principles in the Java language as provided in the Android ecosystem

General requirements

• Provide a stable and secure system upon final deployment
  • The server-side and mobile applications should all contain no critical bugs (where “critical” means the bug causes a complete system crash either on a mobile device or the central server)
  • Minimize the number of other bugs; users should, under ideal circumstances, never encounter a full crash of the MTM application, nor should they be able to trigger undesirable server behavior
• Use Agile methodologies and practices in development
  • Employ an iterative design cycle, where working software betas are made available to the client on a regular basis and documentation is updated as the project undergoes development
  • Test regularly: use -Unit frameworks to perform test-driven development where appropriate, and deploy applications to physical hardware (both server-side and mobile) to run frequent live usage tests
• Be transparent
  • Provide access to information throughout the development process; use GitHub, wikis, and shared blogging tools to create a project in view of the community
  • Release source code and documentation under an open-source license
• Communicate effectively
  • Keep the LCTA and other interested stakeholders up-to-date on project developments and progress, both via project transparency and regular teleconference or Skype check-ins
  • Advise Steve Chenoweth, Rose-Hulman faculty advisor, of any difficulties the team encounters and of progress made, at weekly in-person meetings
  • Include Matt Boutell, Rose-Hulman faculty, in all informational meetings