Effective Requirements Gathering for Successful Software Projects

Welcome to Building Better Developers, the DeveloperNor podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are here cruising through the developer journey. I am Ron Broadhead, one of the founders of DeveloperNor, also known as Building Better Developers, also a founder of RB Consulting, where we simplify, integrate, automate and do our best to just take the nightmare that technology can become and turn it into a nice, pretty little fuzzball that you can use to help your business get done faster, better, sharper and allow you to sleep at night. On the other side is someone who actually never sleeps at night or close to it, Michael, and I'm going to let you introduce yourself. Hey everyone, my name is Michael Melosh. I'm also one of the co-founders of Building Better Developers, DeveloperNor, and I'm also the founder of Envision QA. If you are a small to mid-sized business or a small healthcare clinician or doctor's office, we help you identify what systems you have in place, what software that you're using, and we also build custom softwares. So if the tools you have aren't quite working for you, we can build you what you need, which actually kind of goes into the conversation we're going to have today. Yeah, that's a nice little dovetail into where I talk a little bit about, it's sort of about requirements and expectation setting and level setting and some things like that. As we were talking about in the pre-show that you can go watch out on YouTube, it's a little bit idea of like first you're working at just writing code and then you're sort of becoming a developer so you're developing solution and now you're getting into the point where maybe you've built your own solutions but now it's working with other people to figure out what they need, what is their problem and how do you figure out how to solve their problem and give them a solution that works. Now there's a couple of ways that we step into this. This topic I want to focus on, which is a disconnect, we'll call it. One is, we've talked about this before, we've sort of thrown it out there and Michael just gave an example. Like somebody sees, I want to create Twitter and I want to create something just like Twitter but I'm going to call it Flitter and their budget is 50 bucks. It's like, okay, you have no idea what's involved. It's not just like changing three lines of text and then giving it over to you. You have no idea what's involved in the solution behind there. This can also happen with customers and this is really where I want to focus on more because instead of building new stuff which is more likely to, I think, normally draw us in as far as like gathering requirements and walking through that process with the customer, even if they have done some of that work beforehand because sometimes you will get a fairly solid list of requirements but then you're still going to, you're going through them, you're going to have questions and so it naturally progresses. When you're dealing with an existing system that a customer has, there's two or three different ways that people look at it. I think I'll go into three. There's the one where it's an old system that we love. It works great. We really don't want to, you know, it's not broke, don't fix it kind of thing but we do need to upgrade it because the technology is being sunsetted or something like that. Then you have the people that are on the other end that are like, we've got this thing, it was a piece of crap, it doesn't work, we hate it, we've been trying to get off of it forever and it's now the technology is sunsettig and we've just, we've waited too long and now we need to and we want to build something completely different. And then you have somewhere that I guess we'll see in between where people have something that they, we have something, not really what we want, we've learned some lessons from it and we want to build something better. Now the good thing is in all three of those cases, you, when you come in, not only building better developers, we want to build better solutions. So whether they love their solution or they hate it or somewhere in between, we want to talk to them about that solution. We want to understand in this situation, what is it you have today? What are the processes? How does it work? How does it, you know, how is it successful? How is it failure? Where are your pain points? It's really talking before you get anywhere into what we're going to build for you or where we're going to go with it. Let's really understand what you have. Now that can be a challenge because sometimes you're going to get stuff where they say, well, just go work on the application or here's, you know, rarely do you get here's full documentation, but they'll be like, here's a user's guide and you'll have an application with a hundred screens that's got a two page user guide or something like that. And there's all points in between. The thing is this goes back to something we talk about a lot. It's the why, why is that there? Why, how is it used? It is so easy for even somebody will just say, like, I could be an example of where you've done this a bunch, but you don't push on the, I need to understand the business side of it. And that can run you into problems because now what you're doing is you're making assumptions. You're going to assume that what the customer tells you is exactly what's going on. And while sometimes that's correct, sometimes it's not particularly with systems. There's a lot of times that we have gone in and done assessments and evaluations and things like that. And you get into it and you find that maybe you start, let's say you start with the CEO and maybe they're, they like built this from the ground up. So they talk like they know everything. And then you start talking to their team and you find some people that are like, oh, we have this other thing we use. It's not because the CEO is not smart or something. It's just like people grow and move and they do these other things. And there's stuff that's not on their radar. And you'll find those kinds of things. And even within their systems, they may use it all the time and it's not. And they think that this thing is just a smooth integration. And then you find out that, oh, no, behind the scenes, it's actually like multiple integrations. They've got all these licenses they've got to have, maybe two or three vendors involved. And don't even get me started if you've had multiple teams of developers or individuals come in over the years, because this goes back to some of our other conversations is it always looks like it was written by 50 different people, even if it was three. And so it gets really difficult to understand what's there because you can't look at the code unless it's super, super simple. You can't look at the code and know what it does. If it's like add a number, subtract a number. OK, now we're like then maybe you can look at the code, even a basic crud app where you're just insert, update, delete records, do some listing. There's probably some validations in there. And if you can't crawl through all if you don't crawl through all the code and make sure you've got every little piece of code reviewed, which is very time consuming, you're probably going to miss something. And even if you do, you're probably going to miss something because it's sometimes hundreds of thousands of lines of code. So what do we do? This goes to we come back to the fundamentals. One, we want to make sure that we are setting expectations. Now, sometimes your expectations are going to have assumptions and you're going to have to step up when those assumptions are proved incorrect. So, for example, if you step into a project and they say, we really don't have to do anything but copy these files from A to B and you're good. OK, assuming that it's going to take us X amount of time, here's what we're going to do. Cool. And then you find out, well, you can't just copy those. There's some other things that are going on and there's some stuff over here that you got to look at it. Oh, these things can't just be copied. They've actually got to be rewritten. At those points, you like, hold up, stop. We made an assumption and now we have to reset because now the project has changed. What we walked into as we got further into it, we realized that's not it. And you're going to feel bad sometimes you're going to have customers are going to say, hey, why didn't you tell us that up front? And you can say we didn't spend the time walking through all this code up front. And if they wanted you to or if they want you to walk through all the code up front, then you want to make sure you've got some sort of an agreement or something. So you're getting paid because you don't want to be in a situation where you spend weeks of time crawling through code, putting together a nice requirements document. And they're like, oh, sorry, we're not going to do that. And they walk off and use your stuff somewhere else. The other part of this is the real fundamental. When you're looking at that application, however you're looking at it, even if you can't see the code, when you're looking at the screens and that ask questions, how did I get here? What is this? What does this data do? Where does this data go? Where is it used? Don't be afraid to just be like a two year old, ask questions, ask questions, ask questions, because that is how you're going to get the requirements. And that's how you're going to find the things that are in their head, particularly when they've used this application day in and day out for years. There is so much knowledge that just they know and they just know it like they breathe. But they to tell them, give me that information. You have to find a way to extract it. You've got to write that, ask the right question. And you're going to end up having to ask a lot of questions because you won't know that question until you ask it. So that's like a big, long winded approach. And I'm going to toss over Michael and sort of get your your feedback on those. And what are your thoughts when you run into these situations? So let me start with a little bit of current events, which kind of ties into this nicely. So the current debacle that kind of shut down the US recently with an operating system failure, it has been discovered that the company that was working on the software only tested their code using unit tests. And unit tests are a form of requirements or tests built on the requirements to test the code a certain way. As you're going through these projects, if you're not collecting the requirements, if you're not filling in those assumptions and updating your tests, if all you're doing is making code changes, running your tests, good shipping the software. If you never do end to end testing or any other validation testing to make sure that the system works as the user wants it, you're going to break things. So that's what happened, which literally shut down a lot of systems within the country. Flipping back to that. So as developers, as we are working our way through software, through new software, integrating software, working with a customer. I am very anal about how I go about gathering requirements, because I have worked on multiple sides of the fence. Rob has too a little bit, but I've decided at one point I need to step out of development. I wanted to be a tester. I wanted to learn more about integration testing, automation testing, and see how I could apply the test-driven development approach. As a developer working on systems, working with customers, especially today, since a lot of our work is done virtually, we do a lot of work through the computer. So it's very important to sit down with your end user or your customer and have them walk through the system with you. Do they have a login screen? Well, if you have a login screen, you have to ask yourself, okay, sure, it takes a username and password, but if you have some type of authentication, they probably are not thinking in their minds that they probably have role-based permissions or role-based interfaces where certain things happen in the application for certain people. So this person may come in, they're an admin, they see everything in the system. It's like, cool, this is how it works. You build it that way and you roll it out, and next thing you know, hey, why can my customers access payroll? That shouldn't happen. Well, you didn't show it to me that way. So there's a lot of nuances with software that your end user, your customer may not know. So you're going to want to talk to more than one person, if you can, about the system. Rob mentioned writing up software requirements. Well, sometimes you don't have the time. Sometimes you're pitched with, hey, we have this. So you're going to make a bid or an initial bid or statement of work to say, hey, I can do it for X based on these assumptions. However, once you get in there, very quickly try to find out if those assumptions are right. Don't wait too long. If you can catch this within the first few days, you usually have a little more bandwidth to go back and say, hey, we need to reevaluate this contract. What you pitched us does not match what we have. However, sometimes what you are told is fairly close to what you have within the system. So you get in there, okay, things are going along as expected. But like Rob said, there might be assumptions or things that aren't seen from the end user's perspective. So as you're walking through an application, even if it's for the first time, at the start of the contract, walk through the user stories. So what is a user story? A user story is how a person interacts with the system. What is the person doing on the keyboard? What are their objectives? I am coming to this page to do what? What is my expectation from the application and what is the result? So you're kind of thinking that black box testing. Information in, information out. But there's stuff that happens there that you have to break down so that you can actually write the code or fix the code or even understand what the code is doing behind the scenes. So this kind of gets into that whole white box, gray box testing development. You have to look at things to gather this information. And as you're doing this, you're going to find that there are what are called happy paths. Or simple user stories for the basic implementations of the system. Most companies and most users have that. But what they don't have is all the other things that are required to keep that happy path working. Like, for instance, with the login, can the username, is it an email? Is it just numeric characters? Is it alphanumeric? Does it have to have special characters? What conditions are required just for the username? Password, same thing. Now, if I'm logging into the system, okay, sure, I can have a user account. But what happens if I try to log in three times? Does my account get locked? Does my account expire? If I log in, am I logged in forever? Do I never have to log in again? So just in that scenario alone, I've already thrown out half a dozen scenarios that you need to think about and account for just for a login page. From the user's perspective, hey, I log into this application. It lets me in if I put in the right password. It doesn't let me in if I have an incorrect username or password. From the end user, that's what they see. But from a developer, we have to think about all those nitty gritty details to make sure that the application works. Now, I've kind of really dragged down on that path, but it's one of those where attention to detail from a developer's mindset, it's not just about, hey, I have this feature. No, I need to understand how this feature works and works with the system as a whole, not just that piece. Because it could work for me. My unit test could pass. But when you get to the end user, I click here to get to this page. Whoops, I just broke that. That doesn't work. But my page works. But I've now broken other implementations or other features within the system. So you have to be careful with what you do. You also have to think about these things from the end user's perspective while thinking about it as a developer. So that way, even if you don't do the requirements, you have an idea to start building the software. And if you do it from a test-driven perspective, you're writing all these tests first, all these scenarios first, and then you're building the code that the test will test. So essentially, if you're doing a login, OK, I have a username, I have a password variable, I pass it into this method, I should get logged in. Or I should be rejected because it's not a valid password. And then you essentially write those methods and then change your test to call that method from the hard code to pass and test your code. So that's kind of my soapbox on this part of it. Rob, where are some more of your thoughts? I do want to say that when we talk about setting expectations and the whole, I don't know how many times I've seen stuff where it's like, it's really a simple project. You just have to take this thing and move it from point A to point B. I think if you struggle with getting your customer to understand the complexities involved, I think the login is one of the most perfect examples to work with. Perfect examples to work with because it is literally dozens, if not more, of decisions that are made with a login. And it is, it's stuff like Michael talked about. And some people think, oh, well, how complicated is your password? And then what is your, you know, is your login a name or is it an email address? Well, this is where you go a lot deeper, is there's things like, OK, what characters aren't allowed? What characters aren't allowed for the name? Are you going to have a display name that this user is going to be seen elsewhere in the system? Is that their login? And if so, that's a security risk because now somebody at least knows what their login is. And so you don't necessarily want that, which is the same thing. If it's their email address, then somebody could guess their email address and use that as login. Do you want to do that? What happens if they forget their password? What happens if you want to add, maybe initially do or maybe later you want to add some multifactor authentication? How does that work? Do you have the ability, which is a lot of systems now have, are you going to need the ability that is the for admins to log in as a user? Which goes a little bit to what Michael said, where you now get to see the system as that user and not as you as a super user, maybe see a much different system. And it goes on and on. It's like, well, do you log out? What happens when you log out? When you log in, do you, where do you go? Do you go to your homepage? Does your homepage change depending on what your role is? And then it just, there's so many things that can be involved there. That alone, people are usually like, well, we just need to log in and we need to log out. Okay, let's go into explore that. And by the time you've asked about the 10th question, you say, okay, that's just the login. We haven't gotten anywhere else. That's why this is complicated. That's why when we say we're trusting you, we're trusting you with a lot. If we're just going to say we trust you that your login system currently works fine, we're trusting that you've answered all those questions and that they all make sense. And this goes to a little bit to the unit testing, which is Michael's idea. It's like, okay, let's say that same login and your login works flawlessly. But let's say that, for example, you don't store a display name or you store personal information, first and last name, and it's a system where that shouldn't be displayed anywhere. But everybody else somewhere down the line says, well, I just need a name. So I'm just going to take first, last name, put it together. And then that's how I address them. Well, yeah, those both work fine. But when you put it into the system, you're not following a story. And I think that's probably where we're going to go next, but not right now because we have gotten a little long on this one as we sometimes do. And we are going to wrap this one up and go work on our requirements because that's what we do. As always, we can gather requirements from you by sending us emails at info at developernerd.com. You can check us out on developernerd.com. We've got a form there. You can sign up. You can leave us comments. You can see tons and tons of content. You can check us out at school.developernerd.com and see some of the really short, less than an hour, up to multi-day tutorials and lessons and classes that we've got there. Subscribe wherever you subscribe to podcasts and then three other places as well, just because. And you can get this. We drop this twice a week out on the YouTube channel. You get to see that twice a week. If you're listening, you get bonus material. Although you can always color us out so you don't have to watch us. But there's extra content as well out on the YouTube channel. That's the developer channel out on YouTube. You can go find us there plus past mastermind mentor sessions and things like that as well. So there's tons of content. And now I'm going to take a deep breath and go grab a glass of water or something like that. But for you to go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the developer podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.