OEM의 기본 사양서 (ex: 현대기아의 ES, MS스펙 문서)를 요구사양서에 작성하는 법

ES/MS 스펙 “문서 이름”을 그대로 요구사항으로 가져오면 안 되는 이유는 “요구사항이 아니라 참조 문서(reference)”이기 때문입니다.

그리고 그 이유는 단순히 버전 문제 하나가 아니라 구조적으로 4~5가지 중요한 이유가 있습니다.

---

✅ 1️⃣ 가장 핵심 이유: “요구사항 vs 참조문서” 차이

ES/MS 스펙은 본질적으로:

요구사항 문서 ❌ (direct requirement 아님)
외부 표준/참조 문서 ✅

 

즉

"ES95400-10 적용"

 

이건 요구사항이 아니라

👉 “이 문서를 참고해라”는 선언

---

문제

이걸 그대로 쓰면:

❌ Requirement: ES95400-10 적용

 

👉 이건 검증 불가능한 요구사항

---

올바른 방식

✔ The system shall comply with voltage transient requirements defined in ES95400-10, clause 4.2.

 

👉 구체화 + testable

---

✅ 2️⃣ 버전 문제 (네가 말한 핵심 포인트 맞음)

ES/MS는 자주 개정됩니다.

예:

ES95400-10 Rev.A → Rev.B → Rev.C

 

---

문제

Requirement: ES95400-10 적용

 

👉 어느 버전인지 모름

---

실제 위험

• 개발 중간에 고객이 Rev 변경
• 어떤 기준으로 설계/시험했는지 불명확
• Audit에서 바로 질문 나옴

---

올바른 방식

✔ ES95400-10 Rev.B 기준 적용

 

또는

👉 Stakeholder requirement에서 version freeze

---

✅ 3️⃣ 제품 적용 범위 문제 (매우 중요)

ES/MS는 항상 “전체 차량 기준”입니다.

하지만

👉 우리 제품(ECU)은 일부만 해당됨

---

문제

ES spec 전체 적용

 

👉 불필요 요구 포함 / 적용 불가 요구 포함

---

예

• 차량 전체 요구 vs 특정 ECU
• High voltage vs Low voltage ECU

---

올바른 방식

✔ Applicable clauses only extracted
✔ Product-specific tailoring

 

---

✅ 4️⃣ 요구사항 분해 필요 (Allocation 문제)

ES/MS는 보통 이렇게 되어 있음:

- 환경 요구
- 전기 요구
- EMC 요구
- 시험 방법

 

---

문제

그대로 쓰면:

❌ 하나의 요구사항으로 묶임

 

---

실제 개발에서는

System requirement
→ Hardware requirement
→ Software requirement

 

로 나눠야 함

---

예

ES 요구:

Voltage drop tolerance

 

↓

HW requirement: power circuit design
SW requirement: undervoltage handling logic

 

---

✅ 5️⃣ 검증 가능성 (ISO 26262 핵심)

ISO 26262 / ASPICE 둘 다 요구:

요구사항은 검증 가능해야 함

---

문제

ES95400 적용

 

👉 어떻게 검증함?

---

올바른 방식

✔ The ECU shall withstand voltage drop to 6V for 10ms without reset.

 

👉 testable

---

✅ 6️⃣ Traceability 문제

ES/MS 그대로 쓰면:

Requirement ↔ Test 연결 불가

 

---

왜냐하면

• 요구사항이 너무 큼
• Clause 단위로 쪼개지지 않음

---

좋은 구조

ES Clause → Stakeholder Requirement → System Requirement → Test Case

 

---

✅ 7️⃣ Safety 관점 문제 (중요)

ES/MS에는 Safety 요구도 포함될 수 있음

근데 그대로 쓰면:

Safety relevance 분석 불가

 

---

문제

• ASIL 할당 불가
• Safety goal 연결 불가

---

✅ 8️⃣ 정리 (왜 그대로 쓰면 안 되는가)

 

✅ 9️⃣ 평가자가 실제로 보는 포인트

ASPICE SYS.1에서 질문:

How are customer standards (ES/MS) transformed into stakeholder requirements?

---

❌ 나쁜 답

We use ES spec directly

 

→ NC 가능

---

✅ 좋은 답

Relevant clauses are extracted, tailored, and transformed into stakeholder requirements with clear, testable criteria and traceability.

 

---

🔟 한 줄 핵심 정리

ES/MS는 요구사항이 아니라 “입력 표준”이므로, 제품에 맞게 선별·구체화·분해하여 Stakeholder Requirement로 변환해야 한다.

---

🔥 실무 팁 (진짜 중요)

좋은 조직은 이렇게 합니다:

ES/MS Spec
↓
Applicable Clause List (Tailoring)
↓
Stakeholder Requirements
↓
System/HW/SW Requirements

 

👉 이 중간 단계(Clause 추출)가 있으면
👉 ASPICE에서 거의 무조건 좋게 봅니다