How to build a web page - SES Magazine

1. Lecture Notes – How to Build a Web Page: Requirements – Prepared by Sukh
Sandhu
Page | 1
This was originally published December 2009 in SES Magazine.
Items to Include in Detailed Requirements Documentation
Requirement Acronym Accounts for
User interface UIR includes IA, design,
requirements fonts, images
Search engine SER SEO, PPC, SEM, and
requirements linking
Social media SMR blog, forums, social sites
requirements
Usability and UAR usability heuristics,
accessibility mobile, Section 508, PAS
requirements 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:

2.  BR4.0 Sell online
 BR4.1 Shopping cart
 BR4.1.1 Custom cart
 BR4.1.2 SEO-friendly
Page | 2  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

3. 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
Page | 3 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.