Web Site Requirements: What to Include

  |  December 7, 2009   |  Comments

A cohesive site requirements document will spell out, in detail, how to write content for searchers, how to optimize for engines, and how to display media to sell a product.

Football might seem to be a clumsy game where men run up and down a field. But we cheer touchdowns because we like to see a well-executed plan that's the result of extensive research and planning. Players study film, practice drills, and test new strategies. The same process is part of Web site development. Successful sites are well-planned, documented, and executed. Web developers and designers study their competition and come up with a solid foundation. It all starts with a requirements document.

Items to Include in Detailed Requirements Documentation
Requirement Acronym Accounts for
User interface requirements UIR includes IA, design, fonts, images
Search engine requirements SER SEO, PPC, SEM, and linking
Social media requirements SMR blog, forums, social sites
Usability and accessibility requirements UAR usability heuristics, mobile, Section 508, PAS 78

Business and Functional Requirements First

Typically, the requirements gathering phase of a Web design is performed by your team as you gather around a whiteboard or conference call. The leading business requirements are laid down first. Is the site an e-commerce site, directory, blog, or informational site? What do we want the site to do, and why? What do we need to create a successful Web site?

Top-level requirements are called parent requirements. They anchor the site's plans. Your team discusses all the goals, no matter how big or small, for the site. There may be several business requirements, such as "provide services," "get sales leads," or "to inform." Parent requirements are broad strokes that are later more fully defined.

Along with business requirements, the other set of parent requirements are functional requirements. This is your programmers' domain. Functional specs refer to technical, server, and application issues, and are typically derived from use cases, mental models, and user personas. Functional requirements determine guidelines for browsers, operating system, accessibility, bandwidth, performance, platform, mobile use, and programming choices.

The process of gathering information at the start of your project helps many members of your team throughout the development cycle. This includes those who create the information architecture, those who do QA testing, and the sales department. A final requirements document can be used to create test cases to ensure every requirement is met.

The Forgotten Requirements

Let's look at this example of business requirements for an e-commerce Web site:

  • BR4.0 Sell online
  • BR4.1 Shopping cart
  • BR4.1.1 Custom cart
  • BR4.1.2 SEO-friendly
  • BR4.2 Marketing
  • BR4.2.1 User-generated content, social media, weekly sales, coupons, online accounts, etc.

The process of writing down all the desired elements can be a painstaking exercise. In the example, everything is traceable back to "BR4.0 Sell online." The shopping cart is intended to help, but there is a requirement for a search engine-friendly one. One option is build a custom cart. If that is agreed upon, a separate set of functional requirements are written just for the cart. Every requirement and every guideline is traceable to a parent goal. Any time someone wants something added that can't be traced to a business requirement, it is not included.

Very few companies consider marketing or usability at the earliest stages of development. But what about "BR4.2 Marketing" from our example? To meet the user-generated content needs, team members will need to confer with those who are determining functional specs, which include the kinds of software applications that can be used for comments and customer ratings.

Organic search engine optimization (SEO) and search engine marketing (SEM) are not typically applied to requirements documentation, but they should be, so that certain techniques - such as how to structure title tags or guidelines for link labels - are worked out in advance. A business requirement may be "BR6.0 Be found in search engines."

Most site owners take this for granted and don't begin the process. A requirement for SEO can be broken down into functional requirements for on-page optimization as well as details like robot.txt. When every piece is documented, anyone can go through the site at any point to test for compliance.

Critical Breakdown

When approaching the discipline of requirements gathering, it's imperative that all stakeholders from each area of the development process are communicating. Of equal importance is testing during the development phase to make sure requirements are met and there are no conflicts.

For example, a search for "leather fringe boots" displays several search results. One result is a boot with no fringe. Did the page have incorrect content on it? Or, was it the right boot but the wrong images? Why were the photos not showing the boot properly?

A few things could have occurred. There may not have been a requirement for specific title tags and page titles. There may not have been a requirement that all images be shown at all angles. It's likely that there is no requirement that covers searcher behavior. This is closely tied to usability. A cohesive document will spell out how to write content for searchers, how to optimize for engines, and how to display media to sell a product.

Requirements documentation is a group exercise. Who is the site for? How will you meet user expectations, including searchers? Written Web site guidelines, based on the site's requirements, determine design consistency, site maps, and mockups.

If your main goal is to sell products, do you showcase some of them on your home page? Are product pages optimized for search engines as landing pages? Search engines are unable to deliver site pages the way you want them presented without first including SEM into the overall requirements documentation. This means that every element on the page has to meet criteria traceable back to business and functional requirements, as well as meeting supportive requirements such as marketing and SEO.

This was originally published December 2009 in SES Magazine.


Kimberly Krause Berg

Kimberly Krause Berg is the owner of UsabilityEffect.com, Cre8pc.com, and Cre8asiteForums.

Kim launched Cre8pc.com in 1996, offering search engine optimization and web design resources gathered and tested while working as Webmaster for a technical magazine publishing company.

She was in charge of web design and also getting 13 web sites registered and ranked in search engines. As she moved forward in her career, she freelanced from home in search engine optimization (SEO) and web site building under the Cre8pc domain. In 1998 she started the Cre8pc Website Promotion Club in Yahoo! and co-moderated the Home and Small Business Club, where she gained a reputation for helping people and making SEO and Marketing easy to understand.

Hired by such companies as Unisys and Verticalnet, Kim worked as a User Interface Engineer and eventually moved into the Quality Assurance Software Testing field, where it was her job to test and develop the methodology for in-house web site usability.

COMMENTSCommenting policy

comments powered by Disqus

ClickZ Today is our #1 newsletter.
Get a daily dose of digital marketing.



Featured White Papers

2015 Holiday Email Guide

2015 Holiday Email Guide
The holidays are just around the corner. Download this whitepaper to find out how to create successful holiday email campaigns that drive engagement and revenue.

Three Ways to Make Your Big Data More Valuable

Three Ways to Make Your Big Data More Valuable
Big data holds a lot of promise for marketers, but are marketers ready to make the most of it to drive better business decisions and improve ROI? This study looks at the hidden challenges modern marketers face when trying to put big data to use.