상위,하위 문서의 1:N, N:1 관계

계속해서 기능안전 문서에 대해서 질문을 할건데, 요구사양서에서 아키텍처 설계서로 아키텍처 설계서에서 상세 설계서로 요구사항을 할당하자나 그러면 일반적으로는 상위 문서에서 하위 문서로 갈수록 1:n의 관계처럼 점점 요구사항이 여러개로 분해 되는게 일반적이지? 그 역의 경우도 있어?

 

정확히 짚으셨습니다. 기능안전 개발 프로세스에서는 일반적으로 상위 문서에서 하위 문서로 요구사항을 할당할 때 1:N (one-to-many) 관계가 일반적인 흐름입니다. 즉,

• 하나의 상위 요구사항이 여러 개의 하위 요구사항, 아키텍처 구성요소, 상세 기능으로 분해되어 할당됩니다.

예:

기능 요구사항 ① → SW 모듈 A, B, C로 분해 → 각 모듈에 대한 상세 설계 항목으로 이어짐

---

하지만, 다음과 같은 상황에서는 N:1 (many-to-one) 혹은 N:M (many-to-many) 관계도 발생할 수 있습니다.

---

🔁 N:1 관계가 발생할 수 있는 경우 (역의 경우)

1. 여러 요구사항이 하나의 기능 또는 모듈로 통합되는 경우

• 예: 시스템 요구사항 중 "온도 경고"와 "속도 경고"가 모두 하나의 공통 경고 제어기(logic)에 의해 처리되는 경우
  → 두 개의 요구사항이 하나의 아키텍처 블록에 매핑됨

2. 다수의 기능 요구사항이 동일한 인터페이스나 하드웨어 리소스를 공유하는 경우

• 예: "디버깅용 로깅 기능"과 "에러 보고 기능"이 동일한 UART 포트를 통해 전송되는 경우
  → 서로 다른 요구사항이 하나의 자원/인터페이스에 할당됨

3. 소프트웨어 기능 재사용

• 하나의 SW 함수나 모듈이 여러 기능 요구사항을 처리하는 경우
  → 기능 통합 또는 재사용에 의해 N개의 요구사항이 하나의 상세 설계로 이어질 수 있음

4. 요구사항 통합 시 (상향 통합, Abstraction)

• 하위 설계 또는 구현 수준에서 도출된 여러 내부 요구사항이 상위 레벨의 추상 요구사항으로 다시 통합되어 설명되는 경우
  (예: Verification coverage, FMEA 결과 등에서 파생된 요구들이 하나의 Safety Goal을 만족)

---

🔀 N:M 관계 예시

• 때로는 여러 상위 요구사항이 여러 하위 모듈과 복합적으로 연관되는 경우도 있어요.
• 예:
  • Safety Goal 1은 BSW 모듈과 SWC 두 개에 동시에 관련
  • Safety Goal 2도 동일한 두 모듈에 관련
    → 이 경우는 N:M 추적 매트릭스가 필요합니다 (DOORS, Jama 등에서 관리)

✅ 기능안전 관점에서 중요한 점

• 어떤 관계든지 **정당한 근거(Reasoning)**와 **추적성(Traceability)**만 확보되어 있다면 문제는 아닙니다.
• 다만, 역방향(N:1) 또는 다대다(N:M) 관계가 많아지면 복잡도 증가, 오해 소지, 테스트 누락 위험이 있기 때문에 추적 매트릭스와 설계 근거 문서화가 필수입니다.