Standards and Protocols
Please note: this page and its content were significantly changed on 09 Jan. 2000. I decided not to archive the old version of the content because the new page represents a significant improvement.## The Importance of Standards and Protocols
Just like requirements and specifications define what a project is supposed to accomplish and how it is supposed to be accomplished, standards and protocols provide instructions for the implementation of a project. Standards and protocols, however, are often implicit instructions. Requirements may not always say that a project must be completed in accordance with a certain standard -- this compliance is often assumed in much the same way that an American company may not specify that a report be written in English. Standards are frequently the rules of a profession or field, and protocols are typically the instructions and tools.
[Learn more about requirements and specifications.]
Standards
A standard is an agreed-upon way of doing something or measuring something. For example, a quality assurance team should work from an established standard of quality appropriate to their work and projects. Such a quality standard might specify that there must be no broken or bad links, or that individual page weights must fall between 10k and 50k.
Some standards are widely followed, such as industry-wide standards. The ISO (International Standards Organization) provides a wide range of standards that ensure -- when companies meet and pass the various accreditations and enforcement programs -- consistent, predictable and verifiable levels of compliance and quality. This means that one participating company can be sure that some part X will work with their own part Y. If you have ever experienced a compatibility failure, you'll understand how truly marvelous standards compliance is.
Some standards are open, which means that they were determined and defined by an industry consensus. Other standards are closed and proprietary, which means they were created by a company, and then came to dominate the market because of the success of that company's products.
Other types of standards include benchmarks and style guides, and are usually limited in scope to your projects.
Benchmarks for web sites are standards that specify what kind of user the site is designed for. You must decide which level of HTML you'll use; this is important because not all tags are universally supported across all browsers, many aren't even displayed the same by all browsers. Client side scripts have the same issues, with different browsers supporting different object models for programming behavior. Connection speed is important for the user's experience downloading graphics: the more graphics, the longer your pages will take to display. The benchmarks you code and design for will tacitly exclude sectors of the viewing audience from your site; your challenge is to understand whom you are excluding, and to decide if you will accommodate these users with alternative functionality.
A style guide describes the voice of your site: is it a formal site, with technical jargon and dense prose? Is it a friendly, informal site? Is the web site a company's corporate presence on the web? Your message will suffer if you haven't defined a consistent voice.
A style guide defines the "look and feel" of your site. Are your headings capitalized? Do you use a particular type face and font size for text graphics? Do interface graphics have to be a specific size? These are the kinds of things you need to document.
[Learn more about style guides.]
Protocols
Protocols are rules governing communication between devices or applications, and the creation or manipulation of any logical or communicative artifacts concomitant with such communication.
The Internet and web are built on a slew of such protocols, including:
- hyper-text transfer protocol (HTTP)
- file transfer protocol (FTP)
- transmission control protocol / internet protocol (TCP/IP)
- secure sockets layer
Protocols like these provide the backbone instructions for moving information around the Internet and web. Compliance with and support for common protocols is expected, but may not be specified in requirements documentation.