The Design is the Requirements

I have been checking out Google Sitemaps, but don't have anything to post yet, so I found this article that I wrote a little over a year ago, which had not been posted publicly. Although I think the grammar could use some work, I still agree with the concept, especially for smaller scale web projects.

In software design we are always hearing about the requirements gathering process. I got to thinking about this over the weekend, and wondered if this really applies to web applications. Does it help to have a list of test cases or features when building a small to medium sized web application? In my experience the answer is yes, but not in the traditional sense.

Typically we recieve the HTML pages from the client, and they say "make this work". The pages include sample data, they include the navigation and layout. The design is what they are comfortable discussing because they can see it, and they know that this is what it should look like when the project is complete.

So I contend that the design is the requirements.

If you think about it, this simplifies the requirements gathering process for us, mostly because we aren't part of it :). The stake holder talks to their designer, and says it should look like this, it should do this. The designer then builds the pages to spec, which is in turn reviewed and tweaked. By the time we see the files, they represent the finished design.

From the design we can interpret how the application should work. We look at the links provided and follow them to see which sub-page they go to. We see an "add to cart" button, and we see the finished cart page design.

All we need to do is make the pages work by adding code to them.

Of course it isn't quite as simple as that, but after dealing with this sequence of events time after time you begin to gain the skills in reading the requirments from the design. You train yourself to go over each page, realize the linkage between pages, realize the work done by each page, and understand what the stake holder wants.

Every once in a blue moon someone decides a formal requirements process is required. Based on the few times this happend with projects I was a part of, the process faulters fairly quickly. The stake holder doesn't really know what should be in a requirements document, or how it should be written. And use cases are a foreign concept to those that are not developers.

So yes, we need requirements. We require them to be able to do our job. But there is no rule saying how to create the document. So let the designer become the requirements document creator, and let the design be the document itself. This is something we can all understand with a little practice.

Tags

requirements opinion