The Importance of Client Requirement Analysis

Recently I developed a small bespoke CRM system for a client, based on list of requirements gathered by a colleague approximately 2 months ago. The CRM was nothing out of the oridinary – a maintable customer database, customer login system, email marketing functionality, customer account reminders, invoice associatiion with specific customers etc.

Overall, did the customer get what they? Yes. Did the project take a lot longer than it should have? Definately! The reason for the latter – poor initial requirements analysis from my colleague.

Essentially, requirements analysis is the extracting of all the information from the client from how a certain screen will appear, to what specifically should happen under certain circumstance on screen x.

Getting client requirements defined early on is extremely important. Firstly, this will help myself, the developer, as I can develop the system to a brief and build in a certain set of requirements. Personally, I find it much easier to work to a set of guidlines. Secondly, it allows the client to fine tune their requirements (rule of thumb: 9 times out of 10 clients don’t know what they want).

By having a set of clear requirements the customer will not need to call up late in the project to say I wanted x to do y and also to have a facility to do z. Additionally, the developer then won’t need to go and make another round of changes.

One of the biggest ommisions on the brief I was provided with was the administraton area – far to vague with little detail. The admin area may be totally hidden from your user base, but usually the majority of advanced functionality happens just here! So for a developer, a lot detail is needed here.

Yes, I agree, web development can encompass a huge amount of the agile software development think tank – granted, agile development seems to be more and more common nowadays – espeicially if you work in a larger agency for example). However, this particular project and budget limitations really didin’t allow for ongoing rounds of changes – I imagine a lot of smaller web companies and freelancers operate this way. Sometimes, there simply has to be a cut off point with changes.

When you’re taking client requirements think about the developer – as they are essentially a blueprint of everything the system will and won’t do. To finish off, I’ll go through a few example changes I had to make after the system was developed. These may not seem huge, but they all add on additional development time, project time and all could have been gathered during the requirements stage:

1. File uploads: inital specification requiured for functionality to upload a single file for each customer. In reality, the customer required functionality to upload an unlimited number of files – not a massive task, but still required a decent amount of code amendments
2. File descriptions: no mention of this initially, but the client required an additional field to set a file description for each file added.
3. Customer reminder functionality: initial spec required for automatic customer reminders 3 days before their account date lapsed via a cron job. In reality, the customer needed to set a different reminder period for each customer – the initial 3 days was just the default period the client wanted
4. File view tracking: initial spec required a customer to have the functionality to view files assigned to them. In reality the client required to view when a file had been viewed b y a customer. As a result, additional code to write to track the file view for that particular customer and to refelect this in the admin area
5. Customer import: initial specification made no mention of this at all. The customer had already typed out all of their initial 450 customer onto an Excel spreadsheet. After a bit of messing around I was able to import this into the system for the client. However, more time spent.

Client requirements really shouldn’t be taken light of or underestimated in any scale of project.