Aren't Requirements and Specifications the SAME THING? (Tuesdays with Joe, Episode 06)

Ғылым және технология

Here’s a question for you:
Would you build a house without first knowing how many rooms it should have?
Of course not.
Here’s another:
What would you do when, 3 months after construction starts, your spouse insists you need another bedroom?
You’d be stuck, of course.
You’d be scrambling to figure out a way to minimize the amount of work you have to undo (and redo). You’d be hoping for some miracle to give you the time, budget and people to take on the additional work.
And get it done on the same deadline.
This is exactly what happens when managers, product owners, developers and designers treat requirements like specifications.
Fact is, the two are not the same thing.
The primary reason so many development teams find themselves painted into a corner - or struggling to stem a rising tide of new or changing requirements - is that there is a widespread misunderstanding about what both of these terms actually mean.
In this episode of Tuesdays with Joe, I’m going to clear the air once and for all about the difference between requirements and specifications. And I’m willing to bet that your work (and stress level) will benefit greatly from applying what you hear.
More where that came from: www.ux365academy.com

Пікірлер: 7

  • @therealsimonkemp
    @therealsimonkemp7 жыл бұрын

    Good stuff Joe. Do you have any real world examples you could share that demonstrates how a requirement becomes a specification?

  • @joenatoliUX

    @joenatoliUX

    7 жыл бұрын

    Hi Simon - by way of example, I've had situations work like this: The team uses a low-fidelity prototype to test a data view with prospective users. The requirement calls for a grid view, ton of data, 12 columns across, near-infinite rows, progressive load upon scrolling. The thinking is that customers need to see a wide variety of data points and need the ability to slice and dice it all multiple ways. During user testing with the prototype pulling from the customer database, we see it takes forever to load - sometimes a full minute. Users are frustrated inside 15 seconds. HATING it. After much debate we find out that only FOUR of those columns are really necessary for the user to get what they need and get on with their day. Which loads infinitely faster, near-zero delay. So when the specification gets written, it says 4 columns, progressive load. Had the team just built to the requirement, they'd have burned thousands of budget hours on something customers would ultimately reject.They'd then be scrambling to fix it, blowing the budget and losing a great deal of customer goodwill. That's why you treat requirements as questions, as unknowns ;-)

  • @therealsimonkemp

    @therealsimonkemp

    7 жыл бұрын

    Thanks Joe. In your scenario it was fortunate that you were testing your prototype with real data volumes and therefore were able to discover this performance issue early on. Many times that goes unnoticed until later in the process when you start using real data volumes (usually just before go-live! eek!). So basically the requirement is an "initial guess" and the UX design process (prototyping and testing in this case) validated and refined that guess early enough for the change to be easy to make and avoid problems and more expensive changes much later on. The specification was a result of running that requirement (guess) through the design process. Thanks again!

  • @Hally7050

    @Hally7050

    7 жыл бұрын

    Involving developers at an early stage of the UX design process is important to detect performance related issues early on. Wireframes are a great way to get their feedback.

  • @nikolaosgkionis6575

    @nikolaosgkionis6575

    7 жыл бұрын

    Great stuff indeed. The example answer on the text brings this home. Thanks Nikos

  • @fazilespander7914

    @fazilespander7914

    Жыл бұрын

    ​ @Give Good UX | Joe Natoli I'm sorry, but in your example it was just a very bad requirement that doesn't meet the so called quality criteria and includes implementation. The difference b/w the requirement and specification is that the specification describes the single solution which is just one instance in the set of possible solutions, and the requirement defines the boundaries of this set of the possible solutions. So, the art of setting up the requirements is in finding the right moment where you need to stop because the futher specifying will exclude suitable solutions. But if you stop too early the set of solutions will include those that solve the problem partially or don't solve at all.

Келесі