Non-Functional Requirements

[00:00:00]
>> Jem Young: And that's what non-functional requirements are all about: understanding consistency, availability and fault tolerance or partition tolerance, and then targeting system quality. What aspects of system quality are the most important here, and that's what non-functional requirements are. See how I tied it? I told you I tied it all together. I'm like, oh, Jem, why are you taking this detour over here?

[00:00:22]
Because if we just did non-functional requirements, you'd say like, cool, I'm just answering questions. What are the monthly active users? What's the response time we're expecting? Why? What does it matter? We have to understand all these other things before we can answer these questions. But the good news is, and I have good news. When you start building an instinct for these, it gets a lot faster.

[00:00:45]
You look at a system and say, oh, e-commerce, gotta be consistent. Performance, maybe, let me ask about that. That's the thing I care about. Secure, yes. And you start just building the instinct for these sort of things. Example of non-functional requirements. How many users do we expect? This should usually be your one of your first questions, because that matters. Remember how I sort of tricked you all earlier with the build a to-do app and it was just a single app.

[00:01:18]
That's because we didn't ask how many users are we expecting. Easy, easy one you ask. The trick here is, is users the most important thing? Maybe it depends. I know, Jem, you're not giving us the answers. Yeah, I know there aren't easy answers to these. I got burned by this question a long time ago because when you ask this to a product team, they're going to give you their biggest expectation eventually.

[00:01:53]
But when you go live, you're not going to have that, so like some of our systems were way over scaled, and this was before we were in cloud, to handle basically the lifetime load of the product we're replacing, but we weren't going to hit that until like year two or something like that. It's a, what's the product term of this real thing? Swag? Yeah, the wild ass guess. Yeah. These are guesses. Nobody's going to be able to tell you, oh, it's going to be a million users at 12 o'clock, and then about 3 a.m.

[00:02:30]
It's going to be 10,000 users, something like that. They're probably not going to get to that level. So we're generally thinking when we ask how many users to expect, what's the maximum we're looking to expect. And then if we design our system well, it should be able to scale down and scale up. But we also ask, to your point, does that number change over time? And does that matter if the number changes over time?

[00:02:57]
Good question to ask. But maybe it's not the users, we're saying, what's the monthly active users? Maybe that's important. But if we had something like our URL shortening service, is the users important or the requests per second more important? Again, you, I mean, you can ask all these things. How many users do you expect? What are the average number of requests per second? Or you break that out, what are the users doing like we did in to-do app?

[00:03:26]
If I had 1,000 users in my to-do app, how often are they writing per day? I don't know, three to-do's, and we do the math on that. We can get a rough traffic number on RPS. How consistent does the system need to be? I won't bang this one anymore because we talked about it, but is it important that users see slightly outdated data? If it's okay, they see slightly outdated data. An example of that would be, I don't know, a news homepage.

[00:03:55]
If they're getting news from an hour ago, that's probably okay, not the end of the world. If I have, I don't know what's a good example of something that has to be consistent or it's not acceptable to see outdated data. Stock market trading can't be out of date. There's money riding on this. You can't make a transaction in E-Trade if, you know, that stock number is wrong. You're talking about a lot of money here.

[00:04:20]
Again, there is no giant playbook for figuring these things out. It's just intuition, a lot of it, and asking the questions. So then we get to what's the most important metric here. Is it the performance? The system has to be fast, has to be. Otherwise people are going to leave. Maybe I am Amazon. That 100 milliseconds is costing me tens of millions of dollars, so the performance is the most important metric, the latency.

[00:04:49]
What is the maximum acceptable latency? Then we get more on the data side. What data does need to be protected? Anybody ever worked with medical data, know about HIPAA compliance? Yeah. Yeah, HIPAA, HIPAA is fun. And I mean fun in the not fun way. HIPAA, one of the requirements is the data has to be encrypted at rest, which means that database, you can't just look at it, you have to go through a series of checks to be able to access it and everybody does in every single request.

[00:05:23]
What does that make the system? Slower. Slow, yeah, it's slow. It's slow to have a secure system like that. Also, when you start talking about how does that database talk to other databases where it's maybe not encrypted data, they also have to do all that, and so it adds a lot of complexity. So it's important to ask what data needs to be protected. All of it, some of it, none of it, and really non-functional requirements define the system quality.

[00:05:50]
And I'll hit it again. It's a tradeoff. You can't hit all of them. I can tell, we'll just do the banking one as an independent exercise because I want to see how you all do. Then we'll do the URL shortening one together.