Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to build a web page - SES Magazine


Published on

How to build a web page - SES Magazine

  • Be the first to comment

  • Be the first to like this

How to build a web page - SES Magazine

  1. 1. Lecture Notes – How to Build a Web Page: Requirements – Prepared by Sukh SandhuPage | 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 sites 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 Lets look at this example of business requirements for an e-commerce Web site:
  2. 2.  BR4.0 Sell online  BR4.1 Shopping cart  BR4.1.1 Custom cart  BR4.1.2 SEO-friendlyPage | 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 cant 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 dont 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, its 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. Its likely that there is no requirement that covers searcher behavior. This is closely
  3. 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 sitesPage | 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.