The Importance of Specs

Nov 1, 2004 12:00 PM, By Don Sturgis

Testing Physical Security The Importance Testing a physical security system at various stages of installation ensures that the user's functional requirements have been met.

So-called “testable specifications” contain enough detail about the user's functional requirements to allow tests to be devised to prove they have been met.

A testable specification is one in which the requirements can be verified or tested by operation and/or observation of the system. It must be written in specific and unambiguous terms using measurable quantities.

However, having testable specifications is of little value unless the specifications are relevant to a user's objectives.

What is a specification?

Many physical security systems have been and are still being purchased and installed according to architect and engineering (A&E) specifications conforming to the Master Format standard as created by The Construction Specifications Institute.

Construction specifications typically indicate products by brand name, model number and indicate the quantities of parts required.

Most major access control systems manufacturers have available an A&E specification that describes their system in CSI format. The words “or equivalent” normally appear several times in the specification seemingly to make it possible for bidders with other systems to respond. However, in practice these specifications often describe features that are unique to the named product in hopes of keeping bidders of competing systems from being fully compliant.

Although it is possible to include functional requirements in a CSI format specification, manufacturers cannot because they do not know a user's functional requirements. Thus, many security system projects (especially for new facilities) end up with a list of product features and equipment for a specification, including items like a 2.4 Gigahertz processor, 2 Gigabytes of RAM and two 80 Gigabyte RAID disk drives.

Such specifications are often referred to as engineering specifications, which describe how to build something. Functional specifications describe what the system needs to do. It makes sense to figure out what one wants something to do before deciding how to build it and what to build it from.

From a historical perspective, it is easy to see why most security system specifications are engineering specifications. The functionality of early alarm and access control systems was so simple that it needed no functional specification. Early security system specifications were a list of sensors that would trigger alarms, a list of doors and gates for readers, and the maximum customer-required capacity of the systems (such as 100 alarms, or 500 cards).

Today's computer-based and networked systems require significant setup work. The systems must be configured to determine what functionality will be activated.

Project options

A functional specification provides more ways to approach a project. Hiring a consulting engineering firm to design the system based on functional specifications will allow the user to seek bids from firms bidding to the same engineering design, thus simplifying the procurement process. Alternatively, one could provide the functional specifications to firms and ask them to provide a design/build proposal. This approach allows each firm to tailor a system (and the project) to specific needs based on the advantages of the firm's product lines and project team capabilities.

Functional specifications provide users with a strong basis for evaluating proposals, as well as for testing the system. Typically the larger the project, the longer the project will take in all of its phases, including procurement. Starting a project with only an engineering specification will lock the user into the specified technology even though it may soon be outdated. A functional specification provides a bottom-line list of requirements against which newer technology can be evaluated at a later time. A vendor can recognize an opportunity to add value to a project using new or alternate technology that supports a user's functional requirements.

Functional requirements

To support testing that is relevant to the user, the functional specification should identify system conditions or capabilities based on the needs and objectives of the user, which should also be identified in the specification. The user's needs and objectives can be placed in an introduction, an overview, throughout the specification where appropriate and in scenarios and other appendix material.

With the user's needs and objectives in mind, a functional requirements specification should:

• list the necessary requirements (including essential functional capabilities, physical characteristics, performance and capacity requirements, system usage scenarios and constraints);

• be concise, unambiguous, and easy to read;

• not specify how requirements are to be implemented; and

• define feasible requirements in verifiable terms.

This type of specification has advantages because it provides a clear understanding of what functions are required and how they can be easily tested. It simplifies testing because the document indicates how the system should perform.

Essential functional capabilities

A functional specification does not need to include every detail about the system. It should focus on the functions that are essential to how the system will be used. What is required should be stated — rather than how the requirement should be met. Requirements should not indicate a particular design or implementation, unless a user's needs specifically call for it.

Card and reader requirements

For a new access control system, card technology is a key aspect. What type of technology can or should be used depends on functional requirements. Will the same card be used for physical access and information system access? Will biometric information be on the card, instead of in a central repository? These functional requirements may limit or determine the choice of card technology.

Specifying functionality

If the choice is using a smart card or a proximity card, it is not specific enough to specify “hands-free access.” Instead, the measurable constraints that are important should be listed, such as:

• For all internal office doors in hallways, the reader shall capture the card data (read range) when the card is no less than __ inches from the reader, and no more than __ inches from the reader.

• For all building entry and exit doors, the reader shall capture the card data (read range) when the card is no less than __ inches from the reader, and no more than __ inches from the reader.

• All readers shall be located on the unhinged side of the door (the side of the door with the handle) no more than __ inches from the door handle (knob).

• All readers shall be mounted no higher than 48 inches from the finished floor to be in compliant with American Disabilities Act (ADA) requirements.

Although such details may seem to have the flavor of engineering specifications, they ultimately specify what the user wants the system to do. Descriptions facilitate test design by providing information about how the system should act and why.

Language should be specific in describing what the card and reader shall do. The phrase “A valid card shall unlock a door” might suggest that each card can unlock every door. A more acceptable phrasing might be “When a valid card is presented to a reader to which the card has been given access the door shall be unlocked.” The following phrase would be even better: “A valid card shall unlock a door to which the cardholder has been given access, when presented at the door's card reader at a date and time when access is allowed.”

Note that terms like “valid card” should also be defined in the specification to avoid misinterpretation. For example, a “valid card” is a card assigned to any person who is currently authorized to have access to some or all of the areas controlled by card readers. This cardholder must be listed in the current database as a currently authorized cardholder. A “valid door” is any door that a specific valid cardholder has the authority to have access to. A “valid day” is any day of the week (Monday through Sunday or specified holiday) that a specific valid cardholder has authorized access to a specific valid door. A “valid time” the defined time interval (e.g. 0800 to 1700) or intervals (e.g. 0700 to 0800, 1130 to 1300 and 1700 to 1830) that a specific valid cardholder has authorized access to a specific door.

This chart on page 32 provides an example to guide the development of verifiable tests.

The requirements should state how the system will respond to access attempts, in terms of performance and information. Should the reader make one sound for access granted and a different sound for access denied? Should LED lights indicate access denied or granted?

All of the specified conditions should be verifiable by testing. The specification language should be clear as to the functionality required, and should support testing whether or not the requirements have been met.

Video requirements

In the case of video coverage, the specifications should include or reference maps or drawings of the facility and note the areas that need to be covered. Users should provide information such as the type of perimeter fencing and lighting conditions for each area, and should be specific as to what the system needs to do.

An example: The northeast quadrant is bordered by a chain link fence approximately 100 feet from Building A. Except for public street lights every 200 feet along the fence there is no other lighting. The system shall detect any human intrusion into the area between the fence and building, and shall not interpret small animal movement (such as cats, small and large dogs, or birds) as intrusion. The system shall notify the operator of the intrusion by an audio signal and alarm message on the system monitor.

This example shows the value of functional specifications. If the only specifications for a project specified the type and location of the cameras and the types of lenses to be used, the system would have to be accepted based upon inspection of the installed equipment, regardless of whether or not the customer could use the cameras for the intended purposes.

Compatibility with existing equipment

One place where a functional specification should get technical is with regard to the support of existing equipment. The specification should state that the existing devices shall be supported and list the specific makes and model numbers in an appendix. However, even for the support of existing equipment, it is not sufficient simply to list the equipment alone. What function that equipment is intended to perform in the new system should also be stated.

Security scenarios

Security scenarios (for both security normal operations and security incident or emergency response) are an important element in developing functional specifications, and should be included as an appendix to the specifications document. A security situation may require a set of security features to work in combination or in a particular sequence. Security scenario tests — in which one tries to use the system exactly as he would to respond to an incident — will check those capabilities of the system.

FOR THE RECORD

About the Author

Don Sturgis, CPP, is a senior security consultant for Ray Bernard Consulting Services (RBCS), a firm that provides high-security consulting services for public and private facilities. This article is excerpted material from the upcoming book The Handbook of Physical Security System Testing by Ray Bernard and Don Sturgis, scheduled for publication by Auerbach Publications in the spring of 2005. For more information about Don Sturgis and RBCS, go to www.go-rbcs.com or call 949-831-6788.

A CLOSER LOOK

Verifiable Tests

CARD TYPE	VALID DOOR	DAY & TIME	TEST RESULT
Valid Card	Valid Door	Valid Day & Time	Unlock Door Report Valid Access
Valid Card	Valid Door	Valid Day, Invalid Time	No Lock Action Report Access Denied
Valid Card	Valid Door	Invalid Day, Valid Time	No Lock Action Report Access Denied
Valid Card	Invalid Door	Any Day & Time	No Lock Action Report Access Denied
Invalid Card	Any Door	Any Day & Time	No Lock Action Report Access Denied

Want to use this article? Click here for options!
© 2008 Penton Media Inc.

This month in Access Control

• Opening Up About Door Closers
• An Enterprise Approach
• The Framework For Open Systems
• On A Higher Plane
• More from April's issue