Requirements are not really about technical things. Requirements are a communication problem, not a technical problem. And that's I think why it's hard. And so this process of requirements development where our goal is. Exactly, as you said clear and effective communication, it's not following a set of rules, it's not conforming to some standard. It's effective communication and that has to necessarily be done in an incremental and iterative fashion. Hey everyone.
My name is Henry Surya, we Robin. And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work.
So let's dive into our Journal. Hello again to all of you, my friends and my listeners, welcome to the technology, you know, podcast the podcast where you can learn about technical leadership and Excellence from my conversation, with great thought leaders in the tech industry. If you haven't, please subscribe and follow the show on your podcast app and social media on LinkedIn. Twitter and Instagram. And to appreciate and support my
work. Subscribe as a patron at technology, not Dev slash Patron or buy me a coffee at technology, not Dev slash. Tip my guest for today's episode is called uyghurs. Carl is the co-author of software requirements, Essentials and has previously appeared in our episode. 103, in this episode, we discussed six essential practices for software requirements.
Out of the 20 core practices specified in his book, such as understanding the problem before, converging on a solution understanding what users need to do with the solution prioritizing requirements and a few more. Call also explained the importance of having a clear and effective communication in developing software
requirements. His view on doing software requirements for agile teams and the importance of having good software requirements for becoming an effective software development team and for avoiding unnecessary rework. It's really great to have car back on the show for the second time. And I always enjoy and learn a lot from my conversation with him and I hope you also enjoyed this episode as much as I am producing.
Loosing it, please share this episode with your colleagues, friends and communities, and also leave a five star rating and review on a podcast and Spotify. And I hope more people can benefit from listening to this episode. Before we go to my conversation with call. Let's hear a few words from our sponsors. Are you looking for a new cool swag? Taglit Journal. Now offers you some swags that you can purchase online?
These wax are printed on demand based on your preference and Delivered safely to you all over the world where shipping is available. Check out all the cool tracks available by visiting technology, you know, the death, / shop and don't forget to break yourself. Once you receive any of those tracks. Hey guys, welcome back to technology to our podcast. Today we have a repeat guests. Someone that I really love the conversation last time in episode 103, he's called
uyghurs. So if you still remember we talked about software pulse last time. He He published a book and this time he came back with another book if you see. Remember he has written 13 books back then, right? So he decided to be productive and write one more to become 14 books. Now, and his new book is titled software requirements, Essentials core practices for successful business analysis, Carl. I'm really excited to have this
chance to talk to you again. And hopefully, we can talk a lot of things about software requirements today. Welcome to the show. Well, thank you Henry. I appreciate the chance to be back with you. Like you said, I enjoyed our Before and I'm sure we'll have a good time today as well. So it's been quite a while since our last speak, right? Is there anything that you do recently that you want to talk about besides the book? Well, when I'm not writing books or articles, I do like to record
songs as sort of my main hobby. My wife told me probably about 17 years ago. Now, she said, Carl, you need a new hobby? Well, I've played guitar for many many years since I was 12, and I'm a lot more than 12 now. But I just Started recording songs, just for fun. So, I got some software in a computer and I enjoy trying to reproduce covers of original songs that other people recorded trying to mimic what they did as well as I could. Plus I like to write my own music and record that too.
So, it's kind of fun to do all the guitar parts and the bass, and the vocals, and keyboards and stuff, and program, the drums. So, I've done a number of songs. Since last we spoke, and they're all at my website, Carl uyghurs.com there, just for fun. I'm certainly no professional, but it's a nice. Creative outlet and always a good learning opportunity. Yes, they remember, I could find a number of songs on your website. I think you also listed, I think about 50 songs there, right?
So I think not just writing books, you also write songs, so that's really great. So car let's go to your book, right? So you wrote this software requirements Essentials. If I'm not wrong, you actually wrote the thicker version of, it's called software requirements. Which has gone through multiple editions as well. Maybe if you can give us a background why you decided to write? Thinner version of that book instead.
Yeah, I was kind of funny. I hadn't planned to write this book, but nearly a year ago, I wrote a short article titled, the six most important requirements practices. Sometimes I just feel like writing something or get an idea. And so I wrote this little article, it was only maybe twelve or thirteen hundred words and I posted that article on my medium.com account. I have nearly 100 articles up there on many topics and I was just completely shocked the response to that short.
Go was just astonishing, it's been read more than 18,000 times. The posts that I created on LinkedIn to announce the article have been viewed about 100,000 times with you know, about a thousand likes and many reposts and I was just completely astonished at the positive reaction to just that little article on the six most important requirements practices.
But that made me start thinking maybe there's a market for a short book on requirements that just hits the highlights because like you said, I wrote this book called software requirements. In three additions. The Third Edition came out 10 years ago and that was a big book.
And there are a lot of long comprehensive books on software requirements, and business analysis, and those books describe dozens and dozens of practices, all these things, a business analyst, or a product owner or product manager, ought to do. And those are all useful in various situations. But busy people don't always have time to read these long books. I had this idea of kind of a paradigm shift writing a short book that just skims across the top.
It describes the 20 most important requirements, practices that I think apply to virtually all projects and teams. So that was my idea and you know it was nice because the book just came out a few weeks ago and when I held to my copy of the book in my hands and look through it, I realized that was exactly the book that I was envisioning last summer when I first got this idea. So it's nice when it works out that way and you say yep.
That's What I was trying to do. So I'm very pleased with how that came out and I chose to work with a co-author. I did that on the second edition or the third edition of the software requirements book. But I Enlisted the assistance of a co-author Candace Hawkinson and partly because she had a lot of experience of product ownership and business analysis on agile projects, which I don't have and Candace brought a lot
to the table. She brought like any other co-author different experiences new true life stories to share beyond my own. Inches. And what I've learned from. Other Consulting, clients she has a lot of Hands-On, current project experience that I don't
have personally these days. So she was helpful in making sure that the practices we selected is being in the top 20 apply to virtually all software projects regardless of the kind of product you're building and whether you're following an agile or traditional development approach so that was what we set out to do and I think we did it right? This maybe to give some illustration for people.
Who are not familiar with your software requirements book if you compare the pages, do you know how many pages difference is it? Yeah, it's a pretty big difference. The Third Edition of the software requirements book, which I also co-authored with joy Beatty is a seriously big book. It's more than 600 pages of content, but it's sort of had to be because it comprehensively covers the entire domain of requirements, development and management. And the fact is there's a lot of information.
There's a lot that people need to know about these. Things. There's a lot of things people need to do and requirements really affect everyone. On the project, all the stakeholders on the project requirements is where their interests all intersect. So that's a lot to read and many people have read it. But what about something shorter? Well, in contrast, the software requirements Essentials book is only about 150 pages long. It's about 1/4 is large.
So obviously there's a lot more information in the big book and we didn't try to duplicate all of that. At, but we don't have as many topics, we don't go into as much detail. We don't have as many stories and appendices and all the other things you find in a comprehensive book, but the software requirements Essentials book is really an excellent resource for people who want to
quickly. Learn about these, most important core practices that can add value to their projects and help, keep them out of trouble. And then, you can go back to the big software requirements book or other resources for details when you need them, right? I had to read. For the new book as well. So, I think it's pretty short, right?
Like you said, I think someone who likes to read can easily finish it in a day or two, so I think it covers a lot of Essentials just like the title like the essentials of software requirements which we are going to cover now. So for people who are maybe a little bit of confused about what is software requirements, or they had been burned before about bad software requirements. So baby if you can elaborate,
what is a software requirement? Well, that's an interesting question because it seems like there should be a really simple. Short answer, but there's not and I think the first thing people have to understand when they start talking about requirements on any project is that people have different ideas
of what that word means. And so we immediately have an uphill battle because people, you know, one person says, well let's talk about requirements and different people in that conversation have different ideas of what kind of knowledge, what kind of information that includes. And so I think people have to learn that there are different kinds As of requirements information, we have to put some adjectives in front of the word requirements.
So we have to think about, for example, business requirements and to me that's talking about really, the answering the question of why are we working on this project? What are our objectives that led us to decide that?
This is an important project to start with and then there are user requirements which talk about the things people will be able to do with the product or the solution whatever it is you're building and but then there's other Al's that are the kinds of things that developers need to know about. They need to know about the functional requirements. The basic ways the system is supposed to behave under certain circumstances, and there's also non-functional requirements.
A lot of people don't like that term non-functional because it tells you what something isn't rather than what it is. But when people say non-functional requirements, they're usually thinking of what are more commonly called quality attributes. And these are things like the illah tease, you know, usability portability and so forth.
That describe not what the product does, but how well it does these things, in fact, we've all used products that did just what they were supposed to do, but we hated them because maybe they crash too often, or maybe they were too slow or they took too many steps to get something done. So, those are examples of products that meet their functional requirements, but not our quality expectations. And then we have constraints to worry about an external
interface requirements. So, there's all these kinds of requirements information that we have To deal with. But basically what we're trying to do is with any requirements, conversation is understand a need. And then conceive of ways to describe to construction people like developers what they have to build in a solution to satisfy those needs. So I think what you said speaks true, like they are many different types of requirements.
Probably. Also, some people, they didn't have a chance to have all these comprehensive requirements and that's why I think it requirements, sometimes in any With Team becomes a challenge, right? So the software first of all, why it was being built right? First it must come from requirements but sometimes requirements is Big sometimes requirements just few lines of
statement of objectives, right? And I think that's where the challenge is. And I think I still remember in our previous episode you mentioned that the goal of a requirement is actually to have a clear and effective communication, maybe if you can touch on a little bit about this again, right. Why you think requirements is very, very important for clear. And effective communication. Yeah, that's exactly right. Henry, in fact, requirements are not really about technical things.
Requirements are a communication problem, not a technical problem. And that's I think why it's hard. Because rather than just saying, okay, we understand what the build. Let's go figure out the right language to use in the right code to write and what platform you're run out of all that kind of stuff. It's not like that. It's a matter of human communication and understanding a problem and exploration If you go and ask someone during conversation, what are your requirements or what do you
want? Those are terrible questions to ask because nobody really knows how to answer those questions. And so we need better questions to try to help explore what people have in mind and why they have it in mind. And then, we can use that information to conceive Solutions. Hopefully, multiple possible solutions, so we can evaluate them and choose the most appropriate one, but that's why it's Hard.
And one of the results of that are, one of the consequences is that it has to be done iteratively. Ideally sure we could just go ask somebody, what do you want? They'll tell us will go off and build it and that just simply doesn't work. We know that doesn't work. And so this process of requirements development where our goal is. Exactly, as you said clear and effective communication, it's not following a set of rules. It's not conforming to some standard.
It's effective communication and that has to necessarily be done. In an incremental and iterative fashion. And that's frustrating for people because you go and ask someone for information, you get some and then as the business analyst and no matter what your job title is, if you're doing this kind of work, you're functioning as a business analyst, that's a role not a job title.
So you go think about it and try to understand it and then you realize there's something, you thought you understood during the conversation. But you really don't or you have questions or you realize it's the opposite of what somebody else told you the next day. So you have To go back and revisit things to have to go down layer-by-layer to get more information and resolve conflicts and all that sort of stuff. And so, that's an iterative
process that can be frustrating. For people who might say, well, wait, I already told you that's just go away and call me when you're done and that's just not realistic. So this is why it's a hard problem and I think people just have to acknowledge the reality of the incremental and iterative approach and the fact that it's relying on imperfect human thinking and communication, there's no way. On that, right? Not to mention, you also have to
write it, right? Not just communicating asking people the questions, but you also have to write it. So that the developers or whoever in the downstream is able to understand the requirements itself, and be able to build and test it, right? So, I think, when you mention about asking people what they want, what kind of requirements you want, I thinking some Executives of some leaders who have the ideas, sometimes. I'm not very interested in
detailing the requirements. I don't know whether it's a problem of time or it's something that Even they don't have clear idea just like any great ideas, right? It's just like a spark of an idea but you don't have the lower level details, what would be your advice for people who seem to have this all great ideas but they are not really interested in detailing further into requirements. So that maybe the business analyst job becomes much easier.
Any tips or advice from your experience here. Well yeah, I think it's great. If we could rely on telepathy, just exchanging information, mentally. Or if we could rely on Clairvoyance where someone just Medically. You can see the future and knows what people need and can fill in all the blanks. But the fact is, those are not very good requirements, elicitation techniques, I don't recommend Clairvoyance and
telepathy. Although on some projects that does seem to be the technical Foundation, doesn't work very well. And so I think it's fine to have people who have visions of a product, a solution that's going to hopefully meet some need. And I think it's very helpful if we can first understand what problem this is solving, in fact, someone senior person, or Visionary might come and say hey
build me this. In other words they present you not with a need but with a solution they have in mind and I think it's dangerous to either assume that the presented problem is necessarily correct or that the presented solution is necessarily appropriate. So the question I think of in that situation as well, if that solution was the answer, what was the question? Let's back up a step. So I'm a big fan of doing some root cause analysis to make sure we understand the problem. First.
And then make sure we can address the correct problem. But the fact is, we do have to get down to detail. Somebody has to answer those questions. Somebody has to bridge the gap between, okay, I have an idea for a product down to white color.
Should this text be? You know, in between there there's a whole lot of conversation and thinking that has to take place and frankly I think maybe that's one reason why sometimes people don't want to do that because thinking is hard ideating, is not as hard in some ways. But thinking of all the details, the implications, the connections, the elaboration, that's hard. And it's frankly, not all that much fun, compared to just coming up with a cool idea for a new app, you know.
So I think we do need to get to that point where we understand all those details because developers are going to build one thing. They're just building one thing, and I've heard it said, once that the requirements may be fuzzy, maybe General, may be incomplete, but the product will be very specific It will be one thing. So if we want to make sure we get the right thing, at least eventually, then we're going to need the information to be able
to do that. And this is true of any project of any product of any culture, any development approach, those things are true. And that's something we tried hard to do. With this book is make sure that the 20 practices that we selected, the techniques we describe around each practice really could apply to almost any situation. They're very, very Universal.
But the other thing you got to a little bit earlier Henry that I want to come back to is the idea that we need to write some of this down because not only is telepathy, not very reliable but
neither are human memories. I don't know if you've ever been in a situation where maybe you were in a meeting and some people walked out of the meeting and they later on discovered, they had different Recollections of decisions that were made and what came out of that and what they're supposed to do next whenever we have those kinds of Of differences in our memories,
we've got a problem. So, I think an important thing for people to remember is that the cost of recording knowledge, that is writing it down, or otherwise storing it. The cost of recording knowledge is small compared to the cost of acquiring the knowledge. So I don't frankly have a lot of patience with people who say, well, we don't have time to write this down because they're setting themselves up for
problems in the future. And basically, they're saying, well, we don't have time to write this down, but we'll have time to figure. And out again later. That's not a very good way to think about it. Yeah, we kind of covered this as well in the previous episode right side. I think it's really important for people the cost of recording information is actually small, even though sometimes we may not feel like it or we feel like we have so many things to do, but remember that if we record it?
Well, it actually saves a lot of rework at the end later on. Right? And speaking about just now I was laughing when you said that the requirements could be fuzzy but the Developers We'll build only one product. That is very specific, right? Well, I don't know. Now these days with all this AI capabilities may be the behavior of the product might have more variety with all the generative AI. So I mean, looking forward, maybe one day, even though the requirements is wake, the
product is just one thing. It, I will make it more multiplications in terms of features and capabilities. There's another point. I should make along that line. I mean I know virtually nothing about things like chat GPT and the wave of AI stuff going on. But in 89 a long time ago. I wrote an article called the laws of computing at least as I understood them to be back. Then in law number seven, I think is still worth keeping in mind.
Artificial intelligence is no substitute for the real thing. Yes, I think that's still a valid law, you know. So these are tools but you've probably heard the saying that a fool with a tool is still a fool. Have you ever heard that saying? Yeah, it's a pretty common expression but I changed it slightly. I say a fool with a tool is an amplified fool. And that's worth keeping in mind. Nice, nice. So you mentioned just now about understanding the problem before, converging on a
solution. So this is actually the practice number one part of the requirements foundation. So when you mention sometimes as a software development team, we just given a task with a solution, right? And we have to just deliver it but you invited people to actually stop thinking about what actually the problem is. So maybe from the situation that you encounter before, right?
How can teams react when such situation coming that they are asked to build some kind of just a solution, just build this, right? And how can they actually capture the requirements from that solution better? Well, I think you need to think backwards a little bit. If you're presented with a problem, then I think it's very helpful to do some root cause analysis, and you can build what's called a root cause analysis diagram, sometimes called a fishbone diagram, or an Ishikawa diagram.
This is sort of a tree structure where you think backwards from the presented problem and try to understand the contributing causes like, why is that a problem? And that's the question we're asking with this thought, process is, well, if that's a problem, or if that's a goal that we're trying to achieve, why are we not already achieving that goal or why is that a problem?
And you go through this through a couple of layers of asking why, and hopefully, you'll eventually get to some root causes that are contributing to the perceived problem and those become actionable and we can Growl, how do we address those specific root causes? Or you might find to that thought process that what appears to be? The problem isn't really the real problem. Maybe that's just a symptom of the real problem, or maybe it's a tangential problem or just part of the real problem.
And you do the same kind of thinking if you're presented with the solution and someone says go build this product or this feature, and that's where we start asking ourselves. The question of why, if that's the solution, did you have in mind? What problem do you think that's going? Going to solve, what do you think is going to do for us? And why do we think that needs to be in there? And that's not really challenging. We're not trying to challenge
people or say you're wrong. When we do that, what we're trying to do is understand, we're trying to reach an understanding that we all agree on and can align towards a common shared. Understanding of the problem a common shared vision of the solution with confidence, that that's the right solution for the right problem. So just a Of doing that backward.
Thinking a little bit I think is the right way to make sure that we're not wasting our time or chasing something that turns out not to give us a good outcome and a phrase that I've heard along the line as we were working on the book that I liked. If you don't go through this thought, process first, you might end up achieving project success. Hey, we built our solution.
We delivered it on time and on budget and it looks great, but product failure, because that solution isn't actually solving the problem that you were hoping it. Wood or exploiting the opportunity that you perceived. So we want to try to watch out for project success but product failure. Oh yeah, I think that's really really important. Right because many Enterprise projects, right? Even though they still stay true to the timeline, they say, through the budget scope and
things like that. So they may not bring the kind of business impact of business value once the product is launched, right? So I think understanding the problem instead of just converging to a solution is really important, right? And I think in your book you also give an example of a set Solution that was given but I mean in a hypothetical scenario, right? Actually the team who has the understanding about the product is able to actually advise what kind of road maps are many
Milestones that we can achieve. Don't forget about that. So whenever you give an idea, maybe other people also have a better ideas, especially if the people are working with the product much, much closer than you are right. I'm sorry. If I could just add to that, just a little bit Henry. This is an example of where people have different ideas of what the word requirements, me.
Ins. And, you know, this conversation that we're talking about this exploration of why some people may not even view that as requirements. But that's really addressing the business, requirements that set the stage for everything else that we do, when we build a solution based on technical requirements, right? So, let's move on to other practices. As you mentioned, there are 20 practices, but we won't be covering all of them for sure, but I will just pick some from
my interest. So the other thing that you mentioned about the requirements fundamentals is that we need to Define Solutions. Is in particular, what's in scope and what is out of scope? So can you tell us maybe why it is important especially to mention the out of scope part? Yeah, every project, every product is finite, you know.
It has some things that does, it has some things that won't do and part of understanding our business requirements, and our business objectives is to draw that boundary between what's in and what's out. And I saw that very nicely done at a company once who was building a website and not only did they they have a list of the things that the website was going to let people do but they also had a list of things that it explicitly was not going to let people do that.
Someone otherwise might think it would and that's very helpful for people saying, oh okay well we've decided it's not going to provide this particular service. You might do that in the future, that's fine. But for whatever release you're talking about, we're not going to do that and that helps you avoid the dreaded Specter of scope creep, where people keep adding in this and that and she wouldn't it be nice if we did this. And how about that? And there's this new kind of credit card.
We have to be able to take those now to well at some point you have to draw the line or you never finish anything. And so I think understanding the boundaries between systems is helpful for release planning for scope management. And also it's very helpful to see where our system. Our solution that we're describing fits into our universe and there's some pictures you can draw to help
you visualize these things. When we talk about requirement to sort of naturally, think about natural language text text. And that's a big part of it, but we also can draw all kinds of pictures visual analysis models to represent information that are really valuable. For example, a simple context diagram, which is not a New Concept. It's been around for decades, a simple circle with some boxes on the outside and arrows, connecting the boxes to the circle.
That helps you see what's inside our solution inside that Circle. And what does it connect to on the outside? Those could be users, they could be other systems could be. Pieces of Hardware. That's very valuable information
to draw that boundary. Another thing you can do is you can create an ecosystem map and this is valuable if you have a system that fits into an existing world, as most do rather than being completely Standalone and perhaps the solution that you're building, now requires interfaces to some of the other systems that you already have in your universe and maybe those are not just immediate connections, but they could be two or three levels removed.
So there's some Pass throughs and Communications and interfaces that get involved and by drawing an ecosystem map, you can more easily see how all of these things, all these pieces of systems in your world fit together in a web and what the interfaces between them look like at a high level and that helps you see dependencies, it helps. You see where we're going to have to build some glue to connect these systems so they can communicate.
Maybe you're using some third-party applications for security checks or for payment handling or something like that so you can see how those things. Together but we got to draw those boundaries because otherwise you don't know how to tell when you're done and speaking about scope. Creep, just now you mentioned, right? So I think by specifying clearly what is not in scope, be kind of like covered, okay? This is the things that we
decided early on that. We will not be building, or we will not be including so that later on in the future. You cannot have a room for some maybe Tiki product leaders or Executives to request something, right? Request to add more stuff even though maybe that request. Sounds so simple but sometimes it's not that simple whenever you try to build a system from scratch, for example. So I think having the out of scope is really, really
important. So for software teams out there, if you haven't done this practice, please make sure that you Define explicitly from the beginning. What will be in scope and what will be out of scope? This is practice number three and it's helpful to also know what might be coming in the future. So maybe some proposed feature is going to be out of scope for
now. We see that as a growth Direction. So we might add in the future, and by being aware of that, you can at least build in Hooks and, you know, the interfaces so that it would be easy to plug in something later on to grow in that direction, but not today. Yep, thanks for adding debt. So let's move on to the next practice. This part is actually about requirements elicitation but before we move on to the practice, maybe for some people who are not yet familiar with
this term elicitation, right? Can you maybe explain any lie? Everett, how does it compare elicitation forces Gathering requirements, which maybe some of us are more used to? That's a good question. Henry, people do often talk about Gathering requirements but when I hear that term, I have a mental image of walking around with a basket picking flowers. They're out there. You just pick out the ones you like and you put them in the basket or hunting Easter eggs or
something like that. In other words, Gathering requirements to me, sort of suggest a collection process. And that's definitely A part of it. You know, sometimes we do know of things that we're going to have to build or have ideas. We can just put into the basket, but the be a, the business analyst isn't just a scribe, who just writes down, whatever people tell them they want.
Instead the business analyst is a guide who's leading this exploration of a requirement space and so elicitation is partly collection partly, Discovery partly invention and the ba is the guide for those processes. Has so elicitation involves asking questions, for example, to see if people would find particular ideas or capability useful. So someone says well we want this, okay. Well, would it be helpful to be a might ask? Would anybody ever want to do
that? Which is maybe an extension of this. And they say, hmm, I haven't thought about that. Well no, I don't think anybody would want to do that or they might say oh wow, that's great. I'm sure glad you thought of that because we didn't solicitation is a rich. Process, it's more collaborative. Not just a matter of collection, so I try to avoid seeing requirements Gathering. Yes, I think that's the situation out there. We can just gather requirements, right?
I mean week, no, clearly 100% what we want to build, and we just write it down, right? So, I think that ever, I think, at least in my experience that never happens. So, there's always some room of ambiguity, some room of ideas, as well from different people. So I think requirements elicitation is probably the proper term that you will suggest here. So, Go to one of the practice with its practice number 6. Understand what users need to do
with the solution, right? So just now we talked about understanding the problem not converging to the solution but in this requirements, elicitation you also suggest people to actually understand the need of the users with the solution. Maybe tell us more about this one. That's one of my favorite topics. Understand what users need to do with the solution practice number 6, but in terms of importance, I think it could be considered practically practice
number one. In fact, one of the most important things I learned in my career as a software developer is to focus. Not on features, not on the product itself at least at this stage of requirements exploration. But rather focus on usage. What do people need to do with the product? And that's a much better approach to exploring requirements usage Centric exploration as opposed to product or feature Centric because by understanding what
people need to do with. The solution or certain parts of it. We can then put on our business analyst hat and we can derive the necessary functionality that has to be implemented to let people do that. We can also prioritize at that higher level of abstraction that says, oh, okay. Doing this task, is more common, or more important than doing that task.
So what are all the bits of functionality associated with those two, various tasks that helps us prioritize a little bit higher level of abstraction, instead of trying to take 500 requirements and their stories and Gravel, which one is most important? We can deal with complexity through abstraction that way through some hierarchy. And that's a very good example. Also, of how to change that
question. Remember, I suggested earlier that bad questions to ask around requirements are, what do you want or what are your requirements? A better question is, what do you need to do? What do you want the solution to do for you? Let's not ask what the solution should have in it. Let's ask what you need to do with the solution, so that's where things like use cases and user stories can become
valuable. Abel and that fits at the level of what I consider to be user requirements, the II be a, The International Institute for business analysis. Talks about stakeholder requirements as being kind of between business requirements and solution requirements. I don't really like that term because basically as I see it all requirements come from some stakeholder. So I'm specifically talking about user requirements, the things that various kinds of users need to do with the
solution. And that to me is a really valuable way to both, make sure that we include all the functionality. People need to do those things. And have you ever worked on a project or seen a project where people built functionality that someone said they needed but no one ever used it. You're seeing that happen? Yes. I think it happened in some parts of Valium of my career as well. So we have to build a lot of features but I'm particularly not sure like how many users actually use that.
Yeah, that's very common. In fact, there's data people have tried to study in the software industry. Of what percentage of the features. However you define that in common products never get used or rarely get used and it's over 50% in some of these analyses. Well you've worked very hard building, those features that
nobody used. So I think it's important to make sure we can focus our attention and our priorities on the things that we know people are going to use and that's why understanding usage patterns is a really important starting point for elicitation. Yeah. So in part up, what some people If I thought this is knowing the jobs to be done for the users, that want to use the product,
right? And I think also another important point, which you mention in the book is that sometimes we can demo this features, the cool features that we just built to the users and they will be wild and they seem to like it. But at the end of the day in the real world, they may not use it because that solution that features maybe not solving the actual need, right? So they don't have a use case in the particular situation that they would require the solution from the feature.
So I think that's really important. Is it snowing the users need instead of just building features and solutions over Solutions. So let's maybe touch on a little bit about the HR world since you mentioned it earlier, right? I think in the agile World, sometimes the practice of requirements is perceived to be different, right? So people call it user stories writing in a card or Post-its and things like that, where the requirement seems to be just a one liner.
So user, I want this so that blur, right? So maybe if you can touch on a little bit and advice for the This people outside their what is the better way of writing software requirements for the ages of eight teams? Well, the first problem I have when this kind of question comes up is what difference does it make?
Because the developers need the same information to build the right software correctly regardless of how they're building it, they still need that same knowledge and so I find the idea that requirements are all different on agile, projects, kind of silly, frankly. Now certainly there are differences between agile and traditional projects in how they slice and dice these practices and you may do things in smaller increments, you may not write
down as much which works fine. If you have a short timelines and things aren't changing very rapidly. And people are working close together day to day. That's fine. But it doesn't change the nature of the information that people need to do the job.
So I think whether you call them user stories or epochs that's a Mystique, that's not substantive my I think the idea of how you phrase user stories is valuable by saying, as a particular type of user, I need a certain capability because of some justification. Some rationale that's helpful to put it into a context, that's more valuable and more understandable. So people can see the whole picture a little bit better, but I think really quickly a column user stories or not is not important.
One concern I do have Is that it can do user stories well or like anything else, you can do them badly. And if the user story becomes the only Quantum of requirements, then, really, we're trying to take all those different kinds of requirements knowledge that we talked about at the beginning of our conversation and turn them into user stories. And some of those stories might
be bits of functionality. Some could be full feature descriptions, some could be non-functional requirements, like security requirements, say our Real issues, some could be business rules, some could be data definitions. Well, those are all different kinds of information. And if the only container you create to store requirements, knowledge is this thing called a user Story. How do you tell those apart? How do you connect them?
How do you see that? Oh, here's some pieces of data, which really tied together, multiple functional user stories or here are some business rules that apply to certain user stories but not others or here are some performance requirements. That affect certain user stories but not others. So, I think the taking any idea, you have about something called a requirement and forcing it into a user story, construct, can be less than helpful at
times. Yeah, so I think some people have always dismissing them are right. So whenever they find, for example, the agile Manifesto, it is set that value collaboration more rather than writing comprehensive documentation. So, that's the first thing. And people also seems to refer to user story as the only way of Specifying requirements because we want to be a job. But I think what I find challenging in my day-to-day experience is that sometimes these are not enough, right?
Just one liner of sa Persona, what kind of things they want to do, or kind of business value. It brings is not sufficient for developers to actually write the software, right? We need better specifications, we need better, business rules, validations and things like that. So I think sometimes this misnomer I think is something that is frustrating. And what would you advise people
to do? Then I mean if You have a user story, do you also capture some business requirements somewhere in the different templates so that you can actually correlate between multiple user stories and a business requirement. So maybe if you can give some practical tips here for people to probably improve their software development process. Yeah, I think that's a good idea.
In fact, the business requirements aspect, which includes multiple kinds of information, the idea of business requirements and you can see a template for a vision and scope document from My book and both the software requirements Essentials and the software requirements, book contain a template for a vision of scope document and that's just a container for business requirements. So while I call these things documents, they can take many
different forms. They're just containers for knowledge, but those kinds of things really don't have anything to do with how you're going to build the product, what development lifecycle you're following, what are your business objectives? How are we going to measure whether we've achieved our business objectives? What Our constraints that we have to work within what's our vision of the product whether the limitations that we're going to have as exclusions. Like we talked about earlier
that aren't going to be there. These kinds of things really don't have anything to do with how you build the product. So I think they, they lay a solid foundation for any kind of project that you might be working on. We need some way to tie together the different pieces of information that are related. Now if you have a whole bunch of user stories and Logically flat as opposed to hierarchically grouped in some fashion. That's harder to manage.
I think if you have a big project and you have 500 user stories and no, really good way to group them. Then how do you manage that becomes a harder problem than if you can group them into features and see the relationships there and prioritize at that level and so forth. So I think it's important to identify for every project really what's the best way for us to document at an appropriate? Fiat level of detail at an appropriate time to record the information.
That's essential to see how it fits in with all the other information. We have to see the things that span sets of use cases or of user stories and so forth. Every project should decide how to do that. And the point is not to be agile. People sometimes get confused about that. Who the hell cares? If you're agile, but they care is, if you're effective, that's much more important. So, I think the idea that, well, we can't do that because it's not part of scrum, that's just silly.
You're not trying to be scrum, you're trying to Be an Effective software development team. So let's keep that goal in mind. And then, let's choose those practices. Those kinds of containers, those levels of detail those role assignments, all that, let's choose the approaches that are going to help us be as effective as we can be to build the right Solutions. And if that means that you, violate some agile rule, I can tell you. The agile police are not going to come after you.
That that's not a threat. Yeah, that's a funny joke that In Italy, but I think that brings really true, right? So the point here is to Be an Effective and productive software development teams and also, you minimize a lot of rework as well, right? Especially if you didn't specify the requirements clearly and the developers build something. But turns out, oh actually, this is not what I want. So the developers come back, fix it and the cycle goes on and on.
So I think you mentioned about templates as well, so don't forget for people who want to read the book also put a lot of links to the websites of the book where you can find a lot of templates. So these templates As in relate to any software development methodology that you use, you can use it in any kind of projects so make sure to check
it out as well. You've mentioned, I think twice now Henry a very, very important word that I'd like to talk about for just a minute and that word is rework, you know, everybody wants to be more productive. My first question then is okay, well, why are you not already as productive as you want to be? What's the problem and very often? The problem is that teams end up spending more time than they expect. Doing unplanned rework doing over something that they thought was already done.
And software teams that measure how much of their total effort is spent on rework. Can get very scary numbers Thirty or forty percent of your total time. Might be spent doing things over now.
Some of that's just the nature of what we do, okay, it is an imperfect process things change people, learn more that's fine so we have to expect some of that but you raised the point a couple of times and I'm very glad you did because I think people should be actively choosing approaches and techniques to try to. Avoid the unnecessary rework of having gone this way when you should have gone.
The other way, a lot of the effort we invest in requirements is not to pretend that we can get it. All right. The first time and write it down once and then just go build the product. It's to lower the risk of having to do things over later on when we planned to do something else instead. So a lot of how much you choose to do around requirements, really boils down to controlling the risk of wasting time on unnecessary. Riri work. So I just wanted to pursue that thought a little bit.
Thank you. Yeah, thanks for emphasizing that. So I think for software development teams who haven't really measured the amount of rework that you have to do, I think maybe you can do that exercise and maybe you'll be surprised by the percentage just like what comments and it could be 30 40 percent or even 50%. So in your book you break down the practices into multiple areas like requirements elicitation analysis, specification, validation and management.
We won't be covering all of them. That's maybe fast-forward to the last part. Quadrants management, which I find. Maybe it's also important to cover here in our conversation. The practice number 19 is actually talking about establishing and managing requirements based lines. So first of all, what is Baseline? And the second thing is why it is important to establish a baseline, very good question, and that's one of those things that could maybe turn off agile people's like, oh, Baseline.
Well, that sounds like old talk to me. We don't do that stuff around here. Well, of course you do a baseline, is really just an agreement. It says that for somebody of work, whether that's a single, it development, iteration or a release or an entire project and product, we're reaching an agreement, among the key stakeholders about what's going to be in that delivered piece of software. And that's all a bass line is, it's a reference point.
And as we're going along through our requirements planning and our project planning. Again, regardless of whether you're doing agile or traditional or some hybrid approach, we're iterating on that until we decide, okay? This is what we are settling. Mine is being stuff that will fit in the size of the box that we have for this upcoming work, we're making agreements. We're making commitments at that
point to other people. So they know what to expect whether that's 41 percent of the final product or a hundred percent of the final product. So you do that kind of thing. Basically on an agile project you do it iteration by iteration by saying okay these are the stories that we are planning to implement in this iteration. That's a baseline. It's not more complicated than that. And that's your reference point for Or change, I mean, change happens. We have to adapt to change and
that's actually practice. Number 20 is to manage changes to requirements, effectively affects every project again. And so, what we're doing is we're saying when a change comes along, how does that affect our current and future plans, does it go into a current Baseline that's under development? Well, that means, either, it's going to take longer to finish that implementation or something has to go.
Something has to wait. There's no right answer, but we have to make those decisions and so a baseline because the reference point for Making those changes, it becomes a reference point for tracking our status toward achieving our objectives for that development cycle. And I think reaching that clear agreement is a lot more valuable than saying, well, here go do some stuff and call me when you're done and I'll let you know if you're really done. That doesn't work so well.
So that's all we're talking about when we say defined baselines and their different ways you can do that depending on what lifecycle you're following. But I think it's important for every project to do that you know, thoughtful way. Right? So Baseline is nothing but like an agreement, right? A set of a commitment that the team is delivering, it could be but iteration it could be per really cycle or it could be anything. But the key thing here is that you need to set a baseline right?
Because otherwise, you can't keep building things dynamically day by day. So you need a reference point and speaking about coming to the Baseline. You also need to prioritize the requirements, right? So maybe if we can touch on a little bit, how do we actually prioritize requirements that we have, which could be a lot and committed to a certain of Baseline. So how can we prioritize, better?
Maybe that's the question. Well, they're certainly a lot of Articles written about different ways to prioritize requirements. Different techniques there are valuable for it and we have a practice on that. Practice 13, says, prioritize the requirements and I think teams should prioritize things in the simple away as they can, if we can have a conversation and a handshake to agree on what we do first. And what we do later, that's great.
Sometimes you have to take a more analytical approach, you have to maybe get out of spreadsheet and use various Spreadsheet tools. Some of which I've developed myself. That help you think through the process of deciding which ones are more important than work urgent to do, there are a bunch of questions that you can think through and I think every team should decide well.
How do we make those decisions? What factors are important to us when we try to make priority decisions and you might consider things like the customer or business value, it would deliver how would contribute to the project or the development of relations goals, who requested that A particular feature compared to some other feature. How often is each one likely to be used and what's the cost or time or technical difficulties
associated with implementing it? So there are a lot of factors that's just a handful of them that you might want to consider. So I would say first of all, each team should think about, what's its decision-making. Thought process about priorities who even makes those decisions. Let's figure out who's going to have the authority and the responsibility for making those decisions. There are a lot of ways people
have decided to do this. There's planning poker and there's Things like okay, here's 100 imaginary dollars. How do you allocate those? Do you try to rank order them? Which is fine if you have 15 items? Not so fine if you have 300. So there's a lot of techniques. I wouldn't say there's any one particular technique that's always fits in every situation but the most important thing is for people to consider early on who makes the decisions, how do
we make those decisions? What do we think through? What do we consider when we're going to do that? Because that drives the sequence in which you build the work that you have from your backlog of A pending possibilities and also helps you make decisions when we're considering changes. Okay. Something comes along new feature. Well, how important is that compared to these other things? We plan to do the next development cycle? Does one of those wait, because
this is more important. Those are all part of the thought, process, very important part and that's something I'm glad the agile teams have emphasized more but still every project team has to go through those same considerations. So what I hear you say? Just now you said that importance of knowing the key factors, right? So the team Need to be able to put down the trade-offs. What are the levers that you want to think about? So that the teams can make decisions uniformly, right?
It's not like one day, you use this kind of a trade off. The next day is the different. The next day is, May be the highest person said something. Then you have to follow. So you have to probably Define the key factors that you want to include in the privatization so that we can use it over and over again. So speaking about managing changes, this is the last practice that you have practice. Number 20 this is a real world, right?
So things happen Open software requirements, change, sometimes in the middle of the iteration. That means also changing your Baseline, right? So how we can manage changes to requirements, effectively, I think for people who probably most likely are going to encounter this over and over again in their software development career, well, the first thing every team needs to do is to adopt I think very
early on a change process. And again, that's something where some people might say, hey, well, you know, we don't have a process, we just got to get stuff done. Well, the process is just How you get stuff done, that's all it is. It doesn't have to be fancy but it has to be effective. So we have an example in the book of a flowchart, a process flow from an agile project.
That shows the participants processing a change request and making decisions of what's its impact going to be for, you know, we need some information to be able to handle a change. You need to know what's being requested. You need to do a little impact analysis. You understand what? It's likely to cost and how it's going to affect other pending or Added work or other systems. When would that change be worked into the development activities?
Who makes the decisions. Again, that's a very important part of it. Is who makes the decisions. And how did they make? Those decisions. We actually address that very important issue in the number five, which is to identify the empowered. Stakeholders are decision makers. Rather identify the empowered decision makers. So, having a process then, makes it more systematic and Less ad hoc, we need to know who Seems the change request and how it gets processed that. Can be very simple.
One person might do the whole thing that's fine. But if you're building a Boeing aircraft or something like that, there's probably going to be more than one person involved with making a decision about something to change. So, everything in between a tiny little app, You're Building yourself and building a huge complex systems project. So, adopt a process. And, you know, it's interesting because I've worked for Kodak for many years.
Before I started my own software consulting company process impact, And my last job at Kodak, I spent six months in the development group for Kodak.com their website and that was before the web taken over everything in the late 90s and it was a very fast, moving very agile, kind of environment. And I came in for six months to lead some process Improvement
activities for this group. And one thing that we put into place that was extremely helpful, was in fact, a defined change process which really helped them bring order out of the chaos so that they knew what to Gone when and why and the people in the group had the exact correct attitude. They viewed this process not as a straitjacket but is a structure. So people shouldn't be afraid of
process. A good process helps, you get things done, more effectively, more, consistently more reproducibly, but if the process doesn't work, people will find a way to get around the process and they probably should. So that's a clue that. Hey, maybe your change process. Need some tune up, right? So regardless, whether you are an angel practitioners or motor, Additional practitioners change process. I think is really crucial,
right? Especially as we all know in any software project or software product, you will have changes. You will have some kind of a new ideas, new feature changes, right? Or nubuck somehow critical happening in your product, then the team will need to handle it as soon as possible. So, having the change process,
the prioritization technique. All these will also play a part in to building a more effective software development team so called, I feel that we will not be able to stop talking right about Requirements, because there's so many great things that we can cover it. But unfortunately, we have to wrap up pretty soon because of the time.
But if you still remember last time, I have one last question at the end of our conversation which is called the three technical leadership, wisdom, I will ask you the same question this time. So hopefully you will find a new ones based on this new book, or maybe if you can refer to the previous ones, that's also fine. So maybe if you can share your three technical leadership wisdom for this episode. Okay. I think that's a very good
question. And the first thing, I would suggest that as you listen to this podcast, as you read the software requirements, Essentials book or other books. If you watch the videos that were putting out, I just recently actually, just today started, a series called the one minute analyst, or I'm posting on my YouTube channel, some very quick videos on these topics. Don't feel bad if you don't already do all these things on your project, okay?
That's the first piece of wisdom is, maybe you look at all these things. Should be doing and see sounds like a good idea and you say oh we're not doing that, you know, we're we're failing. No, don't feel bad. If you don't already perform all those practices on your project that's fine. That's where everybody starts. The second one, then would be as you go through this information, try to identify those practices that you think would add the
most value to your project. Look for opportunities to try them and situations whereas some of these practices are techniques might yield better results for you might solve points of pain. That you're currently experiencing or might keep you out of trouble later in the project by reducing risk as we mentioned earlier. So that's the second point is look, actively for practices that you think would be worth trying. And finally, don't try to do everything at once.
People can only absorb change organizations can only absorb change at a certain rate and remember that there's a learning curve that's going to slow you down a bit. As you try to figure out how to make some new method, work for you and for your team. But over time These new ways of working based on these practices that you feel confident or worth trying out. Those will just become part of your business analyst toolkit and I'm pretty confident.
You're going to get better results once that's happened. So, those are my three pieces of advice, maybe wisdom, but at least advice, thanks, for sharing that. I still remember the last wisdom that you mentioned, right? Don't do things at once. It's like your ultimate Pearl from your previous book, right? So we covered that also in the previous episode, thanks for sharing this. So we all want to be better, right?
Especially knowing all this information from this podcast or from YouTube videos books and things like that. But don't feel bad if we haven't actually done any of these. So we can always start something small. Do the things that bring us most value or solving the biggest problem for us, right? So thanks for reminding that so of call for people who want to learn more about the book or
maybe resources from the book. Is there a place where they can find you online or the book resources online? Definitely, I have two websites. My personal website is Carl uyghurs.com, and that's i before, e, except after C or with the uyghurs. My Business website is processed impact.com because my company is called process impact and we have a website. Very simple website for the book. The book is software requirements, Essentials, and the URL is software, Rex, that's
software, reqs.com. And so people, there can see these videos. Those they can read a sample of the book, they can see the list of 20 practices. We've talked about several of them here today, but there's a lot more there and there's also a bunch of checklists and document templates spreadsheet, tools and other work AIDs that we've made available there. So, there's a lot of useful stuff at software x.com, right? And I would suggest people to also read the book, right? It's a very thin.
It's not thick. Like a to the software requirements book. And I find any kind of role in software development team would benefit by reading this book because Then you will understand the essentials of software requirements, which most likely is one of the biggest factor of building the successful product. So, thanks for sharing this, and thanks for writing this book. So, Cal, really a pleasure to have a chance to talk to you again.
And hopefully, the book is becoming successful to transform people to write better software requirements. Well, thanks Henry has been a pleasure to have another stimulating conversation with you and if we can send people away with one final message that I've believed for a long time because I've been interested in It's for a long time. Is that if you don't get the requirements, right? It really doesn't matter how well you execute the rest of the
project, you will fail. Well, really well said. Thank you for listening to this episode and for staying, right until the end if you highly enjoyed it. I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot. In order to grow this podcast better.
You can also find the full show notes of this conversation on the episode page, at Tech Legion o.f website, including the full transcript enter, Resting quartz and links to the resources mention from the conversation. And lastly, make sure to subscribe to the shows mailing list on package. You know, dot f to get notified for any future episodes. Stay tuned for the next technology. No episode. And until then goodbye.