3.1 User Requirements Specification (URS) & Stakeholder Analysis

3.1 User Requirements Specification (URS) & Stakeholder Analysis

In the industrial automation lifecycle, the User Requirements Specification (URS) represents the formal bridge between an operational business need and technical execution. Rooted in Domain 2 (Definition) of the automation engineering body of knowledge, the URS establishes what the facility, process unit, or manufacturing line must accomplish from the perspective of the asset owner and end users. It does not dictate hardware model numbers, software programming paradigms, or field wiring topologies—those technical decisions belong to subsequent functional and detailed design specifications. Instead, the URS serves as the authoritative, contractual foundation against which all engineering deliverables, acceptance testing, and final system validation are measured.

When the UK Health and Safety Executive analyzed 34 incidents involving control systems (published as Out of Control, HSG238), it found that 44% had inadequate specification as their primary cause—more than design and implementation, installation and commissioning, operation and maintenance, or changes after commissioning. An ambiguous, incomplete, or prematurely vendor-constrained URS propagates compounding errors through engineering design, software coding, and panel fabrication, culminating in costly field rework during commissioning and qualification.

---

The Multi-Disciplinary Stakeholder Analysis Matrix

A critical failure mode in requirements definition is treating the automation system purely as a controls engineering exercise. An industrial control system interfaces with operators, maintenance technicians, process chemists, environmental compliance officers, safety engineers, corporate IT networks, and executive management. A rigorous stakeholder analysis must be executed before drafting individual requirement statements.

Eliciting Requirements and Building Consensus

The Definition task asks the CAP to collaborate with key stakeholders using interview techniques, data analysis and consensus building. Common elicitation methods are:

• Structured interviews with each discipline, using a prepared question list so that answers can be compared across groups.
• Facilitated workshops that bring operations, maintenance, safety, quality and IT/OT together to resolve conflicting needs in one session.
• Site observation (walk-downs) of how operators actually run the process, which exposes workarounds that interviews miss.
• Data analysis of historian trends, alarm logs, maintenance records and incident reports to quantify needs.
• Document review of codes, standards, permits, existing SOPs and lessons learned from earlier projects.

Where stakeholders disagree, the engineer records each position, ties it to a business, safety or regulatory driver, and applies the agreed prioritization rules (such as MoSCoW, below) to settle the conflict. Writing the decision and its rationale into the URS keeps the same debate from reopening during design.

---

Formulating Unambiguous, Testable, Verifiable Requirement Statements

A requirement that cannot be definitively tested during Factory Acceptance Testing (FAT) or Site Acceptance Testing (SAT) is not an engineering requirement—it is merely an aspiration. Requirements-engineering practice (for example, ISO/IEC/IEEE 29148 and the GAMP 5 guidance used in life sciences) recommends strict syntactic conventions to ensure requirement clarity.

The Anatomy of a Defensible Requirement Statement

A defensible requirement statement contains five essential syntactic elements:

1. Subject: The specific system, subsystem, or interface under evaluation (e.g., "The reactor thermal control system...").
2. Modal Verb: The legal/contractual obligation level:
   • "Shall": Denotes an absolute, mandatory requirement necessary for contractual compliance or safety/regulatory adherence.
   • "Should": Denotes a desirable, highly recommended capability that may be waived only with documented technical justification and approval.
   • "May": Denotes a permissible or optional feature.
   • "Will": Denotes a statement of fact, future intent, or an external system capability, rather than an obligation placed upon the engineering deliverable.
3. Condition / Trigger: The operational state, process mode, or external event under which the requirement applies (e.g., "Under steady-state production conditions at maximum design throughput (500 kg/hr)...").
4. Action / Performance Metric: The unambiguous, measurable operational behavior (e.g., "...shall maintain bulk slurry temperature within $\pm 0.5^\circ\text{C}$ of target setpoint...").
5. Constraint / Acceptance Criterion: The temporal, environmental, or operational boundary (e.g., "...for a continuous duration of at least 8 hours without requiring manual operator intervention.").

Comparative Analysis: Flawed vs. Defensible Requirement Phrasing

---

Requirement Categorization & Prioritization Frameworks

Uncontrolled scope growth—commonly termed scope creep—is the primary threat to automation project solvency. During stakeholder workshops, participants often request convenient but non-essential features that rapidly inflate software engineering hours and hardware costs. The project team must categorize and prioritize all elicited requirements using structured frameworks such as MoSCoW:

• Must Have (M): Non-negotiable requirements critical for personnel safety, environmental compliance (e.g., EPA, OSHA PSM), core process viability, or legal regulations (e.g., 21 CFR Part 11). If any "Must Have" requirement is dropped, the automation system cannot be commissioned.
• Should Have (S): Highly desirable operational capabilities with significant business return (e.g., automated batch report generation or automated loop tuning diagnostics) that can be worked around manually if schedule or budget constraints force temporary deferral.
• Could Have (C): Low-impact enhancements or conveniences (e.g., customizable operator desktop color schemes or secondary historical trending widgets) executed only if surplus engineering time and budget exist.
• Won't Have (This Time) (W): Explicitly identified features agreed by stakeholders to be out-of-scope for the current project release (e.g., full enterprise ERP closed-loop optimization), deferred to future capital expenditure phases.

---

The Requirements Traceability Matrix (RTM)

The Requirements Traceability Matrix (RTM) is the primary engineering governance tool that ensures no requirement is lost during project execution and no unauthorized logic is surreptitiously introduced. An RTM establishes a continuous, bidirectional lineage connecting every individual requirement identifier through the engineering lifecycle.

URS (User Need: URS-042)
       │
       ▼
FRS (Functional Description: FRS-118)
       │
       ▼
DDS (Detailed Design Specification: DDS-204)
       │
       ▼
FAT / SAT Protocol (Test Step: FAT-TC-089)
       │
       ▼
Commissioning & OQ (Operational Qualification: OQ-V-034)

Bidirectional Traceability Dynamics

1. Forward Traceability (Requirements to Implementation & Testing): Tracing from the URS forward through the FRS, design documents, and test protocols verifies that every authorized stakeholder requirement is physically designed, coded, and verified. If a requirement exists in the URS without corresponding test cases in the FAT/SAT protocol, it is an untested (unverified) requirement—a coverage gap that exposes the plant to unverified operational risk.
2. Backward Traceability (Code & Tests to Requirements): Tracing from test protocols and software routines back to the original URS ensures that no extraneous functionality was engineered into the system. When a developer or system integrator adds unrequested code routines, custom scripts, or auxiliary features without a parent requirement in the URS, those items are orphans in the traceability matrix, and the practice is called gold plating. Gold plating introduces unvalidated code, increases software complexity, expands cybersecurity vulnerabilities, and creates perpetual maintenance costs that the asset owner never approved.

---

Realistic Industrial Scenario

A chemical manufacturing facility initiated a $4.2M capital expansion to install a secondary batch reactor line. During the initial definition phase, the project team drafted a concise URS focusing almost entirely on process throughput (batch turnover within 4 hours, temperature control within $\pm 1^\circ\text{C}$, automated ingredient dosing). However, the team conducted stakeholder interviews exclusively with operations supervisors, failing to formally engage the plant's Maintenance & Reliability department or the corporate IT/OT cybersecurity team.

During Site Acceptance Testing (SAT), two catastrophic definition-phase oversights surfaced:

1. Maintenance Access & Diagnostics: Maintenance technicians discovered that the field instrumentation chosen by the system integrator used proprietary point-to-point communication modules that lacked remote HART diagnostics. Routine instrument calibration required taking the entire reactor loop offline, directly violating the plant's operational availability targets.
2. IT/OT Security Policies: When connecting the reactor supervisory PLC to the site network, corporate IT blocked the communication switches because the system integrator had deployed default administrative credentials and unencrypted legacy protocols that violated the enterprise ISA/IEC 62443 cybersecurity standard.

Rectifying these oversights required issuing $340,000 in emergency engineering change orders (ECOs), redesigning network communication cards, replacing field I/O racks, and delaying commercial startup by 14 weeks. Had a rigorous multi-disciplinary stakeholder analysis and formal URS review been executed during the Definition phase, these constraints would have been captured as explicit, baseline mandatory ("shall") requirements at negligible initial cost.

---

ISA CAP Exam Pitfalls & Traps

• Trap 1: Confusing "What" (URS) with "How" (FRS/DDS). An exam question may present several requirement statements and ask which belongs in a formal URS. Beware of statements that specify commercial vendor model numbers (e.g., "The system shall use a Siemens S7-1500 PLC") or software code syntax. A valid URS statement specifies the required operational performance, availability, or process boundary, leaving the technical mechanism to engineering design.
• Trap 2: Ambiguous Adverbs and Subjective Modifiers. Watch for seemingly detailed statements containing words like rapidly, smoothly, user-friendly, adequate, or industry-standard. On the ISA CAP exam, any statement lacking a defined, measurable metric or tolerance under stated operating conditions must be flagged as flawed and untestable.
• Trap 3: Misinterpreting Modal Verbs per RFC 2119 / IEEE Standards. Pay close attention to the verb: "shall" is mandatory; "will" simply asserts an external fact or expectation; "should" is a recommendation that cannot legally enforce vendor compliance in an engineering contract.