<aside> 💡 This document contains a set of tasks (tactics) to achieve the goals described in previous documents. It contains a list of all technical tasks, user stories and C-diagrams with architecture overview.
</aside>
<aside> ℹ️ Why is this document important: this gives a clear picture of the architecture, product design, modules, interfaces and data for a system to satisfy specified requirements.
</aside>
This section should help you convey your idea and all the findings gathered so far. This will help your development team to understand what needs to be created and what is the expected outcome for each implemented functionality. Having a clear outcome will set the right expectation and will give the team a sense of purpose.
<aside> ℹ️ User stories should convert each item form the list into a sprint-size work item. Make sure that you specify who will benefit from this user story <user>, what they want to achieve <goal> and what is their motivation to do so, or what is the <outcome>.
</aside>
<aside> ℹ️ Job stories are quite similar to User Stories except they are not strictly bound to a specific user. In most cases, job stories are being used to describe the behaviour of your backend.
</aside>
You did an amazing job so far! Seriously, every piece of this puzzle brings so much clarity to the team, and there's no doubt that the product will be a huge success. After sharing these insights with your engineering team, they will create an architecture overview to accommodate all these features. One of the best tools to visualise the architecture is C4 model.
<aside> ℹ️ The C4 model is an easy to learn, developer friendly approach to software architecture diagramming. Good software architecture diagrams assist with communication inside/outside of software development/product teams, efficient onboarding of new staff, architecture reviews/evaluations, etc. You can learn more about it here.
</aside>
<aside> ➡️ A System Context diagram is a good starting point for diagramming and documenting a software system, allowing you to step back and see the big picture. Draw a diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interacts with. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details.
</aside>
Add your Context diagram here
<aside> ➡️ Once you understand how your system fits in to the overall IT environment, a really useful next step is to zoom-in to the system boundary with a Container diagram. The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It's a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike.
</aside>
Add your Container diagram here