CSE 403 project: Proposal and Requirements

Overview

Congratulations! Venture capitalists have accepted your pitch, and you have attracted a talented engineering team to implement it.

Now you will expand your pitch into a proposal. The proposal covers the topics your pitch covered (or should have), in greater detail, and adds functional and non-functional requirements.

What is due

Submit these to Canvas:

  1. The URL for your GitHub repository.

  2. A PDF snapshot of the first version of your living document. The document describes your project’s goals, its functional and non-functional requirements, and the process your team will follow to implement it. You will update and resubmit the living document each week.

  3. A 2-minute video demo of your system’s UI.

Your GitHub repository

  1. Create a public repository for your project on GitHub. Make all team members contributors.

  2. Add a top-level README.md file that briefly describes your project’s idea and goals, explains the layout of the repository, and links to your living document (which may be stored in the repository or elsewhere).

  3. Start exploring, prototyping, and setting up resources. Next week’s milestone asks you to finalize your system’s architecture and design, but you can begin now. For example, if your project needs a web or SQL server, set it up and add instructions to your Git repository.

  4. Work through the Git conflict resolution tutorial. When merge conflicts arise later in the quarter, you will be glad you did.

Repository and collaboration FAQs

Should one person write and commit the status report to the Git repository, or should we each commit our own part of the report?

This is up to you. In the past, teams have found it easiest to write the report collaboratively. Three popular approaches are:

  • a Markdown document stored in your repository.
  • a LaTeX document stored at Overleaf.
  • a Google Doc.

Your living document

The first version of your living document must contain the following sections.

1. Team info (10%)

Concisely summarize the project team and project artifacts:

  • List each team member and their role (one line each; section 6 justifies the roles).
  • Link to each relevant project artifact, such as your Git repository.
  • List your communication channels and tools. For example, CSE 403 uses Ed and has discussion rules that govern communication.

2. Product description (20%)

This section must satisfy all the requirements of the project pitch. Start from your pitch and revise it based on the feedback you have received. Your product plan has probably changed since last week.

Also add:

  • 4+ major features you will implement. Together, they should constitute a minimum viable product (MVP).
  • 2+ stretch goals you hope to implement.

3. Use cases (functional requirements) (30%)

Each team member must write at least one use case for your product, following this template:

  1. Actors
  2. Triggers
  3. Preconditions
  4. Postconditions (success scenario)
  5. List of steps (success scenario)
  6. Extensions/variations of the success scenario
  7. Exceptions: failure conditions and scenarios

4. Non-functional requirements (10%)

Describe at least three non-functional requirements, such as ones related to scalability, usability, or security and privacy.

Make each requirement verifiable: state how you would check whether your product meets it. “The app is fast” is not verifiable, but “search results appear within 1 second for a catalog of 10,000 items” is.

5. External requirements (10%)

The course staff imposes these additional requirements on your project:

  • The product must be robust against errors that can reasonably be expected, such as invalid user input.
  • Other people must be able to use the product. A web-based service must have a public URL. A stand-alone application must be easy for others to download, install, and run.
  • Other people must be able to build all parts of the software, including clients and servers, from source. For a web-based server, provide instructions for setting up a new server. The system must be documented well enough for new developers to make enhancements.
  • The project’s scope must match the resources assigned (the number of team members).

Specialize the applicable requirements to your project and include them in your document; do not copy them verbatim. You may keep them in a separate section or fold them into your other requirements sections.

6. Team process description (20%)

Describe your development process for the quarter:

  • Specify and justify your software toolset.
  • Define and justify each team member’s role: why does your team need this role filled, and why is this team member suited to it?
  • Provide a schedule that gives each member (or subgroup) a measurable, concrete milestone for each week. “Feature 90% done” is not measurable; “use case 1 works, without error handling” is. Your schedule will change during the quarter, but thinking carefully now about what needs to be done, and when, will pay off.
  • Identify and explain at least three major risks that could prevent you from completing your project.
  • Describe when in your process external feedback (from outside your project group) will be most useful, and how you will get it.

Export a PDF snapshot of your document, name it [project name]_m2.pdf, and submit it to Canvas.

Living document FAQs

How much should we say about the software toolset we will use?

What programming languages, data sources, project trackers, and other tools will you use? Which software components, if any, will you use off the shelf, and which will you implement from scratch? Explain why you chose these tools and languages and why they suit your project.

You may settle some of these questions during requirements engineering and others during design. It is also fine if some answers change as the project progresses.

What is a team member “role”?

A role is the part of the project (or set of tasks) that a team member is responsible for. You can refine or change roles as the project progresses, but you must justify your current choices.

Here are two examples:

  1. A web application project might have 2-3 backend engineers, 1-2 frontend engineers, and 1-2 engineers in charge of UI design (probably also serving as frontend or backend engineers).

  2. A data analysis project might have 1-2 people responsible for data collection and storage, 1-2 for data analysis and visualization, and 1-2 for infrastructure and automation.

What if we want to commercialize our project idea?

Your group collectively owns its work. If you might commercialize your project, consult a lawyer early; one campus resource is Comotion. Usually, though, the main value of the CSE 403 project is fleshing out and testing ideas, not producing code that will survive until commercialization.

Any advice regarding writing?

Your score will depend largely on plausibility, thoughtfulness, and level of detail. For example, generic or incomplete use cases often lose points. Choose substantial use cases that are central to your product’s core functionality, and describe them clearly. List the steps of each scenario, without omitting important steps or details. Make sure that every success path ends in a state that satisfies the use case’s postconditions, and that each failure path states the system’s resulting state.

Your document must be clear and professional: concise, with correct spelling and grammar, clear wording, and a structure that helps the reader follow your ideas.

Because this is a living document, expect change requests and revisions.

Is there a minimum or maximum number of pages?

No. Grading focuses on completeness and on clear, concise writing. Address each requirement completely and understandably. Do not pad your proposal. Write concisely and avoid redundancy, using cross-references where needed.

Video demo

You will make a video demo of your product, even though it does not yet exist. Using a mockup of the user interface, narrate a walkthrough of a few use cases to show how users will use your product. It does not matter how many group members speak in the video.

How to make the video

The staff does not expect a polished UI or full functionality. The video should convey how your product will work, how users will interact with it, and how it satisfies their goals.

Your mockup can be static or interactive. Either way, the more it demonstrates your thinking and your understanding of users, the better.

Ways to make the video include:

  • Use AI to make the video directly.
  • Use AI to prototype a mockup of your system, then record yourself using the mockup.
  • Record a voiceover of a Figma design.
  • Create a slideshow of annotated renders of pages (a “storyboard”).