What makes a good requirement?
That’s something that is completely open to interpretation. In my humble opinion, a good requirement is one that is clear and direct. It communicates what it is supposed to and then moves on.
No muss, no fuss.
There are many out there that will disagree with me on this. That’s OK – it’s all open to interpretation and what you’ve seen work before, or have tried, have succeeded with, have failed at, etc…
See to me, in the scenarios where development is not run by product (which should be every scenario if you want to do things right) you need to have a good partnership there. If that doesn’t exist, things will go down the tubes pretty quickly. That being said, you don’t have to love each other and hold hands – but something has to be shipped.
Now, to boil this down pretty quickly, I really see there being only two types of requirements:
1. Agile requirements; and
2. Waterfall requirements
These are really polar opposites of one another. You can’t get much different, aside from the fact that you are communicating the same problem you want solved within each – they are both just different ways to communicate them.
The thing I have come to realize is that for agile to work – for it to really work – you need everyone behind it and you need pretty smart developers who are on the ball. The main reason for this is that you want great code to be written, but the time you are saving by not writing long (and I mean looong) requirements documents produces ambiguity, and that must be filled in by the developer as they go.
They must ask questions. They must talk to you (the product wonk). And above all, you must trust each other.
Some developers have serious issues working this way – I get it. I understand it’s not easy. It puts a lot of onus on those that are writing the code, as opposed to the waterfall way….
Now in waterfall, at least in my experience, you are pushing away communication in favor of documentation. Developers want every single piece of a feature mocked-up, written down, and worked out before they even start thinking about the code. I always picture this style of process as taking things and lobbing them over walls. Requirements over a wall to dev, code over a wall to QA, QA over a wall to production, etc, etc…
Especially if your team is small, working this way is not leveraging one of the team’s crucial strengths – it’s size.
A lot of companies work in waterfall, and it does have its place. Specifically in organizations that demand a heavy process workflow through a release – or something that has a ton of formal check points. Two examples here (respectively) could be a bank and a consultancy
If you are going gangbusters trying to get products out the door, the last thing you need are formal check points. The last thing you need are 50-100+ page requirements documents. But that is what happens. This gums up the works for several key reasons.
The main one is, people stop talking. They stop asking questions. They just assume they can blindly follow the documentation – and if it doesn’t turn out right, oh well – wasn’t documented that way, so it’s becomes a bug. People way smarter than me came up with the agile manifesto for a reason. It can and does work.
People are smarter than this and everyone should expect them to be.
Of course developers need things to go on. You can’t expect them to read your mind and they can’t design anything (in most cases). But they are smart. After all, they are computer programmers.
The bottom line is this – no one can tell the future. As features get implemented, they change. Sure you know a lot of things up-front (button goes here, text goes there, save this, etc…) but you are 100% bound to miss things. If your product release process doesn’t account for things being missed down stream, it’s wrong.
Remember one of the key tenets of agile – put things off as long as possible until the last possible moment you can decide to ensure you have the best set of information at hand to make that decision.
Those things don’t happen in closed-door offices with a product manager huddled over his keyboard typing out requirements and acceptance criteria fast and furious. They happen in talking to those coding out those ideas and breathing life in to them.
But, not all teams are cut out for that sort of challenge. And that’s OK too – just make sure your management team knows you are going to need a solid chunk of time (1 1/2-2 months) per release cycle. And make sure you have some spare toner and paper ready for your printer. You’re going to be doing a lot of editing on those requirements docs.
{ 26 comments… read them below or add one }
Agile and waterfall requirements are exactly alike. What Agile and the waterfall do is package different sized collections of requirements. In Featuer-Driven Design, an Agile methodlogy, you create minimal-marketable functionality, all the requirements for one feature that works enough to show a customer, and you develop that in one or two iteractions. In the waterfall, you would specify all the requirements for all the features.
Consider the need for feedback being the purpose of iteractions, and cash flow being reason for releases, you get more feedback, and more releases with fewer requirements even if you waterfall just one requirement if you don't work in an agile shop. You also reduce your risk with smaller requirements package.
So what is a requirement, a decision to develop something, a what, a functional requirement. That one functional requirement will spawn several non-functional requirements, decisions as to how well the what should work before it is released to the customer. They are decisions. They look like modal sentences.
Requirements are value packages. With smaller sets of requirements you can maximize the value delivered to the customer. You can also reduce the training effort required to use the delivered functionality. A series of small releases will get your customer up to speed quicker than a waterfall of all that funcitonality at the end.
Agile and waterfall requirements are exactly alike. What Agile and the waterfall do is package different sized collections of requirements. In Featuer-Driven Design, an Agile methodlogy, you create minimal-marketable functionality, all the requirements for one feature that works enough to show a customer, and you develop that in one or two iteractions. In the waterfall, you would specify all the requirements for all the features.
Consider the need for feedback being the purpose of iteractions, and cash flow being reason for releases, you get more feedback, and more releases with fewer requirements even if you waterfall just one requirement if you don't work in an agile shop. You also reduce your risk with smaller requirements package.
So what is a requirement, a decision to develop something, a what, a functional requirement. That one functional requirement will spawn several non-functional requirements, decisions as to how well the what should work before it is released to the customer. They are decisions. They look like modal sentences.
Requirements are value packages. With smaller sets of requirements you can maximize the value delivered to the customer. You can also reduce the training effort required to use the delivered functionality. A series of small releases will get your customer up to speed quicker than a waterfall of all that funcitonality at the end.
Agile and waterfall requirements are exactly alike. What Agile and the waterfall do is package different sized collections of requirements. In Featuer-Driven Design, an Agile methodlogy, you create minimal-marketable functionality, all the requirements for one feature that works enough to show a customer, and you develop that in one or two iteractions. In the waterfall, you would specify all the requirements for all the features.
Consider the need for feedback being the purpose of iteractions, and cash flow being reason for releases, you get more feedback, and more releases with fewer requirements even if you waterfall just one requirement if you don't work in an agile shop. You also reduce your risk with smaller requirements package.
So what is a requirement, a decision to develop something, a what, a functional requirement. That one functional requirement will spawn several non-functional requirements, decisions as to how well the what should work before it is released to the customer. They are decisions. They look like modal sentences.
Requirements are value packages. With smaller sets of requirements you can maximize the value delivered to the customer. You can also reduce the training effort required to use the delivered functionality. A series of small releases will get your customer up to speed quicker than a waterfall of all that funcitonality at the end.
David -
I completely agree. I've always thought of features being a collection
of requirements. It just happens that agile “features” are usually 1:1
- 1 requirement, 1 feature. Whereas waterfall are typicall
many-to-one, as you point out in your comment.
The difference lies in how they are packaged and presented and worked
on, but not essentially what they are – that always remains the same.
Thanks for the thoughts and turning the perspective around.
David -
I completely agree. I've always thought of features being a collection
of requirements. It just happens that agile “features” are usually 1:1
- 1 requirement, 1 feature. Whereas waterfall are typicall
many-to-one, as you point out in your comment.
The difference lies in how they are packaged and presented and worked
on, but not essentially what they are – that always remains the same.
Thanks for the thoughts and turning the perspective around.
David -
I completely agree. I've always thought of features being a collection
of requirements. It just happens that agile “features” are usually 1:1
- 1 requirement, 1 feature. Whereas waterfall are typicall
many-to-one, as you point out in your comment.
The difference lies in how they are packaged and presented and worked
on, but not essentially what they are – that always remains the same.
Thanks for the thoughts and turning the perspective around.
I agree that Agile user stories, scenarios, requirements are equivalent to waterfall requirements. Fortunately FeaturePlan is aligned with that.
However, I am not sure I agree that Agile features are 1:1 with Agile requirements but I would recommend that is a goal. Too often people starting writing requirements and it is either one line that breaks all requirement writing rules or becomes one big paragraph that breaks rules in the other direction. This is why I am such a big fan of Mike Cohn's user story template. Short, specific and well written. http://blog.mountaingoatsoftware.com/?p=24
I agree that Agile user stories, scenarios, requirements are equivalent to waterfall requirements. Fortunately FeaturePlan is aligned with that.
However, I am not sure I agree that Agile features are 1:1 with Agile requirements but I would recommend that is a goal. Too often people starting writing requirements and it is either one line that breaks all requirement writing rules or becomes one big paragraph that breaks rules in the other direction. This is why I am such a big fan of Mike Cohn's user story template. Short, specific and well written. http://blog.mountaingoatsoftware.com/?p=24
I agree that Agile user stories, scenarios, requirements are equivalent to waterfall requirements. Fortunately FeaturePlan is aligned with that.
However, I am not sure I agree that Agile features are 1:1 with Agile requirements but I would recommend that is a goal. Too often people starting writing requirements and it is either one line that breaks all requirement writing rules or becomes one big paragraph that breaks rules in the other direction. This is why I am such a big fan of Mike Cohn's user story template. Short, specific and well written. http://blog.mountaingoatsoftware.com/?p=24
I love that user story template – it's the one I use frequently. Sorry if
the the post was un-clear, but I always think about a feature as a
collection of requirements; not necessarily 1:1. With agile, you can get in
to much trouble that way for the exact reasons you mention.
I love that user story template – it's the one I use frequently. Sorry if
the the post was un-clear, but I always think about a feature as a
collection of requirements; not necessarily 1:1. With agile, you can get in
to much trouble that way for the exact reasons you mention.
I love that user story template – it's the one I use frequently. Sorry if
the the post was un-clear, but I always think about a feature as a
collection of requirements; not necessarily 1:1. With agile, you can get in
to much trouble that way for the exact reasons you mention.
There is a Dutch company called Synergio and they have published a very practical guide on writing good requirements. The essence is that you make a clear disctinction between writing the business need and the potential IT solution.
You can preview the book, which is written in English at: http://www.synergio.eu/?menuid=259
I am interested in your comments
There is a Dutch company called Synergio and they have published a very practical guide on writing good requirements. The essence is that you make a clear disctinction between writing the business need and the potential IT solution.
You can preview the book, which is written in English at: http://www.synergio.eu/?menuid=259
I am interested in your comments
There is a Dutch company called Synergio and they have published a very practical guide on writing good requirements. The essence is that you make a clear disctinction between writing the business need and the potential IT solution.
You can preview the book, which is written in English at: http://www.synergio.eu/?menuid=259
I am interested in your comments
Thx for passing the link along, Edwin. I will download the guide and have a
read as soon as I can.
Thx for passing the link along, Edwin. I will download the guide and have a
read as soon as I can.
Thx for passing the link along, Edwin. I will download the guide and have a
read as soon as I can.
Thanks,very interesting and useful post
I would disagree that waterfall method pushs you away from communicating a design. In agile you comunicate only what is needed to ge the programer started and then your project sucess depends on the creativity and quality of the programer. In waterfall as you call it the focuse is on clearly defining the product up front. This is done buy interviewing users, managers and stakeholders in such a manner that the scope of the project is clearly defined. You can teach anyone to code software and as long as it is very clear as to what they have to do, the coding is the easy part.
Most of us who have writen our own programs have used the agile process and we all know how that comes out.
Agile has its place in the developement world but it should be use for what it is good at. Rapid demos and software that is constanly changing. Its good for small teams that work together in a bullpin type of enviorment. Its not so good for large projects that have firm delivery dates or contractual needs. Its also not good for critical software (Banking, Aviation, atomic bombs and such).
In closing waterfall is all about comunicating in clear detail and envolving all the stakeholders.
I would disagree that waterfall method pushs you away from communicating a design. In agile you comunicate only what is needed to ge the programer started and then your project sucess depends on the creativity and quality of the programer. In waterfall as you call it the focuse is on clearly defining the product up front. This is done buy interviewing users, managers and stakeholders in such a manner that the scope of the project is clearly defined. You can teach anyone to code software and as long as it is very clear as to what they have to do, the coding is the easy part.
Most of us who have writen our own programs have used the agile process and we all know how that comes out.
Agile has its place in the developement world but it should be use for what it is good at. Rapid demos and software that is constanly changing. Its good for small teams that work together in a bullpin type of enviorment. Its not so good for large projects that have firm delivery dates or contractual needs. Its also not good for critical software (Banking, Aviation, atomic bombs and such).
In closing waterfall is all about comunicating in clear detail and envolving all the stakeholders.
I would disagree that waterfall method pushs you away from communicating a design. In agile you comunicate only what is needed to ge the programer started and then your project sucess depends on the creativity and quality of the programer. In waterfall as you call it the focuse is on clearly defining the product up front. This is done buy interviewing users, managers and stakeholders in such a manner that the scope of the project is clearly defined. You can teach anyone to code software and as long as it is very clear as to what they have to do, the coding is the easy part.
Most of us who have writen our own programs have used the agile process and we all know how that comes out.
Agile has its place in the developement world but it should be use for what it is good at. Rapid demos and software that is constanly changing. Its good for small teams that work together in a bullpin type of enviorment. Its not so good for large projects that have firm delivery dates or contractual needs. Its also not good for critical software (Banking, Aviation, atomic bombs and such).
In closing waterfall is all about comunicating in clear detail and envolving all the stakeholders.
I agree that agile certainly has a place – and for some very heavy procedural-style projects, it may not be the best way to go.
But the major issues I have with waterfall is this – requirements change – you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking – they are very smart people.
And, more importantly – you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.
If a developer feels a “crystal, crisp, and clear” requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, “I coded this to spec – that's a requirements bug” then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.
Conversely, the person writing requirements can argue, “well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug.”
It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.
I agree that agile certainly has a place – and for some very heavy procedural-style projects, it may not be the best way to go.
But the major issues I have with waterfall is this – requirements change – you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking – they are very smart people.
And, more importantly – you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.
If a developer feels a “crystal, crisp, and clear” requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, “I coded this to spec – that's a requirements bug” then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.
Conversely, the person writing requirements can argue, “well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug.”
It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.
I agree that agile certainly has a place – and for some very heavy procedural-style projects, it may not be the best way to go.
But the major issues I have with waterfall is this – requirements change – you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking – they are very smart people.
And, more importantly – you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.
If a developer feels a “crystal, crisp, and clear” requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, “I coded this to spec – that's a requirements bug” then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.
Conversely, the person writing requirements can argue, “well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug.”
It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.
I agree that agile certainly has a place – and for some very heavy procedural-style projects, it may not be the best way to go.
But the major issues I have with waterfall is this – requirements change – you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking – they are very smart people.
And, more importantly – you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.
If a developer feels a “crystal, crisp, and clear” requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, “I coded this to spec – that's a requirements bug” then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.
Conversely, the person writing requirements can argue, “well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug.”
It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.
{ 1 trackback }