f you were to ask my Internet Software QA Manager what the hardest part of training me was, he would roll his eyes and tell you it was the discipline of the testing methodology. I had no trouble learning Rational testing software. I was perfectly fine with communicating between business units of the company. What drove me nuts was the organizing and planning for web sites. Not only this, we had to write it all down into a formal document! Who had the time for that?
I cant express to you how often I thank the IT guys whom I worked with, who would listen to me grumble and then get all giggly with pride when I completed my documentation , test plans, test cases and tons of hours functional testing. Without fail, this slow process of thinking, planning and visualizing details before any ounce of code starts added up to a clean, working, usable end product such as a new web site or proprietary web-based application.
Requirements gathering are something I teach. Ive been laughed at for bringing up the topic to search engine marketers and those new to web design. In a time when you can buy a web site template or grab a free blog template, who in the heck is thinking of details like target market or error message guidelines? And yet, in nearly every case of site testing Im hired to do, there is no site requirements documentation and I can tell. There is more of a chance of target market analysis applied to copywriting and SEO than there are web site requirements used for guidelines, user and functional testing and making sure business objectives have been met. Its difficult to convert traffic to sales when even you havent figured what your web site is expected to do.
Without getting all technical and drop-dead boring on you, Id like to offer some basic help with requirements that you can apply right now and use to make sure your web site isnt going to tank on you. Feel free to adapt this to your own way of doing things. The most important part of this process is to get everyone thinking and working off the same page.
Start with a Parent requirement. The easiest way to think of this is to ask yourself, What is the objective of this web site? or What are the goals we have for this web site? For us now, our example is an ecommerce web site that sells hand-made pet toys, clothing and accessories.
Our Parent Business Requirement is
BR1. Sell hand-made pet toys, clothing and accessories online
BR2. Provide information on our company
BR3. Enable affiliate sales
Other possible business requirements might be offer search, provide services, get sales leads and To inform on [insert topic].
Next, place details under each BR (Business Requirement).
BR1. Sell products online
BR1.0 Add shopping cart
BR1.1 Marketing (SEO)
BR1.2 [insert and list the ways you plan to sell online; i.e. user generated content, social media, weekly sales, coupons, online accounts, etc.]
BR2. Provide information on our company
BR2.0 About Us page
BR2.0.1 Provide bios of staff
BR2.0.2 Presidents message
BR2.3 [insert and list the ways you plan to provide information; i.e. testimonials, blog comments, forums, product reviews, press releases, contact page etc.]
As you can see, this tedious process has a purpose. It helps everyone associated with the project ask questions regarding goals and objectives, as well as determining ahead of time how to achieve these goals. Once its determined you need a shopping cart, someone else can take the lead on researching and recording the requirements needed for it. Do you want the shopping cart to be built in-house? Should it be SEO-friendly? Easy to use? Each of these is a separate requirement if you want it met. If SEO-friendly is not a requirement, then you can incorporate a shopping cart that has no intention of impressing Google.
Other Types of Requirements
In addition to business requirements, it helps to create User Interface Requirements (UIR) and Functional Requirements (FR). I always suggest a section for SER (Search Engine Requirements), which is where search engine marketing, organic search engine optimization, social media and PPC plans are outlined. In my projects, I also add an UR (Usability Requirement) section.
Functional requirements are a programmers paradise. This is where issues like servers, data bases, programming language and error message procedures are made. Why is this important to know beforehand? Consider search engines. If decisions made in this section conflict with the SER section, the end product will have problems such as complicated URL strings that make engines hiccup.
User interface requirements are extremely helpful for creating web site guidelines. In companies where business units or departments each have their own special place on the web site or Intranet, one set of guidelines keeps the entire site consistent. Usability Requirements are where usability, engagability and accessibility decisions are made. By the way, accessibility should be a business requirement for sites that must meet Section 508 or PAS 78 legal requirements.
Documented Requirements are Your Weapon of Choice
Weve all been in situations where a web site project is in development and one-third of the way through someone from management decides to throw in something like videos of silly pets. For our pet example site, this may work, but where does it go? The design has already been worked out. Does the video go on the homepage? Is it used to help market products or is it some crazy it would be fun to have idea? Does it mess with bandwidth requirements? Youll need to bring in your accessibility people to help make it meet accessibility standards. In other words, a flurry of activity surrounds this new stranger, the video. Rather than simply plopping it in somewhere, a requirements document acts as insurance that doing so wont blow up the site or wreck a key objective.
Make sure every item added to your site is traceable to a requirement. Finally, keep testing to be sure requirements have been met. This is typically done by creating formal test documents but you can also write up checklists for things like user interface and SEO to insure everything you wanted done has been accomplished.
Usability consultant, Kimberly Krause Berg, is the owner of Cre8pc.com, UsabilityEffect.com and Cre8asiteForums. Her work combines usability testing with a working knowledge of search engine optimization.
Kim Krause Berg’s long background in web design, search engine optimization and usability includes software application functional and user interface testing, accessibility, and persuasive design. Human Factors and Usability and how it blends with Search Engine Optimization have been her passion for over a dozen years. Kim founded Cre8asiteforums in 1998 and was a self-employed usability and search engine marketing consultant for Cre8pc.com since 1996. In the fall of 2012 she sold her forums to Internet Marketing Ninjas and retired from private consulting to join their Executive Management team where she continues her work in usability and persuasive design in her role as Usability and User Interface Analyst.