Geeks With Blogs
If you can't riddle them with questions... ...riddle them with bullets.
Today I'd like to talk a bit about requirements and end users as its all related to the software development lifecycle.    So first, the stages.  Over the years there have been many different stages defined, at varying degrees of granularity.  Wikipedia has a good definition.  As developers, we tend to hang out in varying stages of this lifecycle, depending on the size of our company (for me, I hang out in specification, architecture, implementation, and maintenance -- we have a relatvely small company)  So anyway, for my work, there are two ends where I interface with other people in this process -- the requirements stage (where I interface with end users and management), and the testing stage (where I interface with QA).

Now for the principle.  This is important, and people who have worked in the industry for a long time know it to be true -- end users do not know what they need.  Frequently, they do not even know what they want.  To new developers, this might come as a surprise, but to those who have been around a while, its a fact of life.  Shortly after we choose our path as code-o-philes, we quickly realize that the end user/requirements analyst and the developer think on two different levels. 

As developers, we pay attention to details.  We are paid to remember things, otherwise we wouldn't be developers.  Not only do we simply remember details, but frequently entire systems of code are designed based on details.  So while certain details might mean nothing to the end user or person making out the requirements (not to say that such a person is stupid, uninformed, etc.   They simply do not have the same grasp on the details of the system that we do), our jobs depend on these details -- and the number of levels in the lifecycle really help to show that.  It is important to have the details hashed out by the time you go in to do the coding. 

That being said, there is a sad fact that we have to remember -- people in the early stages don't care about details (and will frequently forget about them altogether).  This is why it is important to document EVERYTHING, especially in this stage.  (If you live in only one stage, it is important to document everything going in and out of your stage).  Because others might not have the same understanding of the details that you do, it is important that you transcribe what they want so you can refer to it later if they decide to change their mind.  It is also important that they review your transcription and make sure you've got everything right.  Its also important to keep people at the low end of the lifecycle in the loop on what you're doing -- so they can be sure it meets their requirements.  There is nothing worse than developing whole systems only to have them thrown out on the whim of the end user.  (But believe me, if you choose to be a developer, it'll happen sooner or later)

Believe me when I say that doing this will save you a lot of heartache and irritation later on.  It sucks to rewrite things after you've already finished them to a high degree of quality, but its even worse to finish them and have the blame turned around on you for misinterpreting what the requirements were. 

I think I can sum this post up in one word.  DOCUMENT.  Do it now.  Posted on Friday, August 1, 2008 7:06 AM Standards | Back to top

Comments on this post: Requirements and End Users

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © agundel | Powered by: