UIEtips: Replacing “Requirements Gathering” with Something That Works

Jared Spool

June 25th, 2013

In this week’s UIEtips, I talk about replacing “requirements gathering” with something that works.

Here’s an excerpt from the article:

You’ve seen the box on the project schedule a hundred times. It always has the same label: “Gather Requirements”. And it’s always remarkably short — scheduled for just a day or two (or sometimes less!).

When I ask the project manager what this step involves, they inevitably tell me they’ll interview the major stakeholders and gather up the requirements that emerge. It’s going into the fields and picking berries needed for the project.

How do these major stakeholders know these requirements? Well, they just do. They’ve been thinking about it for a while (except for the ones who haven’t). They’ve talked to customers (except for most of them, who never talk to customers). They’ve talked to the sales people and the technical folks and the business modeling folks, who told them exactly what’s needed to make this product successful (but how do those folks know?).

Read the article: Replacing “Requirements Gathering” with Something That Works

How have you dealt with requirements gathering? Let us know below.

5 Responses to “UIEtips: Replacing “Requirements Gathering” with Something That Works”

  1. Craig J Willis Says:

    Great article, we’ve had exactly the same experience and dumped the term ‘requirements gathering’. Instead the phase you describe as forming a hypothesis we call ‘requirements discovery’, part of which involves talking to the stakeholders about what they ‘think’ the product should do. Combined with other research we develop using agile processes that allow us to deliver small parts often that we can use to test the assumptions and move forward.

    OK, that’s a bit of an over simplification of the process but the core of the approach is to develop a simple common language that describes the product. A language that is common to all involved including the customer, analysts, developers, testers, designers etc. And like English the language needs to be flexible, the rules you start with (the assumptions) will evolve and change as you close the loop between all the stakeholders.

    As the assumptions are proved, or not, they are dropped from the language until such time as there is nothing left to talk about!

  2. Skip Pletcher Says:

    What you describe sounds like Basili’s empirical software engineering. Prototypes are the ‘model.’

    Of course, “best” implies an exhaustive level of measured alternatives, which ‘just ain’t gonna happen.’ So maybe our hypothesis reads “We believe having links to the most commonly visited pages is better than [not having them or some other alternative].” Then we define some measure of better-ness and experiment.

  3. Nick de Voil Says:

    You’re obviously exaggerating in the first couple of paragraphs – I don’t know any project managers who are that naive. Certainly any project with a competent business analyst on board wouldn’t work like that.

    But that said, there’s so much that is right about this article. Requirements are certainly not “out there” waiting to be “gathered”. And I agree that evolutionary value-driven development, which is the only sort that works, is a kind of purposeful experimentation.

  4. Dys Sahagun Says:

    This is very similar to lean UX wherein the process goes a bit more scientific.

    Instead of building the track and lead the train whereever you want to, you ask the passengers where they want to go or where they would go–then build the track based on that.

    But as you’ve stated, the obstacle to this is time and resources–things you have to balance with what you currently have.

    The important thing is it ends up with different levels/details/fidelity of the same process.

  5. Magnus Billgren Says:

    I love it.

    We have abolished old school requirements gathering principles.
    We work with hypothesis and try to provoke response, ideas and involvement. It goes faster, gets better and is more fun.

    The complete thinking of Hypothesis and antithesis that forms the synthesis is great to use. And it goes back to the old greeks….and was very much reinforced by the german philosopher Hegel in 19th century. It is actually fantastic that we can reuse knowledged being created and tested in many environments and times.

    The MRD 1.0 is not the answer it is the start of creating a great product. And all of us working with requirements – remember we love requirements they give us insights, and answers to the market survey we haven’t yet performed.

Add a Comment