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 that’s 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.