개발문서(사양서, 아키텍처 설계서)를 변경할 때 조치해야 할 부분

시스템 요구사양서, 시스템 아키텍처 설계서 같은 이런 개발 문서들은 변경이력이 있을 때 그 변경한 부분에 대해서 문서 내의 History 부분에 쓰는데, 변경한 내용에 대한 서술 방식이 너무 단순해서, 정확히 어떤 부분을 변경했는지, 그리고 왜 변경했는지 이유를 알기가 어려워. 이럴 경우 어떻게 해야 돼?

 

네, 기능안전(ISO 26262) + ASPICE 프로젝트에서 시스템 요구사양서(SRS), 시스템 아키텍처 설계서(SAD) 같은 문서의 History / Revision History / Change History 섹션이 "버전 업 → 날짜 → 작성자 → 변경" 정도로만 단순하게 적혀 있으면 정말 문제입니다. 나중에 감사(audit)나 assessment 시 assessor가 "이 변경이 Safety Goal에 미치는 영향은? 왜 이걸 바꿨나? Impact analysis 했나?"라고 물을 때 증적을 바로 못 보여주면 큰 약점이 됩니다.

왜 단순 서술이 문제가 되는가?

• ISO 26262 Part 8 Clause 7 (Configuration Management): 변경 시 "relations and differences between earlier and current versions can be traced" + 변경 이유를 명확히 해야 함.
• SUP.10 Change Request Management (ASPICE PAM 4.0): 변경 분석(impact), traceability, approval을 요구 → 단순 "변경함"으로는 부족.
• 실무에서 가장 자주 떨어지는 지점: "왜(Why)" + "무엇(What exactly)" + "영향(Safety impact)" 이 빠지면 traceability와 consistency가 약해 보임.

좋은 변경 이력 서술 방식 (실무 베스트 프랙티스)

History 테이블을 아래처럼 구조화하면 assessor가 만족하고, 나중에 본인도 쉽게 이해할 수 있습니다.

 

핵심 요소 설명 (이걸 넣으면 거의 문제없음)

1. CR 번호 : SUP.10에서 관리하는 Change Request ID 필수 연계 (traceability)
2. What was changed : 정확한 위치 + 구체적 변경 전/후 (e.g., "Section 4.2.3, line 17: 'minify' → 'embiggen'" 식으로)
   • 가능하면 "Tracking changes" 기능(Word)이나 diff 툴 스크린샷 첨부
3. Why : 고객 요구, 테스트 실패, FMEA/SPFM 개선, 오타 수정 등 근본 이유 명확히
4. Impact & Justification (가장 중요!):
   • Safety 관련 변경이면 → "ASIL 영향? FMEDA/FTA 재분석 결과? 새로운 hazard?"
   • Non-safety면 → "기능 영향 없음" 또는 "Performance만 향상"
   • 없으면 "No safety impact" 한 줄이라도 써야 함
5. 승인자 : Functional Safety Manager 또는 CCB(Change Control Board) 서명/이름

실무 팁 (이렇게 하면 편함)

• 템플릿 고정 : 회사/프로젝트별 History 테이블 양식 하나 만들어서 모든 문서에 동일하게 적용
• 도구 활용 :
  • Polarion / Jira / Doors → 자동으로 CR 링크 + impact traceability 생성
  • Word/PDF → "Review → Track Changes" 켜고 변경 후 History에 요약
• 간단 변경은 한 줄로 : 오타 수정이면 "Typos corrected in sections 3.1, 5.2. No impact." 정도로 충분
• 큰 변경은 별도 Impact Analysis Report 첨부 (CR 문서 참조)
• 매 릴리스마다 : Baseline 버전 발행 시 History를 최종 확인하고 "All changes traced to approved CRs" 한 줄 추가

이 방식으로 하면

• Assessor가 "좋아요, traceability 잘 됐네요" 할 확률 90% 이상
• 나중에 "이 부분 왜 바꿨지?" 할 때 30초 만에 이유 찾음

 

근데 개발 문서를 베이스라인 긋기 전인데 항상 변경 때마다 변경 관리 절차를 수행해야할까? 변경 근거나 영향 파악은 해야될거 같기는한데

 

 

네, 베이스라인을 긋기 전(즉, 문서가 아직 공식 Baseline 버전으로 확정되지 않은 초기 개발 단계) 에서도 변경이 발생할 때는 변경 관리 절차(SUP.10 Change Request Management)를 적용하는 게 맞습니다. 하지만 항상 풀 프로세스를 100% 수행할 필요는 없고, 실무적으로는 변경의 성격과 영향도에 따라 스케일링해서 적용하는 게 표준적입니다.

왜 베이스라인 전에도 변경 관리를 해야 하나?

Automotive SPICE PAM 4.0 SUP.10의 목적과 BP(Base Practice)를 보면:

• SUP.10 전체 목적: "Change requests are recorded, analysed, tracked, approved, and implemented." → 개발 초기부터 work product(요구사양서, 아키텍처 설계서 등)에 대한 변경을 통제해야 함.
• SUP.10.BP1: Develop a change request management strategy → 프로젝트 시작 시 전략을 세우고, baseline 여부와 상관없이 적용 범위를 정의.
• SUP.10.BP2: Analyze and assess change requests → 모든 변경 요청에 대해 impact 분석(영향 파악)을 해야 함.
• SUP.10.BP3: Approve change requests before implementation → 구현 전에 승인 (baseline 전이라도 "승인"은 필요).
• SUP.10.BP4: Establish bidirectional traceability → 변경으로 영향을 받는 work product 간 traceability 유지.

baseline 전 문서는 "draft"나 "working version"이지만, 이미 SYS.2/SYS.3 등의 출력물로 traceability가 시작되기 때문에, 작은 변경이라도 "왜 바꿨나? 영향은? 안전 관련인가?" 를 기록하지 않으면 나중에 consistency / traceability 가 깨져서 assessment 시 PA 2.1~2.2에서 약점으로 지적됩니다.

ISO 26262 Part 8 Clause 7 (Configuration Management)에서도 "relations and differences between earlier and current versions can be traced" + 변경 시 impact를 관리하라고 하니, baseline 전부터 적용 원칙입니다.

실무에서 어떻게 구분해서 적용하나? (스케일링 팁)

프로젝트 대부분이 이렇게 운영합니다. (assessor도 이 정도면 이해하고 인정)

추천 실무 접근법 (베이스라인 전 단계)

1. 프로젝트 초기에 Change Request Management Strategy (SUP.10.BP1)를 문서화: "Baseline 전: Low-impact 변경은 History에 간단 기록 + CR 생략 가능. Medium/High-impact는 CR 필수 + Impact 분석."
2. 모든 변경은 History 테이블에 최소한 기록 (앞서 공유한 템플릿처럼 Why/What/Impact 포함).
3. Baseline 긋기 직전에는 모든 draft 변경을 CR로 정리해서 한 번에 승인/반영 → baseline에 깨끗하게 들어감.
4. 도구 활용: Polarion/Jira/Doors NG 등에서 draft 버전도 CR workflow를 태우면 자동으로 traceability가 쌓임.

결론: 변경 근거와 영향 파악은 반드시 해야 합니다. (baseline 전이라도!) 하지만 항상 풀 CR 프로세스를 돌릴 필요는 없고, 변경 영향도에 따라 스케일링해서 적용하세요. 이렇게 하면 SUP.10 PA 2.1/2.2를 안전하게 충족하면서도 과도한 overhead를 피할 수 있어요.