시스템요구사양서 분석 실전 기록

시스템 요구사항에서 system state transition diagram과 함께 각 state에 대한 요구사항 설명이 되어 있는데. 이 각 요구사항의 verification criteria에 특정 물리적 혹은 논리적 값없이 설명이 되어 있고, 이 각 요구사항 설명에도 특정 물리적 혹은 논리적 값 없이, "wake up 조건을 만족하지 못할떄는 sleep모드 상태를 유지 해야 한다."정도만 작성되어 있는데. 문제 없어 보여?

 

문제가 매우 큽니다. 이는 검증(Verification) 불가능한 요구사항으로, ASPICE나 ISO 26262 관점에서 심각한 결함입니다.

"문제 없어 보인다"는 생각은 함정입니다. 이는 추상적 설계 문서 수준에 머물러 있으며, 검증 가능한 시스템 요구사항으로는 부족합니다.

---

1. 왜 문제인가? 핵심 원리

요구사항의 기본 속성 중 하나는 "검증 가능성(Verifiability)" 입니다. 즉, 개발이 끝난 후, 누군가가 객관적이고 측정 가능한 방법으로 해당 요구사항이 충족되었는지 '예' 또는 '아니오'로 답할 수 있어야 합니다.

현재 상태의 요구사항은 이 기준에 완전히 부합하지 않습니다.

---

2. 현재 요구사항의 문제점 분석

요구사항: "wake up 조건을 만족하지 못할 때는 sleep 모드 상태를 유지해야 한다."

이 문장에는 검증을 위한 기준이 전혀 없습니다.

결론: 이 요구사항을 받은 검증 엔지니어는 아무것도 할 수 없습니다.

---

3. 어떻게 고쳐야 하는가? (검증 기준 포함 요구사항 작성법)

요구사항은 "조건 + 행위 + 검증 기준" 의 구조를 가져야 합니다. 시스템 State Transition 요구사항은 특히 구체적이어야 합니다.

Bad Example (현재 상태):

SR-01: wake up 조건을 만족하지 못할 때는 sleep 모드 상태를 유지해야 한다.

Good Example (개선 후):

1. 먼저, 관련된 용어와 상태를 명확히 정의합니다.
   • Wake-up Condition: CAN_Wakeup 신호 = High(>3.3V) 또는 Ignition 신호 = On(배터리 전압 > 9V) 또는 RKE_Signal 수신.
   • Sleep Mode State: MCU 코어 클록 정지, Current Consumption < 100µA, CAN Transceiver는 수신 모드 대기.
2. 이 정의를 바탕으로 검증 기준이 포함된 요구사항을 재작성합니다.
   • SR-01.1 (상태 유지): Wake-up Condition에 정의된 모든 신호가 비활성 상태일 때, 시스템은 Sleep Mode State를 유지해야 한다.
     • Verification Criteria: Wake-up Condition 신호들을 모두 비활성화한 후 2초 이내에 시스템 전체 전류를 측정할 때, Current Consumption이 100µA 미만이어야 한다.
   • SR-01.2 (잘못된 조건 방지): Wake-up Condition 중 하나만 부분적으로 활성화되었을 때(예: CAN_Wakeup 신호만 2.5V) 시스템은 Sleep Mode State를 유지해야 한다.
     • Verification Criteria: CAN_Wakeup 신호에 2.5V (±0.1V)를 인가하고 다른 조건은 비활성화했을 때, 시스템 전체 전류가 100µA 미만이어야 한다.

---

4. 시스템 State Transition 요구사항의 좋은 예시 패턴

State Transition 다이어그램의 각 호(Edge)와 상태(State)에 대해 다음과 같은 요구사항 세트가 필요합니다.

 

결론 및 다음 행동

현재 문서는 문제가 매우 큽니다. 이대로 두면:

1. 검증 팀과 갈등이 발생합니다.
2. ASPICE 평가에서 VER.3 (검증 수준) 과 SYS.2 (시스템 요구사항 분석) 에서 주요 결함(Non-compliance)으로 지적될 가능성이 매우 높습니다.
3. ISO 26262 에서는 안전 요구사항이 검증 불가능하다는 것 자체가 표준 위반입니다.

즉시 진행해야 할 작업:

1. State Transition Diagram의 각 상태와 전이에 대해 명확한 물리적/논리적 조건과 값을 정의합니다.
2. 각 요구사항에 검증 방법(시험, 분석, 검토, 데모)과 구체적인 통과 기준(측정값, 범위, 타이밍)을 포함시켜 재작성합니다.
3. 요구사항 추적표에 이 검증 기준을 연결하고, 검증 계획서에는 이 기준을 사용한 구체적인 시험 절차가 작성될 수 있도록 합니다.

시스템 요구사양서에 DTC기능을하는 요구사항이 있는데 그 요구사항 설명 부분에 DTC관련 요구사항을 쭉 쓰다가 "※과거 고장 코드는 기록하지 않는다."라고 되어 있거든? 품질보증 담당자 입장에서 이렇게만 쓰여 있으면 이 부분이 고객의 요구사항으로부터 내려온 요구사항인지 아니면 기술적 제약으로 인한 제약사항을 쓴 건지 구분이 안간다고 생각하는데, 너는 어떻게 판단해?

 

품질보증 담당자로서의 의심은 완전히 정당합니다. 이 문구는 그 자체로 애매모호하고, 출처와 근거가 불분명한 요구사항입니다. 이는 향후 검증과 변경 시 큰 문제를 일으킬 수 있는 불량 요구사항에 가깝습니다.

---

제 판단: 이것은 명확화가 시급한 '불량 요구사항'입니다.

이 문구에는 다음과 같은 중대한 정보가 누락되어 있습니다:

1. 출처 (Source): 누구의 요구사항인가? (고객? 법규? 내부 아키텍처 결정?)
2. 근거 (Rationale): 왜 그런 결정을 했는가? (기술적 제약? 비용? 다른 대안이 있나?)
3. 범위 (Scope): '과거'의 정의는? (이번 Ignition Cycle? 차량 평생? 메모리 초기화 시점?)
4. 명세 (Specification): '기록하지 않는다'의 정확한 의미는? (메모리에 절대 안 쓴다? 전원 차단 시 삭제한다? 진단 통신으로는 보여주지 않는다?)

---

이 문구의 가능한 두 가지 출처와 그에 따른 품질보증 담당자의 대응

시나리오 1: 고객/법적 요구사항 (External Requirement) 으로 판단될 경우

• 의미: "운전자의 프라이버시 보호" 또는 "과거 데이터로 인한 오해 방지"를 위해, 차량 수리 후에는 과거 고장 기록이 완전히 삭제되어야 한다는 고객의 명시적 요구일 수 있습니다.
• 검증 방법: 고객 요구사항 명세서, 시스템 요구사항 추적표를 확인하여, 해당 문구가 고객 요구사항 ID (예: CUS-REQ-123) 에 연결되어 있는지 확인합니다.
• 개선 방향 (QA로서의 피드백):
• "해당 요구사항이 고객 요구사항 CUS-REQ-XXX 에서 유래되었다면, 요구사항 명세에 그 추적 정보를 명시해 주세요. 또한 '과거'의 구체적인 범위(예: '이전 점화 사이클')와 '기록하지 않음'의 구현 수준(예: 비휘발성 메모리 미저장)을 명확히 기술해야 검증이 가능합니다."

시나리오 2: 내부 기술적/설계 제약사항 (Design Constraint) 으로 판단될 경우

• 의미: ECU의 메모리 용량 부족이나 소프트웨어 복잡도 감소를 이유로 한 내부 설계 결정일 가능성이 훨씬 높습니다.
• 검증 방법: 시스템 아키텍처 문서, 하드웨어 자원 정의서, 또는 내부 검토 회의록에서 이 결정의 근거(메모리 분석 보고서 등) 를 찾아봅니다.
• 개선 방향 (QA로서의 피드백 - 이 경우가 더 흔하고 중요):
• "'※과거 고장 코드는 기록하지 않는다'는 문구는 기술적 제약사항으로 보입니다. 요구사항이 아닌 '제약사항(Constraint)' 으로 분류하고, 그 근거(예: RAM 2KB 부족) 를 함께 문서화해야 합니다. 또한, 이로 인해 파생되는 검증 요구사항(예: '전원 Off-On 후 과거 DTC가 조회되지 않음을 확인')을 별도로 도출해야 합니다."

---

품질보증 담당자로서의 구체적 행동 가이드

이러한 애매한 요구사항을 발견했을 때 다음과 같은 체계적인 접근을 취해야 합니다:

1. 출처 추적 (Traceability):
   • 시스템 요구사항 추적표에서 이 문구의 상위 요구사항이 고객 요구사항인지, 하드웨어 제약인지, 아니면 '기술시스템 요구사항'으로 분류되었는지 확인하세요. 출처가 없으면 바로 이슈를 제기하세요.
2. 명확화 요청 (Clarification):
   • 시스템 엔지니어/아키텍트에게 다음과 같은 구체적인 질문을 던지세요:
     • Q1: "이 요구사항의 출처와 근거는 무엇입니까? (고객 요구사항 문서 XX페이지 / 메모리 제약 분석 보고서 등)"
     • Q2: "'과거'의 정확한 정의는 무엇입니까? 이번 주행 사이클만? ECU 수명 전체?"
     • Q3: "'기록하지 않는다'의 구체적 구현은 무엇입니까? 메모리 할당 자체를 안 하는 것인가요? 아니면 전원 Off 시 휘발성 메모리만 사용하는 것인가요?"
     • Q4: "이 결정의 대안(예: 최근 10개만 기록) 을 검토했고, 현재 선택이 최선이라는 것을 증명할 자료가 있습니까?"
3. 문서화 개선 제안 (Proposal for Improvement):
   • 요구사항을 다음과 같이 재작성할 것을 제안하세요:
     • 케이스 A - 제약사항으로 분류 시:
     • 제약사항 CON-MEM-01: DTC 히스토리 저장 기능은 ECU의 비휘발성 메모리(NVM) 용량 부족(가용 1KB)으로 인해 구현이 불가능하다. 따라서, DTC는 현재 점화 사이클(Ignition Cycle) 동안에만 유지되며, 전원이 꺼지면 모든 DTC 기록이 삭제되어야 한다.
       • 출처: HW 자원 정의서 v2.1, 페이지 5.
       • 파생 검증 요구사항: VER-DTC-01: 전원 Off-On 시퀀스 후, 진단 스캔 툴로 이전에 설정된 DTC가 조회되지 않음을 확인해야 한다.
     • 케이스 B - 고객 요구사항으로 분류 시:
     • 시스템 요구사항 SYS-DTC-10: 고객의 프라이버시 요구에 따라, 차량의 수리 이력이 저장되지 않도록 해야 한다. 따라서, 정비 기술자가 DTC를 삭제(Clear)한 후에는 해당 고장 코드가 어떠한 형태로도 복구되어서는 안 된다.
       • 출처: 고객 요구사항 CUS-PRIV-03.
       • 파생 검증 요구사항: VER-DTC-02: DTC 삭제 명령 수행 후, ECU의 비휘발성 메모리를 직접 읽거나 특수 진단 도구를 사용하더라도 삭제된 DTC 데이터가残留하지 않음을 확인해야 한다.

결론

"※과거 고장 코드는 기록하지 않는다."라는 문구는 품질보증 담당자의 관점에서 즉시 이슈를 제기해야 할 '레드 플래그' 입니다.

이 문구는 요구사항 관리의 기본 원칙(명확성, 추적성, 검증 가능성)을 모두 위반하고 있습니다. QA로서 이를 지적하고 명확히 하지 않으면, 이후 검증 단계에서 무수한 논쟁이 발생할 것이며, 최악의 경우 고객에게 설명할 수 없는 동작으로 이어질 수 있습니다.

바로 해당 요구사항 담당 시스템 엔지니어와 미팅을 잡아, 위의 질문들을 통해 그 출처, 근거, 명세를 확정지으세요. 이것이 바로 QA가 프로젝트에 가치는 부가하는 순간입니다.