A Rant on Defining Requirements

I started working on the requirements for the krill application and decided I would take a minute or two to rant about the process of Defining Requirements.

Defining requirements can be done so many ways that it would be impossible for me to provide a universal template for this.  What I will attempt in this post is just give some of my observations on this process so you can see where I am coming from.
 
Getting Together

It all starts with an agreement between the product owner (or business line) and the development team. The development team should have some basic approach to requirements gathering that can be used to coax the necessary information out of the product owner.

In my opinion, there is no replacement for a face-to-face meeting when initially defining a project's requirements.  Getting all the right people in a room together is priceless.

Anyone who has ever sat on a conference call/live meeting for hours can attest to the fact that this really is not the same as meeting in person.

Meeting in person encourages participation and discourages mentally checking out.  Sitting at your computer is far too much of a temptation to keep working on other tasks than many people can resist.

Doodles

I am also quite a big fan of the "doodle" approach to defining requirements.  When I begin to think about a new application, I generally first imagine using this application.

I will then make doodles of the various pages of the application.  These doodles can be done effectively on both paper or with some sort of wire-framing software. 

On the doodle, I will write the business rules of that page off to the side.  This will give you both a mock up of the screen, and the rules in one place.

If you have everyone in the same room, you can easily craft theses screen mock ups together on a whiteboard or flip chart. 

As you beginning drawing these pages and connecting them, the developers and the product owners will begin to view the application in the same way.  Having the same vision of the application is a huge accomplishment.  Can you think of times when you finished an application only to have the product owner dissatisfied with the way it operates?

Why Not Just Write Use-Cases? 

As a developer, every time I see a use-case my eyes will glass over. 

Use-cases generally consist of a description of the page, a listing of fields, and some business rules. 

The developer then needs to translate this information into some usable form before beginning any work.  And what form does the developer usually translate it too?

That's right!  A doodle!  So why not just skip the Use-Cases all together and just start with a doodle?

They say a picture is worth a thousand words and in this case, that is true.  I would trade a thousand word use-case for a doodle any day of the week.

What About the Management Types?

Once you have finished with all of the doodles, you can hand these off to a good technical writer and have them craft whatever document type the organization requires.

The developers then beginning planning the actual implementation off of these doodles. 

Granted, changes to the requirements will be made by both the product owner and the development team in the initial phases (who am I kidding, all phases) of the project.  How much easier is it to modify a doodle compared to some SDD/TDD doc?  The answer is a lot.

Summing Up Defining Requirements

The bottom-line is, I believe that software engineering has gotten to be crazy over the years.  Organizations have become obsessed with the documentation and formalization of every step of development to the point on insanity.

The product should always trump the process.  This is what the Agile methodology is trying to emphasize.  http://en.wikipedia.org/wiki/Agile_software_development

Please do not take my ranting as a plug for Agile.  I believe, first and foremost, in getting back to basics. 

Whatever method you choose, don't make it too complex.  The process should walk that fine line between producing enough documentation and not driving the development team crazy. 

Sounds easy, right?

A Change in Plans

After giving it some thought, I have decided not to rehash the stampy application. Instead, I will start from scratch with a new application.
The idea behind this application will be a web site that helps musicians find bands and band find musicians. 

The application will be named krill since these fish, much like musicians, travel in packs (schools).  The name is also "fishy" to keep with the fishbulb theme.

The requirements for this will be rather simple.

1. Provide a method for musicians to create profiles.  The user will fill out some basic information such as instruments played, genres preferred, and experience level.

2. Provide a method for bands to create profiles.  The user will find out information such as types of musicians needed, genre, and band status.

3. Provide a search mechanism for bands seeking musicians.  For starters, the application will be Austin, TX  only.  Later, I will expand it to include other cities if any one uses it at all.

4. Provide a search for musicians seeking bands.  The user will be able to search for bands that are seeking specific types of musicians by genre and other criteria.

5. Provide a messaging system.  This will allow for anonymous communication between users.

Using these requirements as a starting point, the next step will be to define these in further detail. 

In my next post, I will beginning to hash these out and start some prototyping.

Getting started

In an effort to become more organized, I have decided the best way to accomplish this goal is to start writing things down.

I have decided to document the process of creating a web application from scratch.  While this is technically a replatform of an existing application, so little will remain from the existing application that this is essentially starting with just an idea.

The first stab at the stampy application was merely to get the idea out there.  This go-around will be a more methodical approach to developing a web application.

In my next post, I will begin to define the requirements for the stampy application so that I can get to work.