What are the first steps to take in the personal Android project?
Before you start working in earnest on your personal Android project—even on the high-level design—you must write a proposal that is accepted by the instructors. This is a multi-step process: You will submit a first draft, followed by one or more rounds of instructor feedback with (if directed by the instructors) subsequent revision by you. (Sometimes, the topic itself is not suitable; when this is the case, starting a new proposal may be the best way to proceed.)
Before starting on your proposal, as you consider what you would like to do for your personal Android project, please keep in mind the expected implementation elements, as well as the features that are specifically declared out-of-scope.
In general, the final draft of the proposal is expected to contain the following elements:
This is basically an “elevator pitch”: 1–2 paragraphs summarizing the proposed application, in as compelling a manner as possible. It should include basic information on the overall purpose/intent of the system, but no technical details are required.
This should be written as 1–2 paragraphs of text, or a short bullet list of key features.
This should be an unordered (bullet) or ordered (numbered) list, with 2–4 items. Each item in the list must characterize a single type of intended user, clearly distinct from the other listed types. Be as specific as practical—for example, something along the lines of “Anyone who likes games” is not sufficient, but “People who enjoy tabletop role-playing games” is.
Along with each type of intended user, the proposal must include at least one user story relevant to the intended user.1 Make these specific, but not excessively detailed: a single sentence should be sufficient, and more than two sentences is probably too much.2
Each user story should follow (at least roughly) the form:
As a <personification of an intended user type (who)>, I <use of a key feature or capability (what)>, so that <benefit obtained by the use of that feature or capability (why)>.
For example, one item in this list for a simple puzzle-type game might be:
People who enjoy solving simple puzzles
As someone who likes to use puzzles as a diversion from work when on break, I use the solitaire mode of the Ray Reflex game to break the routine and give myself a quick mental challenge.
If the application will leverage web services (other than those developed as part of the application), external data sources, device sensors or services (camera, GPS, contacts list, accelerometer, etc.), or any other already existing service or data source, these should be included in a bullet list—each with some indication of whether access to the stated service or data source is required for the system be operational, or is intended for use by an optional feature of the system.
The instructor will provide instructions for proposal submission.
For an overview of user stories and their role in software development, see “User story”, Wikipedia. ↩
Extreme verbosity, dramatic expression, or poetic form may be amusing to the instructors (and presumably, to you), but it generally won’t earn any extra credit. In fact, if it detracts from the instructors’—and potential teammates’—ability to understand the who, what, and why of the user story, it may actually work against you. ↩