7.3 Operational, Functional, Performance Requirements, Codes & Metrics

Operational, Functional, and Performance Requirements, Codes, and Metrics

Independent OpenExamPrep teaching for published PSP Domain 2 Task 1 knowledge is that a design is not a pile of model numbers. It is a set of requirements you can explain to an owner, an architect, an installer, and later a tester. PSP-style work sorts those sentences into operational, functional, and performance requirements, then lets codes, standards, and guidelines constrain them, then names success metrics a field test can score.

Exam focus: Same door, three different sentences. Cameras have detection, recognition, and identification capacities. People are a countermeasure. Codes are inputs, not a substitute for residual risk.

Operational requirements: policies, procedures, and staffing

An operational requirement describes how the organization will run the measure: who is present, what procedure they follow, which policy they enforce, and during which hours. It is not a lock function and not a millisecond. It is the human and procedural envelope that makes hardware mean something.

Examples that belong in this row:

• The dock door may be unlatched only while a named attendant role is present.
• Visitors to the lab are escorted; unescorted visitor policy is a deny, not a hope.
• After-hours pharmacy restock uses dual control.
• A console is staffed whenever delayed-egress and door-forced alarms are expected to mean detect.
• Opening-and-closing procedure names who checks Door 4 at end of wave.

People are a countermeasure. Domain 2 Task 2.4 and Chapter 15 will treat proprietary versus contract staffing, posts, and post orders in depth. Task 1 needs the design implication now: if the residual pairing requires an attendant, the attendant is in the design, with hours, a backup when the person is at lunch, and a procedure for what happens if the post is empty. A drawing that shows a perfect strike and a note that “security will handle it” is an operational requirement you refused to write. Officers, attendants, reception, and SOC operators deter by presence, detect by watching, delay by standing on a path, and respond by interrupting. They are not a leftover after electronics are chosen.

Operational requirements also include the policies electronics cannot invent: key control, credential issuance, visitor rules, and what supervisors do when a door is found unlatched. If those policies will not be staffed, do not specify a function that only exists when they are. A dual-control rule with one person on nights is an operational contradiction. Write the hours honestly or change the functional design for those hours.

Worked example: a clinic wants “card access on the staff door.” That is not yet operational. Operational language says nurses badge in; the door is not propped for smokers; a supervisor checks latch state after the last patient; a temporary badge for a traveling nurse is issued and recovered the same shift. Without those sentences, the reader you specified in 7.1 will be taped open by week two.

Functional requirements: capabilities, features, fault tolerance

A functional requirement names what the system or opening must be able to do—capabilities and features—including fault tolerance when power, network, or a device fails.

Examples:

• The door shall lock, unlock on a valid credential, and relock.
• A door-held or door-forced condition shall be reported.
• On loss of power, electrified hardware shall fail to a documented state (fail-safe on a required egress path; fail-secure on a storeroom where egress is not the issue).
• If the network path to the head-end is lost, local locking behavior shall remain defined (cached credentials, locked, or unlocked—chosen on purpose, not by installer habit).
• Supervised circuits so a cut cable is an alarm, not silence.
• Request-to-exit, delayed egress as listed, anti-passback, or interlock logic if the residual pairing needs that feature.

Fault tolerance is a functional subject. A camera that “needs the server” with no buffer, an alarm panel that dies quiet when the communicator fails, and a maglock that has no listed fire-alarm release are functional gaps. Features are not decorations. Do not copy a feature list from a brochure for a pairing that does not need it (over-control from Chapter 6, now as a spec). Do not omit a fail state for a pairing that will see power loss (under-control).

Write the fail state in the same sentence as the lock. “Electrified lock on Stair 2” is incomplete. “Electrified lock on Stair 2 shall unlock the egress path on fire-alarm input and on loss of power” is a functional requirement the AHJ can understand. “Storeroom 14 shall remain locked on loss of power and shall still allow free egress from the occupied side if that leaf is a required exit” is a different functional requirement. Mixing those two rooms in one schedule note is how listings get voided.

Performance requirements: technical capability and design capacities

A performance requirement states how well and against what measurable capacity the function must work. This is where PSP items get specific, and where “provide cameras” fails.

Video: detection, recognition, identification

These words are not synonyms. They are design capacities for a named scene.

• Detection: the image supports deciding that a person or object is present (a figure at the fence, a vehicle in the lane). You would not swear to identity. You would know something is there.
• Recognition: the image supports classifying what is there—adult versus child, car versus truck, staff clothing versus unknown clothing, a face as a type not a named person. Useful for dispatch and for later sorting.
• Identification: the image supports identifying a specific person or reading a face/credential at a named plane (badge desk, mantrap interior, cash-office window) well enough for investigation or for an operator to say that is this badge holder.

A specification that says only “provide cameras” has no performance. A specification that says “Camera 12 shall support identification at the badge-desk plane; Camera 40 shall support detection along the north fence” can be field-tested. Lighting, mounting height, compression, and housing are how you meet that capacity; they are not a substitute for naming the capacity. Do not pretend a wide parking-lot view that was sized for detection will identify a face at the far curb. Do not spend identification-grade lighting on a fence line whose residual pairing only needs detection plus a patrol.

The chart after this section is a teaching scale, not a published pixel standard and not an ASIS rule. Use it to remember that the three tasks occupy different design effort. Real projects still verify with a marked floor line and a test image, not with a brochure megapixel count.

Door cycle times

How long from valid credential (or valid attendant action) until the leaf is closed and latched; how long a delayed-egress countdown runs; how long request-to-exit keeps the alarm shunted. A door that unlocks but takes twenty seconds of closer drag to latch is a performance miss that looks like a functional lock on a drawing. Write a cycle time the occupancy can live with and a tester can measure with a watch. A dock closer set so slow that staff prop the leaf is a performance setting that destroys the operational rule.

Alarm response (technical)

Time from the event (unlatch, glass-break, duress) to annunciation at a named console or communicator, and whether the path is supervised. This is not the fantasy of a police car in thirty seconds on a rural road. That arrival is operational and often outside your control. The performance you own is: the panel reports, the console displays, the notification leaves the building if that is specified. Mixing “alarm response” with “police response” is a common stem trick. Read which clock the item is actually asking for.

Success metrics

A success metric is a testable statement that later commissioning can score without a marketing adjective.

• Door 4 latches within 8 seconds of release in ten of ten trials.
• Unattended unlatch prints at Console A within 10 seconds.
• Camera 12 supports identification of a standing person at the badge plane (tester uses a named chart or a known individual at a marked floor line).
• Attendant post is staffed for 100 percent of restock windows in a two-week sample of schedules (operational metric).
• Fail-safe maglock on Stair 2 releases on fire-alarm input in every tested zone.

Metrics that cannot fail—“world-class security,” “robust coverage”—are not metrics. They are brochure language. Tie metrics to the residual pairing: if the how was unattended unlatch, success is latch plus attended exception plus timed alarm, not a new analytics license. Preview: Domain 3 field tests and acceptance criteria are how these numbers leave the spec and enter a signed report. If you cannot imagine the test, you do not yet have a metric.

Codes, standards, and guidelines as design inputs

Codes are adopted law (building, fire, electrical, accessibility) enforced by the AHJ. Standards are consensus technical documents (often named in specs) that become mandatory when the code, the owner, or the contract says so. Guidelines are recommended practice; they inform judgment unless a contract elevates them.

All three are design inputs. They tell you what hardware is listed for delayed egress, what wiring method is allowed in a plenum, what opening force accessibility rules expect, what a listing on an electrified lock must show. They do not tell you which residual pairing matters on this dock. A code-compliant door can still be the cargo-theft how if it is left unlatched. A guideline camera-mounting height can still fail identification if the scene is backlit.

Confirm the edition the AHJ adopted. Do not invent section numbers. Name families you can defend—IBC/IFC, NFPA 101, ADA, NFPA 70 (electrical), and owner-chosen security standards—then send the detail to the adopted text. Owner standards sit beside this stack; they never punch a hole in egress. Independent OpenExamPrep material covers those published task ideas so you can study; it is not an ASIS publication and does not claim official approval, review, partnership, or exact equivalence with any ASIS course or item bank.

A guideline that suggests a fence height is still filtered through residual risk and through local code. A standard named in the owner master spec is a constraint like 7.1’s owner-standards family. A code provision on egress is a floor. Keep the three words separate on the exam: law, referenced technical consensus, recommended practice.

Same door, three requirement sentences

Use Door 4, the electronics dock leaf, as one object with three grammars. This table is the one to memorize for Task 1 items that ask which sentence is operational, functional, or performance.

Mixing the rows is the usual exam trap. “Post a guard” is not a latch time. “Eight-second strike” is not a visitor policy. “Camera exists” is not identification. Write all three when the residual pairing needs all three. A storeroom with no attendant may be functional plus performance only. A public lobby with a receptionist is operational plus the hardware rows.

The output of Task 1 is a requirements set that CPTED and layers can sit inside, that a specification can carry, and that Domain 3 can test. Model numbers come after the sentences, not before. Chapter 8 begins applying structural measures and CPTED to fences, glazing, lighting, and site planning using this same grammar.