I love what I do; designing and developing RIAs and complete sites is the Cherry on top of my list of jobs that fall into the category of the anti-job. Simply put, my job for the most part is not work for me in the traditional sense. It is at times very difficult, stressful, involving long hours and little rest with the end of the road well over the development horizon. That being said, there are moments in the process that are unarguably the low-points of developing software.
Planning. The vast majority of the time this is tedious and devoid of pleasure or value on the happiness scale. This is the part the I really despise actually. Endless headache inducing meetings that always seem to be more of an organized argument than a discussion about new features and improvements. People get hung on the small scope issues like menu verbiage, where the topic should be focused on structure.
As it turns out, this is also the most valuable portion of the entire process, and glossing over it will likely be result with the project to be plagued with problems such as scope creep, missing the deadline, or coming in over budget, or to fail completely. The planning phase is also where almost all projects get off track, most never to return to the desired path and wind up falling short of the developers idealistic goals and the clients lofty desires. The reasons are as numerous as they are varied as to the hows and whys of the failures, but one thing can almost certainly be tracked down as the culprit: The Requirements Document. Just like an Atlas would help you drive from Phoenix to Scranton, the Requirements Document allows you to follow a defined path from concept to completion. A path which if poorly mapped out, is about as much help as an Atlas without street names; you may be able to still find your way, but it isn't going to be pretty.
The first step to creating a well-written Requirements Document and finishing with a well executed project is to stop looking at the big picture. Being able to plan for every nuance and feature up front is impossible, so stop it! You'll have far greater success by creating smaller microcosms of functionality, then fitting these pieces together into a cohesive unit later. The way I work is to go from menu item to menu item looking at what these categories of functions need to accomplish and how all of the individual items fit into categories and how they all relate. Like the File menu in most applications, all of the items listed under the File menu work together but perform unique functions. When you have a grasp on that, move to the Edit menu…. Don't try and do it all yourself either, black box development doesn't work, so get the input of the developers and the clients on this. Look at what other people are developing in other applications may be similar and different from what you are planning.
For existing applications in need of an upgrade, the first I look at is what works. This is the same approach you might take if your friend asks you what you think of a new drawing he just finished. The first thing out of your mouth shouldn't be negative as it sets the tone for the entire conversation in a negative light; the same thing applies to defining systems in need of an upgrade in software. if you start by looking at what is broken, and what sucks, you are likely going to focus on the frustrating parts and become agitated yourself. By focusing on the parts that are working is more conducive to keeping a positive frame of mind as you plan new features or work through existing features getting a face lift.
The Requirements Document should be above all else consistent. This means several things, and most are generally applied; consistent in tone, detail, and structure. The building blocks are:
- Correct: This is pretty self explanatory, but easily left for dead. I would think most folks don't strive to be wrong, this is still easier said than done.
- Unambiguous: Statements like "Should be easy to use" should be replaced with something like "new articles can be written and posted in 2 steps."
- Complete: Be as detailed, anal, and thorough as humanly possible. You won't get it right first time out, so edit and rewrite. The goal here is to provide everything needed to build the application.
- Ranked for importance: This is important to determine what features are "must haves" or "like to haves", since most the time the client doesn't make this distinction unless pressed to do so.
- Modifiable: Don't treat this like it's the Holy Grail. Everything should be malleable to a point. Being inflexible in your requirements will result in an unsatisfied client.
There's no shortcut to a well crafted Requirements Doc, and there isn't a magic-bullet form to download. Hard work and the discipline to stick with it from start to finish will rule the day here. I have written quite a few Requirements Documents, and it doesn't get any easier from the standpoint of it being a lot of work, it will always be time consuming. Where it does get easier is that the more you edit your work, the more time you put in with the end user, the more you become integrated with the process and the details present themselves more readily.
Knowing all this may not make you like doing it, but it will make you better at it – and in the end that will result in more thoroughly planned and developed software.