Websites & Mobile Apps
Welcome to the Learning Center
Our Learning Center offers a single place where CEO's, senior executives and managers can learn everything they need to have a more meaningful conversation with their technical advisors.
Web Development Topics
A specification, or ‘spec’, is one of the most critical elements in any development project, whether an extension to your home, a new website, the design of a new brochure or a back office data processing system. In fact, whenever a project falls behind schedule, goes over budget or spins completely out of control, this is almost always the culprit.
Stripped down to its essentials, a spec is a statement of your requirements. If the professional(s) you employ don’t know exactly what you want, you’ll probably get something else. When you see the result, you’ll probably complain, and ask for it to be fixed. Your vendor will be unhappy, and probably rush through the changes, since they will put the project over budget and behind schedule. Depending on how severe the misunderstanding, this often becomes a recipe for disaster.
Unfortunately, on a complex project, the spec can sometimes be a bigger effort than the project itself, if you really want it to include all of the pertinent detail. Architects pretty much do nothing but specs, and you have to employ their services in order to get a building permit. Before a builder orders material, the architect will prepare detailed plans for the project, so that the workers know exactly what to do, and don’t build the wrong thing.
System developers sometimes do a poor job with specs (maybe we need the equivalent of a municipal buildings department), and that is why IT projects are notorious for being late and over budget. There are two reasons why this is so prevalent:
Also, a spec for today’s websites and interactive, web based systems tends to be very complex, because nothing is fixed. The behavior of the system, and even the layout of the pages, changes with every keystroke or mouse click.
In order to address these issues, multiple approaches have evolved for handling the systems requirements process, and no one approach is perfect for every project. The traditional approach to systems development was to define each screen, each menu item, each item of input data, each item of output, and every calculation in between. This typically led to a long document, which could easily run into hundreds of pages for a mid-sized project.
At the opposite end of the spectrum is ‘agile methodology’. The client sits down with the developer and discusses his or her project. The developer then creates a small, somewhat functional prototype for the client to interact with. Through an iterative feedback process, detailed requirements evolve as the project proceeds. Agile methodology works best with a flexible development platform, such as Ruby on Rails, YII or ZEND, that relieves the developer much of the detailed infrastructure code that might otherwise be required on the project. With this type of development platform, much of the tedious work associated with requirements changes is eliminated.
Programming projects are largely concerned with data, whereas websites projects are more concerned with content and layout. As a result, the requirements process is a little different as well. Also, today’s websites generally include some form of CMS (Content Management System) that allows content to be updated by the client, without the involvement of a developer.
While each development firm may have their own requirements process, the best of them will include, as a minimum, either wireframes or sketches (or both), depending on the scope and complexity of the project. There should also be a detailed sitemap, and a specification of any dynamic behavior and data handling functions.
The need for a sound requirements process is no less important with either agile development or web projects than with traditional methods, it is just handled differently. Before you retain any professional for a systems project, you should take the time to understand their methodology, since you will be part of it. After all, the purpose of the requirements process is to ensure that the final project reflects the vision of the client. It is your way of getting what you want while minimizing unnecessary rework, and keeping control of the project schedule and budget.