Requirements from the Developer's perspective

Requirements. It's not a very ambiguous term though the meaning behind requirements in software development seems to be one of the hardest concepts to grasp. We all know that they are needed for a successful project...yet it seems that they are often a one of the primary reasons for project failure. Whether the requirements simply don't exist, are incomplete, are too vague, or constantly change, they have the ability to make or break a project.

One of the issues with requirements is they often self-contradict themselves. The system needs to do perform x, y, & z. It needs to perform at this rate, be dynamic enough to handle any change, be scalable, be database independent, persistent ignorant, etc. Simply put, requirements can't be cast in stone. They are all about compromise one need/feature for another. Perhaps performance is increased by 1% taking on the risk that 1 out of every 100,000 reads against the database might have stale data. Who knows? The fact of the matter is that requirements are similar to a person's growth. Early on, there are lots of changes. They grow to be stagnant for awhile only to be following by a few more spurts of rapid and drastic changes. Eventually, the requirements satisfy most needs and are generally accepted thus becoming stagnant once again. Sooner or later, they will become obsolete and die off only to be replaced by a new set of requirements defining a different scope.

So, whose job is it to obtain the requirements? Is it the user, the analyst, architect, project manager, or developer? I think it's everybody's responsibility to contribute. Each person mentioned has some stake in the matter. Granted, a single person may fill more than one role, but that is not the point here. The point is that each role has different needs and wants. Their perspective on the requirements may differ vastly from the next. There needs to be a single person that is the owner of the requirements. All others are just contributors.

As a developer in a project that has had been under constant flux, I have felt the pain of changing requirements all too well. I feel that as a developer, I failed in my role as a contributor. Though I didn't own the requirements, I did recognize some potential pitfalls early on and had mentioned them. I had brought them up in a meeting and consensus ruled that they would not be issues. I should have stood up and spoken with more conviction at that point. The pitfalls I suspected were critical in the overall design. These issues have been debated and discussed over numerous meetings since then...each time with a reactive approach instead of proactive.

The moral is that, as a developer, I should have recognized the impact the issues I suspected would have and my level of conviction should have followed suit. Instead, I just went along with the consensus. As the issues truly did arise, my pains in trying redesign a core portion of the application have increased exponentially as our deadline approached. Had I done a more thorough design up front, I think I would have noticed more of the inconsistencies in the requirements. The questions I would have uncovered would have clarified the requirements and exposed the risks they presented.

Last minute requirement changes....

Though I had intended to keep this blog an informative location on the web, I need to rant. I understand that requirements change. I'm a big believer in iterative development cycles for this very reason. There are, however, few things that irritate me more in my professional life than a breaking requirements change at 4:00pm on the Friday there is supposed to be a code freeze. As valid as the case may be, it's a sure way to ruin a person / team's weekend. It is demoralizing to have a working application going into the code freeze without any bugs reported only to have the requirements change 1.5 hours before you plan to leave work...especially after putting in extra time the entire week to accommodate breaking requirements changed the previous Friday. The change in requirements resulted in an extra 4 hours of work today, a broken service, and the need to work through the weekend with hopes of having a fully working and tested service by Monday.

I suppose that I need to look at the bright side of things though. I am fortunate enough to be employed at a stable company. Also, I am extremely grateful that last minute breaking requirement changes are rare for my team.