<aside> 💡 Use this Architectural Requirements Doc (ARD) template to document any architecturally significant requirements that you discover when planning and scoping a new project.
Treat the ARD as a living document, especially during the early stages of a project. Update it regularly with new information, and use it as a foundation to make architectural decisions such as deciding which languages or frameworks to use, how to structure a project, and so on.
Your Mileage May Vary: An ARD is only useful if it works for you. So feel free to adapt this template to the needs of your project and your team. Larger projects might require more detail, while smaller ones could use a leaner structure.
Read more about how to use this template:
</aside>
Use this section to briefly describe what this doc is about, the intended audience, and any other information you’d like to be immediately accessible to readers.
Date Started | 04/01/2024 |
---|---|
Date Last Updated | 04/30/2024 |
Status | WIP |
Project Lead(s) | Steve Aoki, Rick Astley |
… | … |
Explain at a high-level what is the problem that you’re trying to solve. This might be building an entire app from scratch, rewriting or refactoring a large portion of your app, or building a large feature.
Link to any relevant documents as well to give more context about the project, including:
Start by describing what are the goals different stakeholders have for the project. When it’s time to make decisions about the architecture, business goals will help you prioritize competing concerns and more accurately evaluate trade-offs.
Stakeholders may include anyone who is impacted by the system, not just the people who are responsible and accountable for them. This includes the users of the system and even the development team.
Stakeholder | Goal | Context |
---|---|---|
Sarah (Product Manager) | Increase adoption of the AI Shopping Cart Feature by 30% | The adoption of the AI Shopping Cart Feature has a strong correlation with revenue per customer. |
Megan (VP of Engineering) | Improve team velocity and cycle time by 25% | The new architecture should allow developers to ship features faster without compromising quality. |
Julio (User Persona - Shop Owner) | Reduce the time it takes to review and fulfill customer orders by 50% | Shop owners are sometimes unable to comply with their 2-day shipping guarantee because they can’t process orders fast enough. |
Constraints are architectural decisions that are made for you. They limit your options, but they can also simplify your problem by giving you fewer options to explore.
It’s important to differentiate between constraints that are given (and are unchangeable), and constraints that you give yourself to make it easier to design the architecture or achieve a specific goal.
Constraint | Context |
---|---|
Must use Vue.js as the UI Framework | The team specializes in Vue.js development and we have a fully-featured component library built with this framework. |
Must be deployed on AWS infrastructure | AWS is our only approved data processor for compliance reasons at the moment. |
Must be fully functional on every modern browser | Browser support is part of our service-level agreement. |
Must be fully responsive and fully functional on mobile devices | Half of our traffic comes from mobile devices and our native mobile application is still in the early stages of development. |
… | … |