Description:

Each team's project will focus on building a mobile app of the team's choosing. The app must be useful, it must take advantage of being on a mobile platform (e.g., utilize and integrate with several services offered by the device), and it must run on a mobile phone (tablet support is fine, but it must be demoed on a phone). Apps cannot require crowd buy-in (e.g., it must be useful even if only team members are users of the app), they cannot simply replicate the functionality of a website, and they must not be simple "Create, Read, Update, Delete" (CRUD) apps.

The project proposal is a description of what you intend to accomplish over the rest of the term for this project. It should describe your system and what you intend it to do. If known, it should identify any open source software that you believe might be worth leveraging, and/or available technology that may be exploited. Remember that the challenge is to see what you can accomplish in the time available; not to make the least progress in the time available by doing things the hard way.

Emphasis on projects that are interesting / useful is preferred; use this project to build something that excites your team! A scaling factor will be applied to the final project grade to account for its significance and challenge; we will provide feedback on this aspect of your proposal so you can have an approximate idea of what this factor will be rated as if your team completes the proposed work in a completed app. The scope of the project should assume at least 5h / week development time (e.g., 4 team members * 5h / week * 13 weeks = 260 hours total). This should be enough time to complete an interesting project. Note however that you will be marked on what is developed; not on the effort put into this project by individual members of the team.

Document Requirements:

1. Page 1:

• Metadata: Project title, team number, team member names, team member Quest IDs, contact email address(es).

• What is your project? Why is it interesting? Describe and justify your project selection. Why does this project make sense in a mobile form?

• What risks might impact upon successful delivery of your project. How are you going to minimize such risks?

2. Page 2-3:

• What are the functional properties of your system? I.E. What will it do? Numbered point form is fine (e.g., 1, 1.1, 1.2).

• Provide at least two user scenarios to describe how a user would interact with your system and what the benefit to them would be. These should each be 1-2 paragraphs and can refer back to your numbered functional requirements.

• Also provide a description of the non-functional properties your system needs to support. These are verbs, describing architectural objectives that you will place emphasis on, when developing your system. There should be at least three of these. Justify why these properties are important for your system.

• NOTE: We will compare your architecture and final demo against these functional and non-functional properties.

3. Page 4:

• Identify the major activities that you expect to undertake in order to complete this project.
• Give each activity a short clear title, that may subsequently be used when referencing this activity in later status reports.
• Indicate when you anticipate starting each activity.
• Indicate when you expect this activity to be completed.
• Indicate the expected number of person/hours involved in completing this activity.
• If known who will be working on this activity.
• If known, what resources and/or standards might you use to speed development of your software.

Presentation:

Each team will ‘pitch’ their project to the class with a presentation lasting at most 8 minutes in class on Wednesday 24th May, Friday 26th May, and Monday 29th May, 2017. Actual presentation length may of necessity be uniformly reduced to accomodate the requirement that all teams have opportunity to present in these three days. Each presentation must begin and end with the name and number of the team conducting the presentation, to assist in subsequent voting. The audience may ask questions or comment at the end of each presentation if time permits.

The presentation should describe the main functionality of the system and clearly state why the project is useful / interesting. You may use slides or the blackboard for supporting materials. If you want to use slides, please send them to learn.uwaterloo.ca as cs446-s1_<team-number>.pdf in PDF format (PDF ONLY!) by 08:00am on Tuesday 23rd May. These will be preinstalled on a computer to simplify presentation; please, no animation or transitions.

Assessment:

This deliverable (including presentation) accounts for 5% of your final grade. Part of the feedback may be to indicate that your proposal is deemed too easy to implement, and should be extended to become more challenging if you wish to get a good final grade. You may also be contacted if your project is deemed overly ambitious, in which case you will be permitted to scale back your proposed deliverable.

Voting: