ASPICE - SYS.2 System Requirement Analysis / 시스템 요구사항 분석 정리

1. Introduction

ADAS/자율주행 소프트웨어 개발을 처음 접하는 엔지니어들을 위해, Automotive SPICE(ASPICE) 4.0의 SYS.2 System Requirements Analysis 프로세스를 설명해드리겠습니다. 이 포스트에서는 SYS.2 프로세스의 목적, 결과(Outcome), 기본 수행활동(Base Practice), 그리고 산출물(Output Information Item)을 하나씩 해설하고, 자동 긴급 제동장치(AEB) 예제를 통해 실무 적용 방법과 양질의 산출물이 어떤 모습이어야 하는지 알아보도록 하겠습니다.

2. SYS.2 프로세스의 목적과 결과 (Purpose & Outcomes)

ASPICE 4.0 SYS.2 시스템 요구사항 분석 프로세스의 목적은 이해관계자 요구사항과 일치하는 체계적이고 분석된 시스템 요구사항 세트를 수립하는 것입니다. 쉽게 말해, Stakeholder로부터 받은 상위 요구를 토대로 차량 시스템이 충족해야 할 구체적인 시스템 요구사항을 만들어내는 단계입니다.

 

이 프로세스를 통해 달성해야 할 프로세스 결과(Outcome)들은 다음과 같이 여섯 가지로 정의됩니다:

1. 시스템 요구사항이 명세되었다. – 시스템이 수행해야 할 기능적/비기능적 요구사항들이 정의되고 문서화됨.
2. 시스템 요구사항이 구조화되고 우선순위가 지정되었다. – 식별된 요구사항들이 체계적으로 분류되고 (예: 기능 영역별, 구성요소별 등), 중요도나 릴리스 계획 등에 따라 우선순위가 부여됨.
3. 시스템 요구사항이 정확성과 기술적 타당성 측면에서 분석되었다. – 명세된 요구사항들이 서로 모순되거나 오류가 없는지, 현실적으로 구현 가능한지 검토됨. 기술적 위험이나 구현 가능성(feasibility)이 평가되어 필요시 조정함.
4. 시스템 요구사항이 운영 환경(시스템 컨텍스트)에 미치는 영향이 분석되었다. – 정의된 요구사항으로 인해 차량/제품의 상위 시스템이나 주변 환경에 어떤 영향이 발생하는지 평가됨. (예: 다른 ECU나 센서와의 인터페이스 영향, 전원/열환경 영향 등)
5. 시스템 요구사항과 이해관계자 요구사항 간 일관성 및 양방향 추적성이 확보되었다. – 시스템 요구사항이 상위 Stakeholder 요구사항을 모두 커버하고 있으며, 각 요구사항 간에 양방향 추적성(traceability)이 마련되어 변경 영향분석 등에 활용 가능함. 단순히 링크만 연결된 것이 아니라 내용상 정합성까지 확보되는 것이 중요합니다.
6. 시스템 요구사항이 모든 관련 당사자들에 의해 합의되고 전달되었다. – 최종 확정된 시스템 요구사항과 앞서 수행한 영향 분석 결과가 모든 이해관계자에게 공유되어, 모두가 현재 요구사항 베이스라인과 변경 사항을 알고 있음.

위 결과들이 충족되었다면 SYS.2 프로세스가 성공적으로 수행되었다고 볼 수 있습니다. 이제 이러한 결과를 얻기 위해 어떤 활동과 산출물들이 요구되는지 살펴보겠습니다.

 

3. SYS.2 프로세스 수행 방법: 기본 수행활동 (Base Practices)

ASPICE에서는 각 프로세스에 대해 프로세스 성과지표(PPI, Process Performance Indicators)로서 베이스 프랙티스(BP, Base Practice)라는 수행활동들과 산출물을 정의하고 있습니다. SYS.2 프로세스의 PPI는 총 6개의 BP로 구성되며, 이를 차례대로 수행하면서 앞서 언급한 결과 (Outcome) 들을 달성하게 됩니다. 하나씩 자세히 알아보겠습니다:

1. BP1: 시스템 요구사항 명세 (Specify system requirements) – 이해관계자 요구사항을 활용하여 시스템의 기능 및 비기능 요구사항을 식별하고 문서화하는 단계입니다. 이때 ISO/IEC/IEEE 29148이나 INCOSE 요구사항 가이드 등에서 정의된 좋은 요구사항의 특성을 따르는 것이 중요합니다. 예를 들어 요구사항은 검증 가능성(verifiability)을 가져야 하고, 표현이 모호하지 않고 이해 가능해야 하며, 구현 방법이나 설계에 대한 사전 결정(설계 제약)을 포함하지 말아야 합니다. 또한 다른 요구사항과 충돌하거나 모순되지 않아야 합니다.
   • 예시: Stakeholder로부터 “차량이 전방 충돌 위험 시 자동으로 정지해야 한다”는 요구가 내려왔다면, BP1에서는 이를 달성하기 위한 구체적인 시스템 요구사항들을 작성합니다. 예를 들어: “시스템은 최대 100m 전방까지 보행자와 차량을 감지할 수 있어야 한다,” “시스템은 충돌 예상 시점보다 최소 1.5초 빠르게 긴급 제동을 개시해야 한다,” “브레이크 제어 모듈은 제동 명령 수신 후 0.1초 이내에 최대 제동력을 출력해야 한다” 등으로 명확히 기술합니다. 각각의 요구사항에는 수치나 조건을 명시하여 “신속하게” 같은 모호한 표현 대신 “1.5초 이내”처럼 명확하고 검증 가능하게 작성하는 것이 핵심입니다.
2. BP2: 시스템 요구사항 구조화 (Structure system requirements) – 식별된 시스템 요구사항들을 분류하고 우선순위 부여를 수행하는 단계입니다. 요구사항이 많아질 경우 논리적으로 그룹화하여 체계를 잡아야 관리가 쉬워집니다. 예를 들어 기능 영역별로 챕터를 나누거나, 하위 시스템(카메라 요구사항, 레이더 요구사항, 브레이크 요구사항 등)으로 묶는 방식, 또는 제품 라인/옵션 별로 분류할 수도 있습니다. 또한 프로젝트 상황이나 릴리스 계획에 따라 각 요구사항의 우선순위를 지정합니다. (예: MVP에 반드시 필요한 요구사항 vs. 추후 업데이트 가능 요구사항, 또는 안전 필수 요구사항 vs. 개선사항 등의 태그를 부여) 이를 통해 어떤 요구사항을 먼저 구현할지, 어떤 릴리스에 포함할지를 명확히 합니다.
   • 예시: AEB 시스템 요구사항들을 인지, 판단, 제어 세 부분으로 나누고, 인지 관련 요구사항은 센서 종류별로 (카메라/레이더), 제어 관련 요구사항은 브레이크 ECU와 인터페이스로 묶는 식으로 문서 구조를 잡습니다. 그리고 법규 준수나 안전과 직결된 요구사항에는 우선순위 “High”를 부여하고, 향후 고도화 기능은 “Medium” 등으로 지정해 둡니다. 요구사항 관리 도구(DOORS, Polarion, Codebeamer 등)를 사용한다면 이러한 분류와 우선순위 속성들을 필드로 관리하여 필터링/정렬하기 쉽게 구축합니다.
3. BP3: 시스템 요구사항 분석 (Analyze system requirements) – 명세된 시스템 요구사항들이 올바르고 실현 가능한지 면밀히 검토하는 단계입니다. 요구사항 간 상호 의존성(interdependencies)을 파악하여 서로 충돌하는 부분은 없는지 확인하고, 기술적인 실현 가능성(feasibility)도 평가해야 합니다. 예를 들어 요구사항을 구현하는 데 필요한 자원이 적절한지, 현재 기술 수준으로 달성 가능한지, 과도한 비용이나 시간이 들지는 않을지를 분석합니다. 이 분석 결과는 프로젝트 일정이나 비용 추정에도 활용되므로, 실제 프로젝트 관리와도 연계되어야 합니다. 필요하다면 프로토타입 개발이나 기술 실험을 통해 요구사항이 현실적으로 만족될 수 있는지 검증하기도 합니다.
   • 예시: “100m 전방까지 보행자 감지” 요구사항에 대해 기술팀과 검토한 결과, 현 차량에 장착될 카메라 센서의 해상도로는 80m 이상 거리의 보행자 인식이 어려울 수 있음이 발견되었다고 가정해봅시다. 이 경우 해당 요구사항을 80m로 변경하거나, 100m를 달성하려면 센서 스펙 상향 또는 레이더 보조가 필요하다는 결정을 내리게 됩니다. 이러한 분석 결과(what was decided, 이유, 전제 가정 등)는 반드시 기록으로 남겨야 합니다. 예컨대 “RQ-001을 100m→80m로 변경함. 이유: 현재 센서 한계. 추후 센서 업그레이드 시 재평가.” 같은 식입니다. 이처럼 BP3에서는 각 요구사항에 대해 정확성, 이해가능성, 검증가능성, 실현가능성 등의 측면을 점검하고 필요한 조치를 취합니다.
4. BP4: 시스템 컨텍스트에 대한 영향 분석 (Analyze the impact on the system context) – 시스템 요구사항이 상위 시스템이나 주변 환경에 미치는 영향을 분석하는 단계입니다. 차량 전체 관점에서 볼 때 우리의 시스템 요구사항이 다른 시스템 요소들에 새로운 제약을 주거나 변경을 필요로 하는지를 확인합니다. 예를 들어 전력 소모, 열발생, 차량 무게증가, 인터페이스 변경, 외부 시스템(다른 ECU 등) 요구사항의 추가 변화 등이 없는지 살펴봐야 합니다. 이 활동은 종종 시스템 엔지니어링 관점에서 수행되며, 필요한 경우 상위 레벨의 요구사항 변경이나 시스템 아키텍처 조정으로 이어질 수 있습니다.
   • 예시: AEB 요구사항 중 “브레이크 ECU는 0.1초 이내 반응” 항목을 고려해보면, 기존 브레이크 하드웨어의 통신 지연이나 유압 시스템의 한계로 0.1초 내 반응이 어렵다면 브레이크 액추에이터 자체 업그레이드가 필요할 수 있습니다. 이는 차량 브레이크 시스템 전체에 영향(비용 증가, 부품 변경)을 주는 사항입니다. 또 다른 예로, 센서 관련 요구사항으로 카메라와 레이더를 동시에 사용하도록 하면 데이터 처리량 증가로 메인 프로세서의 성능 요구사항이 상향될 수 있습니다. BP4에서는 이러한 영향들을 미리 분석하여, 추후 개발 단계에서의 충돌이나 요구 누락을 방지합니다.
5. BP5: 일관성 확인 및 양방향 추적성 확보 (Ensure consistency and establish bidirectional traceability) – 시스템 요구사항과 Stakeholder 요구사항 간의 추적성을 양방향으로 수립하고, 상호 일관성(Consistent)을 확인하는 단계입니다. 모든 시스템 요구사항은 출처가 되는 상위 요구사항이 연결되어 있어야 하며, 반대로 상위 요구사항도 하나 이상의 시스템 요구로 이어져야 합니다. 이렇게 해두면 변경 관리 시 영향 분석이 용이해지고, 최종적으로 상위 요구가 모두 하위 요구로 구현되었는지 커버리지를 증명할 수 있습니다. 중요한 점은, 단순히 링크만 걸어놓는 것으로 끝나선 안 되고, 링크된 항목들 간에 내용적 정합성(coherence)이 있는지 증거를 갖춰야 합니다. 예를 들어 상위 요구 “보행자 충돌 방지”에 대해 하위 요구들이 적절히 모든 측면을 다루고 있는지, 서로 모순되지 않고 완결성을 이루는지 검토해야 합니다. Traceability 구현은 도구의 링크 기능이나 요구사항 ID 참조로 할 수 있고, 스프레드시트 매트릭스로 관리할 수도 있습니다. 또한 정합성 증명을 위해 동료 검토(peer review)나 이력 관리 등을 통해 실제 내용이 일치함을 확인하는 절차도 필요합니다.
   • 예시: AEB 시스템의 각 요구사항 옆에는 해당 요구사항의 출처를 명시합니다. “SyRS-5: 레이더는 보행자를 감지해야 한다 (출처: Stakeholder 요구 3.1 보행자 안전)” 이런 식으로 연결지어 두는 것이죠. 이후 보행자 안전 관련 상위 요구가 변경되면 연결된 시스템 요구사항(SyRS-5 등)을 찾아 영향을 평가할 수 있고, 반대로 시스템 요구사항을 추가/변경할 때도 상위 요구 출처를 근거로 타당성을 판단할 수 있습니다. 요구사항 관리 도구를 쓰면 링크로 연결하고 추적성 행렬(traceability matrix) 리포트를 뽑아보며 누락된 링크가 없는지 검증합니다. 또한 정합성 확인을 위해 관련 엔지니어들이 모여 상위-하위 요구를 대조 검토하여 어긋나는 부분이 없는지 확인합니다 (이력이 남도록 변경 코멘트를 기록하거나, DoD 체크리스트를 활용하는 것도 권장됩니다)
6. BP6: 시스템 요구사항 및 영향의 합의와 전달 (Communicate agreed system requirements and impact on the system context) – 최종 도출된 시스템 요구사항 세트와 앞서 수행한 영향 분석 결과를 모든 관련자들과 공유하고 동의를 얻는 단계입니다. 여기서 말하는 관련자들이란 고객, 개발팀, 테스트팀, 공급업체 등 해당 시스템 요구사항으로 영향을 받는 모든 주체를 의미합니다. 요구사항 베이스라인에 대한 공식 리뷰 미팅을 진행하거나, 요구사항 문서를 배포하고 검토 피드백을 받아 승인하는 절차를 거칠 수 있습니다. 또한 영향 분석 결과 중요한 결정사항 (예: 특정 요구사항 변경으로 인한 시스템 아키텍처 변경 필요 등)도 투명하게 공유되어야 이후 단계에서 모두가 동일한 이해를 갖습니다. BP6의 결과로, 시스템 요구사항 명세서(System Requirements Specification)가 공식 승인되고 관련 부서에 공지가 완료된 상태가 되어야 합니다.
   • 예시: AEB 시스템 요구사항 명세서를 작성한 후, 관련 팀들과 함께 요구사항 검토 회의를 가집니다. 여기에는 기능 개발 엔지니어, 테스트 리더, 차량 설계 팀, 센서 공급사 등이 참여하여 우리가 정의한 요구사항들을 확인합니다. 앞서 예로 든 카메라 감지거리 요구 80m로 조정한 사항도 이 자리에서 공유하여 모두 이해관계자가 동의하도록 합니다. 회의 후에는 합의된 요구사항으로 문서를 업데이트하고 형상관리를 통해 버전을 고정(베이스라인)시킵니다. 그리고 이메일이나 협업툴을 통해 승인된 요구사항 문서와 변경 요약 내용을 관련자 전원에게 전파합니다. 이러한 의사소통 증빙으로 회의록이나 이메일 기록을 남겨 두어, 이후 분쟁이나 혼선을 방지합니다.

위 6개의 BP를 충실히 이행하면 ASPICE SYS.2 프로세스의 요구사항을 만족시키게 됩니다. 다음은 SYS.2 수행을 통해 생성되는 대표 산출물(Output Work Products)들과, ASPICE 모델이 기대하는 각 산출물의 특성에 대해 자세히 알아보겠습니다.

 

4. SYS.2 산출물 및 정보 항목 특성 (Outputs & Information Item Characteristics)

SYS.2 프로세스에서 도출되는 주요 산출물(Output Information Items)로는 시스템 요구사항(Requirement) 문서와 그 부수적인 내용들이 있습니다. ASPICE 4.0 PAM Annex B에서는 각 산출물 유형별로 요구되는 특성(Information Item Characteristics)을 상세히 제공하는데, 여기서는 SYS.2와 연관된 산출물 다섯 가지를 하나씩 살펴보겠습니다:

• 시스템 요구사항 (Requirement) – 시스템이 가져야 할 기능/성능/제약 등에 대한 개별 요구사항 설명입니다. ASPICE는 이를 “블랙박스 관점에서 시스템의 기능이나 인터페이스에 대한 기대 사항”으로 정의합니다. 각 요구사항은 검증 가능해야 하고, 명확하며 모호하지 않아야 하며, 설계 또는 구현에 대한 결정사항을 내포하지 말아야 합니다. 또한 다른 요구사항과 상충되지 않아야 합니다. 만약 요구사항 문장이 이미 특정 설계나 솔루션을 지정한다면 그것은 요구사항이라기보다 “설계 제약(Design Constraint)”으로 간주됩니다. 좋은 시스템 요구사항의 예로 “차량은 60km/h 주행 중 50m 전방 정지 차량과의 충돌을 회피하기 위해 2초 이내에 완전 정지해야 한다”와 같이, 무엇을 해야 하는지를 명확히 서술하되 어떻게 구현할지는 언급하지 않는 형태를 들 수 있습니다. (잘못된 예: “레이더 센서를 이용하여 장애물을 감지해야 한다” – 특정 솔루션을 못박는 대신 “장애물을 감지해야 한다”로 작성하고, 솔루션 선택은 설계단계로 넘기는 것이 바람직합니다.)
  
  
• 요구사항 속성 (Requirement Attribute) – 각 요구사항에 부여하는 추가 정보 메타데이터를 말합니다. 요구사항을 분류하거나 릴리스 범위를 정의하는 데 도움이 되는 속성들이며, 일반적으로 요구사항 관리 도구로 구현됩니다. 예를 들면 요구사항 ID, 상태(초안/승인), 우선순위, 위험도, 안전등급(ASIL), 담당자, 변경이력, 추적 링크 등이 모두 요구사항 속성입니다. 이러한 속성들은 요구사항들을 체계적으로 구조화하고 필터링하는 데 필수적이며, ASPICE에서는 요구사항 속성의 활용이 요구사항 분석과 추적성에 큰 도움을 준다고 보고 있습니다. 현업에서는 DOORS, Polarion 등의 도구에서 컬럼(column) 형태로 속성을 관리하며, 각 요구사항이 가진 속성값을 기준으로 정렬, 검색, 대시보드 현황파악 등을 수행합니다.
  
  
• 분석 결과 (Analysis Results) – 요구사항 분석(BP3)을 수행하면서 도출된 결과 기록을 의미합니다. ASPICE에 따르면 이 산출물에는 분석 대상이 무엇이었는지, 사용된 분석 기준(예: 의사결정 기준, 우선순위 선정 기준 등), 그리고 최종 분석 결과가 포함되어야 합니다. 쉽게 말해, *“무엇을 어떻게 검토했고, 무엇을 결정했는가”*를 문서화하는 것입니다. 예를 들어 요구사항의 타당성을 검토한 결과 “OK” 또는 “변경 필요” 같은 판단과, 그 이유와 전제(assumptions), 선택하지 않은 대안의 잠재적 영향까지 기록하는 것이 이상적입니다. 또한 분석 시 고려한 다양한 품질측면(정확성, 이해가능성, 검증가능성, 실현가능성, 유효성 등)을 무엇이었는지도 남겨둡니다. 이러한 분석 결과 산출물은 종종 요구사항 검토 회의록이나 결정 로그(decision log) 형태로 관리됩니다. 나중에 왜 그런 결정을 했는지 추적하기 위해서라도, 중요한 요구사항별로 이런 결과를 남겨두는 것을 권장합니다.
  
  
• 일관성/추적성 증거 (Consistency Evidence) – 요구사항들의 추적성 연결 및 내용 정합성을 입증하는 산출물입니다. 흔히 추적 매트릭스(Traceability Matrix)나 커버리지 리포트 등이 이에 해당됩니다. ASPICE에서는 시스템 개발 생명주기 전반에 걸쳐 아티팩트들 간의 양방향 추적 연결이 이루어졌음을 보여주도록 정의하고 있습니다. 예를 들어 Stakeholder 요구사항과 시스템 요구사항 사이, 시스템 요구사항과 하위 소프트웨어/하드웨어 요구사항 사이에 링크가 빠짐없이 되어 있고, 이를 도구 링크나 하이퍼링크, 명칭 규칙 등을 통해 확인할 수 있어야 합니다. 나아가, 이러한 연결된 내용들이 논리적으로 일관되게 정합함을 보여주는 증거도 필요합니다. 이를 위해 요구사항 상호 리뷰 결과나 변경 이력에 남긴 코멘트, 형상 관리 이력 등을 활용할 수 있습니다. 한마디로 “추적성은 걸었는데, 정말 내용도 서로 맞아?”라는 질문에 답할 수 있는 자료입니다. 실제 프로젝트에서는 요구사항 관리 도구에서 Coverage나 Suspect Links 리포트를 뽑아 검증하거나, 엑셀로 표를 만들어 각 요구사항의 추적 상태를 점검한 문서를 남기는 방식으로 구현됩니다.
  
  
• 의사소통 증빙 (Communication Evidence) – 최종 산출된 시스템 요구사항이 관련자들에게 전달 및 공지되었음을 나타내는 근거입니다. ASPICE는 사람이 관여된 모든 형태의 커뮤니케이션을 포괄하는 증적이라 설명하는데, 예를 들면 요구사항 리뷰 회의 회의록, 이해관계자들에게 보낸 이메일 또는 결재 문서, 요구사항 합의 내용을 공유한 위키 페이지나 공용 포럼/채팅 기록, 교육용 프레젠테이션 영상 등 다양합니다. 중요한 것은 누가 언제 무엇을 전달했고 합의했는지를 사후에 입증할 수 있는 자료입니다. 실제 감사나 평가시에는 “해당 요구사항이 관련 팀에 공유되었나요?”라는 질문에, “예, 여기 회의록/메일 등이 있습니다”라고 보여줄 수 있으면 충분합니다. 프로젝트 관리 측면에서는 이러한 커뮤니케이션 증빙을 통해 모든 당사자가 최신 요구사항을 인지하고 있다는 것을 확인하게 됩니다.

위의 산출물들은 단순한 문서가 아니라, SYS.2 프로세스 수행의 결과물로서 갖춰야 할 품질특성을 나타냅니다. 프로젝트 팀은 이런 산출물들이 제대로 작성되고 관리되고 있는지를 지속적으로 모니터링해야 합니다.

 

5. AEB 시스템 사례로 본 SYS.2 적용 예시

 

이제 구체적인 사례로 앞서 설명한 내용을 정리해보겠습니다. 자동 긴급 제동(AEB) 시스템을 예로 들어, SYS.2 요구사항 분석을 어떻게 진행하며 어떤 산출물이 나오는지 살펴보겠습니다. AEB 시스템은 전방 장애물을 인지하고 차량을 자동으로 감속/정지시켜 사고를 피하는 기능으로, 카메라, 레이더 센서와 브레이크 제어장치로 구성된다고 가정합니다.

 

1. Stakeholder 요구사항 식별: 먼저 고객 또는 법규 등에서 오는 상위 요구를 파악합니다. 예를 들어 “운전자가 개입하지 않아도 차량이 전방의 차량이나 보행자와의 충돌을 방지해야 한다”는 높은 수준의 요구가 있을 수 있습니다. 또한 “시속 80km로 주행 중 정지 차량을 완전 정지로 회피 가능”, “보행자에 대해 60km/h까지 작동” 등 상세한 조건이 포함될 수도 있습니다 (이는 UNECE 혹은 국가 안전 규정에 따른 요구일 수 있습니다).

 

2. 시스템 요구사항 명세 (BP1): Stakeholder의 니즈를 충족하려면 시스템 차원에서 어떤 기능 요구사항이 필요한지 작성합니다. AEB의 경우 크게 물체 감지, 위험 판단, 제동 제어 세 부분으로 나눠 생각할 수 있습니다. 각 부분에 대해 시스템이 가져야 할 구체 요구사항을 예로 들면:

• 인지 관련: “시스템은 전방 0~100m 범위에서 차량, 오토바이, 보행자를 식별할 수 있어야 한다”, “야간 및 악천후 조건에서도 물체 감지 기능을 제공해야 한다”. (비기능 요구로서 환경 조건 명시)
• 판단 관련: “시스템은 충돌 예상 시간이 2초 이하로 산출될 경우 긴급제동을 개시해야 한다”, “오경보(false alarm)를 줄이기 위해 카메라/레이다 데이터를 융합하여 위험 여부를 판단해야 한다”.
• 제동 제어 관련: “시스템은 제동 경고 신호 출력 후 0.5초 내에 자동 제동을 시작해야 한다”, “브레이크 제어장치는 ECU로부터 제동 명령을 수신하면 0.1초 이내에 유압 압력을 상승시켜야 한다”.

이런 식으로 요구사항 하나하나를 명확한 문장으로 나열합니다. 실제 문서는 “요구사항 명세서” 형태로 챕터/섹션을 가지고 위와 같은 문장들을 각각 식별번호(RQ-#)와 함께 포함하게 됩니다. 요구사항 각각은 앞서 언급했듯이 모호한 부분 없이 테스트 가능하도록 수치와 조건을 넣어 작성합니다. (예: “신속히 감지해야 한다” X -> “0.5초 내에 감지해야 한다” O)

 

3. 요구사항 구조화 및 우선순위 (BP2): 위에서 정의한 예시 요구사항들을 체계적으로 정리합니다. 예를 들어 문서를 챕터 3개로 나누어 3.1 감지, 3.2 판단, 3.3 제어 요구사항으로 구분하면 읽는 사람들이 체계를 이해하기 쉽겠죠. 또한 각 요구사항에 우선순위나 안전성 등급 속성을 부여합니다. AEB의 경우 충돌 회피 기능 자체와 같이 생명/안전에 직결된 요구사항은 최우선 구현 대상으로 표시하고, 편의 기능적 요소(예: “포토 로그를 저장한다” 같은 부가요소가 있었다면)는 우선순위를 낮게 책정할 수 있습니다. 이 정보는 나중에 구현 일정이나 검증 계획을 짤 때 유용하게 쓰입니다. 또한 일부 요구사항은 1차 릴리스 (현대차 기준, Proto) 에서 구현되지 않을 예정이라면 “릴리스2 (현대차 기준, P1) 적용” 등의 속성으로 태그해둘 수도 있습니다.

4. 요구사항 정확성/타당성 분석 (BP3): 작성된 요구사항들이 현실적으로 만족될 수 있는지 각 분야 전문가들과 검토합니다. 예를 들어 카메라 팀과 논의해보니 밤에 보행자를 100m까지 식별하는 것은 현 센서로 불가능하다는 피드백이 왔다면, 요구사항 범위를 조정하거나 추가 센서 투입 등 대안을 검토합니다. 레이더 팀과는 레이더의 감지 한계거리, 여러 개체 탐지시 성능 저하 등을 논의해 요구사항에 반영합니다. 브레이크 제어팀과는 0.1초 이내 유압 상승이 현재 브레이크 모듈로 가능한지 확인하고, 만약 0.2초가 최소한도라면 요구사항을 완화하거나 모듈 업그레이드를 추진해야합니다. 이처럼 각 요구사항에 대해 구현 가능성, 예상 비용, 기술적 위험 등을 분석하여 필요하면 수정 및 보완합니다. 결정된 사항은 요구사항 사양서에 즉각 반영하고, 결정 배경과 rationale은 따로 분석 결과 노트로 남겨둡니다 (예: 요구 변경 사유, 고려했던 다른 옵션들).

 

5. 시스템 컨텍스트 영향 분석 (BP4): 요구사항 달성이 차량 전체에 주는 영향을 검토합니다. AEB 시스템의 신규 요구로 인해 다른 ECU들과의 통신 버스 부하가 증가할 수 있고, 이를 수용하기 위해 버스 대역폭 재할당이나 메시지 스케줄 변경이 필요한지 살펴봐야 합니다. 또, 잦은 자동제동으로 브레이크 패드 마모가 빨라져 정비주기에 영향은 없는지, 긴급제동 시 브레이크등이나 경고등 동작에 변경이 필요한지 등 주변 요소까지 고려합니다. 이러한 영향들은 시스템 아키텍처 단계(SYS.3)나 통합 단계(SYS.4)에 넘어가서 해결해야 할 수도 있으므로, 미리 관련 부서 (예: 차량제어 통합팀, 시스템 테스트팀 등)와 상의하여 요구사항에 주석이나 추가 요구(예: “브레이크 마모 알림 기능 필요”)를 추가할 수도 있습니다. 중요한 영향 사항은 별도의 시스템 영향 분석 보고서로 정리해두고, 관련 팀에 공유합니다.

 

6. 추적성 수립 및 검증 (BP5): 이제 시스템 요구사항 각각에 대해 출처가 되는 Stakeholder 요구사항을 연결합니다. AEB의 Stakeholder 상위 요구사항을 몇 개 잡아두었다면, 각 시스템 요구사항에 “Derived from SR-1” 등으로 표시해두거나, 요구사항 관리 도구의 링크 필드를 채웁니다. 예를 들어 “보행자 충돌 회피”라는 상위 요구로부터 센서감지, 판단, 제동 관련 여러 시스템 요구들이 파생되었을 것입니다. 그 연결 상태를 표로 정리하면 상위 요구사항 한 개에 아래 요구사항 여러 개가 매핑됩니다. 혹시 연결되지 않은 요구사항이 있으면 왜 그런지 따져보고(상위 요구사항 없이 생긴 요구사항이라면 누락된 Stakeholder 요구사항인지, 아니면 불필요한 요구사항인지 판단) 조치를 취합니다. 또한 상위 요구사항 중 시스템 요구사항으로 커버되지 않는 부분이 있는지도 역으로 검사합니다. 이를 모두 끝내면 추적 매트릭스를 업데이트하여 상위-하위 요구사항 일관성을 확인합니다. 이 과정에서 발견된 부정합은 요구사항을 수정하거나 추가로 해결합니다. 완성된 추적성 정보는 요구사항 문서의 부록이나 요구사항 관리 DB 리포트로 남겨두며, 이는 나중에 검증 및 발송 단계에서 요구 커버리지를 입증하는 근거가 됩니다.

 

7. 요구사항 승인 및 커뮤니케이션 (BP6): 최종 수정된 시스템 요구사항 사양서를 모든 관련자에게 공유 및 승인받습니다. AEB 요구사항이라면 차량 프로그램의 전체 PM, 안전 담당자, 센서 공급사, 테스트 리더 등이 주요 이해관계자일 것입니다. 이들에게 문서를 보내 검토 의견을 받고, 필요시 회의를 통해 이견을 조율합니다. 모두 동의가 이루어지면 문서를 공식 발행하고 형상관리 툴에 버전업합니다. 그리고 메일로 "최종 AEB 시스템 요구사항 v1.0 배포합니다..."와 같이 공지하고, 수신자 목록엔 모든 핵심 팀을 포함시킵니다. 이렇게 남겨진 이메일, 회의록 등이 의사소통 증빙 자료로서 남으며, 이후 감사나 ASPICE 평가 시에 이 자료를 제출하여 SYS.2의 BP6이 수행되었음을 입증할 수 있습니다.

 

이상의 과정을 통해 AEB 시스템 요구사항 정의가 완료되었습니다. 결과물로는 완성된 시스템 요구사항 문서가 있고, 요구사항마다 속성 정보(우선순위 등)가 포함되어 있으며, 상위 요구사항과의 추적 매트릭스도 갖춰졌고, 검토/합의의 증거자료도 마련되었습니다. 이것이 바로 ASPICE가 의도하는 양질의 산출물을 갖춘 요구사항 분석 단계입니다.

 

6. 맺음말

ASPICE 4.0 SYS.2 프로세스는 체계적인 요구사항 분석을 통해 프로젝트 초기에 품질을 내재화하는 데 목적이 있습니다. 요구사항이 부실하면 이후 단계에서 수정 비용과 시행착오가 폭증하기 때문에, 초심자라도 위 가이드에 따라 하나씩 착실히 수행하는 것이 매우 중요합니다. 명확한 요구사항, 완벽한 추적성, 모두가 합의한 기준서는 이후 시스템 아키텍처 설계(SYS.3)와 구현 단계의 든든한 기반이 됩니다. 부디 이번 포스팅의 설명과 AEB 예제가 실무에 도움이 되길 바라며, ASPICE 기반 개발 프로세스에 대한 이해를 높이는 계기가 되었으면 합니다.