Understanding Requirements

Understanding Requirements

Understanding Requirements is probably one of the most important aspects of programming. In the 1989 movie, Field of Dreams starring Kevin Costner, his character (Ray) hears a voice whisper, “If you build it, he will come”. He sees a vision and promptly proceeds to turn his corn field into a baseball field. Well that takes a bit of determination and a lot of know-how. Ray knew how to grow corn but building baseball fields is a whole different story. What I am trying to say is the following; If you understand what you need to do, you will be able to do it. I am convinced that programmers should live by this mantra.

If you understand it, you can code it

Often there is a total communication breakdown between the analyst and the programmer. That is because the analyst that wrote the functional requirements for the system speaks analyst. Most programmers speak geek. Don’t believe me?

“So I need to create a class of type Sales Order that will enumerate the collection of order lines and execute a non-query to the database to insert the record for the linked Sales Order Header ID?“

Sitting across the person that made this statement is a very nervous, wide-eyed analyst. Okay, so perhaps this isn’t the best of examples, but you get the idea. Sometimes I see programmers (especially junior programmers) that sit in a meeting where the requirements are being discussed, and I can see that this guy or girl have no clue what everything means. They are however (hopefully) fevereshly taking notes.

In the hot seat

This reminds me of the time that I had an 8 am appointment at a client in Johannesburg. Traffic is always a nightmare and I made sure that I had read through the requirements documentation my manager had given me the day before. Needless to say, the GPS took me on the wrong route and I ended up being late for the meeting. When I arrived, the meeting had just started and I was the last to sit down. These guys then started discussing the requirements for the proposed system, and I soon realized that what I had read the night before, was absolutely and utterly a totally different system. My manager forgot to give me the second requirements documentation for the second system they needed.

I decided to bunker down and listen VERY intently to what was being discussed, in the hopes of catching the gist of it all. Then, the horror of all horrors happened. My manager turned around and asked me for my opinion. I broke out in a cold sweat, I could feel the whole boardroom looking at me in expectant anticipation. For the very first time in my life, I was totally and utterly lost for words. Mumbling something about them having covered all the bases, and that the proposed solution sounded solid, I was lucky that the finance guy interrupted with a question to one of the other attendees. (At least I redeemed myself when they started discussing the system I had read the requirements documentation of.)

Speaking up

So many times, I see programmers with that look on their faces… the one I had on my face in that meeting. What I can’t understand is that this behavior is so prevalent in junior programmers. Even if you ask them if they understand what is needed or what was discussed, they often say ‘Yes’. So the ninth tip I would like to share is that, if you understand it you can code it. End of story. We as programmers should be comfortable with our programming skills. In fact, I almost would like to say that what we understand from the requirements of a new system should translate directly to code within our minds. We should be able to conceptualize the application before we write a single line of code.

Going forward

Never be afraid to ask questions. If you don’t understand, ask. You are after all translating business jargon into C# or Java or whatever language you code in. Reversing these roles (in other words, you talking C# and an analyst needed to draw up a functional document from that) I will guarantee you that the analyst would have a couple of questions for you. In fact, what we as programmers often need to do it quite difficult. Understanding what you need to do is essential. You will see, once you know that, the code will come naturally.

Dirk is a Software Developer and Microsoft MVP from South Africa. He loves all things Technology and is slightly addicted to Twitter and Jimi Hendrix. Apart from writing code, he also enjoys writing human readable articles. "I love sharing knowledge and connecting with people from around the world. It's the diversity that makes life so beautiful." Dirk feels very strongly that pizza is simply not complete without Tabasco, that you can never have too much garlic, and that cooking the perfect steak is an art he has yet to master.