The Importance of project Specifications

A specification is literally the discussion of a specific point or issue; it’s hard in this instance to avoid the
circular reference. A project’s specifications consist of the body of information that should guide the
project developers, engineers, and designers through the work of creating the software.

A specification document describes how something is supposed to be done. This document may be very
detailed, defining the minutia of the implementation; for example, a specifications document may list
out all of the possible error states for a certain form, along with all of the error messages that should be
displayed to the user. The specifications may describe the steps of any functional interaction, and the
order in which they should be followed by the user. A requirements document, on the other hand,
would state that the software must handle error states reasonably and effectively, and provide explicit
feedback to the users. The specifications show how to meet this requirement.

Specifications may take several forms. They can be a straightforward listing of functional attributes, they
can be diagrams or schematics of functional relationships or flow logic, or they can occupy some middle
ground. Specifications can also be in the form of prototypes, mockups, and models.

Examples of Requirements and Specifications Documentation

The following list describes the various kinds formal documents that belong to the body of requirements
and specifications document. These are not all mandatory for each and every software project, but they
do all provide important information to the developers, designers and engineers tasked with
implementing a project and to the quality assurance people and testers responsible for evaluating the
implementation of the project. These topics may also be combined as sections of larger and inclusive
requirements and specifications documents.

-Functional Specifications
Functional specifications describe the necessary functions at the level of units and components; these
specifications are typically used to build the system exclusive of the user interface.

-Design Specifications
The design specifications address the “look and feel” of the interface, with rules for the display of global
and particular elements.

- Flow or Logic Diagram

-Technical Specifications
Technical specifications are typically written the by developers and coders, and describe how they will
implement the project. The developers work from the functional specifications, and translate the
functions into their actual coding practices and methodologies.

Sample Project Specification Document

Distribution List

Members com585 – winter 2007

Contents

1. Introduction

2. Project Objectives

3. Success Criteria

4. Site Map

5. Functional Specification

6. Technical Specification

7. Privacy Policy

8. Content Plan

9. Wireframes/storyboards

10. Marketing

11. Testing

12. Updates and Maintenance

14. Budget

15. Appendix

I. Introduction

This is a working document that is intended to capture detailed requirements and to document
outstanding considerations and questions. The document has been developed through meetings with
key stakeholders and appropriate experts. Subsequent changes to project scope will need to be
approved through formal change control; if approved, they will be incorporated into the project
specification.

II. Project Objectives

What is this project trying to accomplish and why? List key deliverables and dates in this section,
including prototypes or go-live dates.

III. Success Criteria

As much as possible, define what constitutes success. This gives the team yardsticks to measure against.
Some measures for web projects include:

• Lead generation

• Site performance (uptime, lack of errors, lack of broken links)

• Page impressions

• Number of unique visitors

• Cost savings

IV. Site Map

This is a visual representation of the content areas of the site, showing varying levels of content and how
they relate to one another, usually in a navigational hierarchy. The site map could be produced as a
Word document, HTML page, Visio diagram … there is no set format for site maps.

V. Functional Specification

What does the site do? What do I do when I visit? This isn’t why the information or site is here. The
functional specification and site map are two key documents that form the basis for the project.
VI. Technical Specification

What technologies are going to be used (web server, databases, middleware)? What technologies are
assumed as a given for the customers using the site (machine, monitor size/color/rez, operating system,
browser, existing plug-ins)? Security issues and performance metrics. Conformance with ADA or Section
508. This may include information about file naming conventions.

VII. Privacy policy

Some sites specify a privacy policy when they use cookies. Others do so only when they ask for personal
data.

VIII. Content Plan

Some site content is recycled, some non-site content is repurposed, some content is created from
scratch, other content is purchased. The plan outlines who is responsible for the different types of
content, the format that content should be in, who manages the content, deadlines, and who can alter
content (and under what circumstances). The content plan may include a requirement to development a
style guide.

IX. Wireframes/storyboards

Wireframes are page design representations that contain content and functional elements of a page (or
template) without color or graphical embellishment.

• They provide an outline of the design approach

• They define and refine elements that need to go on the page

• They show navigational architecture and information flow – this contributes to user
experience

• They should be easy for anyone to create, distribute and manipulate. As such, they are very
cost effective.

The project specification may detail information as to how wireframes will be developed or when they
will be developed; the actual wireframes are not part of the project specification.

X. Marketing

Who is responsible for marketing the site? How will marketing occur? This may include specifications
about meta tags as well as page titles.
XI. Testing

There are several types of testing: user acceptance, functional, load testing, content proofing, usability
testing, security testing. Testing requirements are outlined here.

XII. Updates/Maintenance

Schedule, responsibility. Will content be updated on an ad hoc or versioned basis?

XIII. Critical Path

Timeline with dependencies. Also include key milestones, meetings, and sign-off points. Be sure to add
contingency time.

XIV. Budget

Developed last and includes all resources (monetary, staff, otherwise).

The person in charge of the project plan should make certain all assumptions about these topics are
articulated and agreed to by all decision-making parties.