Detailed Notes
In this episode of Building Better Developers, hosts Rob Broadhead and Michael Meloche revisit one of the most important topics in software development — strong requirements.
Learn why clear, detailed, and testable requirements form the foundation of every great software project. Rob and Michael share practical techniques — like asking the right questions, clarifying assumptions, and planning for scalability — to help developers and teams avoid costly mistakes and build systems that last.
Whether you’re a new developer or an experienced engineer, this episode will help you think before you code and build on a solid foundation.
👉 Listen to the full episode:https://develpreneur.com/building-better-foundations-strong-requirements/
*Follow-us on:*
* [email protected] * https://develpreneur.com/ * https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://x.com/develpreneur * https://www.linkedin.com/company/develpreneur/
#BuildingBetterDevelopers #StrongRequirements #SoftwareFoundations #RequirementsGathering #Develpreneur
Transcript Text
like all the buttons. because I need to turn recording on. Um, yeah, I think we should do requirements. I think we've done this before, but I think requirements gathering and going back into that is always it's one of the things you just can't talk about it too often. I think there and there, who knows, we may get some extra little uh fun things that come out of this discussion uh particularly from a foundational point of view because I think uh I want to talk a little bit about how you grow your ability to gather requirements. uh how you start and it comes actually from a conversation I had um in another interview just recently um about sort of like how do you how do you get into this path in the first place. So three two uno well hello and welcome back. We are continuing our season of building better developers the developer podcast. This season is actually titled building better foundations. uh we have mixed in some interviews but this episode is not going to be an interview. We're going to talk about the foundations of gathering requirements. It is that is like the mother of all foundations for software projects. And so hang out because we're going to dive right into that in a little bit. But first I'm going to introduce myself. My name is Rob Broadhead, one of the founders of Del Developer, also the founder of RB Consulting where we help you do technology and your business better. Think about it like a a doctor coming in or a financial analysis or any of those kinds of things. Anybody that would be like say a financial or medical health care consultant, uh we are technology consultant. We're going to sit down with you. We're going to talk about how you feeling, how you doing, what are you looking for? Uh how's your days going right now? And then what are your days looking like in the future? Because with that, we're going to get a the ability to understand who you are, your company, uh where you're at, where you want to go. So we can craft a recipe for success for you. We're going to call that a road map. We will give you a technology roadmap that says, "Hey, based on where you are and where you want to be, these are the things you should do." Uh it's going to be technology agnostic. We're not coming in there and selling you Oracle products or Microsoft products or Netswuite or blah blah blah blah. We're not going to sell you that. We're going to talk to you about what matters for you, what matters for your budget, what matters for your staff, what matters for your line of business, and we're going to help you with a custombuilt roadmap that is just for you. You can check us out at rb-sns.com. If you go to rb-sns.com.php, you can dive in right away and you can have a technology assessment roadmap within a few days. Uh there's also a lot of other products and services we have there. Not to mention you can reach out if you have questions. Uh there's a contact. I would love to have a conversation for with you about that. Good things and bad things. Um good thing is it is getting into the the later months of the year starting to cool down a little bit, things like that, which makes like these are some of my favorite nights. I love it when you have like a moderately warm day, you get a cooler night. It's perfect for like, you know, kicking back and having a little adult beverage and stuff like that. Uh the bad thing is that it gets dark early and me being I'm now being older and older than I am. By the time it's dark, part of my body is like, "Okay, it's bedtime." And then also getting up in the morning sometimes is a little bit off of my normal schedule, which makes it a tad of a challenge. Uh but I was able to get up today and get going just like my co-host is going to go ahead and introduce himself. >> Hey everyone, my name is Mike Malashsh. I'm one of the co-founders of building better developers, also known as developer. I'm also the founder of Envision QA where we help businesses take back control of their system. We It's e we will either build you a custom software or help you find something over the counter that meets your needs. Our focus is simple, great service, smart solutions, and rockolid quality. We build tools that replace frustrating systems, streamline your operations, and are fully tested to work right the first time. At Envision QA, we combine development and quality assurance to give you software you can trust and support you can count on. Check us out at envisionqa.com. Good things and bad things. So, similar to Rob, it's fall. I'm really enjoying this season. Halloween's right around the corner. I'm really looking forward to it. It's one of my favorite holidays. Uh downside, it just means that we're slowly moving into winter and it's going to be getting colder and I'm not looking forward to snow. Sometimes I have to hit my mute button a little faster. So, we're going to talk about requirements gathering. Now, we have talked about in the prior couple episodes where we were talking and not doing interviews, um, talk about low code and no code and we talked about AI and we talked often about uh, requirements. We got into that quite a bit and user stories and some of those things. I want to focus on the foundational skills, the requirements gathering and how to do better. Um, particularly when you're starting out and this is I think the biggest challenge is that when you come out of college school, whatever it is, you know, even a boot camp, what what you've originally come out of, how you learned your skills was based on being given requirements. You had a a homework assignment or a lab and it said, "Well, this is what you're supposed to do." You didn't you probably unless you had a software engineering class or something like that, you probably did not have a situation where the you know the there was an open-ended solution, an open-ended problem where you would have to actually go, you know, find a problem, figure out the requirements, and then go build the solution. It was always spoonfed to you. And even as junior developers, we were often given that. It's like, here's your task, go do it. here's what you need to do, go do it. Now, that means that we usually don't get into the point where we're part of a requirements gathering effort until we actually, you know, have moved along a little bit and now we have a habits that have nothing to do with requiring GA uh gathering requirements and we're being asked to do something that technically probably we have never done or not done enough of it. So I want to talk about the foundational skills of gathering requirements all the time is making that part of your process, making it part of your building software. So even if you're brand new, if you're into you've got a task assigned to you and it says, I need you to build a function that you know adds these two numbers and kicks out the result. Get in the habit of asking questions about it. ask find some like take an extra step to get either to clarify the requirements or to get more requirements. So for things like this like let's say you are given a task it just says I'm going to be we're going to give you two numbers and you need to put the you you know add them and kick out the sum the summation. Cool. Ask them well are these numbers always going to be you know are they going to be individual? Uh should we ever worry about maybe we're going to send them as a commaepparated values of one and two or is it always going to be two numbers or do these numbers need to be positive? Could it be negative or are they always positive? Are they integers or are they maybe decimals? Uh, does the output need to be a number or should it be a string? Should there be some sort of a user friendly message? Is there some additional formatting we need? I mean, there's I know it feels like because I just did this, it feels like belaboring a point, but I think you can pick a couple of key questions like that and ask those to and maybe you don't even have to ask them. Honestly, if you just go through the exercise of what are all the things I need to know, then now what you're doing is you're gathering requirements and you may be able to answer all of those questions based on what was provided. So, you don't have to gather more. But the whole idea of saying, okay, well, what do I think might be the requirements or what are some clarifications that I need for this? doing that process and either going back to the original the source material you know maybe it's the task that you were assigned or whoever assigned you that task or whoever owns it so that you can ask those questions uh will help you build those skills. It's really about analyzing the problem and then saying okay where are there gaps where are there holes where are there things that are uh that are cloudy and they need to be clarified. So those are my thoughts at the start le and your thoughts u requirement foundations. >> So requirement foundations to me so I liked how you kind of laid it out but to me when I think about requirements like you were talking about how you're getting an assignment in school. I look at cooking cooking is a great example for requirements gathering. You can't cook something unless you have a recipe to follow. So, you go to a cookbook, you go to your, you know, post-it cards from your grandparents. Usually, you have some step-by-step instructions on how to do something right. If you deviate from those requirements, you do not get the desired result. You get something that is different than the expected outcome from what you were expecting. It's like if you want chocolate chip cookies, don't add raisins. You're not going to get chocolate chip cookies. you deviated from the requirements. And when you go to getting requirements or trying to define the requirements for a project you're working on or just trying to understand what someone wants for software, it's getting down to those nitty-gritty details of the stepbystep instructions you need to kind of build the application. The problem a lot of times with requirements gathering is sometimes the people you're talking to don't know everything that they need for the system. They may have an idea of what they want and as they're explaining it to you, you're getting a small slice of the picture. You're getting a very narrow view of the requirements. And if you're just starting out, you may take that at face value and you go build the application. And what you discover by the end of the application, it's like, oh, this little thinly slice is not what they need. They need something bigger than this or they need something different than this. Uh, you gave a good example of, you know, like an EMR or a HR application for someone with no employees. When you go to talk to someone about building software and you want to gather the requirements, ask them multiple questions about what it is they want. Don't just assume that they know what it is that they need or what the steps are. Sometimes they do, sometimes they don't. And many times um we have been burned and we burn many hours trying to build an application because the requirements are constantly changing because we never quite nailed down what they were or what we were told at the beginning is not really the application that we're building. So you have to be careful uh and kind of roll that back at the beginning and have checkpoints. Not only start with the requirements gathering what it is, what's the why and why do we want to build it and how do we want to build it, but keep checking in. Okay, here's where we're going, here's what we're building. You know, uh in previous episode we talked about building wireframes or building a workable demo. That's one way to do it. But the requirements is before all that. You need to really understand the why. And as you're going through those requirements, if you are reading them and you have an if then or a line item on your requirement, your requirements aren't defined. You have multiple paths. You need to go back and figure out what is the actual requirement. Requirement should basically be true or false. If I do this, it should be this or this requirement is this. It should not be open to interpretation. It should not be, oh, um, the user wants them to enter in some information. Well, is this information alpha numeric? Is it numeric? Is it password restrict? There are many questions that could come up from just that one open statement that you don't want. The requirement should be plain and simple. We need an input box that takes a password that is hash code that meets these requirements. If it's not plain and simple like that, you are missing something and you're going to be running into problems. >> I think yeah, I like the the idea of trust but verify. uh particularly when someone comes to me with a uh a I want X. This is the solution I want. Um I think the best way to start with that is uh and granted we're getting a little higher level with these, but it's it's things like okay well what does that look like to you? Tell me what like does say I want a CRM. Well, what does a CRM mean to you? What does that include? Now, you can offer suggestions if they if they need that, but a lot of times it's like, well, what does that mean? What does that include? What features are involved in that? And sometimes you can throw stuff out there like, well, you know, a lot of people that have this kind of system, this is a feature that they use. And they'll find and you'll hear those like, I don't need that. Like, okay, well, cool. Then we won't we won't build that. where so yeah there's things that are assumed and it's within any industry there is a language and there are certain things that their words mean different things as specific things depending on where you're at what your vertical is and things like that those are the things that you need to learn those are things that you need to clarify because just as somebody says they need you know this kind of a system they need like I don't like people say well we need full stack developers okay what Does that mean why why do you need full stack developers? What do you need? They're like, well, that's what I heard. And they'll say, I've I have seen AI generated stuff all over the place that says that we need, you know, requirement for like a developer position requirement must know and it will say Java, PHP, uh, Python, Ruby, Deli, ADA, I don't know. It'll give you like all these things. It's like you will see requirements that are generated that's like where did you get that? I like oh well AI told me. It's like those are contradictory. You need one. You don't need all of those. And that so often is the case that we run into with requirements is that we have these things where people say I want this and this is how it needs to work. And what they're doing is they're getting ahead of the requirements. They're trying to implement it. And a lot of times it's like, wait, let's back this up because I don't think you really need that. I think you need this thing and that actually solves that problem and solves it better than the approach you're taking. But to do that, before you can have that conversation, you need to back them up and say, why do you need that? Explain to me why you need that specific thing. Why do you need that feature? Why do you need that function? What purpose does it serve? What is the why? And then we can figure out whether that makes sense or not. It's like how are we going to do that? We can put the requirements into it and we can dig a little bit deeper. Requirements gathering is always about saying and then what? Okay, so you want that. Great. And then how does that look? And then what? And then what happens after that? And then what is the expected outcome? And then how do people get notified? And it's it really is trying to reset yourself to the mind of a two-year-old so that almost every question that is asked, you're looking for questions around it because you want to learn more about that answer. That is how you're going to get better requirements. Thoughts on that? Yeah, it I like the and then what. Um the other thing I'll throw out is as you're talking to your customer about what they want, expand on what they need. uh stick to what they want and within that area. But be careful that you're not just getting the nice to have or the happy path because sometimes there are edge cases and things that are in their head that are automatic for what they do and they don't think about them and they're going to be missed from the requirements. So you could get the core like this is what I need, but you're going to find out very quickly that there are other components or other pieces that need to be built around this that could actually change the core requirements. But unless you can figure out how to kind of get that pull that information out of them, you're going to miss things. So as you're doing that and then you know why are you doing this and and why and and the next thing make sure you also say okay you're doing this but watch for those things. It's like oh well what else can they do there and try to expand their thoughts on what it is that they're doing if this is an existing system. Now, if it's something new that it, you know, that they're trying to build from their mind or, you know, maybe they've written it down on a notepad, still get to the core requirements, but make sure that you cover enough of the features that you need to build the application because one of the things you run into a lot is that the customer, the person wanting the application built does not always think in tech and they may not be technical at all. So they may not know the right questions to ask or the right information to convey and that's our job. We have to ask the right questions and we have to pull that information out from our customers. And that's a lot of it is with your your general requirements stuff when you're starting out there's going to be you're going to have this goes back to like you know building your foundations. You're going to be assigned certain tasks. um you're going to have, you know, they may say it may be big tasks, it may be small tasks, but usually almost always actually, I guess, when you're starting out, those are going to be part of a bigger thing. They fit into a bigger solution. You're not building an entire application. You're building something that is going to fit in to an existing application. You're probably working with other developers or code that's been, you know, created elsewhere. And those requirements questions are great to ask. then is like okay we have this piece so I'm building this little feature this function is there already maybe like an administrative because it's going to take some administration is there an administrative piece for this is there a report that is going to utilize this uh is there an a navigation uh menu item or a button or something like that that's going to trigger this u is this need to be run as a micros service or is this something that's going to be run without any kind of UI is there if there's a user interface what are what sort of interfaces out there? Those questions may not may not be critical to you getting that task done, but they may be very informative. It may be things where you're going to say, "All right, this is going to be displayed on a phone or some very small device. So, I can't have real big lengthy messages are going to be kicking out or, you know, the text response that I get back. I've got to limit that." Or maybe I've got to be able to have a way to um you know have a have two versions of it, a long and a short version of it or things like that. Um it may be things like what kind of a system are we building this in? These are getting used to the questions that are parts of systems. Things like is there logging? What sort of exception handling is there? What sort of messaging and notifying notification system is there? Is there some sort of authentication thing that I have to verify or take a token or something like that to make sure that there's an authorized user of this feature or this function or this data? Those questions are the questions that a lot of times are going to help you in requirements gathering because people that are not used to building software and even sometimes people that are these requirements are not going to come out right away. And so you need to ask those fundamental things is talk is learn what is fundamental potentially in any application and some of them you may not need. They may say, you know, we don't do unit tests. We don't do logging. We don't do exception handling. We don't have authenticated users or anything. There's we don't have security. There's all kinds of things that may or may need not be a part of it. And there may be uh variations of how much of that is a part of the solution. All of that is what your requirements are. And if you start doing that sooner rather than later and asking those kinds of questions, you're going to get in the habit of sort of having your own little mental checklist of like these are all the like things that are these are the properties of software itself. So I'm going to ask questions about that and then these are properties of of features and then you're going to start being able to ask questions around those. Now, they may, you know, they may be general in a sense, so you can customize them to every customer, but they're going to give you that that to-do list of I need to go through all these things if I'm going to properly gather requirements. Thoughts? >> Yeah, I think you hit most of it, most of the high points on that. One of the other things as you're talking about requirements a lot of people do not think about especially early on in projects is scalability. So unless you're asking the right questions for the requirements, you could pigeon your pigeon hole yourself in such a way that the requirements build you a system that cannot scale to the needs of your customer. And that is a death note. So make sure that as you're asking the requirements, you are thinking about the type of systems and hardware that it does need to go on and that you are going to meet the needs for the customer not just for today but for down the road to make sure that you can the application can grow as the company grows and they don't have to throw it out and start over. >> That is that is an advertisement for us basically. That's what it's why you have technology road maps and things like that is you need to look at not only where you are today but where you going to be in the future because otherwise your requirements are they're not really I guess they're correct they are you know for today but they're really not as useful as they could be. So when you're gathering requirements you definitely want to look at uh be you know looking forward you don't want to paint yourself into a corner. Uh, and a lot of times that is that's a lot of times where I have that conversation with customers where I say, "Look, I'm asking this not because I need I want to build this for you today, but I need to know so that we can have the hooks in place or whatever we need to do so that when you grow and if you do want to do this in the future, then we're not having to rewrite, you know, strip everything out and rewrite it, we're going to be able to very easily access it, enhance it, or whatever needs to be done to give you that feature." Now, that being said, I think it's time for us to wrap this one up. I think we've we've covered our requirements. Uh, next episode, may or may not be an interview. We'll see how it goes. We definitely have some in the works. Uh, we're going to continue doing some of those as part of our uh talking about some of these foundations and, uh, just some of the things that are out there that are, uh, some real world examples on well, as well as the kinds of things that we share on a regular basis. As always, love to hear from you. Shoot us an email at [email protected]. You can leave us feedback on the developer.com site. Uh we have contact forms. You can leave feedback on any of the articles. Uh leave review on anywhere that you are listening to podcasts. You can check us out the developer channel on Yahoo, not Yahoo, YouTube. A very different why. Uh check them check us out there and leave us uh comments and feedback. We would love to hear that, you know, pro positive, negative, all of the above as we just want to take that and build a better podcast for you as we move forward. As always, I appreciate you so much. Thank you for your time. Have yourself a great day, a great week, and we will talk to you next time. Bonus material. Uh because we didn't have it much for the last episode, so I guess we should make up for it this time, right? Yeah. So last episode we talked about vibe coding. You know AI especially today if if you don't know how to do requirements gathering AI is a good example of trial and error. Uh, if you want to kind of play around with like simulate a customer, open up a chat and say, "Hey, um, I want you to emulate a business that is selling cookies and they need an application. So, I'm going to ask you questions about your business to build an application." And just play around with AI. Use it to train yourself on how to ask questions. If AI is giving you crap, you're not asking the right questions. Um, or you're using the wrong AI tool. But if you're starting out, this is a good way to kind of train yourself and learn how to use AI at the same time. >> That is uh an awesome little bit of bonus material. I go back to from requirements gathering. Um, I go back to like the my tried andrue trusted one of like build yourself an application. Find a little side hustle project. Find something some problem that you need to solve and this is scratch your own itch and go define, you know, say, "Oh, I need to build an application to do X." And ideally, at the very least, just document it in some way. Just even if it's just like a little checklist or something like these are the requirements, these are the things I need to do. and make sure it's something that you can uh whether it's a you know a physical notebook if it's if it's something digital make sure that you can like track the history and then as you add features because you're going to be in there you're going to be coding most likely and you're going to add features put those back on the requirements because you're like oh I needed this I forgot it oh I needed this I forgot it so that you instead of I'm going to do this and then you just go build it and you're constantly adjusting the requirements in your head as you're adding the features you're actually tracking what were the what should the requirements have been had I completely built out all the requirements for this when I started because I think that is a great way for you to very quickly realize that there's going to be a lot of questions around that and to give yourself a good list of like you did it and so now if you go back and look at that list it's going to help you it's going to stir the right questions in your mind when you're talking to a customer when you're looking at their requirements and you're saying oh yeah I did this thing and I forgot about this. So, I'm going to ask them about it. Do they need it? How do they want that to look? You know, things of that nature is anytime it's I granted I'm one of those people. I learn best by doing and so this is my, you know, my happy place as far as learning is concerned. Go out and do it. And like I said, if you are the customer and you're building out the requirements, it's really good because you know the only reason that the requirements didn't come out is you didn't ask the right question at the start. It's not because you know and yeah the and you're going to realize too recognize and relate to empathize with the customers when you realize that yeah they're not going to know everything. So you're not going to be frustrated when there's something that was missed or the answer doesn't come back. You know you don't get complete enough answers and you go back and you you just do this. The more you do it the better it's going to be. Uh like everything else the more you practice the better you get. Uh, like I said, you can do little projects all over the place and that will help you quite a bit. That wraps this one up. We have things to do, places to go, all that code, divide, all that kind of good stuff. Appreciate the time that you guys have spent with us. We are not even close to done with this season. We've got plenty ahead. Lot more foundations, lot more interviews, uh, lots to learn for us and for you. So, as always, leave us fed feedback and all the ways that you can do feedback. Uh, we'd happy to hear from you and to see where you guys would like to see us go next. That being said, it is time for us to wrap this one up. So, go out there and have yourself a good one and we'll talk to you next time.
Transcript Segments
like all the buttons. because I need to
turn recording on. Um, yeah, I think we
should do requirements. I think we've
done this before, but I think
requirements gathering and going back
into that is always it's one of the
things you just can't talk about it too
often. I think there and there, who
knows, we may get some extra little uh
fun things that come out of this
discussion uh particularly from a
foundational point of view because I
think uh I want to talk a little bit
about how you grow your ability to
gather requirements. uh how you start
and it comes actually from a
conversation I had um in another
interview just recently um about sort of
like how do you how do you get into this
path in the first place. So three two
uno well hello and welcome back. We are
continuing our season of building better
developers the developer podcast. This
season is actually titled building
better foundations. uh we have mixed in
some interviews but this episode is not
going to be an interview. We're going to
talk about the foundations of gathering
requirements. It is that is like the
mother of all foundations for software
projects. And so hang out because we're
going to dive right into that in a
little bit. But first I'm going to
introduce myself. My name is Rob
Broadhead, one of the founders of Del
Developer, also the founder of RB
Consulting where we help you do
technology and your business better.
Think about it like a a doctor coming in
or a financial analysis or any of those
kinds of things. Anybody that would be
like say a financial or medical health
care consultant, uh we are technology
consultant. We're going to sit down with
you. We're going to talk about how you
feeling, how you doing, what are you
looking for? Uh how's your days going
right now? And then what are your days
looking like in the future? Because with
that, we're going to get a the ability
to understand who you are, your company,
uh where you're at, where you want to
go. So we can craft a recipe for success
for you. We're going to call that a road
map. We will give you a technology
roadmap that says, "Hey, based on where
you are and where you want to be, these
are the things you should do." Uh it's
going to be technology agnostic. We're
not coming in there and selling you
Oracle products or Microsoft products or
Netswuite or blah blah blah blah. We're
not going to sell you that. We're going
to talk to you about what matters for
you, what matters for your budget, what
matters for your staff, what matters for
your line of business, and we're going
to help you with a custombuilt roadmap
that is just for you. You can check us
out at rb-sns.com.
If you go to rb-sns.com.php,
you can dive in right away and you can
have a technology assessment roadmap
within a few days. Uh there's also a lot
of other products and services we have
there. Not to mention you can reach out
if you have questions. Uh there's a
contact. I would love to have a
conversation for with you about that.
Good things and bad things.
Um good thing is it is getting into the
the later months of the year starting to
cool down a little bit, things like
that, which makes like these are some of
my favorite nights. I love it when you
have like a moderately warm day, you get
a cooler night. It's perfect for like,
you know, kicking back and having a
little adult beverage and stuff like
that. Uh the bad thing is that it gets
dark early and me being I'm now being
older and older than I am. By the time
it's dark, part of my body is like,
"Okay, it's bedtime." And then also
getting up in the morning sometimes is a
little bit off of my normal schedule,
which makes it a tad of a challenge. Uh
but I was able to get up today and get
going just like my co-host is going to
go ahead and introduce himself.
>> Hey everyone, my name is Mike Malashsh.
I'm one of the co-founders of building
better developers, also known as
developer. I'm also the founder of
Envision QA where we help businesses
take back control of their system. We
It's e we will either build you a custom
software or help you find something over
the counter that meets your needs. Our
focus is simple, great service, smart
solutions, and rockolid quality. We
build tools that replace frustrating
systems, streamline your operations, and
are fully tested to work right the first
time. At Envision QA, we combine
development and quality assurance to
give you software you can trust and
support you can count on. Check us out
at envisionqa.com.
Good things and bad things. So, similar
to Rob, it's fall. I'm really enjoying
this season. Halloween's right around
the corner. I'm really looking forward
to it. It's one of my favorite holidays.
Uh downside, it just means that we're
slowly moving into winter and it's going
to be getting colder and I'm not looking
forward to snow.
Sometimes I have to hit my mute button a
little faster. So, we're going to talk
about requirements gathering. Now, we
have talked about in the prior couple
episodes where we were talking and not
doing interviews, um, talk about low
code and no code and we talked about AI
and we talked often about uh,
requirements. We got into that quite a
bit and user stories and some of those
things. I want to focus on the
foundational skills, the requirements
gathering and how to do better. Um,
particularly when you're starting out
and this is I think the biggest
challenge is that when you come out of
college school, whatever it is, you
know, even a boot camp, what what you've
originally come out of, how you learned
your skills was based on being given
requirements.
You had a a homework assignment or a lab
and it said, "Well, this is what you're
supposed to do." You didn't you probably
unless you had a software engineering
class or something like that, you
probably did not have a situation where
the you know the there was an open-ended
solution, an open-ended problem where
you would have to actually go, you know,
find a problem, figure out the
requirements, and then go build the
solution. It was always spoonfed to you.
And even as junior developers, we were
often given that. It's like, here's your
task, go do it. here's what you need to
do, go do it. Now, that means that we
usually don't get into the point where
we're part of a requirements gathering
effort until we actually, you know, have
moved along a little bit and now we have
a habits that have nothing to do with
requiring GA uh gathering requirements
and we're being asked to do something
that technically probably we have never
done or not done enough of it. So I want
to talk about the foundational skills of
gathering requirements all the time is
making that part of your process, making
it part of your building software. So
even if you're brand new, if you're into
you've got a task assigned to you and it
says, I need you to build a function
that you know adds these two numbers and
kicks out the result.
Get in the habit of asking questions
about it. ask find some like take an
extra step to get either to clarify the
requirements or to get more
requirements. So for things like this
like let's say you are given a task it
just says I'm going to be we're going to
give you two numbers and you need to put
the you you know add them and kick out
the sum the summation. Cool. Ask them
well are these numbers always going to
be you know are they going to be
individual? Uh should we ever worry
about maybe we're going to send them as
a commaepparated values of one and two
or is it always going to be two numbers
or do these numbers need to be positive?
Could it be negative or are they always
positive? Are they integers or are they
maybe decimals? Uh, does the output need
to be a number or should it be a string?
Should there be some sort of a user
friendly message? Is there some
additional formatting we need? I mean,
there's I know it feels like because I
just did this, it feels like belaboring
a point, but I think you can pick a
couple of key questions like that and
ask those to and maybe you don't even
have to ask them. Honestly, if you just
go through the exercise of what are all
the things I need to know, then now what
you're doing is you're gathering
requirements and you may be able to
answer all of those questions based on
what was provided. So, you don't have to
gather more. But the whole idea of
saying, okay, well, what do I think
might be the requirements or what are
some clarifications that I need for
this? doing that process and either
going back to the original the source
material you know maybe it's the task
that you were assigned or whoever
assigned you that task or whoever owns
it so that you can ask those questions
uh will help you build those skills.
It's really about analyzing the problem
and then saying okay where are there
gaps where are there holes where are
there things that are uh that are cloudy
and they need to be clarified. So those
are my thoughts at the start le and your
thoughts u requirement foundations.
>> So requirement foundations to me so I
liked how you kind of laid it out but to
me when I think about requirements like
you were talking about how you're
getting an assignment in school. I look
at cooking cooking is a great example
for requirements gathering. You can't
cook something unless you have a recipe
to follow. So, you go to a cookbook, you
go to your, you know, post-it cards from
your grandparents. Usually, you have
some step-by-step instructions on how to
do something right. If you deviate from
those requirements, you do not get the
desired result. You get something that
is different than the expected outcome
from what you were expecting. It's like
if you want chocolate chip cookies,
don't add raisins. You're not going to
get chocolate chip cookies. you deviated
from the requirements.
And when you go to getting requirements
or trying to define the requirements for
a project you're working on or just
trying to understand what someone wants
for software, it's getting down to those
nitty-gritty details of the stepbystep
instructions you need to kind of build
the application. The problem a lot of
times with requirements gathering is
sometimes the people you're talking to
don't know everything that they need for
the system. They may have an idea of
what they want and as they're explaining
it to you, you're getting a small slice
of the picture. You're getting a very
narrow view of the requirements.
And if you're just starting out, you may
take that at face value and you go build
the application. And what you discover
by the end of the application, it's
like, oh, this little thinly slice is
not what they need. They need something
bigger than this or they need something
different than this. Uh, you gave a good
example of, you know, like an EMR or a
HR application for someone with no
employees.
When you go to talk to someone about
building software and you want to gather
the requirements,
ask them multiple questions about what
it is they want. Don't just assume that
they know what it is that they need or
what the steps are.
Sometimes they do, sometimes they don't.
And many times um we have been burned
and we burn many hours trying to build
an application because the requirements
are constantly changing because we never
quite nailed down what they were or what
we were told at the beginning is not
really the application that we're
building. So you have to be careful uh
and kind of roll that back at the
beginning and have checkpoints.
Not only start with the requirements
gathering what it is, what's the why and
why do we want to build it and how do we
want to build it, but keep checking in.
Okay, here's where we're going, here's
what we're building. You know, uh in
previous episode we talked about
building wireframes or building a
workable demo. That's one way to do it.
But the requirements is before all that.
You need to really understand the why.
And as you're going through those
requirements, if you are reading them
and you have an if then or a line item
on your requirement, your requirements
aren't defined. You have multiple paths.
You need to go back and figure out what
is the actual requirement. Requirement
should basically be true or false. If I
do this, it should be this or this
requirement is this. It should not be
open to interpretation. It should not
be, oh, um, the user wants them to enter
in some information. Well, is this
information alpha numeric? Is it
numeric? Is it password restrict? There
are many questions that could come up
from just that one open statement that
you don't want. The requirement should
be plain and simple. We need an input
box that takes a password that is hash
code that meets these requirements. If
it's not plain and simple like that, you
are missing something and you're going
to be running into problems.
>> I think yeah, I like the the idea of
trust but verify. uh particularly when
someone comes to me with a uh a I want
X. This is the solution I want. Um I
think the best way to start with that is
uh and granted we're getting a little
higher level with these, but it's it's
things like okay well what does that
look like to you? Tell me what like does
say I want a CRM. Well, what does a CRM
mean to you? What does that include?
Now, you can offer suggestions if they
if they need that, but a lot of times
it's like, well, what does that mean?
What does that include? What features
are involved in that? And sometimes you
can throw stuff out there like, well,
you know, a lot of people that have this
kind of system, this is a feature that
they use. And they'll find and you'll
hear those like, I don't need that.
Like, okay, well, cool. Then we won't we
won't build that. where so yeah there's
things that are assumed
and it's within any industry there is a
language and there are certain things
that their words mean different things
as specific things depending on where
you're at what your vertical is and
things like that those are the things
that you need to learn those are things
that you need to clarify because just as
somebody says they need you know this
kind of a system they need like I don't
like people say well we need full stack
developers okay what Does that mean why
why do you need full stack developers?
What do you need? They're like, well,
that's what I heard. And they'll say,
I've I have seen AI generated stuff all
over the place that says that we need,
you know, requirement for like a
developer position requirement must know
and it will say Java, PHP, uh, Python,
Ruby, Deli,
ADA, I don't know. It'll give you like
all these things. It's like you will see
requirements that are generated that's
like where did you get that? I like oh
well AI told me. It's like those are
contradictory. You need one. You don't
need all of those. And that so often is
the case that we run into with
requirements is that we have these
things where people say I want this and
this is how it needs to work. And what
they're doing is they're getting ahead
of the requirements. They're trying to
implement it. And a lot of times it's
like, wait, let's back this up because I
don't think you really need that. I
think you need this thing and that
actually solves that problem and solves
it better than the approach you're
taking. But to do that, before you can
have that conversation, you need to back
them up and say, why do you need that?
Explain to me why you need that specific
thing. Why do you need that feature? Why
do you need that function? What purpose
does it serve? What is the why? And then
we can figure out whether that makes
sense or not. It's like how are we going
to do that? We can put the requirements
into it and we can dig a little bit
deeper. Requirements gathering is always
about saying and then what? Okay, so you
want that. Great. And then how does that
look? And then what? And then what
happens after that? And then what is the
expected outcome? And then how do people
get notified?
And it's it really is trying to reset
yourself to the mind of a two-year-old
so that almost every question that is
asked, you're looking for questions
around it because you want to learn more
about that answer. That is how you're
going to get better requirements.
Thoughts on that?
Yeah, it I like the and then what. Um
the other thing I'll throw out is as
you're talking to your customer about
what they want, expand on what they
need. uh stick to what they want and
within that area. But be careful that
you're not just getting the nice to have
or the happy path because sometimes
there are edge cases and things that are
in their head that are automatic for
what they do and they don't think about
them and they're going to be missed from
the requirements. So you could get the
core like this is what I need, but
you're going to find out very quickly
that there are other components or other
pieces that need to be built around this
that could actually change the core
requirements. But unless you can figure
out how to kind of get that pull that
information out of them, you're going to
miss things. So as you're doing that and
then you know why are you doing this and
and why and and the next thing make sure
you also say okay you're doing this but
watch for those things. It's like oh
well what else can they do there and try
to expand their thoughts on what it is
that they're doing if this is an
existing system. Now, if it's something
new that it, you know, that they're
trying to build from their mind or, you
know, maybe they've written it down on a
notepad,
still get to the core requirements, but
make sure that you cover enough of the
features that you need to build the
application because
one of the things you run into a lot is
that the customer, the person wanting
the application built does not always
think in tech
and they may not be technical at all. So
they may not know the right questions to
ask or the right information to convey
and that's our job. We have to ask the
right questions and we have to pull that
information out from our customers. And
that's a lot of it is with your your
general requirements stuff when you're
starting out there's going to be you're
going to have this goes back to like you
know building your foundations. You're
going to be assigned certain tasks. um
you're going to have, you know, they may
say it may be big tasks, it may be small
tasks, but usually almost always
actually, I guess, when you're starting
out, those are going to be part of a
bigger thing. They fit into a bigger
solution. You're not building an entire
application. You're building something
that is going to fit in to an existing
application. You're probably working
with other developers or code that's
been, you know, created elsewhere.
And those requirements questions are
great to ask. then is like okay we have
this piece so I'm building this little
feature this function
is there already maybe like an
administrative because it's going to
take some administration is there an
administrative piece for this is there a
report that is going to utilize this uh
is there an a navigation uh menu item or
a button or something like that that's
going to trigger this u is this need to
be run as a micros service or is this
something that's going to be run without
any kind of UI is there if there's a
user interface
what are what sort of interfaces out
there? Those questions may not
may not be critical to you getting that
task done, but they may be very
informative. It may be things where
you're going to say, "All right, this is
going to be displayed on a phone or some
very small device. So, I can't have real
big lengthy messages are going to be
kicking out or, you know, the text
response that I get back. I've got to
limit that." Or maybe I've got to be
able to have a way to um you know have a
have two versions of it, a long and a
short version of it or things like that.
Um it may be things like what kind of a
system are we building this in? These
are getting used to the questions that
are parts of systems. Things like is
there logging? What sort of exception
handling is there? What sort of
messaging and notifying notification
system is there? Is there some sort of
authentication thing that I have to
verify or take a token or something like
that to make sure that there's an
authorized user of this feature or this
function or this data? Those questions
are the questions that a lot of times
are going to help you in requirements
gathering because people that are not
used to building software and even
sometimes people that are these
requirements are not going to come out
right away. And so you need to ask those
fundamental things is talk is learn what
is fundamental potentially in any
application and some of them you may not
need. They may say, you know, we don't
do unit tests. We don't do logging. We
don't do exception handling. We don't
have authenticated users or anything.
There's we don't have security. There's
all kinds of things that may or may need
not be a part of it. And there may be uh
variations of how much of that is a part
of the solution. All of that is what
your requirements are. And if you start
doing that sooner rather than later and
asking those kinds of questions, you're
going to get in the habit of sort of
having your own little mental checklist
of like these are all the like things
that are these are the properties of
software itself. So I'm going to ask
questions about that and then these are
properties of of features and then
you're going to start being able to ask
questions around those. Now, they may,
you know, they may be general in a
sense, so you can customize them to
every customer, but they're going to
give you that that to-do list of I need
to go through all these things if I'm
going to properly gather requirements.
Thoughts?
>> Yeah, I think you hit most of it,
most of the high points on that. One of
the other things as you're talking about
requirements a lot of people do not
think about especially early on in
projects is scalability. So unless
you're asking the right questions for
the requirements, you could pigeon your
pigeon hole yourself in such a way that
the requirements build you a system that
cannot scale to the needs of your
customer. And that is a death note. So
make sure that as you're asking the
requirements, you are thinking about the
type of systems and hardware that it
does need to go on and that you are
going to meet the needs for the customer
not just for today but for down the road
to make sure that you can the
application can grow as the company
grows and they don't have to throw it
out and start over.
>> That is that is an advertisement for us
basically. That's what it's why you have
technology road maps and things like
that is you need to look at not only
where you are today but where you going
to be in the future because otherwise
your requirements are they're not really
I guess they're correct they are you
know for today but they're really not as
useful as they could be. So when you're
gathering requirements you definitely
want to look at uh be you know looking
forward you don't want to paint yourself
into a corner. Uh, and a lot of times
that is that's a lot of times where I
have that conversation with customers
where I say, "Look, I'm asking this not
because I need I want to build this for
you today, but I need to know so that we
can have the hooks in place or whatever
we need to do so that when you grow and
if you do want to do this in the future,
then we're not having to rewrite, you
know, strip everything out and rewrite
it, we're going to be able to very
easily access it, enhance it, or
whatever needs to be done to give you
that feature." Now, that being said, I
think it's time for us to wrap this one
up. I think we've we've covered our
requirements. Uh, next episode, may or
may not be an interview. We'll see how
it goes. We definitely have some in the
works. Uh, we're going to continue doing
some of those as part of our uh talking
about some of these foundations and, uh,
just some of the things that are out
there that are, uh, some real world
examples on well, as well as the kinds
of things that we share on a regular
basis. As always, love to hear from you.
Shoot us an email at [email protected].
You can leave us feedback on the
developer.com site. Uh we have contact
forms. You can leave feedback on any of
the articles. Uh leave review on
anywhere that you are listening to
podcasts. You can check us out the
developer channel on Yahoo, not Yahoo,
YouTube. A very different why. Uh check
them check us out there and leave us uh
comments and feedback. We would love to
hear that, you know, pro positive,
negative, all of the above as we just
want to take that and build a better
podcast for you as we move forward. As
always, I appreciate you so much. Thank
you for your time. Have yourself a great
day, a great week, and we will talk to
you next time.
Bonus material. Uh because we didn't
have it much for the last episode, so I
guess we should make up for it this
time, right?
Yeah. So last episode we talked about
vibe coding. You know AI especially
today if if you don't know how to do
requirements gathering AI is a good
example of trial and error. Uh, if you
want to kind of play around with like
simulate a customer, open up a chat and
say, "Hey, um,
I want you to emulate a business that is
selling cookies and they need an
application. So, I'm going to ask you
questions about your business to build
an application." And just play around
with AI. Use it to train yourself on how
to ask questions. If AI is giving you
crap, you're not asking the right
questions. Um, or you're using the wrong
AI tool. But if you're starting out,
this is a good way to kind of train
yourself and learn how to use AI at the
same time.
>> That is uh an awesome little bit of
bonus material. I go back to from
requirements gathering. Um, I go back to
like the my tried andrue trusted one of
like build yourself an application. Find
a little side hustle project. Find
something some problem that you need to
solve and this is scratch your own itch
and go define, you know, say, "Oh, I
need to build an application to do X."
And ideally, at the very least, just
document it in some way. Just even if
it's just like a little checklist or
something like these are the
requirements, these are the things I
need to do. and make sure it's something
that you can uh whether it's a you know
a physical notebook if it's if it's
something digital make sure that you can
like track the history and then as you
add features because you're going to be
in there you're going to be coding most
likely and you're going to add features
put those back on the requirements
because you're like oh I needed this I
forgot it oh I needed this I forgot it
so that you instead of
I'm going to do this and then you just
go build it and you're constantly
adjusting the requirements in your head
as you're adding the features you're
actually tracking what were the what
should the requirements have been had I
completely built out all the
requirements for this when I started
because I think that is a great way for
you to very quickly realize that there's
going to be a lot of questions around
that and to give yourself a good list of
like you did it and so now if you go
back and look at that list it's going to
help you it's going to stir the right
questions in your mind when you're
talking to a customer when you're
looking at their requirements and you're
saying oh yeah I did this thing and I
forgot about this. So, I'm going to ask
them about it. Do they need it? How do
they want that to look? You know, things
of that nature is anytime it's I granted
I'm one of those people. I learn best by
doing and so this is my, you know, my
happy place as far as learning is
concerned. Go out and do it. And like I
said, if you are the customer and you're
building out the requirements, it's
really good because you know the only
reason that the requirements didn't come
out is you didn't ask the right question
at the start. It's not because you know
and yeah the and you're going to realize
too recognize and relate to empathize
with the customers when you realize that
yeah they're not going to know
everything. So you're not going to be
frustrated when
there's something that was missed or the
answer doesn't come back. You know you
don't get complete enough answers and
you go back and you you just do this.
The more you do it the better it's going
to be. Uh like everything else the more
you practice the better you get. Uh,
like I said, you can do little projects
all over the place and that will help
you quite a bit. That wraps this one up.
We have things to do, places to go, all
that code, divide, all that kind of good
stuff. Appreciate the time that you guys
have spent with us. We are not even
close to done with this season. We've
got plenty ahead. Lot more foundations,
lot more interviews, uh, lots to learn
for us and for you. So, as always, leave
us fed feedback and all the ways that
you can do feedback. Uh, we'd happy to
hear from you and to see where you guys
would like to see us go next. That being
said, it is time for us to wrap this one
up. So, go out there and have yourself a
good one and we'll talk to you next
time.