Subscribe to access the entire course.
🌶️ tip: unsubscribe at any time.
Ah, that's a great question!
Frontend at Scale is a bi-weekly newsletter (as in, once every two weeks) that is all about software design and architecture for frontend engineers.
Subscribing to the newsletter is the best way to support my work and encourage me to keep making free resources like this one.
I probably don't need to say this, but I would never ever spam you—and you can unsubscribe with a single click at any time.
Already subscribed? Don't worry, you won't get double-subscribed. Nobody deserves to read my terrible jokes twice.
Module 2: Understanding
[00:03] Let’s talk about architectural requirements. As we talked about in a previous video, these are influenced by the architectural drivers that we discussed. And you can think of the architectural requirements as a checklist with the success criteria of your architecture. These are all the things that your architecture needs to have in order to be successful.
[00:24] So I put together this doc with the architectural requirements for the FullSnack project. On a real project, you probably want to have a doc that is, you know, as nicely organized as this one. You will have to discover the requirements yourself. There are a number of things that you can do to discover the architectural requirements of your own projects, and we’ll talk about that at the end of this video. For now, I just want to focus on going over some of the more important requirements in the FullSnack architecture.
[00:54] So the way that the doc is organized is using the same categories and different types of drivers that we talked about in the previous video. So we have a section for business goals. We have some constraints, some quality attributes, influential functional requirements and other influencers, which are not really requirements per se, but these are things that will definitely influence our architecture as well.
[01:18] Let’s go over some of the more important architectural requirements in the FullSnack project. So first of all, we have business goals and as we mentioned earlier, these are often overlooked because these are things that we sometimes take for granted, but they are clearly important because these are the things that other people in the team, other stakeholders, might have as the success criteria in their mind for the architecture.
[01:42] So the CEO wants to invest in this development of this app because they want to increase customer orders. The VP of Engineering wants to increase the velocity. A frontend developer in the team cares about shipping to production confidently without fearing of breaking their teammates’ features. And the consumer cares about ordering food from their phone or computer and having it delivered as quickly as possible.
[02:08] Now, these are things that some of them might seem obvious, of course, but we have to keep in mind that even if we develop the most beautiful design architecture, the fastest architecture in the world, it increases the velocity by 100%, but it doesn’t allow customers from ordering food, then we can’t really say that the architecture is a success.
[02:30] Then we have a few constraints. We have a couple of technical constraints. One of them is that we must deploy to an AWS infrastructure. That’s because our DevOps team only supports AWS and we want to get support from them and then we have to use it. Then we have that we must be responsive and fully functional on mobile devices because we don’t yet have a mobile application. And that we must ship to production in the span of four months.
[02:55] These are remember, these are non-negotiable. In this case, we have to align with some marketing initiative, so we have to ship something in four months. It doesn’t mean that we have to ship all of the features, but it will be up to us to determine, you know, the priority of the features. To determine the core functionality we’ll ship in four months and then which features are not as essential.
[03:16] Then we have a section on quality attributes and these are some, so we have a couple of high priority quality attributes, one related to performance, a test that a user on a mobile device with a 4G connection can load the app in 5 seconds or less. These are, you might know these as nonfunctional requirements as well. I like to use the term quality attributes because not all of them are really nonfunctional and we can argue about what is functional, what is nonfunctional, but quality attributes refer more to the actual characteristics that we’re trying to promote.
[03:49] Performance, scalability, accessibility, and the nonfunctional requirement will be more related to the scenario, right? So these are specific scenarios where we must comply with this. These are quality attributes for our architecture to be successful. This will determine, you know, what is important, how do we make certain tradeoffs.
[04:10] Then we have some influential functional requirements, which we’ll talk about in a minute, and then other influencers which may come to, yeah, they will come into play as we continue working on the design of the architecture. So first we have that our frontend team is a single team of four developers right now, but we’re going to grow the team in size. We’re going to triple in size over the next year, so the team composition might change. That will happen. We might have multiple teams instead of just one. So maybe the way we organize the code will be influenced by these different teams.
[04:43] Then we have another influencer that is that frontend developers are experienced with React and NextJS. Yes, and some of them are comfortable using Vue and Laravel as well. This also may come into play when we make architectural decisions about which technologies we’re going to choose. And finally, that not everyone on the team is comfortable working with TypeScript, which may mean that you may decide not to use TypeScript at all, or you might decide to spend some time training the team, doing courses, reading books together to get them more familiar with this language.
[05:20] The decision would be up to you as the architect of this project. So we talk about how on a real project you will have to dig out these requirements yourself. And the way you do that is by doing essentially by talking to people. You have to talk with different stakeholders. You have to talk with maybe potentially users as well, have to talk with your team, with the PMs, designers, and essentially figure out what they care about, what are their wishes for the architecture.
[05:45] It doesn’t mean that you have to comply with all of them, but this will give you an idea of what people care about the most, and it will give you, you know, an understanding of what quality attributes you should care about promoting and how to prioritize them as well. Architects have a number of tools in their toolkit to make this process a bit easier, which are essentially activities that they can perform with their teams or with different groups of people to uncover these architectural requirements.
[06:14] I will link to some of my favorite resources in the description of this video with some of the activities that you can do with your teams. But if I had to call out just one single resource, it would be the book “Design It”. We talk about “Design It” earlier when we describe software architecture. This is the book where we grab the definition of software architecture, and the book has an entire section on activities that you can do to, you know, to uncover requirements during the understanding phase, but also across the entire design and implementation process as well.
[06:46] So I highly recommend if you’re looking into, you know, if you want to dive deeper into any of these advanced activities or tools and techniques, I highly recommend grabbing a copy of this book. Also, if you want to put together a document like this one, you can of course use this file as a template. This is a simple markdown file that you can use for your own projects.
[07:08] And you can also use this template that I have. These are more a more complete template that is in Notion. But of course you can copy and paste this anywhere you like and it essentially has the same contents of the other doc that we saw. But it has a bit more information about how you would use each one of these sections. So feel free to take a look. There is a link to this template as well in the description and is of course free to download and use.
[07:34] Now the last thing that we need to talk about is influential functional requirements and we’ll talk about in the next video because that is going to be the second exercise of the course.