BlogIco Rss

Use the sidebar to search through our blog, it's really helpful.

Jonathan Kelly

Spec It Out: Remove Ambiguity

by in Development on Apr 22, 2009

We are firm believers in not only planning your work, but also working your plan. If you need proof, checkout what Brad has to say about our process, James on sketching first or Joel on setting up Expression Engine. When it comes to web development for clients, the specification and documentation process or “spec,” is as much a cornerstone as any for a successful project. That little gem of the left-brain logic tells us that we have to know what we are building before we build it. So in that rare occurrence when we get lost in technicalia, we have that road map to constantly refer to along the way.

Why Spec?

Every now and then, there will be a project that requires feature or scope changes well into the process of development. If there is no specification developed during the planning phase, it will be hard to determine how the changes affect budget, time frame or deliverables. The presence of proper specification is an indicator of a proactive posture, and the lack of specification is an indicator of a reactive posture. Also, the specification phase must always precede the development phase. That isn’t to say that during the development phase changes to the spec will not occur - they most likely will. However, we must be wise and methodical about how we change the spec and ensure that all stakeholders understand the implications of such changes.

What Spec Entails

So now we know we need a spec. How do we go about getting one? What does it look like? Well, it depends on the type of development project.

A Functional Specification document for a 10-page mobile WAP will be quite different from the specification document for a 120-page website. For example, the WAP doc may talk more about usability while the website doc may talk more about granular functionality of features. Both are appropriate for the respective project. But if the reader is left with questions about how the website or application will operate after reading the spec, then the document probably needs to be revisited. And I’m not talking the type of granularity that goes so far as to mention every link and where they go. That would breed insanity for writer and reader!

For most website projects, our process involves sitting down with the design and development team and working through the sitemap and wireframe to identify what features are on a page, how those features function and how they are administered.

OK, Show Me How It’s Done

Enough of this abstract speak. Let’s look at an excerpt from one of our recent specs:

Feature

The blog content will be further divided and set apart visually into the following sections:

  • Headlines
  • Cover Story
  • Members Posts
  • ...

Each blog section (category) will feature HTML content.

The user will have the ability to submit a comment in response to any of the blog postings, in any blog category. Each comment will be submitted into a database and kept in a queue until an administrator has approved the comment. Upon comment approval, the comment will be displayed on the front-end website along with the associated blog entry.

The user will have the ability to navigate through the blog by selecting a category. Once a category is selected, the user can then further navigate by sorting by author and date. The user can also navigate by date to view archived blog entries.

A search feature will also be present in the blog area at any level. E.g. the search will be available before a category is selected, after a category is selected or even when the user is viewing an individual blog entry. The search will allow the user to enter a keyword phrase, as well as select optional search parameters of author, date range and category.

The commenting form must contain some sort of anti-spam technology, such as a CAPTCHA, hidden input, etc. The form must also have client-side and server-side validation for required fields.

Administration

  • Ability to add, edit, delete and sequence blog categories.
  • Ability to upload a graphic for each blog category. This graphic will serve as a banner/badge to represent the category and will be displayed in a scalable, dynamic space within the blog area.
  • Ability to view, edit, approve or delete submitted comments.

Thoughts?

« Newer Article

Older Article »

  • You have a very nice website that is very informative on website development.
    And I also agree about what you said about ry now and then, there will be a project that requires feature or scope changes well into the process of development. If there is no specification developed during the planning phase, it will be hard to determine how the changes affect budget, time frame or deliverables. The presence of proper specification is an indicator of a proactive posture, and the lack of specification is an indicator of a reactive posture
    Thanks for the info.
    Rick

Sorry! This entry is no longer accepting comments.