Functional Requirements Exercise

[00:00:00]
>> Jem Young: And exercise: you are designing a mobile banking application that allows users to manage a single bank account. No, I said single bank account. Already we're scoping it down. We don't have to worry about savings or IRAs or different types, one bank account. So what are the questions you might ask? And then from there, what are examples of functional requirements that might come out of a banking app?

[00:00:29]
And you're saying, why do I have to ask the questions and then write examples of functional? The functional thinking is about domain thinking as well. And that's probably one of the most difficult parts. It's not just a technical requirement, it's what domain am I operating in? There's a difference between a banking app and say a video streaming application, very, very different domains, even though the parts are going to be similar.

[00:00:56]
So that's part of the challenge is stepping back and saying, hm, what do I know about this domain? I'll give you a hint for this one. Open your banking app on your phone if you have one or on the browser and take a look at, like what's happening there? How do you break that down as a system into these core requirements? So we just took some time to write down the functional requirements for a banking app.

[00:01:32]
So let's start with the questions that you might ask in this scenario, very, very real scenario. So, we already asked what types of transactions should the app support. So, already, if we ask that question, we're thinking critically about what does our app do? You know, what does a banking app do? Fundamentally, this is the fundamental question of anything. It's not just viewing money because that's most of what you're going to do.

[00:01:58]
I don't know how you all use your app, but you also want to see what happened before, where your current balances, should you be able to take money out, move it back in. Yeah, these are all questions we ask when you have an app. That's why I like the example of let's pull open our phones and look and see what are the functionalities. Maybe another question we might ask is around transaction history, something I've done, what is this charge from?

[00:02:30]
So we might say something like, how far back does the history need to go, transaction history? How long do we need to store this data? How often is that data accessed? Is it people routinely go back a year? That changed our data storage thinking. Is it 90 days and then everything else is archived somewhere and you have to, you know, do one of those request PDF and it builds a PDF as part of the workflow?

[00:03:05]
Could be that, but we don't know until we ask that sort of question. Speaking of transactions, have you ever had fraud on your any sort of fraud? Yeah, Bitcoin fraud, yeah, scammers. So, you know, a question I ask is, what level of detail? Do the transaction, what are those details? Is it the date, time, the account number coming in, coming out, when the money was sent and received?

[00:03:41]
Is it clear, you know, what does that look like on the screen? We don't know until we ask questions, and by getting those details, we're now building out kind of the entities in our mind and the schema in our mind. Cool, a transaction, what are the properties of transaction? It's going to have something like the amount, it's going to have a to and from, it's going to have a date, maybe if it is it successful, but only by asking these questions, we can start building this model in our head of like, what are we doing?

[00:04:10]
What, you know, what's something really important with banks that we didn't talk about yet? Something really, really important. Security. Yeah, so let's say, it already says we already said we should be able to use log in with a username and password. Let's say like what level of security on that, we'll say, let's go further and say, is there, say some level, is there a compliance we need to adhere to?

[00:04:50]
If it's a banking app, the answer is yes, there's some level of compliance. You want to make sure the transactions went through, they're all valid, the site is secure. If you send money to someone, it's not going to disappear in the ether magically, because they're all just ones and zeros these days, unless you're like Mark and you get briefcases full of cash every Friday, which, you know, that's his prerogative.

[00:05:15]
What else? What other questions? What do we miss? How real time does it need to be updated? That's a great one. Well, let's translate that down and say, mm. I'd say, you know, what are the performance requirements? I'm debating if that should be a functional or nonfunctional. It's kind of in between, those sort of are, but we'll put it here. Say what are the performance requirements?

[00:05:55]
It's probably different for the reads and the historical data versus what's your balance. Yeah or hm, maybe a different way of thinking of that is, what are the user expectations when it comes to sending money? Is it okay if it takes 2 days or 3 days? Yeah, that's a good one. How do you show pending or do you need to show pending? Or I'll say, how do we display status, transaction status?

[00:06:40]
Yeah, how do we alert users for fraud or important notifications like deposits, stuff like that. That's a great question. What, we'll see what types of notifications do we show, say slash send the user? Yeah, maybe there's not, maybe that's out of scope. Maybe that's the most important thing in all this is understanding fraud, then that's the question they're trying to answer is how you design a system that's secure and fraud resistant.

[00:07:15]
We don't know until we ask these questions. Basically, I think specifically because it was a mobile application, I was just thinking, okay, what protections do we need in case the user accidentally loses their phone or it gets stolen? But then also I guess I was just thinking, okay, well, how does this mobile application fit into the ecosystem of what might already be there because I imagine there's already like other stuff, especially with like bank tellers and stuff like that.

[00:07:50]
Hm. How would we formulate that down into, yeah. What do we do if the phone was stolen? I'm debating if that falls under like just general security and like consideration, but I think it's just more strategies around like auto logging out and stuff like that. That's a good one. Invalidate sessions. Well, that's a fancy word. How do invalidate sessions slash log a user out? Yeah.

[00:08:28]
That's a great requirement. It's not like your Netflix password that you accidentally left logged into the hotel and now everybody's watching, I don't know, Teletubbies on your account, you know, a bank account, you want to log people out, you have to. You don't have to, it's a feature, but it doesn't have to be. It's a good one. Okay. These sort of in the ballpark of what you're thinking for features, functional requirements.

[00:09:02]
Anything major we're missing? There's probably also some government regulations and things you got to deal with. Like what might those be? Yeah, we'll roll that into compliance. I don't think banking falls under GDPR or something like that, but it might. I don't know. It's like a book. I think there might be something around login sessions, but I'm not sure. Do we need more requirements around like the front-end presentation like which mobile ecosystems it's going to be a part of, like iOS or Android or?

[00:09:47]
Maybe I'll ask you a question back, what would that change? Maybe you pick a tech stack that easily compiles into both platforms or something if such a thing exists, yeah. Mm. Trying to roll it into a, because I like the point you're making, because there are different ecosystems. The two main mobile are Android or Apple and Google, and they are very different ecosystems. What Google allows sometimes Apple won't allow, and vice versa.

[00:10:17]
Hm, how do we roll that into a question? Because that's where are their users currently? Are there most of their users on Apple devices or most of their users on Android devices? So what is the primary device type for users. Does it have to support Apple or Google Pay? That's a new one. I'm trying to think if I want to be that specific or I want to say like what ecosystems do we support?

[00:10:55]
We'll be specific because mobile is generally just two. So do we have to support Apple or mobile wallets, I think is the, oh, mobile wallets, yeah, generic term. Mobile wallets. And we can keep going. And likely you have questions on here that, you know, we didn't ask. But the whole point is, what do you need to know to feel confident in your design? You don't have to ask 100 questions.

[00:11:17]
It's what are the broad ones that help you scope it down, and narrow it down and narrow it down. This is what I need to focus on, this is what I don't need to focus on. If I don't need to focus on notifying a user or alerting them in some way, that cuts out a lot of scope for us, honestly. But if that is the thing we have to focus on, that also cuts out a lot of scope and not focus so much on transaction history or something like that.

[00:11:45]
Good questions to ask. So when it comes to, based on these answers, and this is where it's going to get, you know, your answers are going to be different from mine, and that's okay. It's more, how do we scope this down? What are some examples of functional requirements that you all wrote down? The one related to how far back history needs to go, we could say the user should be able to view transactions and export these transactions to a PDF or CSV for the last 12 months.

[00:12:31]
Something specific that can be modified if there's a disagreement. Yes. Yeah. And Monica, I'd like you to put the specific time period in there, not just users should be able to export transaction data. How far back? It's okay to be specific, 2 years, 5 years. You know, maybe that factors into our design, maybe it doesn't, but it doesn't hurt to have that level of specificity.

[00:12:50]
Odds are when you're giving a system design interview, that it's usually like a list of 3 or 4 bullet points about the system that are relevant and that's what they're trying to get you to ask the question so they can give you that answer. Everything else they'll be like, ah, it's not material, or just pick a number, 1 year, cool, doesn't affect what we're trying to do. But it's helpful just to know, because maybe that is the critical thing they want you to ask.

[00:13:36]
What else? Users should be required to set up MFA. Hm, multi-factor authentication. Users should probably be able to use their money to make payments or transfer money through the app. Able to transfer money. Say receive money as well, I would assume, maybe not. Yeah, I think that's on probably in the behind the scenes. Maybe. Should we add transfer immediately or schedule? Oh yeah.

[00:14:35]
Report fraud. Maybe, Mark, some from online are search and filter transaction history, categorizing transactions and budgeting, some banks offer that. You can put it in there. And then how about currencies supported. That's a great one. Yeah. What currencies do we support? The only currency. Keep it simple. Hm. Lisa, the balance shouldn't be able to go below 0. Debating on that one.

[00:15:17]
Users should always see a real number for the balance. Not a number is not a valid. I guess I mean like you can't overdraw. They don't allow a user to overdraw on their account. Mhm. Like if they are making a transfer. Don't let them go below. But maybe there are instances where transactions cause them to go below. Yeah, well, I like where you're going. I'm debating where that falls.

[00:15:50]
Because we could say, yeah, users can't go below 0 or have a negative balance. But is that realistic for a banking app? I don't know. Or what, I guess, what would it change if they did go below on our end in terms of system design, that's more of a logic. There might be alerting, notifications or a message in there. Mobile app. Oh, what do you think, Lisa? Is that a good one? I'm just thinking with the confluence of like scheduling transactions and like, you know, we support this type and this type and transferring and withdrawals and they all kind of take different amounts of time and like.

[00:16:49]
How that will all happen in sequence. Yeah, I like that. Hmm. How do we quantify that as a functional requirement? Users can't send money. I don't know if that's super. The money if their balance is below 0 or something like that. Yeah, I can't think of how to wordsmith, but yeah. Users should see transactions localized to their time zone. Hm. Yes, let's step back one. What are we missing in a functional requirement?

[00:17:33]
We asked the question, we never answered it. Oh, like what things should be displayed in general? Yeah, yeah, so. Who sent it? The amount, the date and time it happened, maybe which account or. We said this is one bank account. There aren't multiple accounts here for the requirements, right? Okay, so we don't need to show like which account it's happening in. Status. Yeah. Then you said users should be or.

[00:18:06]
We'll say all daytime should be localized. Yeah. That's an interesting one because it takes us in a very different direction on the problem we need to solve if you're saying like, hey, how do we rectify transactions, sort of to your point, Lisa, like that's a very different problem and then we're thinking more critically about the databases we choose and. How do we process those transactions?

[00:18:40]
Like what are the geographical requirements in terms of, like, you know how you get alerts if you're using your card somewhere in like, I don't know, Europe and you didn't notify your bank or stuff like that? What is the performance requirements? I go along with that or is a user local for most of the time, are we trying to support locality first or kind of global CDN computing.

[00:19:09]
So we'll shorten it down, say users are located in the US. Keep it easy, but yeah, it's a good question to ask. Okay, we'll move on to the next one, mainly because we can keep going on these. These are great. But what's, you know, what's the hard part here? Figuring out what you want to cut out to just design the MVP. Yeah, there's a lot here. We're talking about very different things.

[00:19:33]
So asking the right question helps us get down to, okay, they said this, they're only in the US, so we're probably localized. Daytimes probably aren't as important in this particular instance, but maybe we're saying no, this is a global banking app, and you think, oh, okay, so that's going to impact my system design because they're telling me that. And that's the assumption I made.

[00:19:58]
And then the other one is. This is really hard, isn't it? You have to think really critically about something that seems trivial. It's an app. Easy. Send money, receive money, how much detail do we need there? And we need a lot and to me personally, this is the hardest part of system design is just dropping all of your assumptions and it's kind of leveling yourself up in the domain, becoming that product manager, asking these sort of questions, and that's hard.

[00:20:30]
It's just a skill. Some of it's instincts, some of it's just. Oh wait, what's my strategy? How do I want to think of these? What's the questions I should ask and ask the baseline questions and then get to the specific functions. Okay. Yes. Case in point for me was like what was the what types of transactions should the app support? Like when we were doing the exercise I was already so far ahead of that and I just assumed that that was figured out.

[00:21:08]
And I didn't even consider that as a question or a requirement to put into that, so. So looking at this, kind of based on that, Michael, you know, what's the main entity we're thinking about here? Like, what's the most important thing here? Or the thing we're designing around. Business requirement. A user more specific. The transaction. That's the thing that comes up that we're talking about the most, the transaction is what's most important here.

[00:00:00]
We also didn't say the account balance, we kind of took that for granted. And that's, I think it's okay for a banking app, but you know, it's good to write it down. Hey, users should be able to see their account balance. We didn't write that down. We assumed it. But really the transaction is the most important thing here because that's where all the details going.