Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche explore why requirements matter more than ever in software development. From vague specs to blown budgets, they break down how poor requirements—not bad code—are the root of most failed projects.
We cover: • Why requirements matter more than perfect code • How to write user stories that work • Managing scope, budget, and stakeholder expectations • Using prototypes and mockups to validate early • Balancing detail without over-specifying implementation
👉 Learn how to prevent rework and improve delivery through better planning.
🎧 Listen to the podcast: https://develpreneur.com/requirements-matter-software-success/ 📩 Contact us: [email protected] 🌐 More resources: https://develpreneur.com/
#RequirementsMatter #SoftwareDevelopment #UserStories #Agile #ProjectPlanning #BuildingBetterDevelopers #TechPodcast #SoftwareSuccess
00:00 - Welcome & Episode Setup 01:30 - Meet the Hosts: Rob & Michael 03:00 - Why Requirements Gathering Matters 05:20 - Common Causes of Project Failure 07:15 - Asking Better Questions Early 09:00 - Scope Creep & Account Modeling 11:00 - Managing Client Expectations 13:00 - Core Requirements vs. Bells & Whistles 15:00 - What Good Requirements Look Like 17:00 - User Stories & Testable Outcomes 20:00 - The Danger of Piecemeal Requirements 22:30 - Adding Detail Without Overdesigning 25:00 - Prototypes, Demos, and Visual Feedback 28:00 - Bonus: Bridging Business & Dev Teams 30:00 - Tools, Change Control & Keeping in Sync 32:00 - Final Thoughts & How to Connect
Transcript Text
[Music] record and we're going to dive right into this one which is getting it right. How effective requirements gathering leads to successful projects. Wow, there's a lot there. Let's see how this one goes. Um, this is another one. We could probably talk for days on this one alone, but we're going to see how we're going to do it and try to keep it to our normal three, two. Well, hello and welcome back. We are building better developers. We are developer and now we are with AI. Yes, we are using AI in past episodes and we're gonna 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 Broadhead. I am a founder of developer 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. 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 are here to help you use technology to make your business better. We sit down with you, talk about your business, walk through and create a special a 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 and human stuff that happens and you can actually go worry about your business and growing your business instead of working in your business. Now, good things, bad things, uh whole lot of stuff going on lately. So, we will go with um 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 uh we've come through a little bit of a 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 uh 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 intro introduce yourself. Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of developer 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. Uh 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 6:00. Walk out my glasses fog over there. It was so bloody humid this morning. Uh it was miserable. Uh thank goodness we have AC, but also u my wife has a little 10-ft pool, kid kind of kitty pool she puts up every year. And uh it's in a nice shady spot. So uh after we, you know, struggle with all the yard work and dying of the heat, we can just jump in that and cool off real quick. Uh except 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 when you like we we had this recently where you like 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. Uh 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 object 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. Ah, get the choir going because we're going to preach. Um, 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 qual requirements lead to scope creep, rework, and 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 and then we start getting into not the why of their business but the why if we're doing a project of that project because this is where requirements gathering starts is 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 variance 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 thing 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?" Side note there. Um, 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 a 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. people are either 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 pro 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, they 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 like quiet the choir down like a little bit here. I've got to step back because I know otherwise I'm going to go too long. What your thoughts on this, Michael? >> Oh my god. Yeah. Uh such a clear example of how quickly something can go off the rails uh 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, "Okay, 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. um not just understanding their why, but you also have to be careful understanding what it is that they need built. If is it like a calendar system? Okay, 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 it's basically a meeting place basically a card catalog or a post-it note for a meeting. That is kind of the bo 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 uh besides requirements in general but it is to really understand what it is you're building. It's like if you're building a physical building one of the things you probably need to know from the start and I'm not a 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? Uh 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 could do and maybe we will. We could do seasons on this. What good requirements actually look like. It's got four sub points. Uh smart requirements, specific, measurable, achievable, relevant, timebound. Next one, the difference between features, goals, and constraints. Next one, functional versus nonfunctional 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 flagagillate on the last one there. Explicit is always better. Now, I will I will we've probably mentioned this before, but I have a very different side of requirements of Michael. We are polar opposites probably in that sense. I am very much a highlevel 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 of as far as like sending them out to development team. If I'm building requirements documented talking to the customer that's a different thing. Then 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 um artistic freedom for 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 C, 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 uh 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. Uh this is part of why a lot of times I'm I'm a big fan of not even talking about uh the implementation language and environment stuff like that until you actually get done with requirements first is actually walk through them and 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 okay we need to make some adjustments uh 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 uh 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 u you know the a 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 okay, 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 requirement. It's like one of these, you know, circular arguments to some extent, but 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 what 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 gonna 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 task 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 are 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 uh 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 cart 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 it 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 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 I apologize but it's because it reminded me of this. Um I think part of the problems with user stories I love that is it should be a user story because that should give you it 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 you know write this thing that does this thing. it doesn't and nobody actually knows why it is. This gives them uh reason and also gives them an opportunity when they're implementing it to uh have some you know 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. uh by the same >> 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 plug into the big picture. That's true is you need you definitely need I I will back up there and just put that extra caveat to the whole thing. The warning over all of this is that like you should not be peacemealing requirements to your developers. This should 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, you know, a long time ago in a galaxy far far away, there were some people blah blah blah. You need to think more like uh scripts for movies and stuff like that where there's directions in there. Is there things like, you know, the you know, the lighting opens up and it's a little bit of a blue and then somebody's sh staring off in the distance and blah blah blah. Those things more detail. What happens a lot of times is this is it's user stories like the user needs to log in. Okay, cool. You need to tell me more. And this is what we've added when we've and it's I got to remember which one it is. I think it's the it's the software development book on out on the RB site. You can go find it. It's free. It's an ebook. But I have in there a user ca a use case 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 the 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 validations. 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 the display name need need to be? Like, 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 a list of users and suddenly 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. Um that is definitely an area that you need to be paying attention is that the level of detail that you add to your users stories. Now uh moving on uh to try to get a little bit more in on this one. Uh techniques for effective requirements gathering. Again whole season on this stakeholder interviews and empathydriven discussions user stories. We've said that use cases and personas prototypes wireframes and mockups as communication tools. Joint application development. JD sessions and workshops. I'm going to dive right into uh prototypes, wireframes, mockups. I love Michael's always about the kitchen sink and stuff like that. I am a clickable demo person. I I was with a group that we were called our managers names/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. And 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. But I told them I was like part of it is we were building an interface for them that they needed they needed to be able to actually like work with this thing before they could get a really good honest assessment and evaluation of it and and tell us where it needs to go. So, 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? >> Yeah, I I know you kind of get on me about the kitchen sink, but I also like the prototypes as well. Um, I I like the Figma tools and that, but I'm like old school, I guess, because I'll just th open up like a PowerPoint or some type of presentation thing and just quickly copy paste, throw 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 uh of an application. Especially when you're dealing with web applications, it is so easy to just throw something together like that. Kitchen sync apps though for me um the reason I like the kitchen sync app is if you have done a kitchen sync 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 uh 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 it 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 peace meal, 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'd just start at the bottom and work our way back up and we would get a whole different set of uh useful information. But that's why if you're listening to us right now, you should actually go check us out on YouTube, check out the developer channel because we have bonus material after every episode and a lot of times we actually go a little further into these particular this season of AI. As always, love to hear from you. Send us an email [email protected]. We would 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 can do our job better. How can we help help us help you? Uh, you can check us out on xdevelopure. You can check out the developer.com site and we've got tons and tons of stuff out there. As I mentioned, YouTube, uh, anywhere that you listen to podcasts, developer, building better developers is out there as well. Uh, there's a Facebook page. We're out there. or if there's somewhere else you'd like to see us. We're not on Instagram or anything yet. If you want to see us out there, we'll figure it out. Uh 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. Go out there and have yourself a great day, a great week, and we will talk to you next time. All right, then. Bonus material. I'm going to dive into Let's see. We got two more things. So, bridging the gap between business and dev teams. Uh, four subs. Translating business goals into technical specs. Avoiding the lost and translation trap. The role of a good business analyst or product owner. Involving developers early, not just for estimates but for feasibility. And then the next one, requirements are living documents. How to manage changes mid- project, change control, backlog, grooming. Tools to track and update requirements. Jira, confluence, notion, etc. tying requirements directly to tasks, code, and test cases. So, I'll let you go first. Bonus material. Where where do you want to add that? Well, you can't knock the tools, you know, using Confluence or some project tracking tool is really good. We beat this horse to death death, but you know, code repository back, you know, always checking your code. Uh, you know, tie your code to tickets, ties it to requirements. Um, and I guess the big one is get your teams involved early on. I mean that is the big one because if you don't you or if you're running behind on getting your requirements together there there is one of those situations where you want to get started early but if you don't have enough of the requirements solidified or you don't have enough of the why bringing them in too soon could get you going down too many rabbit holes. So sometimes you have to kind of weigh the balance here of if you get your developers in front of this and you start getting more questions, more confusion than answers, it might be worth pausing with the developers, going back, spending a little more time with the requirements and the customer to get things refined and then go back to your developers. If you sit down with your developers and everything seems to be going smoothly, everyone has a clear picture, that's good. But do that again like Rob says with, you know, Scrum, do it in sprints. Do it more often. Make sure everyone's on the same page. If you start getting to where your team is confused again or you seem to be going off track or floundering, pause. That might be a situation where you've hit a gap in the requirements or your requirements aren't clear enough for them to continue. So those are just some warning signs to help you stay on track with your projects. >> I will I going to do the keeping up with the documentation uh with requirements in particular. I think it is very important to uh stay in sync as you're particularly if you're doing uh agile approaches is because we there have been more than a few times I've been in a project where it evolves as we are you know moving through implementation and what you started out with for the vision for the application changes sometimes substantially and sometimes the uh particularly like there'll be an approach that you were going to take to solving the main problem that now you've realized that's not really a good approach. approach and you're going to try something different and that can be very confusing if you are not clearly updating things to say oh by the way we are now moving in this direction we have done a pivot or something along those lines be very clear when you're doing those kinds of changes and don't be afraid to like gather the troops around essentially and say okay let's make sure everybody's clear that we are this is what we did but now we're throwing that out and this is what we're and to make sure that everybody understands that impact because whenever you make those changes, uh, it can be confusing and you can end up in situations, particularly if you're not communicating that back to the team where somebody gets left behind because they weren't paying attention or weren't part of that meeting or things like that. That being said, it is time for us to wrap this one up. We've got to go deal with our own meetings and rounding up the troops and all that kind of goodness. Thank you so much for your time. We appreciate you guys hanging out with us, listening to all of this. Um, feedback, however you can get it to us, we will love to hear it. U, if you can find a way to snail mail us, we may find a way to get to a mailbox. I don't know if that's going to happen, but email always is the best way to go. [email protected]. Check us out. Give us a drop us a line and we would be happy to we'll even give you a shout out if you would like. Just let us know if you want to be anonymous. We're good with that one, too. As always, go out there and have yourself a great one. Enjoy your your summer, whether it's hot or not, and we will see you next time. [Music]
Transcript Segments
[Music]
record and we're going to dive right
into this one which is
getting it right. How effective
requirements gathering leads to
successful projects. Wow,
there's a lot there. Let's see how this
one goes. Um, this is another one. We
could probably talk for days on this one
alone, but we're going to see how we're
going to do it and try to keep it to our
normal three, two.
Well, hello and welcome back. We are
building better developers. We are
developer and now we are with AI. Yes,
we are using AI in past episodes and
we're gonna 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
Broadhead. I am a founder of developer
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. 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 are here to help you
use technology to make your business
better. We sit down with you, talk about
your business, walk through and create a
special a 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 and human stuff that
happens and you can actually go worry
about your business and growing your
business instead of working in your
business. Now, good things, bad things,
uh whole lot of stuff going on lately.
So, we will go with um 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 uh
we've come through a little bit of a 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 uh 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 intro
introduce yourself. Hey everyone, my
name is Michael Malashsh. I'm one of the
co-founders of developer 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. Uh
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 6:00. Walk out my
glasses fog over there. It was so bloody
humid this morning. Uh it was miserable.
Uh thank goodness we have AC, but also u
my wife has a little 10-ft pool, kid
kind of kitty pool she puts up every
year. And uh it's in a nice shady spot.
So uh after we, you know, struggle with
all the yard work and dying of the heat,
we can just jump in that and cool off
real quick. Uh except 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 when
you like we we had this recently where
you like 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. Uh 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 object 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. Ah, get the choir going because
we're going to preach. Um, 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 qual requirements
lead to scope creep, rework, and 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 and then we start getting into
not the why of their business but the
why if we're doing a project of that
project because this is where
requirements gathering starts is 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 variance 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 thing 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?" Side note there. Um, 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 a
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. people are either
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
pro 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, they 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 like quiet the choir down
like a little bit here. I've got to step
back because I know otherwise I'm going
to go too long. What your thoughts on
this, Michael?
>> Oh my god. Yeah. Uh such a clear example
of how quickly something can go off the
rails uh 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, "Okay, 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.
um not just
understanding their why, but you also
have to be careful understanding what it
is that they need built.
If is it like a calendar system? Okay,
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 it's
basically a meeting place basically a
card catalog or a post-it note for a
meeting. That is kind of the bo 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 uh
besides requirements in general but it
is to really understand what it is
you're building. It's like if you're
building a physical building one of the
things you probably need to know from
the start and I'm not a 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? Uh
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 could do
and maybe we will. We could do seasons
on this. What good requirements actually
look like. It's got four sub points. Uh
smart requirements, specific,
measurable, achievable, relevant,
timebound. Next one, the difference
between features, goals, and
constraints. Next one, functional versus
nonfunctional 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 flagagillate
on the last one there. Explicit is
always better. Now, I will I will we've
probably mentioned this before, but I
have a very different side of
requirements of Michael. We are polar
opposites probably in that sense. I am
very much a highlevel 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 of as far as like sending
them out to development team. If I'm
building requirements documented talking
to the customer that's a different
thing. Then 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 um artistic freedom
for 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 C, 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 uh 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. Uh
this is part of why a lot of times I'm
I'm a big fan of not even talking about
uh the implementation language and
environment stuff like that until you
actually get done with requirements
first is actually walk through them and
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 okay we need to make some
adjustments uh 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 uh
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 u
you know the a 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 okay, 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 requirement. It's like one of
these, you know, circular arguments to
some extent, but 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 what 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 gonna 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
task 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 are 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 uh 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 cart 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 it 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
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 I apologize but it's because it
reminded me of this. Um I think part of
the problems with user stories I love
that is it should be a user story
because that should give you it 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 you know write this thing that does
this thing. it doesn't and nobody
actually knows why it is. This gives
them uh reason and also gives them an
opportunity when they're implementing it
to uh have some you know 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. uh by the same
>> 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 plug into the big
picture.
That's true is you need you definitely
need I I will back up there and just put
that extra caveat to the whole thing.
The warning over all of this is that
like you should not be peacemealing
requirements to your developers. This
should 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, you know,
a long time ago in a galaxy far far
away, there were some people blah blah
blah. You need to think more like uh
scripts for movies and stuff like that
where there's directions in there. Is
there things like, you know, the you
know, the lighting opens up and it's a
little bit of a blue and then somebody's
sh staring off in the distance and blah
blah blah. Those things more detail.
What happens a lot of times is this is
it's user stories like the user needs to
log in. Okay, cool. You need to tell me
more. And this is what we've added when
we've and it's I got to remember which
one it is. I think it's the it's the
software development book on out on the
RB site. You can go find it. It's free.
It's an ebook. But I have in there a
user ca a use case 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 the 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 validations. 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 the
display name need need to be? Like, 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 a list of users and suddenly
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. Um that
is definitely an area that you need to
be paying attention is that the level of
detail that you add to your users
stories. Now uh moving on uh to try to
get a little bit more in on this one. Uh
techniques for effective requirements
gathering. Again whole season on this
stakeholder interviews and empathydriven
discussions user stories. We've said
that use cases and personas prototypes
wireframes and mockups as communication
tools. Joint application development. JD
sessions and workshops. I'm going to
dive right into uh prototypes,
wireframes, mockups. I love Michael's
always about the kitchen sink and stuff
like that. I am a clickable demo person.
I I was with a group that we were called
our managers names/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. And 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. But I told them I was like
part of it is we were building an
interface for them that they needed they
needed to be able to actually like work
with this thing before they could get a
really good honest assessment and
evaluation of it and and tell us where
it needs to go. So, 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?
>> Yeah, I I know you kind of get on me
about the kitchen sink, but I also like
the prototypes as well. Um, I I like the
Figma tools and that, but I'm like old
school, I guess, because I'll just th
open up like a PowerPoint or some type
of presentation thing and just quickly
copy paste, throw 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 uh of an
application. Especially when you're
dealing with web applications, it is so
easy to just throw something together
like that. Kitchen sync apps though for
me um the reason I like the kitchen sync
app is if you have done a kitchen sync
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 uh 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 it 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
peace meal, 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'd just start at the bottom and
work our way back up and we would get a
whole different set of uh useful
information. But that's why if you're
listening to us right now, you should
actually go check us out on YouTube,
check out the developer channel because
we have bonus material after every
episode and a lot of times we actually
go a little further into these
particular this season of AI.
As always, love to hear from you. Send
us an email [email protected].
We would 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 can do our job better.
How can we help help us help you? Uh,
you can check us out on xdevelopure.
You can check out the developer.com site
and we've got tons and tons of stuff out
there. As I mentioned, YouTube, uh,
anywhere that you listen to podcasts,
developer, building better developers is
out there as well. Uh, there's a
Facebook page. We're out there. or if
there's somewhere else you'd like to see
us. We're not on Instagram or anything
yet. If you want to see us out there,
we'll figure it out. Uh 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. Go out there and have yourself a
great day, a great week, and we will
talk to you next time. All right, then.
Bonus material. I'm going to dive into
Let's see. We got two more things. So,
bridging the gap between business and
dev teams. Uh, four subs. Translating
business goals into technical specs.
Avoiding the lost and translation trap.
The role of a good business analyst or
product owner. Involving developers
early, not just for estimates but for
feasibility. And then the next one,
requirements are living documents. How
to manage changes mid- project, change
control, backlog, grooming. Tools to
track and update requirements. Jira,
confluence, notion, etc. tying
requirements directly to tasks, code,
and test cases. So, I'll let you go
first. Bonus material. Where where do
you want to add that?
Well, you can't knock the tools, you
know, using Confluence or some project
tracking tool is really good. We beat
this horse to death death, but you know,
code repository back, you know, always
checking your code. Uh, you know, tie
your code to tickets, ties it to
requirements. Um,
and I guess the big one is get your
teams involved early on.
I mean that is the big one because if
you don't you or if you're running
behind on getting your requirements
together there there is one of those
situations where you want to get started
early but if you don't have enough of
the requirements solidified or you don't
have enough of the why
bringing them in too soon could get you
going down too many rabbit holes. So
sometimes you have to kind of weigh the
balance here of if you get your
developers in front of this and you
start getting more questions, more
confusion than answers, it might be
worth pausing with the developers, going
back, spending a little more time with
the requirements and the customer to get
things refined and then go back to your
developers. If you sit down with your
developers and everything seems to be
going smoothly, everyone has a clear
picture, that's good. But do that again
like Rob says with, you know, Scrum, do
it in sprints. Do it more often. Make
sure everyone's on the same page. If you
start getting to where your team is
confused again or you seem to be going
off track or floundering, pause. That
might be a situation where you've hit a
gap in the requirements or your
requirements aren't clear enough for
them to continue. So those are just some
warning signs to help you stay on track
with your projects.
>> I will I going to do the keeping up with
the documentation uh with requirements
in particular.
I think it is very important to uh stay
in sync as you're particularly if you're
doing uh agile approaches is because we
there have been more than a few times
I've been in a project where it evolves
as we are you know moving through
implementation and what you started out
with for the vision for the application
changes sometimes substantially and
sometimes the uh particularly like
there'll be an approach that you were
going to take to solving the main
problem that now you've realized that's
not really a good approach. approach and
you're going to try something different
and that can be very confusing if you
are not clearly updating things to say
oh by the way we are now moving in this
direction we have done a pivot or
something along those lines be very
clear when you're doing those kinds of
changes and don't be afraid to like
gather the troops around essentially and
say okay let's make sure everybody's
clear that we are this is what we did
but now we're throwing that out and this
is what we're and to make sure that
everybody understands that impact
because whenever you make those changes,
uh, it can be confusing and you can end
up in situations, particularly if you're
not communicating that back to the team
where somebody gets left behind because
they weren't paying attention or weren't
part of that meeting or things like
that. That being said, it is time for us
to wrap this one up. We've got to go
deal with our own meetings and rounding
up the troops and all that kind of
goodness. Thank you so much for your
time. We appreciate you guys hanging out
with us, listening to all of this. Um,
feedback, however you can get it to us,
we will love to hear it. U, if you can
find a way to snail mail us, we may find
a way to get to a mailbox. I don't know
if that's going to happen, but email
always is the best way to go.
Check us out. Give us a drop us a line
and we would be happy to we'll even give
you a shout out if you would like. Just
let us know if you want to be anonymous.
We're good with that one, too. As
always, go out there and have yourself a
great one. Enjoy your your summer,
whether it's hot or not, and we will see
you next time.
[Music]