Why Requirements Stink
Rodica pointed me at this article on why requirements stink on ice from the Forrester blog, which asks the question, why aren’t we using social media in helping to sort out what customers want, instead of relying solely on customer interviews and other old school approaches.
My answer? This is the wrong question. Data collection is not the big problem. Sure, forums and blogs can be handy, but rarely is finding better data the big challenge.
Requirements suck for two major reasons.
1. Requirements is not Design.
Here’s a requirements list: Make a $5 car that goes 500 miles per hour, weighs 10 lbs, and is invisible. Those are very clear requirements. They’re also impossible. No matter how well defined these requirements are, or how happy the customer and the VP is with them, the project is set up to fail.
How can you know if your requirements are BS? You probably can’t. Requirements are not a product. The product is the product. A requirement is best seen as a way to help the design/engineering team succeed in making the product. End of story. The design/engineering team is the true customer of a requirements document. They know first hand all the stupid things requirements often include since they’ve been forced to experience them before. Want to avoid these stupid mistakes? Get their input early.
The easy test for how much a requirements document sucks or rocks is what the people who have to use it to do their own work think of it. If they think it sucks, they’re right. This means anyone charged with requirements should, from day one, be collaborating with the designers and engineers in defining the requirements. Incorporating their ideas, their feedback, and convincing them of new perspectives they need to understand. If they think requirement #21 is stupid, and they are wrong, at a minimum, it’s Mr. Requirement’s job to invest the time to convince them otherwise. I don’t want an engineer working on something s/he thinks is stupid. How I can expect them to do good work on something they find stupid? I couldn’t do good work that way. So I can’t expect them to either.
However, if you throw a requirement over the wall, which is what most requirements document authors pridefully do, it’s about as likely to succeed as throwing a hand grenade – people will scream and run. But if instead the requirements document is something they feel they contributed do, that it’s in part their document, they’ll run towards it, love it, and work hard to make it real. Bingo.
2. Too many cooks.
Requirements processes are long and stupid only because authority is spread out too thin across the organization. Talk to any person that is self employed, like your plumber, your gardener, or even your hair stylist. They do requirements gathering with their customers all the time, for important and expensive things, without 20 page documents, committee meetings or therapy bills. How is this possible!? What magic do they know that has yet to hit the business world? It’s simple. They have requirements authority. They have the power to make decisions.
Your requirements process sucks not because you don’t have the right forms, or because you’re not following the right process, it’s because you have too many people involved, all pretending to be effective with a tiny, minuscule piece of the requirements pie.
Pick one person per major area, a person who gets that requirements are part of design and not the other way around, a person who sees the value of collaboration and input, but is confident enough to make unpopular decisions when they are in the best interest, and give them the authority to drive requirements. I guarantee quality will rise sharply by picking the right person and giving them more authority.
Fewer cooks. It’s a simple way to solve many problems, but oh so rare to see.
The one book anyone working on requirements needs to read is Exploring Requirements by Gerald Weinberg. It points out most of the stupidity that goes on, explains avoidance tactics, and clearly expresses how requirements are part of the design process – that good problem solving techniques can quickly make your requirements documents better than ever.
Weigers Software Requirements has an excellent reputation, but I’m not as familiar with it as Weinberg’s book.
And Chapters 3 thru 7 of my book Making things happen offers one way to get from ideas all the way to specs. There are tons of other ways of course, but if you want my general take on this for large teams, it’s in there.
And Getting Real, by the folks at 37 signals, is a book that puts simplicity first, advocating almost no formal documents, requirements lists or specs at all.
Hey Scott — great post! Certainly being given some control and ownership over the requirements document would have made my life easier in the past.
Always enjoy your writing: The Myths of Innovation was thought-provoking, and provoked some interesting responses from cow orkers.
BTW, “Two many cooks” -> “Too many cooks”.
— psj
Thx PSJ. One point I was trying to make, but had to rip out, was that when people argue over process they’re often really fighting for more ownership. It doesn’t usually work :(
I’ve often struggled with how requirements should be done. Coming freshly from college, I thought everything had to be written from the start, there should be extensive requirements and design docs, etc.
Once I got into industry, it was amazing how slow and time wasting these processes were, precisely because of the Too Many Cooks syndrome. Everyone wants to have their hands on the issue at hand to justify their existence on the project.
Since I’m starting my own company, it’ll be interesting how I handle requirements once they come in.
I’ll have to check out your book.
I agree with the points you have raised. I actually hate the term requirements. Rather call it a vision, if it’s an aspiration. If it something that defines the deliverables it design. The problem is many people involved in requirements processes are not designers. They don’t understand the limitations and options available. A ‘requirements’ (or early design) process is a collaborative effort. Allowing a user, business analyst or programmer produce a requirements document on their own will result in something sub-standard. Any system has multiple stakeholders (unless you’re writing a bit of code for yourself) therefore any requirement / design point should be the result of the agreement of all the stakeholders – so how can anyone own it?
Keep it simple and communicate, communicate, communicate.
This is why requirements engineering is hard.
Most teams botch this step and tend to jump into quoting and implementation. Often this results in a poor product.
1. Requirements are not supposed to be design. It’s a problem statement. Design is the first step to solving the problem. If you are asking the client to provide the problem statement as well as providing the solution, what good are you?
2. There are always too many cooks. Manage them. It is the requirement engineer’s job to filter many voices into one clear voice to the developer. If this is not possible, then replace that person with someone who can.
Scott,
I would suggest to look at “Mastering the Requirements Process” by Robertson and Robertson (of the atlantic systems guild). Overall, I feel it’s a better book than Exploring Requirements. There are one or two areas in particular that I think they breeze over a bit; however, overall, I think they hit the main points VERY well.
It’s helped me on a number of projects.
excellent post. I’m in the middle of gathering requirements for an ecommerce projects – and your ideas are spot on. Thanks for sharing the book links!
I love it when I read an article that effortless articulates things I’ve felt but never managed to capture. Thanks, Scott!
Requirements don’t stink — badly done requirements stink. My current client generally has developers write the requirements, which they hate doing, but which also forces them to get close to “the business” and figure out what their actual customer wants.
If you designate one technically clued person, who will actually be involved in the development or testing process later, as requirements author, there’s a fair chance you’ll end up with practicable and concise checklist document that’s absolute gold to refer to during the creation of the product.
I found this post interesting, and blogged a response at http://www.developsense.com/blog/archive/2009_03_01_archive.html. Thanks, Scott.
—Michael B.
The plumber? He forgot to cap one of the pipes, opened the mains and walked out the front door. The contractor, he got told A, so they made B cause it was less work. Got told again, then made C. Thin organization indeed. What universe do you live in?
Chaogai: I live in a universe where it’s possible to pick better plumbers and contractors than the ones you did. They might be harder to find, cost more, or take longer to do their work, but they are out there.
If your point is that you can have too little requirements effort, I’d agree. But it sounds mostly like you had incompetent people.
It also seems I live in a universe where people read a blog post and entirely miss the point.
I’ve always found that requirements suffer from the Observer Effect. When you discuss them with the stakeholders, they don’t necessarily know what they want, but they will tell you something. However, the act of asking them causes them to think about it, after you’ve spoken to them, and to change them. I think the solution is to recognize this and consider the first set of interactions as just catalysts to getting to the real (or more accurate) ones
Asking people what they want is the wrong question, its open ended: how do you you are done?
The right question is “What do you do?” followed by “How will it change in the future?” and “What information do you need to do it?” Get the business to describe its process to a step level, and then ask if each step needs to be supported by a system. When a step needs to be in the system, that’s a requirement.
Then developers can tell you what it will cost to meet these requirements, and can deliver what can be paid for.
This works: contact me if you want to know more.
I think #1 is ONE valid technique but one that is too narrowly presented here. I have worked with plenty of development teams who have little appreciation (or respect) for who will finally use the product and wish to slash requirements because of that. So, while I agree that the dev team should be able to be part of passing judgment as a quasi-customer, the defense of the requirements should not simply come down to a BA vs. Engineers and what they do and don’t like.
Thanks for writing about this, Scott. I think that as social media strives to find its place in the business world, we’ll have increasingly more people asking these types of questions.
I actually believe that you can use social media to see what your consumers are thinking, to help them connect, and to allow them to provide you with some honest feedback that you wouldn’t otherwise have.
I wouldn’t expect at all to see those insights translate directly into a requirements document, but you may happen to see a critical mass of people who have the same problems. And that can be eye-opening sometimes. :)
I agree that poorly written requirement docs can be more of a hindrance than asset, but I don’t completely agree with the reasoning presented here as to why they are a hindrance.
You mention Getting Real, but one of the biggest points made in Getting Real is not the exclusion of processes and documentation, it’s the inclusion of business and the customer at more stages in the project.
From my experience, the main problem with requirement docs is they are perceived to be an infallible blueprint on how to get from point A to point Z. So the development team goes out and builds until Z is reached. However, while this was happening, the business side may not have been looking at the progress, or maybe they were only exposed to “controlled demos”. When they finally get their hands on the completed project, they realize there might have been a better way of doing point C. So development goes back and fixed C, and everything else that is impacted in the project.
Great ideas don’t happen, they evolve. By having those with the product vision involved at all stages, it gives their ideas a chance to mature. It reduces the scope of requirements docs, reduces the amount of rework needed at the end of a project, and allows for a more mature system and any given stage.
Good article! I like the idea of collaboration on the requirements document, especially after a recent project that went rather un-smoothly due to problems with the initial spec. I do have one question that brings up another issue…
In my experience, the provided spec or requirements doc has been our primary tool for estimating projects. In your suggestion, the spec/doc should come after project starts and therefore after the initial estimate. Project based billing has been our primary method thus far and we are transitioning away from that. My questions is… What are your thoughts on the best way to handle estimates without a spec/doc? And your thoughts on project billing vs. hourly billing?
The original article that this blog entry references has been moved. “Why Traditional Requirements Stink on Ice” can now be found at http://blogs.forrester.com/tom_grant/09-03-23-traditional_requirements_stink_ice
What if the engineers are told A on paper, then told B verbally, and also know that the requirements in both A and B cannot satisfy the requirements of acceptance test C. If engineers need to deal with this kind of nonsense, then of course they are going to build D.
I’m not making this up. This is exactly the nightmare I’m facing right now as a developer. I’m tired, angry, frustrated and the next step is resignation.
I think having detailed upfront requirements can be extremely helpful. The problems can begin when the requirements documentation is not updated over time. That can create a lot of confusion, especially if the Agile environment has not reached maturity yet. Another issue is if the requirements also mixed together with the design documents. Having very detailed design documents to work from can sound like a dream, but it creates a first impression of how the system should be, that is very hard to get out of the developer’s head. Programmers don’t just code, they design with every single line of code. Sometimes, given the technology and evolving requirements, it is just not appropriate to lay out a design document and say “well this is how it must be”.