Requirements Matter: Building Software Right from the Start

Welcome to Building Better Developers, the Developer Noir podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are Building Better Developers. We are Developer Noir and now we are with AI. Yes, we're using AI in past episodes and we're going to see what it spits out. It's really just a fun little experiment we've had here, taking some of these past topics and then basically get to redo them. But we start with what AI suggests we should talk about. Sometimes it's very much what we talked about before. Sometimes it's very different. But every time we get some new conversation points going out of it, it's almost like having a third person suddenly added into our series of hosts. First of all, let's talk about the people that are here. My name is Rob Brodhead. I am a founder of Develop Noir, also a founder of the founder of RB Consulting, where we help you do technology better. The whole thing about technology is that it's there. It's everywhere. You can't escape it. It doesn't matter what your business is. I don't care if you're you've got a pet store or if you've got an e-commerce suite or whatever you've got. Technology is something that is here and it is here to help you. And we're here to help you use technology to make your business better. Sit down with you, talk about your business, walk through and create a special, unique recipe for success for you that involves leveraging technology through integration, simplification, automation, innovation. We may need to build something new, but a lot of times what we really need to do is just walk through your processes, the steps you take, and then show you how to make those go faster, whether it's eliminating steps or automating things so that now you can just get rid of it. You don't have to touch it. It just happens. You don't have to worry about all the errors and human stuff that happens. And you can actually go worry about your business and growing your business instead of working in your business. Good things, bad things. Whole lot of stuff going on lately. So we will go with good thing is, and this is we'll go back to weather because hey, weather has been one of those things. Good thing is, is that we have we've come through a little bit of a rainy period of starting to see some sun again and stuff like that. Bad thing is, is now summer is here where we are at. We had a great spring lasted into June. Actually, I think almost to July. And now suddenly, bam, summer is here. And it makes me very happy that that's a good thing. I have fans and I have AC. I even have like a little USB powered one that wherever I take my laptop, I can put a fan right there in my face so I don't sweat bullets. Just like Michael is because he knows his turn on the hot seat is next. Go ahead and introduce yourself. Hey, everyone. My name is Michael Melosh. I'm one of the co-founders of developer Neur building better developers. I'm also the founder and owner of Envision QA. We are a software consulting group focused on helping startups and growing teams improve their software quality through smarter testing, automation and development workflows. At Envision QA, we work with clients who want to ship faster without sacrificing quality, offering support in everything from test strategies and continuous integration and development to scalable QA practices. You can learn more about what we do at EnvisionQA.com where we share resources, insights and ways to connect if you're looking to level up your software delivery. Let's see. Good thing and bad things. A bad thing. Yes, it is July. It is hot. I walked outside today. I mean, first thing this morning, we're talking it's barely sun up at six o'clock. I walk out, my glasses fog over. It was so bloody humid this morning. It was miserable. Thank goodness we have AC, but also my wife has a little 10 foot pool, kind of kiddie pool she puts up every year and it's in a nice shady spot. So after we struggle with all the yard work and dying of the heat, we can just jump in that and cool off real quick. When the humidity is really bad, you just literally just cool off, but you just stay hot, humid and wet all day. It's just miserable. Yeah, that is probably the worst. We had this recently where you would walk out of an air conditioned place and it didn't matter how dry you were. Two seconds later, you would be wet and not necessarily from sweat. It's from just everything condensing on your skin. That's a whole other problem AI hasn't solved yet, but it is how it solved our problem of having some cool stuff to talk about. So we're going to dive into this one. The episode we're talking about that we're going to we took this topic from the past was called getting it right. How effective requirements gathering leads to successful software projects. Now this again was one where it did not give me a whole lot of like, oh, great topic. It just jumped right in. So it said episode objective, help developers, PMs and founders understand the critical role of clear, complete and validated requirements and how skipping this step sabotages software success before a line of code is written. Get the choir going because we're going to preach. Keep talking points. First one, why requirements gathering is the silent killer or savior? Then here's the sub bullet points. There's three of them. First one, most software failures aren't due to poor code. They're due to unclear goals. Second one, misunderstandings between stakeholders and developers. Third one, how vague or evolving requirements lead to scope creep rework in budget blowouts. We could do a season, I think, on every single one of those. One of the things that we do every time we start a project is we sit down as I talked about part of the reason we sit down with our customer and talk to them about their business is we start with the why. Then we start getting into not the wideness of their business, but the why if we're doing a project of that project. This is where requirements gathering starts. We're going to talk about what are we building. This is sort of back to when we talked about documentation. It starts like, what is the problem you're trying to solve? How are we trying to solve this? What does the solution look like? What are the steps involved in that process to a solution? What are the variants of that? What are the requirements of that? What are the constraints of the data that's in that? What does it need to look like when the output comes out? All of those questions are just the tip of the iceberg and they are so key. Simple things. I will tell you one of the simplest things that I have seen blow up projects. I bet in 30 to 40% of the projects that I've dealt with over the last many, many, many years, even though I'm so young, you will say, how is it you could possibly doing software that long? Right. Note there is how many users will be on this at a given time or a variant of that is, is each user going to have their own account or is there some sort of a, like say, an organizational account that has employees or members or things like that, or a household that has a mom and a dad and kids and things like that. That one would think is a very simple question to answer. So they're going to say, yes, this is always going to be one user or no, we're going to build this so that there's going to be an organization and they're going to have employees and blah, blah, blah. There is so much, so many devil in the details to those answers. And it is so often a problem because the customer, when they're talking about it, they originally have this very small, we'll say, or very focused solution. And this isn't a knock on them. It's just like they're solving this problem. But then as we grow, as we get into the implementation, their eyes start to open up and say, oh, well, there's a different approach I can take that now explodes where I can provide value. And then suddenly it goes from, no, we just have a person that logs in and they can have one password and they never change it and all this kind of stuff to now we have to have multiple users and we're going to put it out on the internet and they have to have all of these password guidelines and they have to be able to relate accounts to each other because they need to share data in some way. These things are very valid solutions to so many problems. But if we don't nail those things down and agree that that's what we're going to stick with, then hopefully you can see that that can really blow this stuff out of proportion. I've got to quiet the choir down a little bit here. I've got to step back because I know otherwise I'm going to go too long. Your thoughts on this, Michael? Oh my God. Yeah. Such a clear example of how quickly something can go off the rails from like a small scope to a larger scope of a project. One of the other things you potentially run into is your customers may already have existing software and they're looking to move to something similar or upgrade. The problem is, depending upon how old that software is, what they are expecting or what they're used to, they're looking at basically for something similar to what they have. But the problem is if it's so old, what they have doesn't exist or what exists today is so vastly different that, well, yes, you can literally check all the boxes for their requirements for what the new software is. The problem is what pieces is the new project going to look like? You're going to have to spend a lot more time in the requirements gathering phase kind of educating your customer on what is available, but at the same time trying to keep it concise and say, all right, what is your why? What is it that you need? And then what are basically what is the absolute requirements to get you off your old system on your new system or build you an existing system to all the bells and whistles? You have to be very careful in these situations because a lot of times they'll be like, oh, wow, yes, let's go with this or this or this. And it's like, OK, you've just blown the whole scope of the project and you're out of money before you even get off the ground. So you have to be careful not just understanding their why, but you also have to be careful understanding what it is that they need built. Is it like a counter system? Calendar being like Microsoft Calendar, Google Calendar, you know, calendars come in many flavors, but at the end of the day, a calendar does what it allows you to schedule appointments or schedule events in different times, invite different people to them. It is basically a meeting place, basically a card catalog or a post it note for a meeting. That is kind of the that really boils it down to the simplicity of it. But if you get to the core of whatever it is that you're building and stick with the core requirements, once you have that, everything else that you put on top of that is you have to be careful with that because that's where the scope can come in, because you can now start adding too many bells and whistles. But stick with that core, get all those requirements in place and then slowly work your way out from there. I think that is the it is sort of the measure twice cut once approach besides requirements in general, but it is to really understand what it is you're building. If you're building a physical building, one of the things you probably need to know from the start, and I'm not an architect of that sort, but you probably need to know, for example, how many floors is this going to have? Is it going to you know, how many rooms does it need to have? How big is the foundation need to be? Some things like that. And that is what we're actually dealing with when we're talking about requirements. Now this next section is actually really interesting as well. Again, I can do maybe we will we could do seasons on this, what good requirements actually look like. It's got four sub points smart requirements, specific, measurable, achievable, relevant, time bound. Next one, the difference between features, goals and constraints. Next one, functional versus non functional requirements. The fourth one, avoiding assumptions. Explicit is always better. I'm going to go ahead and just beat on myself a little bit self-flagellate on the last one there. Explicit is always better. Now I will I will we've probably mentioned this before, but I am a very different side of requirements of Michael. We are polar opposites, probably in that sense. I am very much a high level go do it. You know, don't get very I don't I do not get bogged down in details when I'm building requirements as far as like sending them out to development team. If I'm building requirements document and talking to the customer, that's a different thing that I'm going to sit down there and we're going to walk through a lot of stuff and we're going to figure all that stuff out. But then once we're done, what I'm going to do usually is I'm going to say these are the things that matter and then allow somebody to go fix the you know, build the rest of it and have some level of artistic freedom for lack of a better term. Michael's on the other side is he's going to write stuff because he's thinking about like, well, how do I test it? So he wants the bullet points of well, it does a if you do a it B should occur if you do see D should occur. That's if you've got that, then your tests literally can write themselves in a sense, especially if you're using AI. So the problem here is that we want to we don't want to micromanage and design and implement during requirements gathering. And this is where I think a lot of times that we we find struggles. Now some of this goes back to the other bullet points, things like smart requirements or features versus goals versus constraints and functional versus non-functional. I think the challenge with requirements is being detailed with the requirements without getting yourself detailed because you've already put implementation into the requirement. It really is having that focus on the business and the end result as opposed to the implementation piece of it. This is part of why a lot of times I'm a big fan of not even talking about the implementation language and environment stuff like that until you actually get done with requirements first is actually walk through them and keep yourself free from the implementation side, because if there's going to be a problem implementing it, you can figure that out further down the road and say, OK, we need to make some adjustments first. Let's figure out what the actual requirements are. And if we have to change a requirement, then at least we're changing it based on something that we need to do. But at least the requirement is tied back to something that we actually need for the end user. And so while explicit is going to be is very useful and very helpful, I will fall back on a little bit of the, you know, the little bit the agile approach of it is very useful is very helpful. If somebody says if if their requirement is this has to be this color blue, then OK, let's make sure that we specify that. But if it's not and it's just that happens to be they want something close to that because it's a favorite blue of theirs or something along those lines, then we need to make sure that that actually is not a requirement. So we want to be specific when it's a requirement and explicit when it's a requirement. We actually don't care if it's not a requirement. I mean, it's like and if there's something and if we should care, then guess what? It's a requirement. It's like one of these circular arguments to some extent. We need to nail those things down. Be very clear early on, especially in your questions of things like does that really matter? And if somebody says, yes, it matters, this goes back to a little bit when Michael was hitting at you may end up blowing out your entire budget before you even start because too many things matter. All right. I'm going to let you dive in on it now. All right. So I like being explicit because I like test driven development. Now, I also agree with Rob though, where you don't need to put too much implementation into your requirements. However, I am a strong believer if you are writing a requirement, it should be in the form of a user story. It should explain what it is that you are supposed to be building and what is the expected result of that. It does not have to be implementation, but it essentially has to say is the software has to do X and from the user perspective or from the software perspective, it should do Y. What happens in between up to the developer. But if you do not have those two things in your requirements, one, you don't know what you're building and two, you have no idea that what you built meets the requirements that you're building. So you have to be explicit enough in the requirements to define the tasks that you're doing. And if you're doing it right, and if you're being explicit enough, you're going to find very quickly that the requirements that you're trying to put together, either a too narrow, too refined or too broad and need to be broken down into smaller stories so that you can actually divvy up the work and get it done faster. Because if you're at that large, if you have that large story that can have many possible outcomes, you could be going down rabbit trails. You could be opening up for interpretation and then you essentially could start building the software and find out you have to go back and refactor things because you put the car before the horse or you jumped ahead on some things or you did something that wasn't even a part of the user requirement, even though it looked like it met the requirement, it didn't. So to me, being more explicit is really define the story well enough that you know what it is you're building or what has to be implemented and essentially how does it work? What is the outcome of what it is? What this requirement is? If you have those two things, then you should have no doubt when that developer picks up that ticket and writes that code, when it gets done, he knows that, okay, this meets that second condition. When I run this piece of code, it does. I get the expected outcome. If you don't have that in your ticket and they say, oh, I'm done, how do you know you're done? If you look at a ticket and you can't say what is it that this is providing, then your ticket is not explicit enough. I want to go to that is, and this is a little bit of a shameless self plug, but I apologize, but it's because it reminded me of this. I think part of the problems with user stories, I love that is it should be a user story because give you it really within itself. If you're doing it as a user story is it is doing the things like tying you back to the why and giving people the understanding of what we're actually trying to do and not just write this thing that does this thing. It doesn't, and nobody actually knows why it is. This gives them a reason. It also gives them an opportunity when they're implementing it to have some efficiencies and things like that because like, oh, this is where we're going so we can do this and this is something we want to check out all the time. But the same myself. I want to follow up on what you just said with that though. You have to be careful with the requirements and the tickets as you're building them because if you give those tickets to your developers out of order or, oh, hey, go build this small piece. If they don't know enough of the big picture, you could end up in a rabbit hole of what you've written doesn't play into the big picture. That's true. You definitely need, I will back up there and just put that extra caveat to the whole thing. The warning over all of this is that you should not be piecemealing requirements to your developers. When you go through this, they should actually be able to have access to the entirety of the user story so they can understand what's being built. Now, back to my point is that with the user stories, a user story, you need to think more of instead of like a long time ago in a galaxy far, far away, there were some people, blah blah blah. You need to think more like scripts for movies and stuff like that where there's directions in there. Is there things like the lighting opens up and it's a little bit of a blue and then somebody's staring off in the distance and blah blah blah, those things. More detail. What happens a lot of times is it's user stories like the user needs to log in. Okay, cool. You need to tell me more. This is what we've added. I got to remember which one it is. It's the software development book out on the RB site. You can go find it. It's free. It's an ebook. I have in there a user case, a user story template that is not just like you write your little thing. There's a lot of questions in there. There are details to that story and that is what you're going to need for the requirements because it can't be as, it's not going to be as simple as the user needs to log in. It is the user needs to log in and things like, but it needs to automatically log them out after 30 minutes or they need to have a password or they need to be able to do it without a password or all of that. There's a lot of things that go into even the most simple of stories and making sure that where there are requirements as opposed to just like, yeah, it'd be cool if it worked this way. Those actual requirements, they need to be laid out there and that includes things like limits and validation. So it's things like, hey, they need to be able to create a user account and have a display name. Well, how long does display name need to be? Oh, it needs to be open text. They can make it as long as they want. Okay, well what happens when we start showing, you know, somebody decides to have something that is literally 4,000 characters long and it's in the list of users and so that they've blown out the entire screen. There's things like that that need to be discussed and I don't want to get too far in there. Probably already have gone down that rabbit hole too far. That is definitely an area that you need to be paying attention is that the level of detail that you add to your user stories. Now moving on to try to get a little bit more in on this one, techniques for effective requirements gathering. Again, a whole season on this. Stakeholder interviews and empathy driven discussions, user stories, we've said that, use cases and personas, prototypes, wireframes and mockups as communication tools, joint application development, JAED sessions and workshops. I'm going to dive right into prototypes, wireframes, mockups. I love Michael's always about the kitchen sink and stuff like that. I am a clickable demo person. I was with a group that we were called our managers names slash dangerous demos because we could crank out demos that you would look at them and you thought they were real. Those are the things I love for requirements is not just getting the basics of it and saying, okay, here's what we've got, but it's actually putting it back in front of them so they can see it. There are tools like figmas and stuff like that that are out there that allow you to do this stuff very quickly, very high quality and allow you to get a lot of feedback quickly. I was literally in a call just a few hours ago with a customer where they were a little bit lamenting and a little bit apologizing that they did not have as much input six months ago as they do now. Part of it is we were building an interface for them that they needed. They needed to be able to actually work with this thing before they could get a really good honest assessment and evaluation of it and tell us where it needs to go. I think things like that, the more we'll call it real in quotes that you can make it in front and put it in front of them, the better feedback you're going to get. Thoughts on that? I know you kind of get on me about the kitchen sink, but I also like the prototypes as well. I like the figma tools and that, but I'm like old school, I guess, because I'll just open up like PowerPoint or some type of presentation thing and just quickly copy paste or something together because I guess just because I've been doing it for so long, it takes me less than an hour or two to throw a clickable demo, so to speak, in a PowerPoint slide and make it look like you are actually going through a demo of an application, especially when you're dealing with web applications. It is so easy to just throw something together like that. Kitchen sink apps, though, for me, the reason I like the kitchen sink app is if you have done a kitchen sink app right and you have taken all these things and pieces that you've written for other tools and applications, you put them in a kitchen sink app, you could almost essentially have a Hello World or Swiss Army Knife interface for your kitchen sink app where you could literally go click through, oh, this is what I'm talking about. Click here. Oh, here's a mail interface that we've written. This would look something like this or oh, click over here. Hey, here's another feature we're talking about. You could almost completely demo real functional code piecemeal, but in a way that you could explain to the user visually what it is that you're talking about building for them. And in that we will wrap this one up. We still these things are great. That is a nice thing about this. We could probably do a whole other season of AI and we just start at the bottom and work our way back up and we would get a whole different set of useful information. But that's why if you're listening to us right now, you should actually go check us out on YouTube to check out the Develop a Newer channel because we have bonus material after every episode. And a lot of times we actually go a little further into these particular this the season of AI. As always, love to hear from you. Send us an email info at Develop a Newer dot com. We any feedback positive negative. We just want to know what works for you, what doesn't work for you and how we can do, you know, basically how we do our job better. How can we help help us help you? You can check us out on X at Develop a Newer. You can check out the Develop a Newer dot com site. And we've got tons and tons of stuff out there. As I mentioned, YouTube, anywhere that you listen to podcasts, Develop a Newer, Building Better Developers is out there as well. There's a Facebook page. We're out there. If there's somewhere else you'd like to see us around on Instagram or anything yet, if you want to see us out there, we'll figure it out. We'll black out pictures of ourselves so we won't have pictures of ourselves everywhere. That just that would be a little too disturbing to the Internet's equilibrium. That being said, my equilibrium is as disturbed as it's going to get. So I'm going to wrap this one up. You're out there and have yourself a great day, a great week. We will talk to you next time. Thank you for listening to Building Better Developers, the Develop a Newer 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.