Creating Software: Getting the Requirements

Most software projects follow a fairly similar path from creation to completion. They start with talking to the user, getting the requirements for the project. It moves to the next stage, taking the requirements and getting them on paper (designing your software). After that, you get into coding, testing, bug fixing and more testing, and finally, you show the finished project to the client.

Now I know that I’ve outlined a fairly crude time-line but thats the basics of it. Over the next few weeks I’m going to go over each of the parts of the software project time-line and outline a few of the things that I find difficult.

Today I’m going to start off with the first in the list and also the hardest in the time-line; talking to the client and getting the requirements.

Don’t talk code, talk requirements

I have failed this aspect numerous times. The first time I ever talked to a client about a project I was so nervous I didn’t even ask for requirements, I merely talked about how I was going to design it. The problem with this is that the client doesn’t care how you create the software, they just care about the final project.

The problem with talking about the code instead of the requirements, is that if the client gets mixed into the details of how the project is created, they may forget functionality that they want, and this is a great way for a project to fail. When you sit down with a client make sure you keep your sentences as non-technical as possible and don’t talk about how you’re going to create the project; just talk about what they want from it.

Implicit and Explicit requirements

There are two different kind of requirements: implicit and explicit. Explicit requirements are those that the client explicitly tells you - “The project must be able to do this”. Implicit requirements are those that the client assumes will be there - “The project must look nice”. As you can see, implicit requirements are much harder to deal with than explicit ones.

The problem though, is that implicit requirements are still requirements. If you fulfill all of the explicit requirements but miss the implicit ones, the client won’t be happy with the software.

I’ve had a number of talks with friends who wanted something completed a certain way but never told me about it. I’ll complete the software to the specifications that they tell me, only to hear from them in a couple days that its not what they wanted. I normally fix it and then tell them that they have to tell me what they want from the beginning.

Software developers can’t read minds.

Your Thoughts?

Do you even bother with a formal requirement setting? Have you had any experience with an annoying client when it comes to getting requirements? Tell me your stories or tricks in the comment section below.

If you like this post then why not share it?
  • StumbleUpon
  • description
  • Technorati
  • Digg
  • Slashdot
  • Design Float
  • TwitThis
  • Reddit
  • E-mail this story to a friend!
Add devjargon( ); to your RSS Updates.

Get new posts sent to you by email for free!


  1. 1 07.09.08
    9:48 am

    Really nice summary, Adam. And thanks for linking to my article from way back when.

    I remember (as a former code-slinger) when I had the epiphany that getting requirements (do the right thing) was harder than writing code and tests (do things right). I get excited any time a developer (or a dev-focused blogger :)) has the same insight.

    And you’re also right about implicit requirements - they are definitely hard. Another challenge - when explicit requirements aren’t really requirements. Stakeholders will often say “I need X” when in reality, they need “Y” and “X” is just one way of getting to “Y” or even worse, in direct conflict with “Y.”

    Thanks again, and keep it up here!

  2. 2 07.09.08
    9:43 pm

    Of course it’s a completely different story when you don’t have any clients / users until the software is written. As is the case for most startup companies. It’s not uncommon for the first version of the product to be build a certain way (for the founders themselves, or for a small group of people they know), but have the community take the product into a completely different direction afterwards.

    As was the case for PayPal, Facebook, etc. Hotmail was originally build as an internal tool for the developers working on something else.

  3. 3 07.15.08
    12:26 pm

    [...] software is difficult. You need to first get the requirements from the client (or create them yourselves), then you’ll use the requirements and design a working system. [...]

  4. 4 07.29.08
    10:02 am

    [...] takes a long time to make. You first need to get the requirements from the client. Once you’ve gotten the requirements you then need to spend the time to properly design your [...]

  5. 5 08.28.08
    10:40 am

    [...] now looked at Getting the Requirements, The Design Phase, and Start Coding of Creating Software. Stay tuned for the final installment. If [...]

Leave a Comment