Congratulations! Your pitch has been accepted by the venture capitalists, and you have attracted a talented engineering team to implement it.
Now you will expand your pitch into a proper proposal. It involves many of the same aspects you (should have) touched upon in your pitch, but at a greater level of detail. You should also include both functional and non-functional requirements.
Establish a solid definition of your project from which to base a design and implementation. You will write a document that describes the goals of your project, its functional and non-functional requirements, and the processes your team will follow to implement it. This is the first iteration of a living document, and you’ll be asked to update it during the development cycle.
Create a public repository for your project on GitHub, make all team members contributors, give all staff members edit access.
The top-level README should briefly describe the idea and goals of your project and explain the layout of the repository. It should link to your living document (which might be stored in the repository, or might be stored elsewhere).
Next week’s milestone will have you finalize your system’s architecture and design, but start exploring, prototyping, and setting up resources. For example, if your project requires setting up a web or SQL server, get started on this task and add relevant instructions and information to your Git repository.
Review and follow the Git conflict resolution tutorial. When merge conflicts come up later in the quarter, you will be happy that you did.
Complete the tasks and submit the link to your repository on Canvas.
This is up to you, but in the past teams have found it easiest to write the report collaboratively. Two popular approaches are a Markdown or LaTeX document (stored in GitHub or some other repository), or a Google Doc.
Read GitHub’s introduction to writing Markdown.
Work with your newly-assigned project teams.
Create a shared living document. (We recommend a Google doc, or a Markdown or LaTeX document in a shared repository.) The majority of your technical writing will go in to this document, and when a milestone is due you will make a snapshot (PDF) of this document and upload to Canvas.
Produce the first version of your living document with the following sections.
Provide a concise summary of the project team and project artifacts. Specifically:
Copy your project proposal as a starting point into this part of your document. Revise it based on feedback you received so far. It is rare that your product plan at this point is identical to the project pitch last week.
Additionally, add the following to this section:
The major features should constitute a minimal viable product (MVP).
Each team member must come up with and describe at least one use case of your product, following this template:
(At the end of this step you will have at least one use case per team member.)
Describe at least three non-functional requirements, e.g., related to scalability, usability, security and privacy, etc.
In addition to the requirements stated above, the course staff imposes the following requirements on your product:
Make sure that these requirements, if applicable to your product, are specialized to your project and included in your document—do not copy and paste these requirements verbatim. You may leave this as a separate section or fold its items into the other requirements sections.
Describe your quarter-long development process.
Export a PDF snapshot of your document named [project name]_m2.pdf and submit it to Canvas.
What programming languages, data sources, project trackers, and other tools will you use? What, if any, software components will you attempt to use “off the shelf” versus implementing them from scratch? Explain why you chose these tools and languages, as well as why they are suitable for your project.
It is OK to establish some of the answers during the requirements engineering stage and others during the design stage. It is also OK of some of these change as you continue working on the project.
A role describes the part of the project (or a set of tasks) a team member is responsible for. You can refine these roles as you continue to work on your project and you are free to change them as you go forward. It is important, however, to justify your current decisions.
Here are two examples for defining roles:
A typical web application project could have roles of: 2-3 backend engineers, 1-2 frontend engineers, and 1-2 engineers in charge of UI design (probably in addition to being frontend or backend engineers).
A data analysis project could have roles of: 1-2 people responsible for data collection and storage, 1-2 people responsible for data analysis and visualization, and 1-2 people responsible for infrastructure and automation.
Your group will collectively own its own work. If you think you may want to commercialize your project, you may want to consult early with a legal source. A resource on campus is Comotion. Most often, the main value of the CSE 403 project is to flesh out and test ideas, rather than to produce code that will live until commercialization.
Plausibility, thoughtfulness, and level of detail will largely determine the score for this assignment. For example, generic or incomplete use cases often lead to deductions. You should choose and clearly describe substantial use cases that are important to the core functionality of your product. You should also list a reasonable set of steps in the various scenarios that can occur in these use cases. Make sure to not omit important steps or details. Make sure that the state of the system at the end of any path through the use case matches what the use case claimed is the final state.
Your documents must be clear and professional. This means they should be concisely written, with proper spelling and grammar, clear wording, and formatted with supporting structure to present your ideas clearly to the reader.
You are developing a living document, which means you should expect change requests and iterations.
No, grading focuses on completeness and proper writing (clarity and conciseness). As with all writing, technical or otherwise, you want to completely address each thing that needs to be addressed (in this case, requirements) clearly enough to be understandable. Do not pad your proposal. Express it concisely and largely free of redundancy. (Use cross-references if necessary to avoid redundancy.)