Team Project
Project Stages
Proposal

Proposal

⚠️
Before you can proceed, you must have completed the instructions under setup your project.

In this milestone, you will describe your project idea, requirements and anticipated features. This should not be an overly technical document; it’s meant to capture requirements and design intent. When completed, you will meet and present this to your TA.

The section below describes what you are expected to include in your proposal. The examples listed are minimal and illustrative; your actual proposal will likely require more detail than this.

Requirements

Create a Wiki page named Project Proposal. Your README.md file should have a link to this page.

Your project proposal should include the following sections:

Title

The name of your product should be listed at the top.

Product Vision

Write a product vision statement that includes:

  • The name of your product.
  • A description of your product i.e. what it does.
  • A clear definition of your target users i.e., who will use it?
  • An explanation of a problem that they have and how your application will address it i.e., why should they buy it?
ℹ️

Example: Description

Recipe-Rolodex is an application that helps indecisive people choose where to eat out. Users open the application, click on the “Pick for me” button and the application will randomly select a restaurant based on location and food preferences, taking into account any food allergies that the user might have. The application also allows friends to connect and go out together, and it will take into account the groups preferences when suggesting a destination.

Personas

Define at least one persona which characterizes your target user. It should be sufficient to capture the characteristics of that user which are relevant to the problem and your proposed solution. You will usually require one person for each role or type of person that will interact with your application i.e. you will probably require more than one.

ℹ️

Example: Personas

Michael Bluth
Michael is a student at UW who lives in residence, so he eats most of his meals at restaurants (take-out much of the time). He would describe himself as “passionate” about food, and he goes out of his way to find places that have interesting dishes, and will often return to a place if he has a positive experience. He’s not very well organized and would like something to help him keep track of places he’s been. He has a shellfish allergy, so he really should be careful about ingredients as well.

Sally Sitwell
Sally is also a student at UW, but she lives in a house with four of her friends. They normally cook together, but occasionally like to go out and try different restaurants with thier extended friend group. For her, eating out is a social expereience and she would like a way to help her and he friends track where they have been together (and choose a place when it’s time to go out again).

Scenario

Write a 2-4 paragraph scenario that describes the context in which your product would be used. Describe a situation from the perspective of your personas, including what they are trying to achieve and any problems that they might encounter.

Hint: you should have at least one scenario for each persona that you have identified.

ℹ️

Example: Scenario

Sally talked with a couple of her friends after class and they all decided to go out for dinner together! As she was walking to her next class, she setup a group chat in Discord, and invited Josie, Michael, and Frank to the discussion. Over the next hour, the four of them had a sporatic conversation where someone would suggest a restaurant, but then someone else would shoot it down (“Didn’t we go there before and it was bad?”, or “I don’t their kitchen with my allergies, can we go someplace that doesn’t have seafood?”). It was a frustrating experience because they all had different opinions and recollections of the places around town, which made choosing one really, really challenging for the group. Eventually they chose the same diner that they always go to, which didn’t really satisfy anyone.

User Stories

In this section, you will extract User Stories from your scenarios. You should expect to have anywhere from five to a dozen user stories for each scenario that you have identified. Each user story should describe a goal that your persona has, in greater detail than the scenario. Each user story will form the basis for one or more features of your product.

Note that you are not expected to have implementation details figured out yet! Your goal is to have a reasonable set of user stories that encompass all of the functionality that you might implement.

Make sure to consider how these requirements will interact with the standard requirements.

ℹ️

Example: User Stories

Problems Identified
We identified the following problems from the scenario (above). We will try and address these in User Stories.

  • Challenges in coordinating a group of people (they had to use Discord).
  • Nobody remembers the details of what they have liked/disliked previously.
  • Difficulty identifying restaurants that could be acceptable for a group of people.
  • Difficulty in making the final decision in a group.

User Stories
Recipe-Rolodex is a mobile application that runs on Android devices, which aims to simplify the process of eating out with friends. Here are some user stories (the complete list would be larger!)

  1. As a user of the application, I need to be able to describe my preferences in the application. Michael needs a way to identify food allergies.
  2. All users should be able to review their meal after they have visited a restaurant, by filling out a review card. Sally would like to be able to store this alongside her profile, and share it with her friends.
  3. Sally would like to be able to identify her friends in the application. Ideally, she and her friends could friend each other: one person sends a request, and if accepted, they can see one another’s profiles (including reviews and ratings).
  4. Any user can create an event (e.g. dinner tonight) and invite friends to join them at this event. An event associates details of a restaurant visit to a group of people and replaces the individial visit (see above). Chat functionality built-in so that they can discuss going out.

Project Plan

Your final step is to create each of your User Stories as issues in your GitLab project.

For each User Story, create an issue with a Title and Description matching your User Story.

  • The implementation details should be left to your Sprint Planning Stage.
  • Consider assigning priorities to each user story e.g., “high”, “medium” and “low”. This can be accomplished by creating Labels and adding them to each User Story.
  • Consider assigning high-priority issues to milestones. Do NOT assign everything, but if you have critical User Stories that you must achieve, you can assign them to a milestone now (and discuss with your TA).

Finally, create a Gantt chart, drawn on your wiki page with Mermaid.js.

  • List each of your milestones e.g., Proposal, Sprint1 and so on.
  • Add the most important user stories/priorities for each milestone. These items can probably be taken directly from the deliverable requirements e.g., Sprint 1 page.
  gantt
    title Uber-Tweets Project Plan
    dateFormat YYYY-MM-DD
    section Sprint 1
        Setup architecture :a1, 2025-01-01, 2d
        Add unit testing libraries :after a1, 1d
        Write unit tests :after a1, 8d
    section Sprint 2
        Prototyping :b1, 2025-01-15, 5d
        Implement screens :after b1, 5d

Presentation

You are required to present your proposal to your TA in the scheduled lab time - see the schedule for dates.

Format

For full marks, you should show up with a Google Slide deck, Powerpoint presentation or PDF that summarizes your proposal. Make sure that you attach this presentation (PDF, PPT) to your Proposal Wiki page, so that your TA has access to it.

Delivery

You will have 15 minutes to deliver your presentation.

  • Everyone on the team should present some portion of it.
  • It should include the main contents from the project proposal.
  • The final page should be “Outstanding Questions” if there is anything you wish to ask the TA. You aren’t expected to “know everything” at this point, but you should be open about what you need to still figure out.
  • You are responsible for writing these down any feedback from your TA, and addressing any concerns before your next demo.

Submission

After the demo, you will need to ensure that your proposal is complete so that it can be graded. The deadline is 6:00 PM on the listed time and date. You do not need to actually submit anything; we will grade what is posted in your GitLab project at the deadline.

The content that is in GitLab should be the same as what you presented in-class. You are allowed to make small corrections but please avoid making major content changes between the demo and the submission.

Grading

The grading scheme is available in Learn under Resources > Rubrics.

Deliverables are normally graded by the following week’s lecture, and the grade and feedback will be posted under Submit > Dropbox. Any questions related to this should be sent directly to your TA.

See grading policies for more information.