The Technical Requirements Specification (TRS) in Web Projects
By Katy Whitton
The Technical Requirements Specification (TRS – Also known as a Functional Requirements Specification) scopes out all aspects of the project, from what platforms the website will run on, whether users have to have cookies enabled, down to databases, site and database architecture and testing methods.
Basically, anything that’s not in the TRS isn’t in the web project.
The advantages of this are:
- You don’t do unnecessary work outside the scope of the project.
- You know what you have to design and build for.
- If anything needs to be changed it’ll cost the client.
- As they’ll have to pay for the changes, the client may decided not to go ahead or put it off for a while with a “Wait and see if it crops up” attitude.
What you’re doing is covering your back so that change requests don’t start creeping in at the last minute and you end up building a CMS driven site when it was supposed to be 2 pages of static HTML.
The rule of thumb is the more complicated the site, the more complicated the TRS as you’ll need to cover a lot more aspects in-depth in order to cover all of the bases.
It also depends on the company; Joe Bloggs 1 man band probably won’t be too interested and will just sign it anyway but a Fortune 500 company will want to see exactly what they’re getting and how it will work written down in exact detail and then change it (and change it, and change it) until they get what they think they want.
Below is a listing of all of the specifications I’ve used in the past. This will cover all levels of websites so feel free to pick and choose those most relevant to you. However, note those with a star next to them as these are the ones I feel are fundamental parts of the TRS.
- TRS Version Number*: This may sound trivial but when you’ve been through 30 revisions and the client says, “Oh, that bit in version 6 about the widget is missing” at least you know which document they’re talking about.
- Purpose of the site*: What will it do? Who is it’s target audience? What’s the aim of the site?
- Browser Compatibility*: What browsers does the site have to work on?
- Operating system Platforms*: Different OSs do different things with code (thanks Microsoft), also different companies use different platforms (often weird or old ones), which is important to consider if you’re developing an Intranet.
- Site Breakdown*: This section lists each of the main areas of the site and the pages associated with them. There are many ways to present this but I prefer to do it visually using a site map.
- Section Breakdown: Here you list each section in turn, the pages within the section, their components and functionality.
- Databases and structure: This is definitely needed if you are using a database. This section outlines the type of database(s), tables within the database(s), field names, field types and lengths.
- Testing*: Firstly set out what browser platforms/operating systems you will be testing on (this should ideally match the requirements set out in sections 3,4 and 5). In the testing section you’d list all pages and the requirements you are testing against. If this is quite a large section you may wish to move it to a separate document and reference it here.
- Server details: It may not be necessary to inform the client of the location of some servers and their passwords, but having the details all in one place makes for a handy reference tool. You may also wish to list server platforms, processors, hard drive space, ram etc. here if the project warrants it.
- Backup System: Details of how, where and when any data will be backed up, who is responsible for the backups (e.g. an external supplier) and data protection notes would go here.
- Revisions List: This is useful to keep track of changes to the TRS, when they were made and who made them.
- Client Sign-off: This is where you and the client sign the document to show that you’re both happy with the TRS and the site’s functionality/components.
Other things that you may consider putting into your TRS can include:
- Deliverable dates/milestones/phases (may also be set out in the contract)
- Definitions of terms used (abbreviations, acronyms etc.)
- Documentation to be provided (help file text etc.)
- Location of work (e.g. your office, onsite at the client office)
- Expected costs (stock photos, travel etc.) (May also be set out in the contract)
Budget breakdown (may also be set out in the contract)
- Style Guide (if this is a large section, it may be better as a separate document)
Once everyone is happy with the TRS, you’re almost ready to begin work on the actual site but first you need to consider staff, which I’ll cover in the next post.
Katy Whitton has over 10 years of experience in dynamic website creation, e-commerce, database integration, accessibility, usability and project management and has worked with a variety of clients including Cable & Wireless, NATS, Ribena, Wourburtons and The British Dental Journal amongst others. She also run a successful blog which discusses productivity, motivation, project management, web development and whatever else takes her fancy!
After becoming Senior Web Developer and Maintenance Manager she decided to change directions and worked for a series of startups managing their website design and build from start to finish and now works for a large multi-national Printing and E-Commerce company.
For more information about Managing Web Projects and for your free sample chapter, please visit http://www.managingwebprojects.net/.