Assignment 3 - Tech Choices, Architecture Diagram, Roadmap

The intention of this assignment is to get an initial sense of the direction of your engineering focus. By now you should have had enough time with your teams to know what you’re building. Given the project and the skills in your team, the goal of this assignment is to choose a tech stack, design an architecture diagram for your application, and fill out a roadmap.

None of this is set in stone. These are initial plans and I will be highly skeptical if they are executed exactly as you plan here. The idea of this assignment is to get an initial sense of what you intent to do, the scope of work, and start planning the rest of the terms work.

Since you can change you decision from this initial starting point, you should keep track of it. You will be expected to record in some way why the pivot happened and what caused the pivot to happen. A GitHub issue is a recommended place to record this decision.

You will be expected to work together and submit this assignment as a team. Anyone can submit it, I suggest using an issue on the repo you’re about to create to coordinate that submission.

Initial Requirements

  1. Develop at least 3 use cases and no more than 6 that you will implement for your MVP.
    • These should be accompanied with low fidelity sketches of UI where possible to illustrate your meaning.
    • They should take into account your tech stack and architecture diagram in points 2 and 3
    • These should adequately describe the use case for the teaching staff to refer back to for marking the remaining assignments in this course.
    • Use cases must be approved by CSC491/2600 teaching staff to be sufficiently complex for the course and sufficiently simple for the MVP stage of your product.
  2. Design your tech stack.
    • Under the DCSIL StackShare Team (
      • You must use the same GitHub account that you use with the DCSIL GitHub Org to sign into StackShare
    • Fill out your team’s intended stack, record the link to your stack in the DCSIL Team App for your Team’s Profile.
    • Record the decision for every piece of the stack in the StackShare Decisions feature.
  3. Based on your use cases, discuss the product requirements with all members of your team. Once that is complete, with the technical members of your team, design an intended architecture diagram
    • The diagram should not be highly detailed as you have just started. You’ll be using this to help guide your work.
    • It should include all pieces of your production infrastructure (emails, databases, caches, servers, email, background jobs, ML models, etc)
    • Include a short write up explaining anything that is not obvious
  4. Roadmap
    • Using the GitHub Projects feature, GitHub Issues, and GitHub Milestones record and intended roadmap.
    • The roadmap should include implementation of all pieces of your infrastructure, testing infrastructure, and development environment. All items in StackShare should be accounted for as well.
    • Setup a roadmap. The roadmap must go past the end of the term. The roadmap can include as much detail as you want with the following conditions:
      • Pretend like you are planning a company, not a class project
      • Must include your immediate next steps (short term up to end of the next month), medium term (up to 6 months in the future), and long term (6+ months).
      • Must include plans to perform user research
      • Must include low-fidelity plans for a launch date
      • You fill in the gaps. Be careful not to go too detailed as we have limited knowledge still.

None of this information is set in stone. Provide a basic insight into your initial thought processes, change the repo and StackShare as these insights evolve throughout the course.

Architecture Diagram

An architecture digram can be made in many different applications. Some common ones you’ll probably come across are LucidChart, Google Drawing, and MermaidJS (programmatic, not super powerful). When it comes to your diagram, I expect it to make sense and be grouped logically. It should try to indicate similar pieces of the architecture and make the paths between nodes flow smoothly.

Below are 2 examples of the same architecture diagram. These are real diagrams that we made for the Slack Application at GitHub.

Needs ImprovementGood!
This diagram, while it has all the pieces, failed to group the different systems together. The data sources (3rd party APIs) are even on different sides of the diagram. Logos are all different sizes, and arrows aren’t as smooth as they can be.This diagram has all the same information, however we have logically grouped the pieces into data sources, data storage, and monitoring. This gives the reader a clear indication of intent and architecture. This diagram made sure the logos were all the same size as size could indicate something like important, which we were not trying to do here. We also reduced the clutter of the arrows and removed all angles. This makes the diagram far easier to read and understand

Your diagram should follow these same principles. You do not need to include pieces of your stack that don’t touch production (e.g. GitHub), but should include all tools that do (like monitoring). You can see an alternative format in the F2019 team Klutch.


You must create a release on your repo. This will give us a snapshot in time and allow us to grade it.

Assignments are always due at 11:59:59pm Eastern Time.

Second, you must submit the release on the LearnSoftware application. You can find the submission location here:

Questions or Concerns?


Use CasesDescribes the use cases well. Illustrates UI with low fidelity sketches where applicable. Is approved by teaching staff30.0
Stackshare.ioDescribes the main technologies the team intends to use. For every technology, there is also a decision record. StackShare URL is added to the team profile in the App25.0
Architecture DiagramIncorparting all parts of the technologies in and adding adequate detail inside of those technologies (e.g. don’t just list React server when there’s major components to list), design an architecture diagram in the software of your choice. Include it in the team repo20.0
RoadmapRoadmap clearly captures in-depth details of the short term future (next week weeks), some light details about the medium term (towards the end of the term), and high level goals for the future (past the end of the term). Includes plans for significant user research.25.0

Rating Scale

This scale is used for each line of the rubric above.

Outstanding100% of pts
Strong80% of pts
Acceptable60% of pts
Insufficient40% of pts
Unacceptable0% of pts