Here’s a great YouTube clip detailing the problem with the traditional (waterfall) requirements documentation method. It does a great job at highlighting why requirements often fail—misinterpretation.
Here’s a great YouTube clip detailing the problem with the traditional (waterfall) requirements documentation method. It does a great job at highlighting why requirements often fail—misinterpretation.
Funny how little the problem highlighted here is talked about in the “real world” of business. The amount of time wasted fixing things that I never should have been asked to build is scary.
I really enjoy the blog btw. Loved the color IQ test.
First off, that music was horrid.
Secondly, I get the point, which could have been made alot more succinctly. Interesting that the climax of their problem statement had the narrator reading an entire balloon of dense text instead of graphically depicting the point via more pictures.
Third, I totally agree that prototypes are an effective way to communicate an experience, which is their solution. But they term it as the only solution, not addressing the fact that their “requirements document”, sans any pictures whatsoever (other than dense diagrams) could have added pictures and gone alot farther.
Boo hoo.
Perhaps text does not always have to be ambiguous? Let’s say we are talking about a requirement such as the following: “The interface should work on a screen resolution of 1024×768″. Not that much ambiguity in that, is there?
Secondly, in my opinion an interactive or clickable prototype on its own is not adequate in communicating with clarity. So the idea of sending someone a link and expecting them to understand everything, is a bit stretched. The power of clarity comes from a visual demonstration and a good story which supports an explaination. This is also visible in the video itself where the voice over guides the viewers. My 5 cents.
@Jakub the point isn’t that text is always ambiguous, but rather that it leaves more room for misinterpretation than a sketch. Even in your example of should work on 1024×768, that leaves a wide variety of options and interpretation. However, if you create a prototype based on that request, there’s less misinterpretation for what that size actually is.
I would also agree that a prototype on its own isn’t always going to be enough. You may need to include a supplemental document to clarify things the prototype doesn’t include (e.g. some type of business requirement that lead to the design decision).
Classic. I was just in a meeting yesterday discussing similar issues more at a process level than a spec level. It also kills me that companies still only ask “what it needs to do” and not “why it needs to do it”. The video captured this perfectly, though I’m not sure if they intended to. I’m not sure if prototyping is the panacea they’re suggesting. You need someone to ask the why questions first.