(기능안전 18강) SW Safety Requirements 작성 요령 – 요구사항, 이렇게 씁니다!

📄 18강. SW Safety Requirements 작성 요령 – 요구사항, 이렇게 씁니다!

안녕하세요, 기능안전 SW 개발자 여러분! 🖐
오늘은 “도대체 이 소프트웨어 안전 요구사항, 어떻게 쓰는 거야?”
하고 머리를 쥐어뜯던 그 순간을 깔끔하게 정리해 드리는 시간입니다.

 

오늘의 목표는 딱 하나!
TSR(Technical Safety Requirement)에서 SSR(Software Safety Requirement)로
정확하고 명확하게 요구사항을 도출하고 작성하는 법을 알려드립니다! ✍️

---

🔄 1. TSR → SSR 도출, 어떻게 연결되나요?

🤔 TSR이란?

시스템 또는 하드웨어/소프트웨어 수준에서 구현 가능한 기술적 요구사항.
예: “차량 정지 상태에서 100ms 이내에 브레이크 모터를 구동해야 한다.”

✅ 그럼 SSR은?

해당 TSR을 소프트웨어 관점에서 책임지고 구현하기 위한 SW 기능 요구사항

💡 연결 방식

TSR	대응하는 SSR
TSR-01: 차량 속도 확인 후 정지 상태 판단	SSR-01: SW는 10ms 주기로 차량 속도 입력값을 수신해야 한다.
TSR-02: 브레이크 모터 구동 신호 발생	SSR-02: SW는 정지 상태 조건 만족 시 100ms 이내에 구동 명령을 송신해야 한다.
TSR-03: 이상 상황 진단 및 Safe 상태 전환	SSR-03: 센서 오류 발생 시, SW는 즉시 진단 코드를 생성하고 Fail-safe 모드로 진입해야 한다.

📌 한 TSR이 여러 SSR로 분해될 수도 있고, 하나의 SSR이 복수 TSR을 만족시킬 수도 있습니다.

---

✍️ 2. 좋은 SSR, 이렇게 쓰세요!

✨ SSR 작성 시 체크리스트

항목	설명
✅ 명확성	누구나 이해 가능한 문장으로 (예: “즉시” 대신 “100ms 이내에”)
✅ 검증 가능성	나중에 테스트가 가능한 조건 포함
✅ 구현 독립성	“if-else로 구현” 같은 말은 금물!
✅ 추적 가능성	어떤 TSR에서 유도되었는지 명시
✅ ASIL 반영	요구사항마다 안전 등급 명시 (예: ASIL C)

---

🙅‍♂️ 3. 나쁜 요구사항 예시 vs. 좋은 요구사항 예시

나쁜 예시	좋은 예시
"센서 신호를 처리해야 한다."	"SW는 매 10ms마다 센서 입력값을 수신하고 유효성 검사를 수행해야 한다."
"오류가 발생하면 알려야 한다."	"SW는 센서 오류 발생 시, 50ms 이내에 DTC를 기록하고 CAN 메시지를 전송해야 한다."
"사용자에게 경고를 띄운다."	"SW는 오류 조건 충족 시, 100ms 이내에 경고등 제어 신호를 GPIO 핀으로 출력해야 한다."

🚨 키포인트: 측정 가능한 조건과 수치를 반드시 포함하세요!

---

🧠 4. 실무 중심 SSR 작성 전략

1) 구조적 요구사항 분할

• 입력 처리 요구사항 (Input)
• 논리 처리 요구사항 (Processing)
• 출력 제어 요구사항 (Output)
• 진단/오류 처리 요구사항 (Fault Handling)

2) 인터페이스 명확화

• 어떤 데이터?
• 어디에서 받아서?
• 누구에게 전달?
• 어떤 주기로?

3) 표준화된 표현 사용

• "SW는 ~해야 한다" (Shall / Must)
• "정해진 주기", "오류 발생 시", "100ms 이내에" 등 정량적 표현 필수

---

✅ 실무 체크포인트

항목	체크 내용
🔲 각 SSR은 TSR과 명확히 매핑되었는가?
🔲 SSR의 실행 조건, 입력, 출력이 명확히 정의되었는가?
🔲 검증 가능성(Validation Criteria)이 포함되어 있는가?
🔲 ASIL 등급이 명시되어 있는가?
🔲 변경 시 영향 범위 추적이 가능한가? (Traceability Matrix 활용)

---

🧾 작성 템플릿 예시

항목	내용
SSR ID	SSR-001
관련 TSR	TSR-003
설명	SW는 토크 센서 신호가 200ms 이상 유효 범위를 벗어나는 경우, Safe 모드로 전환하고 CAN 메시지 전송을 수행해야 한다.
조건	센서 입력 주기: 10ms, 유효 범위: ±5Nm
출력	진단 플래그 ON, CAN 메시지 송신
ASIL 등급	ASIL C
검증 항목	Fault Injection 테스트, CAN 로그 분석

---

🏁 오늘의 요약

• SSR은 TSR을 소프트웨어 관점에서 세분화한 요구사항!
• 좋은 SSR은 명확성, 검증 가능성, ASIL 명시, 구현 독립성이 핵심
• 실무에서는 SSR 간 Traceability와 테스트 가능성까지 확보해야 완성!

---

🔮 다음 강 예고

“요구사항은 썼는데, 그걸 어디에다 연결하죠?”

다음 시간에는 SW Architecture Design에서 자주 빠뜨리는 포인트들을
설계 흐름과 함께 짚어드립니다!

19강: SW Architecture Design에서 놓치기 쉬운 포인트 – 구조 설계의 함정들

기대해 주세요! 🧱📐