What is the problem that your team is trying to solve? A problem statement should describe the gap between the current state and the desired state of an issue. It should also address when and where the problem was first encountered–– and by whom? That is, who is your user? What is the current impact of this problem, and why is it important to solve it?
At a high level, what is your team’s solution to the problem? This should describe how your team’s solution will achieve the desired behavior outlined above. What technology will your team use to build your solution, and who will it serve?
Check out IDEO’s guide on brainstorming here!
Will your teams’ solution cover all aspects of the problem, or just some? Which aspects, if any, do you expect your solution not to address? This is one of the most critical parts of defining a project.
What are the technical requirements and desired behaviors of your solution? How will you measure success and how will you define your project as ‘Done’? The technical specification should address inputs and outputs to your system and user behaviors. What is the expected load (# of requests, transactions per second, etc.)?
High Level Design
What are the software components that make up your solution? Which architectural patterns will you use and why? This section should include diagrams of your solution. What is your technical stack and why did you choose it? What frameworks will you be using? How will your solution handle it’s expected load and can it scale to handle even more? How will you ensure security in your solution?
If your team had unlimited time to work on your solution, what more would you do? Would you add new features or build a more complex, but potentially more scalable architecture? Would you improve the usability? Feel free to dream big here.