P3: Project Proposal

P3: Project Proposal #

Deadline: Jan 30, 11:59pm Eastern Time

Requirements #

The proposal document should be a PDF document. Formatting requirements: 4–6 pages (including the figures, but excluding acknowledgements and references); letter size; main text font size should be at least 11pt.

The document should include the following sections.

Introduction #

Introduce your project topic in a couple of paragraphs. Focus on answering the following questions:

  • What is your project?
  • Why is it interesting?
  • Why does this project make sense in a mobile form?

Optionally, you can include figures (mockups / screenshots / hand drawings) to help describe your app.

Not sure what app to build? Take a look at the project videos from previous years to get some inspirations.

Use Cases #

Related lecture: User Scenarios, Use Cases, Human Values

  • Draw a use case diagram for your app. This should be a summary showing the primary stakeholders (actors) and how they interact with you app (through use cases).

    • Remember the best practices when organizing use cases: each use case should have its own business value; do not include trivial/technical tasks (e.g., login) without business value as a use case.
    • You do not need to include the details of each use case in the proposal document; but if you prepared them in a separate document, you can include a link to that.
    • Although the user scenarios come after the use case diagram in this document, you may want to think about them first.

  • Write down the most important 3 user scenarios of your app, illustrating how your app helps the users achieve their goals.

    • Each user scenario will be a paragraph describing the goal, context and constraints, and success criteria.
    • These user scenarios will be the ones that we want you to demonstrate in the later prototype/final presentations.

Requirements and Timeline #

Related lecture: Non Functional Requirements

  • List the functional+non-functional requirements of your project, organized with numbered points (e.g., 1, 1.1, 1.2, 1.2.1, etc.).

    • The number of requirements varies; a good way to initialize this list is from the use cases (each use case may correspond to one or a few requirements; some requirements may be shared by multiple use cases).
    • For non functional requirements, please explicitly mark the type of this requirement (e.g., “- 1.2 Usability: A first-time user can buy a single-ride ticket in at most 4 screens, with no account creation required.”).

  • Describe a timeline describing the when you plan to implement each requirement.

    • You may set some milestones (e.g., by Week 6, etc.) and say which requirement items should be implemented by then.
    • Optionally, you may draw a Gantt diagram to visualize the timeline.
    • You can also mark some requirement items as “stretch goals”, if you are not sure yet whether you can implement them by the end of the term.

Design Considerations #

Related lecture: User Scenarios, Use Cases, Human Values

  • Discuss how you address human values and prevent unintended harms when designing the requirements.

    • Is there any feature that you initially wanted to add, but realized that it may cause unintended harms? How did you mitigate it (e.g., exclude it / add additional non functional requirements / redesign)?
    • Is there any feature that you initially didn’t consider, but now realized that it is important?

  • Discuss the trade-offs you made when designing the requirements.

    • What conflicts between stakeholders / non-functional requirements did you encounter?
    • What is your design decision (e.g., prioritize one over another) and why?

Acknowledgments / References #

These two sections do not count towards the page limit.

  • Acknowledge any help you received from others during the requirement elicitation and proposal writing process, which may include your classmates, friends, stakeholders you interviewed, or generative AI tools you used.

  • Cite the references used in the proposal (e.g., papers, books, websites, etc.).

Submission #

Submit the PDF on Learn > Submit > Dropbox > P3: Project Proposal. Your file should be named as p3-XXX.pdf where XXX is your team name or project name.

Grading Rubric #

60% of the points are given based on subjective factors: adhering to formatting requirements, having the required sections (with adequate content), having the correct number of user scenarios, etc. The rest 40% of the points are awarded based on the aesthetics values of your proposal: clarity of the writing and drawing, novelty and relevancy of the proposed idea, whether the design (use cases, requirements, etc.) is logically sound and well-thought, etc.

The proposal will be compared against what you actually implement in the project by the end of the term, as one of the factors that may impact the grade of later deliverables (e.g., final presentation and final report). We do acknowledge that requirements may change later, e.g., based on the prototypes and feedback from the course staff or peers. Those changes should be clearly documented and communicated with the course staff, e.g., in the weekly updates.

Feedback #

We will provide feedback on your proposal via written comments on Learn, within 1 week after submission.