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