안전 요구사항 명세서(SRS) 작성을 위한 안내서

2025-09-21, G25DR

1. 안전 요구사항 명세서(SRS)의 본질과 역할

1.1 안전의 청사진, SRS

시스템 개발 프로젝트의 성패는 요구사항의 명확성에 달려있다 해도 과언이 아니다.1 요구사항 명세서(Software Requirements Specification, SRS)는 프로젝트의 방향을 설정하고, 개발자와 고객을 포함한 모든 이해관계자 간의 오해를 최소화하며, 구현해야 할 시스템의 범위를 명확히 정의하는 핵심적인 소통 문서이다.3 이는 프로젝트의 과업, 비용, 기간을 정량화하고 합의하는 기준이 되어, 전체 개발 과정에서 의사결정의 근간을 이룬다.6

특히 자동차, 항공, 원자력, 의료기기와 같이 인간의 생명이나 환경에 직접적인 영향을 미칠 수 있는 안전 필수 시스템(Safety-Critical System)의 영역에서, 요구사항 명세서는 단순한 기능의 나열을 넘어선다. 여기서 SRS는 ‘안전 요구사항 명세서(Safety Requirements Specification)’로서, 시스템이 의도된 기능을 올바르게 수행하는 것을 넘어, 어떠한 상황에서도 치명적인 위험을 초래하지 않도록 보장하는 안전의 청사진 역할을 한다. 이는 시스템 개발의 기술적 책무를 넘어, 사회에 대한 법적, 윤리적 책무를 이행하고 있음을 증명하는 핵심 증거 자료가 된다.7

1.2 일반 요구사항 명세서와 안전 요구사항 명세서의 근본적 차이

일반적인 요구사항 명세서는 주로 시스템이 ‘무엇을 해야 하는가(What it should do)’에 초점을 맞춘다. 즉, 사용자가 원하는 기능을 정확히 구현하는 것이 주된 목표이다. 반면, 안전 요구사항 명세서는 여기에 두 가지 중요한 차원을 더한다. 첫째, 시스템이 ‘절대로 무엇을 하지 말아야 하는가(What it must not do)’를 명시적으로 정의한다. 둘째, 만약 시스템에 고장이 발생했을 때 ‘어떻게 안전하게 실패할 것인가(How it must fail safely)’에 대한 구체적인 동작을 규정한다.9

이러한 차이는 기능안전(Functional Safety)이라는 핵심 개념에서 비롯된다. 기능안전은 시스템의 전기/전자/프로그램 가능 전자(E/E/PE) 제어 시스템이 오작동하더라도 수용할 수 없는 위험(Unacceptable Risk)을 유발하지 않는 상태를 의미한다.10 따라서 안전 SRS는 시스템 개발의 출발점을 기능 구현이 아닌, 잠재적 위험(Hazard)을 식별하고 그 위험의 발생 가능성과 심각도를 평가하는 위험 분석 및 리스크 평가(Hazard Analysis and Risk Assessment, HARA) 활동의 결과물에서 찾는다. 이 분석을 통해 도출된 추상적인 안전 목표는 SRS를 통해 구체적이고 검증 가능한 안전 기능(Safety Instrumented Function, SIF)과 그 기능이 달성해야 할 신뢰도 등급인 안전 무결성 수준(Safety Integrity Level, SIL) 요구사항으로 변환된다.10 결국 일반 SRS가 기능 중심적이라면, 안전 SRS는 위험 중심적 접근 방식을 취한다는 점에서 근본적인 차이를 갖는다.

1.3 안전 수명주기(Safety Lifecycle)의 핵심 문서로서의 SRS

IEC 61508, ISO 26262 등 현대의 모든 기능안전 표준은 개념 설계부터 폐기에 이르기까지 시스템의 전 생애에 걸쳐 안전 관련 활동을 체계적으로 관리하는 ‘안전 수명주기(Safety Lifecycle)’ 모델을 기반으로 한다.10 이 수명주기 모델에서 SRS는 개념 설계 단계와 상세 설계 단계를 연결하는 핵심적인 교량 역할을 수행한다.

SRS는 위험 분석 단계에서 식별된 안전 목표들을 엔지니어링 관점에서 구체화하여, 후속 단계인 시스템 설계, 하드웨어 및 소프트웨어 개발의 명확한 입력이 된다.17 더 나아가, SRS는 개발 과정 전체에 걸쳐 일관성과 추적성(Traceability)을 보장하는 기준 문서(Baseline)로 기능한다. 모든 설계 결정, 코드 구현, 테스트 케이스는 SRS의 특정 요구사항에 연결되어야 한다. 이를 통해 개발 산출물이 초기의 안전 목표를 충실히 반영했는지 객관적으로 증명할 수 있다.6 SRS 없이는 시스템이 요구된 안전 수준을 달성했는지에 대한 검증(Verification)과 확인(Validation)이 불가능하며, 이는 기능안전의 근간을 흔드는 심각한 결함이다.10

1.4 프로젝트 성공과 규제 준수를 위한 SRS의 중요성

잘 작성된 SRS는 기술적 성공, 경제적 효율성, 법적 방어라는 세 가지 측면에서 프로젝트에 결정적인 기여를 한다. 첫째, 명확하고 완전한 SRS는 이해관계자 간의 오해를 방지하고 요구사항의 모호성으로 인한 불필요한 재작업 비용을 최소화한다.1 또한 프로젝트의 범위를 명확히 고정시켜, 개발 과정에서 기능이 무분별하게 추가되는 ‘요구사항蔓延(Requirements Creep)’ 현상을 효과적으로 통제한다.

둘째, 자동차, 항공, 의료기기와 같은 규제 산업에서 SRS는 규제 기관의 형식 승인(Type Approval)이나 인증(Certification)을 받기 위한 필수 제출 자료이다. 감사(Audit) 과정에서 심사관은 SRS를 기준으로 시스템의 설계와 검증 과정이 표준을 준수했는지 면밀히 검토한다. SRS의 부재나 내용의 부실함은 인증 실패로 직결되며, 이는 제품 출시 지연과 막대한 경제적 손실을 초래한다.7

마지막으로, SRS는 시스템 결함으로 인한 사고 발생 시, 개발 조직이 안전 확보를 위해 합당한 전문가적 노력을 다했음(Due Diligence)을 입증하는 중요한 법적 증거 자료로 활용된다. 초기 소프트웨어 공학에서 SRS가 주로 개발자와 고객 간의 ‘소통 도구’에 머물렀다면 3, 기능안전 시대의 SRS는 기업의 법적 책임을 증명하고 방어하는 ‘법적 문서’로 그 역할이 진화하였다. 이처럼 SRS 작성의 엄격성과 완전성은 단순한 프로젝트 성공을 넘어, 기업의 지속 가능성과 직결되는 중대한 과제이다.

2. 양질의 안전 요구사항 작성을 위한 핵심 원칙

2.1 요구사항의 8대 특성

고품질의 안전 요구사항은 모든 이해관계자가 동의하고, 설계자가 구현할 수 있으며, 시험자가 검증할 수 있는 형태로 작성되어야 한다. 이를 위해 요구사항은 다음과 같은 8가지 핵심 특성을 반드시 만족해야 한다. 이 특성들은 상호보완적이어서 어느 하나라도 결여될 경우 요구사항의 전체적인 품질이 저하된다.

명확성 (Clarity/Unambiguous): 요구사항은 단 하나의 의미로만 해석되어야 한다. ‘빠르게’, ‘효율적으로’, ‘사용자 친화적인’과 같은 주관적이고 모호한 표현은 배제해야 한다. 모든 성능과 관련된 표현은 정량적 수치와 허용 오차를 포함하여 기술되어야 한다.2
완전성 (Completeness): 시스템이 모든 동작 모드에서 수행해야 할 기능과 지켜야 할 제약조건이 빠짐없이 기술되어야 한다. 특히 오류 처리, 예외 상황 대응 등 비정상적인 시나리오에 대한 요구사항이 누락되지 않도록 주의해야 한다.2
일관성 (Consistency): 요구사항 집합 내에 서로 모순되는 내용이 없어야 한다. 또한, 문서 전체에서 사용되는 용어, 단위, 표현 방식이 통일되어야 한다.2
원자성 (Atomicity): 각각의 요구사항은 더 이상 분리할 수 없는 단일한 개념만을 기술해야 한다. ‘그리고(and)’, ‘또는(or)’, ‘~뿐만 아니라’ 등의 접속사를 사용하여 여러 요구사항을 하나로 묶어 기술하는 것을 피해야 한다. 복합 요구사항은 검증과 추적을 어렵게 만든다.18
추적성 (Traceability): 모든 요구사항은 고유한 식별자(ID)를 가져야 한다. 이를 통해 각 요구사항이 어떤 상위 요구사항(예: 안전 목표)으로부터 파생되었는지 역추적하고, 어떤 하위 산출물(설계 문서, 소스 코드, 테스트 케이스)로 구현되었는지 순추적할 수 있어야 한다. 추적성은 변경 영향 분석과 규제 준수 증명의 핵심이다.2
실현 가능성 (Feasibility/Attainable): 요구사항은 현재의 기술 수준과 주어진 예산, 일정 등 프로젝트 제약 조건 내에서 현실적으로 구현 가능해야 한다. 기술적 타당성이 불확실한 요구사항은 별도의 기술 검토나 프로토타이핑을 통해 실현 가능성을 확인해야 한다.21
필요성 (Necessity): 모든 요구사항은 시스템의 목적 달성을 위해 반드시 필요한 기능이나 특성이어야 한다. “만약 이 요구사항이 없다면 최악의 경우 어떤 일이 발생하는가?“라는 질문을 통해 불필요한 요구사항을 제거해야 한다. 이는 과잉 설계를 방지하고 개발 비용을 절감하는 데 기여한다.21
검증 가능성 (Verifiability/Testable): 요구사항의 충족 여부를 시험(Test), 분석(Analysis), 검사(Inspection), 시연(Demonstration) 중 하나 이상의 객관적인 방법을 통해 확인할 수 있어야 한다. 검증이 불가능한 요구사항은 선언에 불과하며, 안전을 보장할 수 없다.2

2.2 검증 가능한 요구사항(Verifiable Requirements) 작성 기법

‘검증 가능성’은 안전 요구사항이 가져야 할 가장 중요한 특성 중 하나이다. 요구사항이 검증 가능하다는 것은 기술적으로 테스트할 수 있다는 의미를 넘어, 프로젝트 관리와 계약의 근간을 이룬다. 검증 가능한 요구사항을 작성하는 과정 자체가 요구사항의 모호성을 제거하고 이해관계자 간의 숨겨진 가정을 드러내는 역할을 한다.21 예를 들어, “시스템 응답이 빨라야 한다“는 요구사항은 검증이 불가능하다. 이를 검증 가능하게 만들기 위해서는 다음과 같은 기법을 적용해야 한다.

적합성 기준(Fit Criterion) 명시: 모든 요구사항에 대해, 그 요구사항이 충족되었는지를 판단할 수 있는 구체적이고 측정 가능한 기준을 함께 기술한다. 이는 요구사항의 본질적인 부분이다.24
나쁜 예: 시스템 응답 시간은 빨라야 한다.
좋은 예: 외부 비상 정지 신호 수신 시점으로부터 100ms 이내에 주 동력 액추에이터의 전원을 차단해야 한다.
검증 방법(Verification Method) 정의: 각 요구사항을 어떤 방법으로 검증할 것인지(시험, 분석, 검사, 시연)를 사전에 명시한다. 이는 개발 초기부터 테스트 계획 수립을 용이하게 하고, 검증 과정에서 발생할 수 있는 논쟁을 예방한다.18
시험(Test): 시스템을 특정 조건 하에서 작동시키고, 그 결과를 측정하여 요구사항 충족 여부를 판단한다.
분석(Analysis): 수학적 모델링, 시뮬레이션, 계산 등을 통해 요구사항 충족 여부를 예측하고 증명한다.
검사(Inspection): 문서, 코드, 도면 등 산출물을 시각적으로 검토하여 요구사항 충족 여부를 확인한다.
시연(Demonstration): 특정 시나리오 하에서 시스템을 작동시켜 요구된 기능이 수행됨을 보여준다.

이처럼 검증 가능성은 프로젝트의 ’완료’에 대한 객관적인 기준을 제공하며, 고객에게 제품을 인도할 때의 ’인수 기준(Acceptance Criteria)’이 된다. 따라서 검증 가능성은 단순한 기술적 특성을 넘어, 프로젝트의 성공적인 완료와 건전한 비즈니스 관계를 담보하는 핵심적인 관리 원칙이다.

2.3 모호성을 배제하기 위한 정량적 표현 및 용어 정의

요구사항의 모호성은 프로젝트 실패의 주된 원인 중 하나이다. 이를 방지하기 위해 모든 성능 관련 요구사항은 반드시 정량적으로 표현해야 한다. 응답 시간, 처리량, 정확도, 가용성 등은 목표 수치와 함께 허용 오차 범위(Tolerance)를 명시해야 한다.22

또한, 프로젝트 초기에 용어집(Glossary)을 작성하여 모든 이해관계자가 주요 용어를 동일한 의미로 사용하도록 강제하는 것이 매우 중요하다.25 특히 ‘안전 상태(Safe State)’, ‘고장(Fault)’, ‘오류(Error)’, ‘결함(Failure)’, ‘위험(Hazard)’, ‘리스크(Risk)’와 같이 기능안전 분야에서 특별한 의미를 갖는 용어들은 국제 표준(예: IEC 61508-4)에 기반하여 명확하게 정의해야 한다.

2.4 요구사항 구문 패턴 (예: EARS)

자연어로 요구사항을 기술할 때 발생하는 구조적 모호성을 줄이기 위해, 정형화된 구문 패턴을 사용하는 것이 효과적이다. EARS(Easy Approach to Requirements Syntax)는 요구사항의 유형에 따라 간단하고 일관된 문장 구조를 제공하는 대표적인 기법이다.18

보편적 요구사항 (Ubiquitous): 시스템이 항상 만족해야 하는 요구사항.
The <시스템명> shall <시스템 응답>.
예: The Braking System shall provide a deceleration of at least 7 m/s^2.
이벤트 기반 요구사항 (Event-Driven): 특정 트리거 이벤트가 발생했을 때 만족해야 하는 요구사항.
WHEN <트리거>, the <시스템명> shall <시스템 응답>.
예: WHEN the "Emergency Stop" button is pressed, the Conveyor Belt shall stop motion within 1 second.
상태 기반 요구사항 (State-Driven): 시스템이 특정 상태에 있는 동안 만족해야 하는 요구사항.
WHILE <특정 상태>, the <시스템명> shall <시스템 응답>.
예: WHILE the aircraft is in "take-off" mode, the Landing Gear System shall prevent retraction.
선택적 기능 요구사항 (Optional Feature): 특정 기능이 포함된 경우에만 만족해야 하는 요구사항.
WHERE <기능이 포함됨>, the <시스템명> shall <시스템 응답>.
예: WHERE the "Adaptive Cruise Control" feature is installed, the Vehicle shall maintain the user-selected following distance.
원치 않는 동작 요구사항 (Unwanted Behavior): 특정 조건에서 시스템이 수행해서는 안 되는 동작을 명시. 안전 제약조건 기술에 매우 유용하다.
IF <조건>, THEN the <시스템명> shall not <금지된 시스템 응답>.
예: IF the train doors are not fully closed, THEN the Propulsion System shall not apply traction power.

이러한 패턴을 사용하면 요구사항의 일관성과 명확성을 크게 향상시킬 수 있으며, 요구사항 검토 및 분석을 자동화하는 데에도 도움이 된다.

2.4.1 표 1: 요구사항 명세에 사용되는 LaTeX 기호

안전 요구사항, 특히 복잡한 조건이나 논리적 관계를 포함하는 경우, 자연어만으로는 모호함이 발생할 수 있다. 예를 들어, “A가 발생하고 B가 발생하지 않을 때, 시스템은 C를 수행해야 한다“는 문장보다 논리식을 사용하는 것이 훨씬 명확하다. 아래 표는 요구사항을 정형적으로 기술할 때 유용한 주요 LaTeX 기호와 명령어를 정리한 것이다.26

분류	기호	의미	LaTeX 명령어
논리 연산자	$ \neg A $	A가 아님 (NOT)	`\neg A`
	$ A \land B $	A 그리고 B (AND)	`A \land B`
	$ A \lor B $	A 또는 B (OR)	`A \lor B`
	$ A \rightarrow B $	A이면 B이다 (Implies)	`A \rightarrow B`
	$ A \leftrightarrow B $	A와 B는 동치이다 (If and only if)	`A \leftrightarrow B`
	$ \forall x $	모든 x에 대하여 (For all)	`\forall x`
	$ \exists x $	어떤 x가 존재한다 (There exists)	`\exists x`
집합 기호	$ a \in S $	a는 집합 S의 원소이다	`a \in S`
	$ a \notin S $	a는 집합 S의 원소가 아니다	`a \notin S`
	$ A \subset B $	A는 B의 진부분집합이다	`A \subset B`
	$ A \cup B $	A와 B의 합집합	`A \cup B`
	$ A \cap B $	A와 B의 교집합	`A \cap B`
	$ \emptyset $	공집합	`\emptyset`
확률/통계	$ P(A) $	사건 A가 발생할 확률	`P(A)`
	$ E[X] $	확률변수 X의 기댓값	`E[X]`
기타	$ t_{response} \leq 100ms $	응답 시간은 100ms 이하	`t_{response} \leq 100ms`
	$ \vert V_{sensor1} - V_{sensor2} \vert > 5% $	센서1과 센서2 값의 차이가 5% 초과	`\vert V_{sensor1} - V_{sensor2} \vert > 5\%`

3. 안전 요구사항 명세서의 표준 구조와 핵심 구성요소

효과적인 SRS는 단순히 요구사항을 나열하는 것을 넘어, 정보가 논리적이고 체계적으로 구성되어야 한다. 이는 SRS가 단순한 정보의 집합이 아니라, 시스템을 체계적으로 분석하고 요구사항을 빠짐없이 도출하도록 유도하는 ‘사고의 프레임워크’ 역할을 하기 때문이다. 예를 들어, ’운영 모드’를 먼저 정의하도록 강제함으로써 12, 개발자는 정상 상태뿐만 아니라 시동, 정지, 비상 상황 등 모든 가능한 시나리오를 고려하게 되어 잠재적 위험을 조기에 발견할 수 있다. 아래는 국제 표준과 모범 사례를 기반으로 한 표준적인 SRS 문서 구조이다.

3.1 문서 개요 (Overview)

이 섹션은 독자가 문서의 전체적인 맥락을 이해하는 데 도움을 준다.

소개 (Introduction): 이 SRS 문서의 목적, 개발 대상 시스템의 범위, 그리고 이 문서를 읽어야 할 대상 독자를 명확히 기술한다.13
시스템 개요 (System Overview): 개발하고자 하는 시스템이 무엇인지 전반적으로 설명한다. 시스템의 주요 기능, 상위 수준의 아키텍처, 그리고 시스템이 운영될 환경에 대해 기술한다.32
참조 문서 (References): 이 SRS를 작성하는 데 참조한 모든 문서를 목록화한다. 상위 수준의 시스템 요구사항 명세서, 위험 분석 및 리스크 평가 보고서, 관련 법규 및 표준(예: IEC 61508, ISO 26262), 하드웨어 사양서 등이 포함된다.
용어 및 약어 정의 (Glossary): 문서 내에서 사용되는 기술 용어, 약어, 그리고 특별히 정의된 용어들을 명확하게 설명한다. 이는 이해관계자 간의 오해를 방지하는 데 필수적이다.

3.2 시스템 수준 요구사항 (System-Level Requirements)

이 섹션은 시스템 전체에 적용되는 전반적인 요구사항과 제약사항을 다룬다.

운영 모드 (Modes of Operation): 시스템이 가질 수 있는 모든 운영 모드를 정의한다. 예를 들어, ‘초기화(Initialization)’, ‘정상 운전(Normal Operation)’, ‘유지보수(Maintenance)’, ‘비상 정지(Emergency Stop)’, ‘고장 상태(Degraded Mode)’ 등이 있다. 각 모드에서 시스템의 동작과 활성화/비활성화되어야 할 안전 기능들을 명시해야 한다.12
제약 조건 (Constraints): 시스템의 설계와 구현에 영향을 미치는 기술적, 환경적, 법적 제약사항을 기술한다. 특정 운영체제(OS)나 하드웨어 플랫폼의 사용, 특정 통신 프로토콜 준수, 관련 법규 및 표준 준수 의무, 개발 언어 제한 등이 여기에 해당한다.4

3.3 기능 요구사항 (Functional Requirements)

이 섹션은 SRS의 핵심으로, 시스템이 안전을 보장하기 위해 수행해야 할 구체적인 기능들을 상세히 기술한다.

안전 기능 명세 (Safety Function Specification): 시스템이 수행해야 할 각각의 안전 기능(Safety Instrumented Function, SIF)을 개별적으로, 원자적으로 상세히 기술한다. 복잡한 안전 로직을 명확하게 분해하고 개별적으로 검증할 수 있도록 각 SIF는 고유한 섹션으로 구성하는 것이 바람직하다.

각 SIF에 대해 다음 항목들이 반드시 포함되어야 한다 12:

SIF ID 및 이름: 추적성을 위한 고유 식별자(예: SIF-001)와 기능에 대한 직관적인 이름(예: 보일러 과압 방지 기능).
목적/설명: 해당 SIF가 어떤 위험(Hazard)을 방지하기 위해 존재하는지, 그리고 어떤 기능을 수행하는지를 명확히 설명한다.
안전 무결성 수준 (SIL/ASIL/DAL): 위험 분석을 통해 결정된, 해당 SIF가 달성해야 하는 신뢰도 등급을 명시한다.
입력 (Inputs): SIF의 작동을 촉발하는 모든 조건과 신호를 명시한다. (예: 압력 센서 PT-101의 측정값, 비상 정지 버튼 입력 신호).
트립 포인트 (Trip Points): SIF가 작동해야 하는 구체적인 임계값을 정량적으로 기술한다. (예: 압력 센서 PT-101의 측정값이 10.5 bar를 초과할 경우).
논리 (Logic): 입력과 출력 간의 기능적 관계를 명확히 기술한다. 단순한 논리(예: A > X 이면 Y 수행)부터 복잡한 논리(예: 2개의 센서 중 2개 모두(2oo2) 또는 3개 중 2개(2oo3)가 트립 포인트를 초과할 경우)까지 상세히 명시한다. 원인-결과 매트릭스(Cause & Effect Matrix)를 활용할 수 있다.
출력 (Outputs): SIF가 작동했을 때 시스템이 취해야 할 구체적인 조치를 기술한다. (예: 연료 공급 밸브 XV-101을 닫고, 경보 AL-101을 활성화한다).
안전 상태 (Safe State): SIF 작동 시 시스템 또는 프로세스가 도달해야 하는 궁극적인 안전한 상태를 명확하게 정의한다. (예: 보일러의 내부 압력이 1.0 bar 이하로 유지되고, 모든 연료 공급이 차단된 상태).
응답 시간 (Response Time): 트립 포인트 도달 시점부터 시스템이 안전 상태에 도달하기까지 허용되는 최대 시간을 명시한다. (예: 총 응답 시간은 2초 이내여야 한다).
고장 반응 (Fault Reaction): SIF를 구성하는 요소(센서, 로직 솔버, 액추에이터) 자체에 고장이 발생했을 때의 동작을 정의한다. 일반적으로 위험을 방지하는 방향으로 작동(Fail-safe)하도록 설계된다. (예: 압력 센서의 전원 공급이 끊기면, 고압 상태로 간주하고 SIF를 작동시킨다).
운영 모드 및 바이패스 (Operating Modes and Bypasses): 해당 SIF가 활성화되어야 하는 시스템 운영 모드를 명시하고, 시운전이나 유지보수 등의 특수 상황에서 SIF를 일시적으로 무력화(Bypass 또는 Override)해야 할 경우, 그 조건과 절차, 그리고 바이패스 상태임을 알리는 명확한 표시 방법을 기술한다.
수동 정지 및 리셋 (Manual Shutdown and Reset): 운전원이 SIF를 수동으로 작동시킬 수 있는 수단이 필요한지 여부와, SIF가 작동한 후 시스템을 정상 상태로 복귀시키기 위한 리셋(Reset) 절차를 정의한다.

3.4 비기능 요구사항 (Non-functional Requirements)

이 섹션은 시스템의 품질 속성과 운영 환경에 대한 요구사항을 정의하며, ‘얼마나 잘’ 동작해야 하는가에 초점을 맞춘다.

성능 요구사항 (Performance Requirements): 안전 기능과 직접 관련되지 않은 시스템의 일반적인 성능 요구사항을 기술한다. (예: 정상 상태에서의 데이터 처리량, 화면 전환 시간 등).32
신뢰성/가용성 요구사항 (Reliability/Availability): 시스템의 신뢰도와 관련된 지표를 정의한다. 평균 무고장 시간(MTBF), 평균 수리 시간(MTTR), 그리고 안전 기능이 불필요하게 작동하는 오작동(Spurious Trip)의 최대 허용 빈도(Spurious Trip Rate) 등을 명시한다.12
환경 요구사항 (Environmental Requirements): 시스템이 설치되고 운영될 물리적 환경 조건을 상세히 기술한다. 온도, 습도, 진동, 충격, 고도, 전자기 간섭(EMI/RFI) 내성, 방수/방진 등급(IP 등급) 등이 포함된다.12
보안 요구사항 (Security Requirements): 의도하지 않은 우발적 고장뿐만 아니라, 악의적인 외부 공격으로부터 시스템의 안전 기능이 훼손되지 않도록 보호하기 위한 사이버 보안 요구사항을 기술한다. (예: 접근 제어, 데이터 암호화, 침입 탐지).35
유지보수성 요구사항 (Maintainability): 시스템의 유지보수 용이성과 관련된 요구사항을 정의한다. 안전 기능의 성능을 주기적으로 확인하기 위한 점검(Proof Test)의 주기와 절차, 내장된 자가 진단 기능, 고장 부품의 교체 용이성 등을 명시한다.12

3.5 인터페이스 요구사항 (Interface Requirements)

이 섹션은 시스템이 외부와 상호작용하는 모든 접점에 대한 요구사항을 정의한다.

사용자 인터페이스 (Human-Machine Interface, HMI): 운전자 또는 조작자가 시스템의 상태를 인지하고 제어하는 데 사용되는 모든 인터페이스를 기술한다. 화면 표시 정보, 경고 및 알람의 종류와 우선순위, 조작 버튼의 기능 등을 포함한다.13
하드웨어 인터페이스: 시스템이 외부의 다른 하드웨어 장치(센서, 액추에이터, 다른 제어기 등)와 주고받는 신호의 종류, 전기적 특성, 커넥터 사양 등을 정의한다.
소프트웨어 인터페이스: 시스템이 다른 소프트웨어 시스템과 데이터를 교환하는 방식을 정의한다. 통신 프로토콜(예: CAN, Ethernet/IP), API(Application Programming Interface), 데이터베이스 연동 방식 등을 포함한다.

4. 기능안전 표준 기반의 SRS 심화: IEC 61508을 중심으로

4.1 IEC 61508: 모든 기능안전 표준의 어머니

IEC 61508은 특정 산업 분야에 국한되지 않는, 전기/전자/프로그램 가능 전자(E/E/PE) 시스템의 기능안전에 관한 가장 근본적이고 포괄적인 국제 표준이다. 이 때문에 ‘모든 기능안전 표준의 어머니(Umbrella Standard)’라고 불린다.14 자동차 산업의 ISO 26262, 프로세스 산업의 IEC 61511, 철도 산업의 EN 50128 등 대부분의 주요 산업별 기능안전 표준은 IEC 61508에서 제시하는 기본 원칙과 개념, 안전 수명주기 모델을 각 산업의 특성에 맞게 구체화한 것이다.14 따라서 IEC 61508이 요구하는 SRS의 구성과 내용을 깊이 이해하는 것은 모든 기능안전 관련 시스템 개발의 견고한 기초를 다지는 것과 같다.

4.2 위험 분석 결과와 SRS의 연계

안전 요구사항 명세서는 독립적으로 작성되는 문서가 아니다. 이는 반드시 선행 단계인 ‘위험 분석 및 리스크 평가(Hazard and Risk Assessment)’의 결과물을 직접적인 입력으로 받아야 한다. 이 연계 과정은 기능안전의 논리적 흐름에서 가장 중요한 부분이다.10

위험 분석(예: HAZOP, FMEA)을 통해 시스템이 초래할 수 있는 잠재적 위험원(Hazard)들을 식별하고, 리스크 평가(예: LOPA, Risk Graph)를 통해 각 위험원이 실현될 경우의 심각도(Severity)와 발생 빈도(Likelihood)를 조합하여 현재의 리스크 수준을 평가한다. 만약 이 리스크가 조직이나 사회가 수용할 수 없는 수준이라면, 리스크를 허용 가능한 수준까지 낮추기 위해 필요한 ‘리스크 감소량(Risk Reduction)’을 결정한다.

바로 이 ‘필요한 리스크 감소량’이 SRS로 구체화되는 것이다. SRS에 기술되는 각각의 안전 기능(SIF)은 특정 위험을 제어하기 위해 존재하며, 해당 SIF에 할당되는 안전 무결성 수준(SIL)은 그 기능이 달성해야 하는 리스크 감소의 정도를 정량적으로 표현한다. 이처럼 위험 분석부터 SRS까지의 명확한 추적성(Traceability)은 시스템의 안전 조치가 임의적이거나 경험에 의한 것이 아니라, 체계적이고 논리적인 분석에 기반하고 있음을 증명하는 핵심적인 증거가 된다.

4.3 안전 무결성 수준(SIL)과 요구사항

안전 무결성 수준(Safety Integrity Level, SIL)은 안전 관련 시스템이 요구된 안전 기능을 성공적으로 수행할 확률, 즉 신뢰도를 나타내는 4단계의 척도(SIL 1, 2, 3, 4)이다. SIL 4가 가장 높은 수준의 안전 무결성을 의미한다.11 SIL은 시스템의 운영 방식에 따라 두 가지 주요 지표로 정량화된다.

저빈도 요구 모드 (Low Demand Mode): 안전 기능에 대한 요구(Demand)가 1년에 1회 이하로 발생하는 경우. 이 모드에서는 요구 시 평균 위험 고장 확률 (Average Probability of Failure on Dangerous Demand, $PFD_{avg}$ ) 로 SIL을 정의한다.
SIL 1: $10^{-2} \leq PFD_{avg} < 10^{-1}$
SIL 2: $10^{-3} \leq PFD_{avg} < 10^{-2}$
SIL 3: $10^{-4} \leq PFD_{avg} < 10^{-3}$
SIL 4: $10^{-5} \leq PFD_{avg} < 10^{-4}$
고빈도/연속 요구 모드 (High Demand/Continuous Mode): 안전 기능에 대한 요구가 1년에 1회를 초과하거나, 지속적으로 요구되는 경우. 이 모드에서는 시간당 평균 위험 고장 빈도 (Average Frequency of a Dangerous Failure per Hour, $PFH$ ) 로 SIL을 정의한다.
SIL 1: $10^{-6} \leq PFH < 10^{-5}$ $h^{-1}$
SIL 2: $10^{-7} \leq PFH < 10^{-6}$ $h^{-1}$
SIL 3: $10^{-8} \leq PFH < 10^{-7}$ $h^{-1}$
SIL 4: $10^{-9} \leq PFH < 10^{-8}$ $h^{-1}$

SRS에 명시된 목표 SIL 등급은 단순한 신뢰도 목표치를 넘어, 해당 안전 기능을 개발, 구현, 검증하는 데 투입되어야 할 엔지니어링 자원과 프로세스의 ’엄격성 수준’을 직접적으로 규정하는 강력한 지표이다. IEC 61508-2(하드웨어)와 IEC 61508-3(소프트웨어)의 여러 테이블들은 각 SIL 등급별로 ‘매우 권장(Highly Recommended)’ 또는 ‘권장(Recommended)’되는 설계 기법, 코딩 표준, 테스트 방법 등을 구체적으로 제시한다.40 예를 들어, SIL 3 시스템을 개발하면서 SIL 1에 해당하는 개발 기법만을 적용했다면, 이는 명백한 표준 위반이며 인증을 통과할 수 없다. 따라서 프로젝트 초기 단계에서 결정된 SIL 값은 전체 개발 비용, 기간, 필요한 인력의 전문성 수준, 그리고 사용해야 할 개발 및 검증 도구까지 모든 것을 좌우하는 핵심 변수가 된다.

4.4 IEC 61508/61511 기반 SRS 상세 항목 체크리스트

IEC 61508-2와 이를 프로세스 산업에 적용한 IEC 61511-1 Clause 10.3.2는 SRS에 포함되어야 할 상세 항목들을 구체적으로 명시하고 있다. 이는 SRS 작성 시 누락되는 내용이 없도록 보장하는 실용적인 체크리스트로 활용될 수 있다.12 아래 표는 이들 표준에서 요구하는 핵심 항목들을 정리한 것이다.

4.4.1 표 2: IEC 61511 기반 SRS 체크리스트

분류	항목	설명 및 고려사항
기본 정의	1. 안전 기능 설명	각 안전 계장 기능(SIF)이 어떤 위험을 방지하고 어떤 동작을 수행하는지에 대한 명확한 설명.
	2. 안전 상태 정의	각 SIF가 작동했을 때 프로세스가 도달해야 하는 안전한 상태에 대한 명확하고 모호하지 않은 정의.
	3. 동시 발생 위험 정의	개별적으로는 안전하지만, 동시에 발생할 경우 새로운 위험을 초래하는 상태에 대한 정의. (예: 여러 릴리프 밸브 동시 개방)
성능 요구	4. 요구 발생원 및 빈도	SIF의 작동을 요구하는 잠재적 원인(예: 제어 밸브 고착)과 예상되는 연간 요구 빈도.
	5. 응답 시간 요구사항	위험 감지부터 안전 상태 도달까지 요구되는 최대 허용 시간 (Process Safety Time 고려).
	6. SIL 및 운영 모드	각 SIF에 요구되는 안전 무결성 수준(SIL)과 운영 모드(저빈도/고빈도) 명시.
	7. 최대 허용 오작동률	안전과 무관한 상황에서 SIF가 불필요하게 작동하는(Spurious Trip) 최대 허용 빈도.
기능 명세	8. 프로세스 측정 및 트립 포인트	SIF 작동을 위한 입력 변수(예: 압력, 온도, 레벨)와 구체적인 트립 포인트(설정값).
	9. 출력 동작 및 성공 기준	SIF 작동 시 출력부(예: 차단 밸브, 펌프)의 동작과 성공적인 작동으로 간주되는 기준(예: 밸브의 완전 차단).
	10. 입출력 기능 관계	입력과 출력 간의 논리적 관계(예: 1oo2, 2oo3 voting), 수학적 함수, 인터록 조건 등.
	11. 수동 정지 요구사항	운전원이 SIF를 수동으로 작동시킬 수 있는 수단에 대한 요구사항.
	12. 트립 방식 (Energize/De-energize)	안전 상태 달성을 위해 출력을 여자(Energize) 시킬 것인지, 무여자(De-energize) 시킬 것인지 명시. (일반적으로 De-energize to Trip 방식이 선호됨)
	13. 리셋 요구사항	SIF 작동 후 시스템을 정상 상태로 복귀시키기 위한 리셋 절차.
운영 및 유지보수	14. 주기적 점검(Proof Test) 간격	SIF의 숨겨진 위험 고장을 찾아내기 위해 요구되는 주기적 점검의 최대 간격.
	15. 평균 수리 시간(MTTR)	고장 발생 시 수리가 완료되기까지의 평균 시간. (현장 접근성, 예비 부품 보유 현황 등 고려)
	16. 운전 모드별 요구사항	시동(Start-up), 정상 운전, 정지(Shutdown) 등 플랜트의 각 운전 모드별로 요구되는 SIF 식별.
	17. 바이패스/오버라이드	유지보수 등을 위한 바이패스(Bypass), 인터록 무시(Override) 등의 요구사항 및 관리 절차.
시스템 요구	18. 고장 모드 및 시스템 반응	SIS 자체의 고장(센서, 로직 솔버, 액추에이터) 발생 시 원하는 시스템 반응(Fail-safe 등) 명시.
	19. 공통 원인 고장(CCF) 대책	다중화된 시스템이 단일 원인으로 동시에 고장나는 것을 방지하기 위한 요구사항(예: 물리적 분리, 다양한 기술 사용).
	20. 외부 시스템 인터페이스	SIS와 기본 공정 제어 시스템(BPCS), 분산 제어 시스템(DCS), HMI 등 다른 시스템과의 인터페이스.
	21. 환경 조건	시스템이 견뎌야 하는 온도, 습도, 진동, EMI/RFI 등 극한의 환경 조건.
	22. 소프트웨어 요구사항	IEC 61508-3에 따른 애플리케이션 소프트웨어 안전 요구사항.
	23. 보안 요구사항	악의적 공격으로부터 SIS를 보호하기 위한 사이버 보안 조치.
	24. 중대 사고 시 생존 요구사항	화재, 폭발 등 중대 사고 발생 시에도 일정 시간 동안 기능을 유지해야 하는 SIF에 대한 요구사항.

5. 산업별 SRS 적용 및 특화

기능안전의 기본 원칙은 모든 산업에 공통적으로 적용되지만, 각 산업의 고유한 특성, 기술 환경, 규제 문화에 따라 안전 요구사항을 명세하는 방식과 강조점에는 차이가 있다. 자동차, 항공, 의료기기 분야는 기능안전이 가장 엄격하게 요구되는 대표적인 산업으로, 이들 표준은 결국 ’동일한 안전 원칙’을 각자의 ’언어’와 ’문화’로 번역한 것이라 볼 수 있다. 즉, ① 위험을 식별하고, ② 위험 수준에 따라 요구사항의 엄격성을 차등화하며, ③ 최상위 안전 목표부터 최하위 구현까지 끊김 없는 추적성을 보장하고, ④ 모든 요구사항이 객관적으로 검증되었음을 증명한다는 공통된 철학을 공유한다.

5.1 자동차 (ISO 26262): 계층적 안전 요구사항의 정수

ISO 26262 개요: IEC 61508을 기반으로, 양산되는 도로 차량에 탑재되는 전기/전자(E/E) 시스템의 기능안전을 다루는 국제 표준이다.15 대량 생산과 복잡한 공급망(OEM-Tier1-Tier2) 구조를 특징으로 하는 자동차 산업의 특성을 반영하여, 요구사항을 체계적으로 분해하고 관리하는 계층적 접근 방식을 강조한다.
HARA와 ASIL: 개발 초기 단계에서 ‘위험 분석 및 리스크 평가(Hazard Analysis and Risk Assessment, HARA)’를 수행한다. 차량 수준의 잠재적 오작동을 식별하고, 이것이 위험한 상황으로 이어질 경우의 심각도(Severity), 해당 상황에 노출될 확률(Exposure), 그리고 운전자가 위험을 회피할 수 있는 제어 가능성(Controllability) 세 가지 요소를 평가하여 ‘자동차 안전 무결성 수준(Automotive Safety Integrity Level, ASIL)’을 결정한다. ASIL은 A, B, C, D 네 등급으로 나뉘며, ASIL D가 가장 높은 위험 등급을 의미한다.15
요구사항의 계층 구조 (V-Model): ISO 26262는 시스템 개발 V-모델에 따라 안전 요구사항을 체계적으로 상세화하는 계층적 구조를 따른다.

안전 목표 (Safety Goal): HARA로부터 직접 도출되는 최상위 안전 요구사항이다. 차량 수준에서 방지해야 할 불합리한 리스크를 정의한다. (예: “주행 중 의도치 않은 가속을 방지해야 한다. ASIL D”).44
기능안전 요구사항 (Functional Safety Requirements, FSR): 안전 목표를 달성하기 위해 시스템이 수행해야 하는 기능적 동작을 구현과 무관하게 정의한다. (예: “시스템은 가속 페달 센서 신호의 유효성을 10ms 주기로 진단해야 한다.”).44
기술안전 요구사항 (Technical Safety Requirements, TSR): FSR을 구체적인 시스템 아키텍처(예: 센서, ECU, 액추에이터)에 할당하고, 기술적인 구현 방안을 명세한다. 고장 감지 메커니즘, 고장 허용 시간 간격(FTTI), 안전 상태로의 전환 조건, 하드웨어-소프트웨어 인터페이스(HW-SW Interface) 등을 상세히 기술한다. (예: “시스템은 두 개의 독립적인 가속 페달 센서를 사용해야 한다. 두 센서 신호의 차이가 5%를 초과하면 고장으로 판단하고, 50ms 이내에 엔진 토크를 아이들(idle) 상태로 제한하는 안전 상태로 전환해야 한다.”).44
하드웨어/소프트웨어 안전 요구사항 (HSR/SSR): TSR을 다시 개별 하드웨어 컴포넌트와 소프트웨어 컴포넌트에 할당하여, 각 컴포넌트가 수행해야 할 가장 구체적인 안전 관련 동작과 제약사항을 정의한다. (예: HSR: “하드웨어는 두 센서에 독립적인 전원을 공급해야 한다.” / SSR: “ADC 드라이버 소프트웨어는 센서 A의 아날로그 값을 12비트 디지털 값으로 변환해야 한다.”).44

추적성과 ASIL 분해: 이 모든 계층의 요구사항들은 상하위 간에 완벽한 양방향 추적성(Bi-directional Traceability)을 가져야 한다.20 또한, ISO 26262는 ‘ASIL 분해(Decomposition)’라는 독특한 개념을 제공한다. 이는 높은 ASIL 등급의 요구사항을 갖는 기능을, 서로 독립적인 낮은 ASIL 등급의 중복된(redundant) 요소들로 구현하여 동등한 안전 수준을 달성하는 방법론이다. 예를 들어, ASIL D 요구사항을 갖는 기능을 독립적인 두 개의 ASIL B(D) 컴포넌트로 구현할 수 있다.42

5.2 항공 (DO-178C): 목표 기반의 절대적 엄격성

DO-178C 개요: ‘항공 시스템 및 장비 인증에 대한 소프트웨어 고려사항(Software Considerations in Airborne Systems and Equipment Certification)’으로, 민간 항공기에 탑재되는 소프트웨어의 감항 인증(Airworthiness Certification)을 위한 사실상의 국제 표준이다.49 항공 산업의 극단적인 안전 요구 수준을 반영하여 매우 엄격하고 보수적인 접근 방식을 취한다.
설계 보증 수준 (DAL): 시스템 안전성 평가(System Safety Assessment) 프로세스를 통해 소프트웨어의 고장이 항공기와 탑승자에게 미치는 영향을 분석하고, 그 심각도에 따라 ‘설계 보증 수준(Design Assurance Level, DAL)’을 할당한다. DAL은 A부터 E까지 5단계로 나뉘며, DAL A(Catastrophic, 파국적)가 가장 높은 등급이다.49

DAL A (파국적): 항공기 손실 및 다수의 사망자 발생 가능.
DAL B (위험): 안전 여유 감소, 심각한 부상 또는 사망자 발생 가능.
DAL C (주요): 안전 여유 감소, 승객 불편, 경미한 부상 가능.
DAL D (경미): 운영상 영향 미미.
DAL E (영향 없음): 안전에 영향 없음.

목표(Objectives) 기반 접근: DO-178C는 ISO 26262처럼 구체적인 개발 프로세스나 문서 템플릿을 강요하지 않는다. 대신, 각 DAL 등급에 대해 소프트웨어 수명주기의 각 단계(계획, 개발, 검증 등)에서 반드시 달성해야 할 ‘목표(Objectives)’의 목록을 제시한다. 개발 조직은 자신들의 프로세스를 통해 이 모든 목표를 충족했음을 객관적인 증거(Life Cycle Data)를 통해 인증 당국에 증명해야 한다.52
엄격한 추적성 및 검증: DO-178C의 핵심은 요구사항의 완전한 추적성과 코드 수준의 철저한 검증에 있다.

요구사항 계층: 시스템 요구사항 → 상위 수준 요구사항(High-Level Requirements, HLR) → 하위 수준 요구사항(Low-Level Requirements, LLR) → 소스 코드로 이어지는 완벽하고 빈틈없는 추적성을 요구한다.51
검증: 모든 요구사항은 테스트 케이스와 일대일 또는 다대일로 연결되어야 한다. 특히, DAL 등급이 높아질수록 코드 수준의 구조적 커버리지(Structural Coverage) 분석에 대한 요구사항이 매우 엄격해진다. 예를 들어, DAL A 소프트웨어는 가장 높은 수준의 커버리지인 ‘수정 조건/결정 커버리지(Modified Condition/Decision Coverage, MC/DC)’를 100% 만족해야 함을 증명해야 한다.54

5.3 의료기기 (IEC 62304 등): 위험 관리 기반의 환자 중심 접근

관련 표준: 의료기기 소프트웨어 개발은 주로 IEC 62304(의료기기 소프트웨어 - 소프트웨어 수명주기 프로세스) 표준을 따르며, 이는 의료기기 위험 관리에 대한 표준인 ISO 14971과 긴밀하게 연동된다. 환자의 안전을 최우선으로 고려하는 특성을 반영한다.
소프트웨어 안전 등급 (Class A, B, C): 소프트웨어 시스템의 고장이 환자, 조작자, 또는 제3자에게 미칠 수 있는 상해(Injury)의 심각도에 따라 안전 등급을 A, B, C 세 가지로 분류한다.55

Class A: 상해나 건강 손상 가능성 없음.
Class B: 심각하지 않은 상해(Non-serious injury) 가능.
Class C: 사망 또는 심각한 상해(Serious injury) 가능.

위험 관리 파일과의 연동: 의료기기 SRS 작성의 가장 큰 특징은 ISO 14971에 따라 작성된 ‘위험 관리 파일(Risk Management File)’과의 직접적인 연동이다. 위험 관리 프로세스를 통해 식별된 모든 잠재적 위험원(Hazard), 위험 상황(Hazardous Situation), 그리고 그로 인한 위해(Harm)에 대해, 이를 통제하기 위한 ‘위험 통제 수단(Risk Control Measure)’이 결정된다. 소프트웨어를 통해 구현되는 모든 위험 통제 수단은 반드시 SRS에 구체적인 안전 요구사항으로 명시되고 추적 관리되어야 한다.55
요구사항 명세의 특징:

구조, 기능, 알고리즘 명세: 의료기기 소프트웨어 기술문서에서는 소프트웨어의 전체적인 구조(기능 모듈 다이어그램 등), 주요 기능, 그리고 진단/분석과 관련된 핵심 알고리즘(플로우차트 등)을 명확하게 기술하도록 요구한다.56
기성 소프트웨어(SOUP) 관리: 상용 운영체제, 라이브러리 등 출처가 불분명한 소프트웨어(SOUP, Software of Unknown Provenance)를 사용할 경우, 해당 SOUP의 기능 및 성능 요구사항을 정의하고, SOUP으로 인해 발생할 수 있는 잠재적 위험을 분석하여 SRS에 반영해야 한다.
소프트웨어 밸리데이션(Validation): 소프트웨어가 최종적으로 의도된 사용 환경에서 사용자의 요구를 만족시키는지를 확인하는 밸리데이션 활동 계획과 결과가 요구사항과 긴밀하게 연결되어야 한다.55

5.3.1 표 3: 주요 산업별 안전 무결성 수준 비교

표준 (산업)	등급 체계	최고 등급	최저 등급	등급 결정 기준	정량적 목표 예시 (최고 등급)
IEC 61508 (일반 산업)	SIL (Safety Integrity Level) 1-4	SIL 4	SIL 1	리스크 평가를 통한 필요 리스크 감소량	`PFH: < $10^{-8}$ $h^{-1}$
ISO 26262 (자동차)	ASIL (Automotive SIL) A-D	ASIL D	ASIL A	심각도(S), 노출확률(E), 제어가능성(C)	정성적 목표 (정량적 목표는 비규범적)
DO-178C (항공)	DAL (Design Assurance Level) A-E	DAL A	DAL D (E는 안전 무관)	시스템 고장 시 항공기/탑승자에 미치는 영향	목표 기반 (정량적 고장률은 시스템 수준에서 정의)
IEC 62304 (의료기기)	Class A-C	Class C	Class A	소프트웨어 고장 시 발생 가능한 상해의 심각도	위험 관리 기반 (정량적 목표는 위험 분석 결과에 따름)

6. 결론: 효과적인 SRS 작성을 위한 종합적 제언

6.1 성공적인 SRS 작성을 위한 조직적 고려사항

효과적인 안전 요구사항 명세서 작성은 단순히 한 명의 뛰어난 엔지니어의 역량에 의존하는 활동이 아니다. 이는 조직의 문화와 프로세스가 뒷받침되어야 하는 종합적인 엔지니어링 활동이다.

첫째, SRS 작성은 반드시 다양한 분야의 전문가로 구성된 **다분야 팀(Cross-functional Team)**의 협업을 통해 이루어져야 한다. 시스템 아키텍트, 기능안전 전문가, 소프트웨어 및 하드웨어 엔지니어, 테스트 엔지니어, 그리고 실제 시스템을 운영할 사용자 대표까지 참여하여 각자의 관점에서 요구사항을 검토하고 보완해야 한다. 이러한 협업은 요구사항의 완전성을 높이고, 특정 분야의 시각에만 치우쳐 발생할 수 있는 잠재적 위험을 조기에 발견하는 데 결정적이다.10

둘째, 경영진의 강력한 지원과 안전 문화(Safety Culture) 조성이 필수적이다. 안전은 단순히 지켜야 할 규정이나 추가적인 비용이 아니라, 제품의 본질적인 가치를 높이고 기업의 지속 가능성을 보장하는 핵심적인 투자라는 인식이 조직 전체에 공유되어야 한다. 경영진은 안전 활동에 필요한 충분한 시간과 자원을 배분하고, 안전 관련 문제를 제기하는 것을 장려하며, 결과에 대한 책임을 묻되 비난하지 않는 문화를 조성해야 한다.8 이러한 문화 속에서만 엔지니어들은 압박감 없이 잠재적 위험을 투명하게 논의하고 최선의 안전 요구사항을 도출할 수 있다.

6.2 SRS의 생명주기 관리: 살아있는 문서

SRS는 프로젝트 초기에 한 번 작성되고 서고에 꽂히는 정적인 문서가 되어서는 안 된다. SRS는 시스템의 수명주기 전체에 걸쳐 지속적으로 유지보수되고 관리되어야 하는 **‘살아있는 문서(Live Document)’**이다.10 개발이 진행됨에 따라 초기의 가정이 틀렸음이 밝혀지거나, 새로운 기술적 제약이 발견되거나, 사용자의 요구가 변경될 수 있다. 이러한 변경 사항들은 SRS에 즉시, 그리고 체계적으로 반영되어야 한다.

이를 위해 엄격한 변경 관리(Change Management) 및 버전 제어(Version Control) 프로세스가 수립되어야 한다. SRS의 특정 요구사항에 대한 변경 요청이 발생하면, 해당 변경이 다른 요구사항, 시스템 설계, 테스트 케이스, 그리고 무엇보다 시스템의 전반적인 안전성에 미치는 영향을 체계적으로 분석해야 한다. 모든 변경 이력은 명확하게 기록되고, 모든 이해관계자에게 최신 버전의 SRS가 공유되어야 한다.10 살아있는 문서로서의 SRS 관리는 프로젝트 후반부에 발생하는 값비싼 재작업을 방지하고, 시스템의 안전 무결성을 끝까지 유지하는 데 필수적이다.

6.3 미래 시스템을 위한 SRS의 진화 방향

인공지능(AI)과 머신러닝(ML) 기술이 자율주행차, 지능형 의료 진단 시스템 등 안전 필수 영역에 점차 도입되면서, 전통적인 요구사항 명세 방식은 새로운 도전에 직면하고 있다. 데이터 기반으로 학습하고 스스로 행동을 결정하는 비결정론적(non-deterministic) 시스템의 안전 요구사항을 어떻게 명확하고 검증 가능하게 명세할 것인가는 현재 기능안전 분야의 가장 중요한 화두 중 하나이다. 이는 단순히 ‘IF-THEN’ 형식의 규칙 기반 요구사항을 넘어, 운영 설계 도메인(ODD) 정의, 데이터의 품질 요구사항, AI 모델의 성능 및 견고성(Robustness) 요구사항 등 새로운 차원의 명세를 요구한다.

이러한 복잡성에 대응하기 위해, 요구사항 명세 방식 또한 진화하고 있다. 자연어 기반의 문서 대신, SysML과 같은 표준 모델링 언어를 사용하여 시스템의 구조, 행위, 요구사항을 통합적으로 관리하는 **모델 기반 시스템 엔지니어링(Model-Based Systems Engineering, MBSE)**의 도입이 확산되고 있다. MBSE 환경에서는 요구사항이 모델의 일부로서 존재하며, 이를 통해 일관성 검증, 변경 영향 분석, 시뮬레이션을 통한 조기 검증이 용이해진다.20 또한, 강력한

요구사항 관리(Requirements Management) 도구를 활용하여 수많은 요구사항 간의 추적성을 자동으로 관리하고, 검토 및 승인 프로세스를 체계화하는 것은 더 이상 선택이 아닌 필수가 되었다.43

결론적으로, 안전 요구사항 명세서는 시스템 안전을 확보하기 위한 가장 근본적인 출발점이다. 기술이 복잡해지고 시스템의 사회적 책임이 커질수록, 명확하고, 완전하며, 검증 가능한 요구사항을 체계적으로 작성하고 관리하는 능력은 미래의 엔지니어링 경쟁력을 좌우하는 핵심 역량이 될 것이다.

7. 참고 자료

요구사항 명세서 작성법 - ernest Dev - 티스토리, https://ernest-o.tistory.com/35
소프트웨어 개발 요구사항 명세서 작성 방법 - Dev Inventory - 티스토리, https://devinventory.tistory.com/20
[IT 기본] 요구사항 정의서 & 요구사항 명세서, https://raflras.tistory.com/3
4장. 요구사항 개발 및 관리 - 차얀의 프로그래밍 노트 - 티스토리, https://chayan-memorias.tistory.com/72
[프로젝트 process-분석] 요구사항 명세서란? - #Not_Defined - 티스토리, https://moon99610.tistory.com/32
요구명세(SRS)의 중요성과 제도화 방향 - SPRi - 소프트웨어정책연구소, https://spri.kr/posts/view/22234?code=data_all&study_type=ai_brief
Safety Requirements Specification (SRS) - Symestic, https://www.symestic.com/en-us/what-is/srs
Safety Requirements Specifications, https://www.canadasafetytraining.com/Safety_Blog/safety-requirements-specifications.aspx
A Taxonomy of Safety-Related Requirements - Software Engineering Institute, https://www.sei.cmu.edu/documents/162/2004_019_001_29423.pdf
Safety Requirements Specification in Functional Safety - Cenosco, https://cenosco.com/insights/safety-requirements-specification-in-functional-safety
Safety Requirements Specifications - Safeopedia, https://www.safeopedia.com/definition/5012/safety-requirements-specifications-srs
Embracing Safety Requirements Specifications - Emerson Automation Experts, https://www.emersonautomationexperts.com/2016/safety/embracing-safety-requirements-specifications/
Safety Requirements Specification (SRS) Development - Mangan SIS, https://mangansis.com/functional-safety-engineering/srs-development/
IEC 61508 Overview Report - Exida, https://www.exida.com/articles/IEC-61508-Overview.pdf
What is ISO 26262 Functional Safety Standard? - Synopsys, https://www.synopsys.com/glossary/what-is-iso-26262.html
IEC 61508 (all parts) - Gt-Engineering, https://www.gt-engineering.it/en/insights/functional-safety-300321/iec-61508-all-parts/
소프트웨어 개발 수명 주기(SDLC) 모델, https://dev-test-hqsw.tistory.com/79
Best Practices for Writing Safety-Critical Requirements - Embedded Computing Design, https://embeddedcomputing.com/technology/security/iec-iso-other-standards/best-practices-for-writing-safety-critical-requirements
Best Practices for Developing Safety-Critical System Software Requirements, https://www.jamasoftware.com/blog/how-to-develop-safety-critical-system-software-requirements/
Best ISO-26262 Compliance Tools, Checklists & Templates - Visure Solutions, https://visuresolutions.com/iso-26262-guide/tools-checklists-templates/
Writing Good Requirements - Space Systems Engineering, https://spacese.spacegrant.org/uploads/Requirements-Writing/Writing%20Good%20Requirements.pdf
Appendix C: How to Write a Good Requirement - NASA, https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/
Writing Verifiable Requirements - Tyner Blain, https://tynerblain.com/blog/2006/06/13/writing-verifiable-requirements/
Volere Requirements Specification Template, https://www.cs.uic.edu/~i440/VolereMaterials/templateArchive16/c%20Volere%20template16.pdf
10 Best Practices in Writing Requirements, https://archives.obm.ohio.gov/Files/Major_Project_Governance/Resources/Resources_and_Templates/04_Plan/37_Requirements_10_Best_Practices.pdf
Logic Notations in LaTeX - GeeksforGeeks, https://www.geeksforgeeks.org/engineering-mathematics/logic-notations-in-latex/
Logic symbols in Unicode, HTML, and LaTeX - Applied Mathematics Consulting, https://www.johndcook.com/blog/logic-symbols/
Set Notations in LaTeX - GeeksforGeeks, https://www.geeksforgeeks.org/engineering-mathematics/set-notations-in-latex/
Math 504 LATEX Symbols, https://web.math.utk.edu/~finotti/files/latex/307symb.pdf
LaTeX Commands to Write Math - Pascal Michaillat, https://pascalmichaillat.org/e/
Safety Requirements Specification - Hargrove Engineers …, https://hargrove-epc.com/wp-content/uploads/2024/02/Safety-Requirements-Specification.pdf
요구사항 명세서(Software Requirement Specification) - Goooooood - 티스토리, https://seing.tistory.com/203
SIL Platform - Brochure Safety Requirement Specification 2021 - NEN, https://www.nen.nl/media/PDFjes/SIL_Platform_-_Brochure_Safety_Requirement_Specification_2021.pdf
Document Title Safety Use Case Example - AUTOSAR.org, https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_EXP_SafetyUseCase.pdf
Safety Requirements Specification | ABB, https://library.e.abb.com/public/04cb0a3a45a9651ec1257b7a003680ad/FSM%20Safety%20Requirements%20Specification.pdf
IEC 61511-3:2016 - Annex F SAFETY REQUIREMENT … - ProSET, http://proset.co.uk/wp-content/uploads/2017/10/Example-SRS-Report.pdf
Safety Requirements Specifications (SRS): The Good and the Bad - exida, https://www.exida.com/blog/safety-requirements-specifications-srs-the-good-and-the-bad
Structure of IEC 61508 - BYHON, https://www.byhon.it/structure-of-iec-61508/
IEC 61508 Commented Version.pdf, https://share.ansi.org/Shared%20Documents/News%20and%20Publications/Other%20Documents/IEC%2061508%20Commented%20Version.pdf
What Is IEC 61508? Determining Safety Integrity Levels (SILs) - Perforce Software, https://www.perforce.com/blog/qac/what-iec-61508-safety-integrity-levels-sils
IEC 61508: A comprehensive guide to functional safety with FAQ - Spyrosoft, https://spyro-soft.com/blog/industry-4-0/iec-61508
ASSESSMENT OF THE ISO 26262 STANDARD, “ROAD VEHICLES – FUNCTIONAL SAFETY” | Volpe, https://www.volpe.dot.gov/sites/volpe.dot.gov/files/docs/Assessment%20of%20the%20ISO%2026262%20Standard,%20%E2%80%9CRoad%20Vehicles%20%E2%80%93%20Functional%20Safety%E2%80%9D.pdf
ISO 26262:2018 & ASPICE Template | 3HTi, https://3hti.com/wp-content/uploads/2024/08/iso-26262-aspicce-codebeamer-template-new.pdf
A Reference Example on the Specification of Safety Requirements using ISO 26262 - IQPC, https://www.iqpc.com/media/9259/28571.pdf
Functional Safety Concept According to ISO 26262 - Hermes Solution, https://www.hermessol.com/2024/06/20/3_7/
ISO 26262 Functional Safety - Cameo Safety and Reliability Analyzer 2022x, https://docs.nomagic.com/spaces/CSRA2022x/pages/92209181/ISO+26262+Functional+Safety
ISO 26262 Functional Safety Concept - BYHON, https://www.byhon.it/iso-26262-functional-safety-concept/
anandman/functional-safety: ISO 26262 Functional Safety Documents - GitHub, https://github.com/anandman/functional-safety
최고의 DO-178C 규정 준수 도구, 체크리스트 및 템플릿 - Visure Solutions, https://visuresolutions.com/ko/%ED%95%AD%EA%B3%B5-%EC%9A%B0%EC%A3%BC-%EB%B0%8F-%EB%B0%A9%EC%9C%84/178c-%EC%B2%B4%ED%81%AC%EB%A6%AC%EC%8A%A4%ED%8A%B8%EC%99%80-%EB%8F%84%EA%B5%AC%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%84%B8%EC%9A%94/
DO-178C란 무엇입니까?, https://visuresolutions.com/ko/%ED%95%AD%EA%B3%B5-%EC%9A%B0%EC%A3%BC-%EB%B0%8F-%EB%B0%A9%EC%9C%84/178c%EB%A5%BC%ED%95%98%EB%8B%A4/
3팀 주재빈, 소경현, 이정우, [http://dslab.konkuk.ac.kr/class/2020/20SV/Team%20Project/functional%20safety/T3]ppt.pdf
DO-178C란? - Ansys, https://www.ansys.com/ko-kr/simulation-topics/what-is-do-178c
RTCA DO-178C와 새로운 RESSAC 소프트웨어 인증기술의 비교 분석, https://koreascience.kr/article/JAKO202010163508625.pdf
표준감항인증 기준 SW 적합성 검증 - (주)모아소프트, https://moasoftware.co.kr/case_study/military-aircraft-standard/
의료기기 소프트웨어 밸리데이션 가이드라인 (Guidelines for Software Validation of Medical devices) - 한국화학융합시험연구원, https://ktr.or.kr/kor/data/%EC%9D%98%EB%A3%8C%EA%B8%B0%EA%B8%B0_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EB%B0%B8%EB%A6%AC%EB%8D%B0%EC%9D%B4%EC%85%98_%EA%B0%80%EC%9D%B4%EB%93%9C%EB%9D%BC%EC%9D%B8.pdf
의료용 소프트웨어 심사 가이드라인.hwp, http://www.mdworkskorea.com/module/board/download.php?boardid=pds&b_idx=102&idx=516
의료기기 소프트웨어밸리데이션 가이드라인 | PDF - Scribd, https://www.scribd.com/document/852544816/%EC%9D%98%EB%A3%8C%EA%B8%B0%EA%B8%B0-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EB%B0%B8%EB%A6%AC%EB%8D%B0%EC%9D%B4%EC%85%98-%EA%B0%80%EC%9D%B4%EB%93%9C%EB%9D%BC%EC%9D%B8
8 Characteristics Of A Positive Safety Culture - Infinit-I, https://infinitiworkforce.com/2024/12/30/positive-safety-culture/
Characteristics of an Excellent Safety Culture - KTL, https://kestrelmanagement.com/characteristics-of-an-excellent-safety-culture/