Strong Foundations Start with Strong Requirements

Welcome to Building Better Developers, the DeveloperNord Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season of Building Better Developers, the DeveloperNord Podcast. This season is actually titled Building Better Foundations. We have mixed in some interviews, but this episode is not going to be an interview. We're going to talk about the foundations of gathering requirements. That is like the mother of all foundations for software projects. And so hang out because we're going to dive right in that a little bit. But first, I'm going to introduce myself. My name is Rob Broadhead, one of the founders of Development DeveloperNord, also the founder of RB Consulting, where we help you do technology and your business better. Think about it like a doctor coming in or financial analysis or any of those kinds of things. Anybody that would be like, say, a financial or medical healthcare consultant, we are a technology consultant. We're going to sit down with you. We're going to talk about how you're feeling, how you're doing, what are you looking for, how's your days going right now, and then what are your days looking like in the future. Because with that, we're going to get the ability to understand who you are, your company, So we can craft a recipe for success for you. We're going to call that a roadmap. We will give you a technology roadmap that says, hey, based on where you are and where you want to be, these are the things you should do. It's going to be technology agnostic. We're not coming in there and selling you Oracle products or Microsoft products or NetSuite or blah, blah, blah, blah. We're not going to sell you that. We're going to talk to you about what matters for you, what matters for your budget, what matters for your staff, what matters for your line of business. We're going to help you with a custom built roadmap that is just for you. You can check us out at rb-sms.com. If you go to rb-sms.com slash product.php, you can dive in right away and you can have a technology assessment roadmap within a few days. There's also a lot of other products and services we have there. Not to mention, you can reach out if you have questions. There's a contact. I would love to have a conversation with you about that. Good things and bad things. Good thing is it is getting into the later months of the year, starting to cool down a little bit, things like that, which makes like these are my favorite nights. I love it when you have like a moderately warm day, you get a cooler night. It's perfect for like, you know, kicking back and having a little adult beverage and stuff like that. The bad thing is that it gets dark early and me being, I'm now being older and older than I am by the time it's dark, part of my body is like, okay, it's bedtime. And then also getting up in the morning sometimes is a little bit off of my normal schedule, which makes it a tad of a challenge. But I wasn't able to get up today and get going just like my cohost is going to go ahead and introduce himself. Hey everyone. My name is Mike Mollach. I'm one of the co-founders of Building Better Developers, also known as Developner. I'm also the founder of Envision QA, where we help businesses take back control of their system. We will either build you a custom software or help you find something over the counter that meets your needs. Our focus is simple, great service, smart solutions, and rock solid quality. We build tools that replace frustrating systems, streamline your operations, and are fully tested to work right the first time. At Envision QA, we combine development and quality assurance to give you software you can trust and support you can count on. Check us out at EnvisionQA.com. Good things and bad things. So similar to Rob, it's fall. I'm really enjoying this season. Halloween is right around the corner. I'm really looking forward to it. It's one of my favorite holidays. Downside, it just means that we're slowly moving into winter and it's going to be getting colder and I'm not looking for work to stop. Sometimes I have to hit my mute button a little faster. So we're going to talk about requirements gathering. Now we have talked about in the prior couple episodes where we were talking and not doing interviews, we talked about low code and no code and we talked about AI and we talked often about requirements. We got into that quite a bit and user stories and some of those things. I want to focus on the foundational skills of requirements gathering and how to do better, particularly when you're starting out. This is I think the biggest challenge is that when you come out of college, school, whatever it is, even a boot camp, what you've originally come out of, how you learned your skills was based on being given requirements. You had a homework assignment or a lab and it said, well, this is what you're supposed to do. You didn't, you probably, unless you had a software engineering class or something like that, you probably did not have a situation where there was an open ended solution, an open ended problem where you would have to actually go find a problem, figure out the requirements and then go build the solution. It was always spoon fed to you. And even as junior developers, we were often given that it's like, here's your task, go do it. Here's what you need to do. Go do it. Now that means that we usually don't get into the point where we're part of a requirements gathering effort until we actually have moved along a little bit. Now we have a habits that have nothing to do with requiring gathering requirements. And we're being asked to do something that technically probably we have never done or not done enough of it. So I want to talk about the foundational skills of gathering requirements all the time is making that part of your process, making it part of your building software. So even if you're brand new, if you're into, you've got a task assigned to you and it says, I need you to build a function that adds these two numbers and kicks out the result. Get in the habit of asking questions about it. Ask, find some, like take an extra step to get either to clarify the requirements or to get more requirements. So for things like this, like let's say you are given a task. It's just says, I'm going to be, we're going to give you two numbers and you need to put the, you add them and kick out the summation. Cool. So ask them, well, are these numbers always going to be, you know, are they going to be individual? Should we ever worry about maybe we're going to send them as a comma separated values of one and two, or is it always going to be two numbers? Or do these numbers need to be positive? Could it be negative or are they always positive? Are they integers or are they maybe decimals? Does the output need to be a number or should it be a string? Should there be some sort of a user friendly message? Is there some additional formatting we need? I mean, there's, I know it feels like, cause I just did this. It feels like belaboring a point, but I think you can pick a couple of key questions like that and ask those and maybe you don't even have to ask them. Honestly, if you just go through the exercise of what are all the things I need to know, then now what you're doing is you're gathering requirements and you may be able to answer all of those questions based on what was provided. So you don't have to gather more. But the whole idea of saying, okay, well, what do I think might be the requirements or what are some clarifications that I need for this? Doing that process and either going back to the original, the source material, you know, maybe it's the task that you were assigned or whoever assigned you that task or whoever owns it so that you can ask those questions will help you build those skills. It's really about analyzing the problem and then saying, okay, where are there gaps? Where are there holes? Where are there things that are that are cloudy and they need to be clarified? So those are my thoughts at the start and your thoughts requirement foundations. So requirement foundations to me. So I liked how you kind of laid it out. But to me, when I think about requirements, like you were talking about how you're getting an assignment in school, I look at cooking. Cooking is a great example for requirements gathering. You can't cook something unless you have a recipe to follow. So you go to a cookbook, you go to your, you know, post-it cards from your grandparents. Usually you have some step-by-step instructions on how to do something right. If you deviate from those requirements, you do not get the desired result. You get something that is different than the expected outcome from what you were expecting. It's like if you want chocolate chip cookies, don't add raisins. You're not going to get chocolate chip cookies. You deviate it from the requirements. And when you go to getting requirements or trying to define the requirements for a project you're working on or just trying to understand what someone wants for software, it's getting down to those nitty gritty details of the step-by-step instructions you need to kind of build the application. The problem a lot of times with requirements gathering is sometimes the people you're talking to don't know everything that they need for the system. They may have an idea of what they want and as they're explaining it to you, you're getting a small slice of the picture. You're getting a very narrow view of the requirements. And if you're just starting out, you may take that at face value and you go build the application and what you discover by the end of the application, it's like, oh, this little thinly slice is not what they need. They need something bigger than this or they need something different than this. You gave a good example of, you know, like an EMR or a HR application for someone with no employees. When you go to talk to someone about building software and you want to gather the requirements, ask them multiple questions about what it is they want. Don't just assume that they know what it is that they need or what the steps are. Sometimes they do, sometimes they don't. And many times we have been burned and we burn many hours trying to build an application because the requirements are constantly changing because we'd never quite nail down what they were or what we were told at the beginning is not really the application that we're building. So you have to be careful and kind of roll that back at the beginning and have checkpoints. Not only start with the requirements gathering, what it is, what's the why and why do we want to build it and how do we want to build it, but keep checking in. Okay, here's where we're going. Here's what we're building. You know, in previous episode, we talked about building wireframes or building a workable demo. That's one way to do it. But the requirements is before all that. You need to really understand the why. And as you're going through those requirements, if you are reading them and you have an if then for a line item on your requirement, your requirements aren't defined. You have multiple paths. You need to go back and figure out what is the actual requirement. Requirements should basically be true or false. If I do this, it should be this or this requirement is this. It should not be open to interpretation. It should not be, oh, the user wants them to enter in some information. Well, is this information alphanumeric? Is it a merit? Is it password restricted? There are many questions that could come up from just that one open statement that you don't want. The requirement should be plain and simple. We need an input box that takes a password that is hash code that meets these requirements. If it's not plain and simple like that, you are missing something and you're going to be running into problems. I think I like the idea of trust, but verify, particularly when someone comes to me with a I want X. This is the solution I want. I think the best way to start with that is and granted, we're getting a little higher level with these, but it's it's things like, OK, well, what does that look like to you? Tell me what like does say I want to see RM. Well, what does the CRM mean to you? What does that include? Now, you can offer suggestions if they if they need that. But a lot of times it's like, well, what does that mean? What does that include? What features are involved in that? And sometimes you can throw stuff out there like, well, you know, a lot of people that have this kind of system, this is a feature that they use and they'll find it and you'll hear those like, I don't need that. Like, OK, well, cool. Then we won't we won't build that. Where so? Yeah, there are things that are assumed. And it's within any industry. There is a language and there are certain things that their words mean different things and specific things depending on where you're at, what your vertical is and things like that. Those are the things that you need to learn. Those are the things that you need to clarify, because just as somebody says they need, you know, this kind of a system, they need like, I don't know, really, people say, well, we need full stack developers. OK, what does that mean? Why? Why do you need full stack developers? What do you need there? Like, well, that's what I heard. And they'll say I've I have seen a I generated stuff all over the place that says that we need, you know, requirement for like a developer position requirement must know. And it will say Java, PHP, Python, Ruby, Delphi, Ada. I don't know. It'll give you like all these things. It's like you will see requirements that are generated. That's like, where did you get that? I think, oh, well, I told me. It's like those are contradictory. You need one. You don't need all of those. And that's so often is the case that we run into with requirements is that we have these things where people say, I want this and this is how it needs to work. And what they're doing is they're getting ahead of the requirements. They're trying to implement it. And a lot of times it's like, wait, let's back this up because I don't think you really need that. I think you need this thing. And that actually solves that problem and solves it better than the approach you're taking. But to do that before you can have that conversation, you need to back them up and say, why do you need that? Explain to me why you need that specific thing. Why do you need that feature? Why do you need that function? What purpose does it serve? What is the why? And then we can figure out whether that makes sense or not. And it's like, how are we going to do that? And we can put the requirements into it and we can dig a little bit deeper. Requirements gathering is always about saying, and then what? OK, so you want that great. And then how does that look? And then what? And then what happens after that? And then what is the expected outcome? And then how do people get notified? And it's it really is trying to reset yourself to the mind of a two year old so that almost every question that is asked, you're looking for questions around it because you want to learn more about that answer. That is how you're going to get better requirements. Thoughts on that? Yeah, I like the and then what? The other thing I'll throw out is as you're talking to your customer about what they want, expand on what they need, stick to what they want and within that area. But be careful that you're not just getting the nice to have or the happy path, because sometimes there are edge cases and things that are in their head that are automatic for what they do and they don't think about them and they're going to be missed from the requirement. So you can get the core like this is what I need. But you're going to find out very quickly that there are other components or other pieces that need to be built around this that could actually change the core requirements. But unless you can figure out how to kind of get that pull that information out of them, you're going to miss that. So as you're doing that and then why are you doing this and why? And the next thing, make sure you also say, OK, you're doing this, but watch for those things. It's like, oh, well, what else can they do there? And try to expand their thoughts on what it is that they're doing if this is an existing system. Now, if it's something new that they're trying to build from their mind or maybe they've written it down on a notepad, still get to the core requirements, but make sure that you cover enough of the features that you need to build the application. Because one of the things you run into a lot is that the customer, the person wanting the application builder does not always think in tech. And they may not be technical at all, so they may not know the right questions to ask or the right information to convey. And that's our job. We have to ask the right questions and we have to pull that information out from our customers. And that's a lot of it is with your your general requirements stuff when you're starting out, there's going to be you're going to have this goes back to like building your foundations. You're going to be assigned certain tasks. They're going to have, you know, they may say it may be big tasks, it may be small tasks, but usually almost always actually, I guess, when you're starting out, those are going to be part of a bigger thing. They fit into a bigger solution. You're not building an entire application. You're building something that is going to fit in to an existing application. You're probably working with other developers or code that's been created elsewhere. And those requirements questions are great to ask then, it's like, OK, we have this piece. So I'm building this little feature, this function. Is there already maybe like an administrative because it's going to take some administration? Is there an administrative piece for this? Is there a report that is going to utilize this? Is there a navigation menu item or a button or something like that that's going to trigger this? Is this need to be run as a microservice or so? Is this something that's going to be run without any kind of UI? Is there if there's a user interface, what are what sort of interface is out there? Those questions may not. May not be critical to you getting that task done, but they may be very informative. It may be things where you're going to say, all right, this is going to be displayed on a phone or some very small device. So I can't have real big, lengthy messages are going to be kicking out or, you know, the text response that I get back. I've got to limit that. Or maybe I'm going to be able to have a way to have a have two versions of it, a long and a short version of it or things like that. It may be things like what kind of a system are we building this in? These are getting used to the questions that are parts of systems, things like is there logging? What sort of exception handling is there? What sort of messaging and notifying notification system is there? Is there some sort of authentication thing that I have to verify or take a token or something like that to make sure that there's an authorized user of this feature or this function or this data? Those questions are the questions that a lot of times are going to help you in requirements gathering because people that are not used to building software and even sometimes people that are these requirements are not going to come out right away. And so you need to ask those fundamental things as talk is learn what is fundamental potentially in any application. And some of them you may not need. So they may say, you know, we don't do unit tests. We don't do logging. We don't do exception handling. We don't have authenticated users or anything. But there's we don't have security. There's all kinds of things that may or may not be a part of it. And there may be variations of how much of that is a part of the solution. All of that is what your requirements are. And if you start doing that sooner rather than later and asking those kinds of questions, you're going to get in the habit of sort of having your own little mental checklist of like, these are all the like things that are these are the properties of software itself. So I'm going to ask questions about that. And then these are properties of features. And then you're going to start being able to ask questions around those. Now, they may, you know, they may be general in a sense, so you can customize them to every customer. But they're going to give you that that to do list of I need to go through all these things if I'm going to properly gather requirements. Thoughts? Yeah, I think you hit most of it. Most of the high points on that one of the other things as you're talking about requirements, a lot of people do not think about especially early on in projects is scalability. So unless you're asking the right questions for the requirements, you could pigeon your pigeonhole yourself in such a way that the requirements build you a system that cannot scale to the needs of your customer. And that is a death note. So make sure that as you're asking the requirements, you are thinking about the type of systems and hardware that it does need to go on and that you are going to meet the needs for the customer, not just for today, but for down the road to make sure that you can the application can grow as the company grows and they don't have to throw it out and start over. That is that is an advertisement for us. Basically, that's what it's why you have technology roadmaps and things like that is you need to look at not only where you are today, but where are you going to be in the future? Because otherwise, your requirements are they're not really I guess they're correct. They are for today, but they're really not as useful as they could be. So when you're gathering requirements, you definitely want to look at be looking forward. You don't want to paint yourself into a corner. And a lot of times that is that's a lot of times where I have that conversation with customers where I say, look, I'm asking this not because I need I want to build this for you today, but I need to know so that we can have the hooks in place or whatever we need to do so that when you grow and if you do want to do this in the future, then we're not having to rewrite, you know, strip everything out and rewrite it. We're going to be able to very easily access it, enhance it or whatever needs to be done to give you that feature. Now, that being said, I think it's time for us to wrap this one up. I think we've covered our requirements next episode may or may not be an interview. We'll see how it goes. We definitely have some in the works. We're going to continue doing some of those as part of our talk about some of these foundations and just some of the things that are out there that are some real world examples on well as well as the kinds of things that we share on a regular basis. As always love to hear from you. Shoot us an email at info at developer.com. You can leave us feedback on the developer.com site. We have contact forms. You can leave feedback on any of the articles, leave review on anywhere that you are listening to podcasts and check us out the developer channel on Yahoo, Yahoo YouTube, a very different why check them check us out there and leave us comments and feedback. We would love to hear that. You know, pros positive negative all of the above. We just want to take that and build a better podcast. As always, appreciate you so much. Thank you for your time. Have yourself a great day. It's a great week. We will talk to you next time. Just a little bit of effort every day ends up adding into great momentum and great success.