Prior to the creation of something as potentially complex and ubiquitous of a website, an analyst must create a thorough, precise set of requirements in consultation with the right subject matter experts and business stakeholders. But unless one is armed with the proper planning procedures and techniques, the prospect of creating requirements for something as vast as an online business presence or functioning e-commerce system (or both) can be intimidating. The following considerations are worth examination as an analyst goes through the process of website requirements creation and can potentially save time and costly mistakes.
Similarities and Differences from Other Types of Requirements Projects
Website requirements are similar to other types of system requirements in that you use many of the same tools to discern them: focus groups, user interviews, surveys, and prototyping and visualization tools are especially useful for websites. Prototyping in particular can be enormously useful in evaluating websites for missing requirements. According to Karl E. Weigers in Software Requirements, prototypes can reveal missing or unnecessary functionality, unaddressed error conditions, poor navigation, and more 1. Often equally or more helpful than prototypes are requirements visualization tools such as wireframes, UML models, and mock-up screens.
Also, while many requirements projects involve numerous phases of implementation, this approach is almost always essential in website design. Prior to any website launch, consider a Beta phase in which you recruit a select audience to use it. Once this sample group has a chance to “test-drive” the new features, you will likely get some feedback that no one thought of in the discovery and development process. Therefore in your requirements planning, it may make sense to build in several phases for evolving prototypes or mock-ups, another phase for a Beta launch, and a final phase for the real site launch.
Websites are different from other types of system requirements in that the marketing team may be more involved, and graphic designers may play just as key a role as developers and engineers. With the exception of internal websites, most are public facing. For internal websites that focus more on function than form, the process may be more similar to the traditional requirements gathering route.
Key Considerations
You will want to weigh the following features in concert with your stakeholders to see what direction to take on some of them, and whether the others are even legitimate needs for your company. However, before you can weigh these, you must know what the key objective of your site is. In her article “Website Requirements,” Kimberly Krause Berg notes key questions that an analyst should ask business owners: “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 Website?” 2
Additionally, a crucial consideration to website requirements is the ongoing concern for audience design. When it comes to websites, your requirements must be wed to marketing, because you’re writing requirements for audience needs. Is your audience fairly technically savvy? You can include more advanced features? Scholarly? You can include academic features such the ability to customize and run reports, for example. For an audience of mostly women, consider more feminine colors and features. For an older audience, consider larger font sizes, and so on. If your site will have an audience with multiple types of demographics and needs, you may need to write a subset of requirements for each group in order to create a smooth user experience.
Another consideration to keep in mind is device requirements. Where and how will this site be primarily accessed? Will your audience(s) be viewing it on their phones or mobile devices so that everything must be simple and clean, or is it an intranet site used in-house that will be primarily accessed on computer by people who are already familiar with most of the content? The latter type of scenario would also more easily lend itself to large, slower-loading files such as video or large graphics.
Once these business questions are answered, more granular details of the user experience, such as the key features below, can be examined. Some of the following features may be of more interest to your business owners and marketing team than to software developers. In putting together your stakeholder list, be sure to include current and potential customers who likely to be strong leads in helping you discern what is truly needed.
-
Graphic design and layout – As we mentioned above, when a site is customer-facing (or even if it’s not), prototyping can be essential in helping everyone envision exactly what to expect of the final product. A working prototype also reveals when a site may be visually appealing but not functional or easy to navigate.
-
Ease of update (content management system available for business owners) – If the person who drives the site’s content is someone other than the software developer, and updates will be frequent and/or time-sensitive, a content management system must be built in. Discerning which type is best and what its features should be may require a set of requirements unto itself.
-
Log-in/security/rights-based contributing – If the public is permitted to contribute to the content via blogs or other forms of social media, or if the site’s information is sensitive, authentication prior to contributing or updating content is essential. It may also be useful to track changes based on user/IP address so that developers can track who contributed what.
-
E-Commerce – If the site will enable customers to do shopping, a host of ancillary features must be honed and polished for ease of use, including tracking items in a shopping cart, the check out process, debit or credit card processing, and the calculation of shipping charges and local taxes.
-
Site Map – While the site that’s being developed may be involved and complex, a flat view of it should still be logical. Even if business owners decide not to include a customer-facing site map, keeping an updated one as part of your requirements may be useful in helping everyone to see what’s available at once. As one article advises, “Create a Site Map Diagram based on usability requirements to depict the website’s optimal navigation and organization.” 3
-
SEO copy – This involves key words that should be included in the site’s content to ensure a higher ranking from search engines. The marketing department is likely to be heavily involved; in fact, SEO may sound like more of a marketing consideration than a requirement. But to quote Berg, “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.” 4
-
RSS features – If your site offers frequently updated information, you may want to ask stakeholders to consider an RSS feature, and research what’s involved with popular RSS tools.
-
Blogs/Chatrooms/Social media – The inclusion of social media ensures a more involved audience, but it also necessitates more involvement from your company’s personnel. Someone will need to monitor these for appropriate content, spam, and other security breaches.
-
Video – Videos can take up a lot of site space, unless the business owners simply post the videos to a site such as YouTube and send visitors there. In these cases, a legal consultant may need to be involved.
-
Data/Security encryption (SSL) – Leaving something this essential for e-commerce sites out of your requirements would be disastrous. SSL (easily discernable by the https in the address bar) helps ensure that customers’ financial data remains secure.
If your stakeholders elect not to include some of the above features in the site, it may save time to note the reasons in an exclusions section of your requirements (i.e., EX-1: Social media features will not be included in the initial release since we lack the personnel to monitor the content. For details, see 4.21.10 meeting notes on the intranet). This will help stakeholders remember why something was not included, and save time in examining the feature again.
In addition to the above considerations (the inclusion or exclusion of which will create a certain type of user experience) you will want to consider the equally crucial site performance and security. The following technical or functional requirements will be essential to your programming colleagues.
-
Expected traffic and hits – This will dictate how much bandwidth should be allowed for the site, along with other consideration.
-
Analytics to track site visitors – Measurements of this type enable business owners to judge the extent of a site’s reach—how many unique visitors come, how long they stay, and where they go and what they do while there.
-
Back-ups – The frequency and type of back-ups will affect not only the site’s security, but may affect its performance when back-ups are performed. These considerations may need to be weighed in concert with both business owners and the technical team.
-
Section 508 – You may also want to ask business owners if they want to make the site Section 508 compliant, ensuring that it meets or exceeds government standards for accessibility to the disabled.
Templates to Get Started
If you’re getting started on your first set of website requirements, or just looking for ideas to improve your current approach, a number of useful website requirement template documents are available. Samples of just a few templates are included here http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html and here http://www.gtms-inc.com/webrequirements.htm.
Website requirements bring their own host of benefits and concerns, each of which warrant the judicious application of existing tools in your analyst arsenal (prototyping, survey, focus groups, brainstorming, and so on—your project and stakeholder mix will dictate the proper tools). Once you try your hand at website requirements a few times, your technique will evolve and improve for the better, much like the evolution of website design itself.
Author: Morgan Masters, Business Analyst, Modern Analyst Media LLC
Morgan Masters is Business Analyst and Staff Writer at ModernAnalyst.com, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at http://www.ModernAnalyst.com
1 Weigers, Karl E. Software Requirements, Redmond, Washington: Microsoft Press, 2003. p. 242.
2 “Website Requirements: What to Include,” by Kimberly Clause Berg. http://www.clickz.com/3635934
3 “Website Design,” http://www.usabilityfirst.com/about-usability/website-design/
4 “Website Requirements: What to Include,” by Kimberly Clause Berg. http://www.clickz.com/3635934