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.