Notice: This blog is no longer maintained. All new content is being published as guides/books/screencasts. Have a look around!

A Programmer's Road To Productivity - Step 1 : Deconstruction of Requirements

April 16, 2015 - Marco Behler

9:00 AM, your boss storms into the room and says: „Marketing wants a new fancy login box on our website. Just username/password field alright? And maybe a recovery link. Shouldn’t take more than a couple of days. Gotta go, bye!“

In situations like this, you usually scream on the inside. But this time you stay calm. Because you’ve learnt how to deconstruct.

What is deconstruction?

Deconstruction means taking a requirement and splitting it into the smallest possible pieces. Those pieces then need to get clarified. Finally, they should then form the common understanding between you (coder) and your boss/customer.

It does not really matter if someone hands you a ready-made specification (yeah, right), you follow some agile-process-of-the-month or have a really loose process. It all starts with deconstruction. And deconstruction starts with asking questions. A ton of them!

Let me start coding already, why do I need to do this?

Yes, you might already be drooling about how to ng-submit() your login-form with AngularJS and how this is sooo much easier and faster than with Struts 1. Nope, hold your horses!

First, we need to check our requirement for soundness. Break it up. „I want users to be able to login through a box“ is not a proper requirement.

It sounds almost too simple, I mean you can whip up the two fields and a backing controller in a matter of minutes, right ? Well, let’s see…

Didn’t you mention something about a real-life example before ?

Oh yes, this specific example actually happened to us in February 2011. It was a requirement on a German car manufacturer’s then-new website.

Have a look at the lower left corner of the following picture. Spot that innocent looking login-box. What looks so small and easy, was actually pretty complex. Let’s find out why…

But first, how do you deconstruct ?

You should start with two people, a technical driver and a business driver. So get your boss back into the room to get more INPUT! Sometimes we have even seen developers being anxious to ask for more information, as to not "look bad".

Oh, and add in more people only if needed. From our experience, a whole team deconstructing (for example in Scrum planning meetings) is a huge waste of time, money and effort - but that’s a different topic.

And then, with your favourite writing tool open, you have a couple of rounds of „play infant“. Why „play infant“? Because you are going to ask questions, write down the answers and group them into topics. And the questions are going to be infant-like questions. „What is that?“ „What does it entail?“ „Why do we need it?“ „What other parts are there?“.

How long you ask? Until you run out of questions or the other person smacks you ;)

Example please ?

To come back to our example above: „We need a login box“. Let's split it up. [1.] we need [2.] login [3.] box. Let’s assume [1] is given for the moment and start with [2]. ( Note: Please don’t take the tone of the conversations seriously :) )

The issue with the [login] part

You: „What is a login?"

Mr Biz: „Well, a username/password should be enough to login“

You: „Username or email?“

Mr Biz: „Both!“

You: „Wait a minute, who are our users again?“

Mr Biz: „Stupid question. Want me to fire you? Everyone who registers via the website“.

You: „Is that really everyone?“

Mr Biz: „Well, yes. But upper management quickly mentioned something that users who already bought a BMW in the past should be able to logon to the website with their customer reference number and automatically get some guest account“

You: "Erm, where do we get those customers from?"

Mr Biz: „From a CRM system. In parallel to our own newly built user database. Oh and btw, there’s several different CRM systems, so please account for that“

You: *Erm, customer reference number and then they get sent a password or do they have password already somewhere or can they just login“? What is when the CRM system is unavailable? What is an automatic guest account? How do they know they can suddenly login? HELP! ….“

=> Keep on asking for X more days

Let’s take a break and look at the [box] part

You: „What is a box ?“

Mr Biz: „Man, there’s already designs for that. Username/Password field, login button. How hard can it be?“

You: „That box, should it only be displayed on the front page?“

Mr Biz: „Well no, we want to display it on several pages, maybe some campaign pages or whatever. So make it a component in that CMS system of yours.“

You: „Component? Aha. Erm, ever heard something about HTTP/HTTPS? Our website runs on HTTP, and it is a bit tricky to…(technical explosion in the head with https iframe in http page)..well…let’s just say…we need to make sure the user transmits his data safely.“

Mr Biz: „Yeah, yeah. You’ll get it done, I’m sure. Btw, regarding security. Users can also be banned. And it could be that they have to accept new „terms and conditions“ before they can login..in some sort of layer. Or else our lawyers kill us.“

You: „Ouch! Banned users. Terms and conditions?. Layers? A layer in the embedded iframe or a layer on the parent page?“

=> Keep on asking for X more days

Ouch! We only just started!

There’s a TON of topics we didn’t even cover. Infrastructure, SSL-Loadbalancers. Password forgotten workflows. Error messages/info messages. Yada yada yada. And who said we need the loginbox after all? The customers? Who actually is the customer???

The HTTP/HTTPS issue highlights how critical it is that tech AND business people sit together when writing requirements. If there’s no two-way communication, you’re really only in dreamland.

Last but not least, with the topics we have, we are not even close to being completely deconstructed - instead we are looking only at the tip of the iceberg.

Forest Forest Forest, but where’s the trees???

After asking just a couple of questions, we now have a whole forest of questions which need clarification. And without that clarification you cannot plan, you cannot estimate, and you cannot push back, if something is completely unreasonable.

And you certainly should not start banging out code already before we are finished with this. Rinse. Wash. Repeat, you know?

Next Step: Yep, we are far from finished. But this was just the start with our deconstruction.

In the next article we will continue our deconstruction till the very bottom and learn how to clean up, before we then move on to angling and skinning our requirement. As always, if you want to be the first to get notified, join our newsletter !

(Update May 2015: Check out our related, upcoming book: Customer Requirements - Everything programmers need to know before writing code)