These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents
Max knows that the goal of the software to be built is to match potential team members based on their skills to a team. But that is not enough knowledge to start designing a software architecture.
Max organizes an initial requirements workshop and invites all stakeholders.
The stakeholders discuss two kinds of scenarios. The functional scenarios describe the functionality of the software: Adding employees, adding skills, defining the needed skills of a team, matching team members to a team.
The non-functional scenarios describe the quality attributes of the software: how fast should it be, what availability is needed, how long should the software life and so on.
Whenever Max stumbles over a risk regarding technology or business or a question that cannot be solved directly, he notes them for later.
The results of this workshop are a quality tree, the initial version of a product backlog for version 1 and a product road map for future versions of the product.
The quality tree describes the quality attributes – non-functional requirements – and the trade-offs between them. What is more important? Security or easy usability? Performance or maintainability?
See Quality Cheat Sheet for a list of quality attributes and how you can increase quality in your software products.
The product backlog describes the functionality of the first version – as far as currently known. The road map gives Max a glimpse into the future, how the product may evolve. Remember that Max works in an agile way, so the needed functionality will change once feedback from real users will be gathered.
With the knowledge about the quality tree, the product backlog and the product roadmap, Max can now design an architecture vision. The architecture vision describes the direction into which Max’s team will build the system. it is coarse and leaves a lot of open questions, but the vision is a guide for making design decisions. Max can use the vision to prevent dead-ends that would prevent the software from reaching the vision. Not always, but most of the times.
Continue reading: Incremental and iterative
[…] Where to start when there is just a product vision […]