ASPICE 4.0 SWE.1 소프트웨어 요구사항 분석 정리

1. Introduction

자동차 소프트웨어 품질 향상을 위해 Automotive SPICE (ASPICE) 모델이 널리 활용됩니다. 그 중 SWE.1 소프트웨어 요구사항 분석 프로세스는 ADAS(첨단 운전자 보조 시스템)나 자율주행 기능 개발에서 매우 중요합니다. SWE.1은 시스템 수준에서 내려온 요구사항을 소프트웨어 요구사항으로 구체화하고 검증하는 단계입니다. 본 포스트에서는 자동 비상 제동(AEB, Autonomous Emergency Braking) 시스템을 예시로, SWE.1 프로세스를 하나하나 살펴보겠습니다. AEB는 차량 전방의 물체와의 TTC(Time-To-Collision) 계산을 통해 충돌 위험을 판단하고, 필요시 자동으로 브레이크를 거는 안전 기능입니다.

 

 

위의 그림은 예시로 사용 할 AEB 시스템의 제어 아키텍처 예시입니다. 센서 계층에서 레이더/카메라 등을 통해 선행 차량과의 상대속도, 거리 등의 정보를 수집하고, 제어 계층에서는 도로 상태나 운전자 반응 시간 등을 고려한 TTC 알고리즘과 안전거리 알고리즘을 통해 충돌 임박 여부를 판단합니다. 마지막으로 제어 (구현 계층) 에서 경고음, 경고등 및 단계별 브레이크 제어 출력을 수행합니다. 이러한 계층별 기능을 수행하는 S/W 요구사항들을 체계적으로 정의하는 것이 SWE.1의 목표입니다.

 

아래 작성되는 S/W 요구사항 실무 예시는 이해를 위해 추상화되어 작성되는 내용으로 실제 실무에서 작성되는 내용과는 다릅니다.

실제 실무에서는 차량의 AEB 기능을 구현하기 위해, 센서 계층(레이더, 카메라), 판단 계층 (AEB 판단 로직), 제어 계층 (브레이크, HMI) 이 서로 다른 회사에서 개발될 수 있어서 각 계층 별 아이템/프로덕트에 대한 요구사항이 시스템 수준에서 상세하게 구체화되어 작성되는 경우도 있습니다. 

 

2. SWE.1 프로세스의 목적과 결과 (Outcomes)

SWE.1 (소프트웨어 요구사항 분석) 프로세스의 목적은 “시스템 요구사항 및 시스템 아키텍처와 정합성(consistency)을 가지는 구조화되고 분석된 소프트웨어 요구사항 세트를 확립”하는 것입니다. 이를 통해 소프트웨어 개발팀이 무엇을 구현해야 하는지 명확히 파악하고, 이후 설계와 구현, 테스트가 올바른 방향으로 진행될 수 있습니다. ASPICE 프로세스 레퍼런스 모델(PRM)에서는 SWE.1을 성공적으로 수행하면 아래와 같은 7가지 결과(Outcome)가 달성된다고 정의합니다:

1. 요구사항 명세 – 소프트웨어 요구사항이 정의되어 있다. (예: AEB 기능에 필요한 모든 S/W 의 동작 및 성능 요구사항 식별)
2. 요구사항 구조화 및 우선순위화 – 소프트웨어 요구사항이 체계적으로 분류되고 우선순위가 정해져 있다. (예: 긴급 제동 로직이 최우선, 부가 알림 기능은 차순위 등)
3. 요구사항 정확성/타당성 분석 – 소프트웨어 요구사항의 정확성, 기술적 실현 가능성이 검토되었다. (예: 요구된 TTC 계산 알고리즘이 구현 가능한지, 센서 정확도로 충분한지 검토)
4. 운영환경 영향 분석 – 소프트웨어 요구사항이 차량 운영 환경(하드웨어 장치, 다른 ECU 등)에 미치는 영향이 분석되었다. (예: AEB 소프트웨어 추가로 ECU 부하나 Cycle time, memory 관련 영향 평가)
5. 일관성 및 추적성 확보 (시스템 요구사항) – 소프트웨어 요구사항과 시스템 요구사항 간에 양방향 추적성이 확보되고 내용이 일치한다. (예: 시스템 수준의 AEB 요구사항과 소프트웨어 요구사항이 서로 빠짐없이 연결되어 있고 모순이 없음)
6. 일관성 및 추적성 확보 (시스템 아키텍처) – 소프트웨어 요구사항과 시스템 아키텍처 간에도 양방향 추적성이 확보되고 정합성이 보장된다. (예: 센서/액추에이터 인터페이스 등 시스템 설계 요소들과 소프트웨어 요구사항이 서로 부합됨)
7. 요구사항 합의 및 소통 – 정의된 소프트웨어 요구사항이 관련된 모든 이해관계자들에게 합의되고 전달되었다. (예: 개발팀, 테스트팀, 고객/OEM 등이 AEB 소프트웨어 요구사항에 동의하고 인지함)

이러한 결과들이 충족될 때 SWE.1 프로세스가 제대로 수행되었다고 평가됩니다. 다음으로는 SWE.1 프로세스의 각 Base Practice (BP), 즉 세부 실천 항목을 실제 엔지니어의 활동 관점에서 살펴보겠습니다. AEB 시스템 사례를 통해 각 단계에서 무엇을 해야 하고, 어떤 산출물이 나오는지 구체적으로 설명하겠습니다.

 

3. SWE.1 Base Practice

SWE.1 BP1: 소프트웨어 요구사항 명세 (Specify Software Requirements)

BP1의 핵심 목표: 시스템 수준에서 내려온 기능/비기능 요구사항을 토대로 소프트웨어 요구사항을 식별하고 문서화하는 것입니다. 소프트웨어 요구사항은 구현 방법이 아닌 “소프트웨어가 무엇을 해야 하는가”를 black-box 관점에서 서술합니다. 다시 말해 입력-처리-출력의 관점에서 소프트웨어 동작을 명확히 정의하는 것입니다. 또한 요구사항은 나중에 검증할 수 있도록 명확하고 시험가능한 형태로 작성해야 합니다. ASPICE 가이드는 좋은 요구사항의 특성으로 “검증 가능(verifiable), 모호하지 않으며(unambiguous), 구현 설계에 종속되지 않고(freedom from design), 다른 요구사항과 모순되지 않음” 등을 제시하고 있습니다.

 

실무 활동 예시: AEB 시스템의 시스템 요구사항으로 “운전자가 반응하지 않을 경우 차량이 자동으로 긴급 제동을 수행하여 충돌을 피하거나 피해를 감소시킬 것”이 주어졌다고 가정해봅시다. SWE.1.BP1 단계에서 엔지니어는 이를 달성하기 위한 구체적인 소프트웨어 요구사항들을 정의합니다. 예를 들어:

• 객체 및 TTC 계산 요구사항: 전방 센서(예: 레이더)로부터 선행 물체의 속도와 거리를 입력받아 충돌까지 남은 시간(TTC)을 실시간으로 계산해야 한다. (Functional Requirement)
• 제동 동작 결정 요구사항: 계산된 TTC가 설정 임계값 이하로 떨어지면, 시스템은 운전자 브레이크 개입 여부를 확인하여 자동 제동 명령을 출력해야 한다. 이때 제동 명령의 세기(감속도)는 상황에 맞게 결정되어야 한다.
• 센서 인터페이스 요구사항: 소프트웨어는 차량 전방 레이더 센서로부터 Object_Data 메시지(물체 거리, 상대속도 등 포함)를 매 주기(예: 50ms 마다) 수신하여 처리해야 한다. (Interface Requirement)
• 브레이크 액츄에이터 인터페이스 요구사항: 충돌 위험 시 전자제어제동장치(ESC)에 자동 제동 신호(예: 목표 감속도 혹은 제동력 요청 메시지)를 CAN 버스를 통해 전송해야 한다.
• 예외 처리 요구사항: 센서 데이터 오류나 신뢰도 저하 상황에서는 운전자 경고 표시등을 점등하고 자동제동 기능을 일시 정지해야 한다.

위 요구사항들은 하나의 문서에 모여 소프트웨어 요구사항 명세서(SRS)를 구성합니다. 아래는 간략한 요구사항 예시를 표로 나타낸 것입니다:

요구사항 ID	소프트웨어 요구사항 (예시)	출처(연계된 시스템 요구)
SWR-1	레이더 센서로부터 선행 물체의 상대속도와 거리를 입력받아, 실시간으로 **충돌까지 남은 시간(TTC)**을 계산해야 한다.	SYS-REQ-3.2.1 (AEB 작동)
SWR-2	TTC가 1.6초 이하로 감소하고 운전자가 브레이크를 밟지 않는 경우, 소프트웨어는 자동으로 제동을 수행해야 한다.	SYS-REQ-3.2.2 (AEB 제동)
SWR-3	AEB 제동 시 차량 감속도는 최대 0.6g를 넘지 않아야 한다.	SYS-REQ-3.2.3 (제동 한계)
SWR-4	소프트웨어는 **레이더 센서 CAN 메시지(ID:0x120)**를 50ms 주기로 수신하여 객체 데이터를 업데이트해야 한다.	SYS-ARC-2.1 (센서 HSI)
SWR-5	소프트웨어는 **ESC 제어기 CAN 메시지(ID:0x200)**를 통해 제동 요청을 보내야 한다.	SYS-ARC-2.3 (브레이크 HSI)
SWR-6	센서 데이터가 유효하지 않을 경우, 대시보드 경고등을 켜고 자동제동을 시도하지 않아야 한다.	SYS-REQ-3.2.4 (AEB 예외)

 

이처럼 BP1 단계에서는 시스템 요구사항으로부터 세분화된 모든 소프트웨어 요구사항을 식별합니다. 기능 요구사항뿐 아니라 성능, 인터페이스, 예외처리 등의 비기능 요구사항도 놓치지 말아야 합니다. 작성된 각 요구사항에는 고유 ID를 부여하고, 출처(연계된 상위 요구사항이나 설계 정보)를 명시해 두면 이후 추적성 관리에 도움이 됩니다. 또한 요구사항 하나당 한 가지 기능만 서술하고, “해야 한다(shall)”과 같은 표현을 사용하여 명확하고 검증가능하게 기술합니다. 초기에는 초안 형태일 수 있지만, 이후 BP3, BP4의 분석을 거치며 내용이 개선될 수 있습니다.

 

BP1 산출물과 정보 항목: 이 단계의 주요 산출물은 소프트웨어 요구사항 명세서(SRS)입니다.

ASPICE에서는 이를 정보 항목 (Information Item) 17-00: Requirement로 분류하며, 요구사항들이 “기능 및 성능에 대한 기대를 나타낸 문장”으로서 검증 가능하고, 모호하지 않으며, 구현 세부를 포함하지 않고, 다른 요구사항과 모순되지 않아야 한다고 명시합니다.

각 요구사항에는 우선순위, 안전등급(ASIL), 출처, 상태 등의 속성(정보 항목 17-54: Requirement Attribute)을 함께 관리하여 요구사항의 맥락과 분류를 체계화합니다. 정리하면, BP1 산출물은 적합성(상위 수준 기대에 부합하고 적절한 상세 수준), 명확성(이해하기 쉽고 모호성 없음), 검증가능성(테스트나 분석으로 입증 가능), 일관성(상충되는 내용 없음), 정형성(합의된 템플릿과 형식에 따라 체계적으로 작성됨) 등의 품질 특성을 갖추도록 작성되어야 합니다. 이러한 요구사항 문서는 이후 단계의 기반이 되므로, 초기부터 충분한 숙고와 협의를 통해 작성하는 것이 중요합니다.

 

SWE.1.BP2: 소프트웨어 요구사항 구조화 (Structure Software Requirements)

BP2의 핵심 목표: 식별된 요구사항들을 논리적으로 그룹화하고 우선순위를 부여하여 구조화하는 것입니다. 요구사항이 많아질수록 체계없이 나열되어 있으면 이해와 활용이 어려우므로, 분류 체계를 수립해야 합니다. 분류 기준은 프로젝트 특성에 따라 정할 수 있는데, 예를 들어 기능별 그룹화, 서브시스템별 분류, 시나리오별 분류, 또는 필수/선택 기능 등으로 나눌 수 있습니다. 또한 각 요구사항에 대해 중요도나 구현 우선순위(priority)를 지정하고, 단계적 개발일 경우 어떤 릴리즈에 포함할지 결정합니다.

실무 활동 예시: AEB 소프트웨어 요구사항을 구조화한다고 가정해보겠습니다. AEB 기능은 감지, 판단, 제어 세 부분으로 나눌 수 있으므로, 요구사항을 다음과 같이 그룹화할 수 있습니다:

• 그룹 1: 위험 감지 및 계산 – 센서 입력 처리, 물체 인식, TTC 계산 관련 요구사항 (예: SWR-1, SWR-4 등).
• 그룹 2: 제동 판단 로직 – TTC 임계값 결정, 운전자 입력 모니터링, 제동 여부 판단 요구사항 (예: SWR-2, SWR-6 등).
• 그룹 3: 제동 제어 및 출력 – 브레이크 제어 신호 생성, 단계별 제동 강도, 차량 인터페이스 요구사항 (예: SWR-3, SWR-5 등).
• 그룹 4: 경고 및 HMI – 운전자 경고 알림, 대시보드 표시 등 (해당 기능이 있다면 요구사항 묶음).

각 그룹별로 요구사항들을 챕터/섹션으로 묶어서 SRS 문서를 구조화하면 가독성이 향상됩니다. 또한 요구사항 속성으로 “Category”를 두어 각 요구사항이 어떤 기능 영역에 속하는지 태깅(tagging)해둘 수도 있습니다. 예를 들어 SWR-1, SWR-4에는 Category=“Sensor & Calculation”, SWR-2는 “Logic”, SWR-5는 “Actuator Interface” 식으로 표기하면 추후 특정 영역 요구사항만 모아서 볼 때 유용합니다.

우선순위 결정: AEB 시스템의 경우 모든 핵심 요구사항이 안전과 직결되어 중요하지만, 그래도 긴급 제동 로직 (예: SWR-2, SWR-3)이 경고 표시 (SWR-6)보다 우선시 될 수 있습니다. 프로젝트 일정상 초기 버전에 필수로 포함될 요구사항과 추후 개선에 포함될 요구사항을 나누는 것도 BP2의 작업입니다. 예를 들어, 1단계 개발에서는 차량 및 보행자에 대한 AEB만 구현하고, 2단계에서 사이클리스트 인식 강화나 더 높은 속도 영역 커버 등을 추가할 계획이라면, 관련 요구사항들을 우선순위 “높음/낮음” 또는 “Phase1/Phase2”, 또는 "Proto/P1" 등으로 마일스톤으로 표시해 둡니다. 이러한 속성(Requirement Attribute) 관리로 요구사항의 릴리즈 계획(Release scope)을 명확히 할 수 있습니다.

BP2 산출물과 정보 항목: 이 단계에서는 SRS 문서가 개정되어 요구사항들이 체계적으로 분류되고 각종 속성이 채워집니다. 결과적으로 요구사항 집합은 일관된 계층 구조나 목록 구조를 갖추게 됩니다. 정보 항목 관점에서 보면, 앞서 생성된 Requirement (17-00) 항목들이 서로 논리적 그룹으로 묶이고, Requirement Attribute (17-54)들이 활용되어 요구사항의 분류, 우선순위, 릴리즈 정보 등이 부여됩니다.

 

품질 특성 측면에서, BP2의 결과물은 적합성을 갖춰야 합니다 – 즉 해당 프로젝트에 알맞은 구조로 요구사항을 조직해야 합니다. 예를 들어 기능별로 묶는 것이 개발팀 이해에 가장 적합하다면 그 방식이 옳을 것입니다. 또한 일관성 있게 분류 규칙을 적용해야 합니다 – 어느 일부만 임의로 그룹화하고 다른 부분은 뒤섞여 있다면 오히려 혼란이 커집니다. 정형성도 중요한데, 요구사항 관리 도구(예: IBM DOORS, Polarion 등)를 사용한다면 폴더/태그 기능을 활용하여 체계적으로 구조화해야 합니다. 마지막으로, 추적 용이성도 고려됩니다. 구조화된 요구사항은 상위 시스템 요구사항과의 관계를 명확히 표시하고, 중복이나 누락 없이 분류되어 있어야 합니다. BP2를 통해 얻어진 깔끔한 요구사항 구조는 이후 BP5~BP7의 추적성과 일관성 작업에도 큰 도움이 됩니다.

 

SWE.1.BP3: 소프트웨어 요구사항 분석 (Analyze Software Requirements)

BP3의 핵심 목표: 앞서 명세된 각 요구사항을 면밀히 검토하여 정확성, 완전성, 타당성을 확보하는 것입니다. 구체적으로는:

• 요구사항 내용이 올바르고 모순이 없는지 (Correctness),
• 기술적으로 구현 가능한지 (Feasibility),
• 테스트가 가능한지 (Testability),
• 다른 요구사항들과 상충되거나 중복되지 않는지 (Consistency),
• 요구사항 간 인터페이스나 의존관계가 있는 경우 그 연계가 명확한지 등을 분석합니다.

또한 요구사항 실현을 위한 예비 비용/일정 산정에도 입력을 주기 때문에, 난이도가 높은 요구사항은 프로젝트 관리 관점에서 별도로 표시하고 대비해야 합니다. 만약 분석 과정에서 요구사항 변경이나 추가가 필요하면, 이를 구별하여 상위 요구사항 담당자와 협의해야 합니다.

 

실무 활동 예시: AEB 요구사항을 분석하는 상황을 생각해봅시다. 엔지니어들은 각 요구사항에 대해 다음과 같은 질문을 던지며 검토합니다:

• 명확성 검토: “이 요구사항 문장이 이해하기 어렵거나 여러 해석의 여지가 있지는 않은가?” 예를 들어 SWR-2 “TTC가 1.6초 이하로 감소하면 제동한다”는 문구에서 1.6초의 기준이 충분히 명확한지 확인합니다. (이는 어느 속도 범위에서나 동일한지, 1.6초 미만이 되는 순간 즉시 제동인지 등 부연 설명이 필요할 수 있습니다. 또한, 주행 상황이 직진 주행인지 또는 곡선 주행인지 등의 조건도 필요할 수 있습니다.)
  
  
• 타당성 검토: “TTC 임계값 1.6초는 어떻게 도출된 값인가? 너무 보수적이거나 공격적이지 않은가?” 실제 주행 시나리오 데이터나 Euro NCAP 테스트 프로토콜을 참고하여 1.6초가 적절한지 검토할 수 있습니다. 필요하다면 시스템 엔지니어와 논의하여 값을 조정하거나 조건을 세분화합니다. (예: 속도에 따라 다른 TTC 임계값 적용 등)  
  
  
• 기술적 가능성: “현재 사용되는 ECU와 센서로 이 요구사항을 구현할 수 있는가?” 예를 들어 “50ms 주기로 레이더 데이터를 처리”하는 SWR-4의 경우, ECU의 처리속도로 50ms마다 TTC 계산이 가능할지, 레이더 센서의 업데이트 주기가 실제 50ms인지 확인합니다. 만약 레이더 센서가 100ms마다 데이터를 제공한다면 요구사항 또는 아키텍처를 조정해야 합니다 (센서 교체 또는 요구사항 완화 등).
  
  
• 성능/자원 분석: SWR-3 “감속도 0.6g 이하” 요구사항을 검토하며, 0.6g 감속을 달성하려면 현재 브레이크 시스템의 제동력으로 충분한지, 타이어/노면 조건에서 가능할지 따져봅니다. 0.6g가 너무 높아 차량 거동에 문제가 생길 위험이 있다면 0.5g 등으로 조정할 필요가 있을 수 있습니다. (사실 이 부분은 시스템 수준에서 결정되서 정해진 사항일 수 있습니다. 추가로, SW 요구사항에서는 AEB 판단 로직이 동작하는 MCU 의 Resource 또는 통신 관련 내용을 분석해야 할 수도 있습니다.)
  
  
• 인터페이스 정합성: SWR-5 “CAN 메시지 ID 0x200으로 제동 요청” 부분을 시스템 아키텍처 팀과 확인하여, 해당 메시지가 이미 정의되어 있는지 또는 새로 정의해야 하는지 검토합니다. 만약 다른 ECU와 메시지 충돌이 있다면 수정이 필요합니다.
  
  
• 상호 의존성: 요구사항들 간에 선후관계나 조건이 있는 경우 논리적 모순이 없는지 봅니다. 예를 들어 SWR-2 (제동 조건)와 SWR-6 (센서 예외 시 동작중지)가 충돌하지 않는지 검토합니다. 센서 데이터가 없으면 “제동을 시도하지 않는다”는 SWR-6 규칙이 있으므로, SWR-2에서 “TTC 이하이면 제동”이라고 했더라도, 전제가 “센서 데이터 유효 시”라는 조건을 명시해야 모순이 없습니다. 이러한 세부 논리를 팀 내부 리뷰를 통해 다듬습니다.

분석 수행 방법: BP3 분석은 문서 리뷰(meeting) 형태로 수행되기도 하고, 각 요구사항마다 체크리스트를 적용해 개별 검토할 수도 있습니다. 예컨대 요구사항 검토 체크리스트 항목으로 “해당 요구사항은 단일 의미를 갖는가?”, “검증 가능한 형태로 서술되었는가?”, “필요시 근거 자료나 계산을 첨부했는가?”, “상위 요구사항과 일치하는가?” 등을 점검합니다. AEB 팀은 시스템 엔지니어, 소프트웨어 개발자, 테스트 엔지니어, 안전 전문가 등이 함께 모여 요구사항을 하나씩 읽어보며 이러한 질문들을 던지고 피드백을 모을 수 있습니다. 발견된 문제점(애매한 부분, 실현 어려움 등)은 액션 아이템으로 기록하고, 이후 수정하거나 상위에 제시할 변경 요청으로 정리합니다.

 

분석 보완 조치: 만약 어떤 요구사항이 기술적으로 너무 난해하거나 위험 요소가 크다고 판단되면, 프로토타이핑이나 추가 타당성 실험을 제안할 수도 있습니다. 예를 들어 AEB의 물체 인식 알고리즘이 복잡해서 걱정된다면 시뮬레이션으로 간이 구현을 해보고 성능을 가늠해보는 것입니다. 또는 요구사항 만족을 위해 프로젝트 계획 조정이 필요한 사항(예: 추가 개발 시간)이 있으면, Project Management 프로세스와 연계하여 견적을 산정하고 리스크로 등록합니다.

 

BP3 산출물과 정보 항목: 요구사항 분석의 결과로 검토 기록이나 분석 보고서가 생성됩니다. ASPICE에서는 이를 정보 항목 15-51: Analysis Results로 다룹니다. Analysis Results에는 어떤 대상(Object)이 분석되었고, 사용된 기준(Criteria)과 결정된 사항 및 근거가 포함됩니다. 예를 들어 “SWR-2 요구사항에 대해 TTC 임계값을 1.5초로 변경하기로 결정 – 근거: 시뮬레이션 결과 상 1.5초에서 제동해도 충돌 회피 가능, false alarm 감소 기대”와 같은 내용이 기록될 수 있습니다. 또한 분석 과정에서 제기된 가정(Assumption)이나 제약(Constraints)도 명시합니다.

정보 항목 특성으로 보면, Analysis Results는 완전성 있게 (검토한 모든 요구사항을 다루고), 추적 가능해야 합니다 (어떤 요구사항에 대한 분석인지 식별 가능해야 함). 또한 명확성 있게 작성되어 나중에 다른 사람이 봐도 이해할 수 있어야 하고, 일관성 있게 유지되어야 합니다 (요구사항이 변경되면 분석 결과도 업데이트). Analysis Results 자체는 회사마다 검토 회의록, 요구사항 검토 체크리스트, 타당성 분석 보고서 등 다양한 형태일 수 있습니다. 중요한 것은 이러한 근거와 결정을 문서화해 놓음으로써 이후 단계 (설계, 테스트)에서 혼선을 줄이고, 필요시 추적성 증빙으로 활용할 수 있다는 점입니다.

 

SWE.1.BP4: 운영 환경 영향 분석 (Analyze the Impact on the Operating Environment)

BP4의 핵심 목표: 정의된 소프트웨어 요구사항들이 차량의 전체 운영 환경(operating environment)에 미칠 영향을 분석하는 것입니다. 여기서 운영 환경이란 해당 소프트웨어가 동작하는 주변 요소들을 말합니다. 예를 들어 AEB 소프트웨어의 운영 환경에는 센서 장치(레이더, 카메라), 브레이크 액추에이터(ESC 모듈), 차량의 CAN 통신망, 다른 ECU들과의 상호작용, 심지어 운전자(HMI 측면) 등이 포함됩니다. 요구사항이 이러한 환경 요소에 어떤 부하나 변경 요구사항을 초래하는지, 또는 환경의 제약으로 인해 소프트웨어 동작에 제한이 생기는지를 살펴봐야 합니다.

 

실무 활동 예시: AEB 소프트웨어 요구사항의 환경 영향 분석 시 고려할 항목들은 다음과 같습니다:

• 하드웨어 자원 영향: 새로 정의된 AEB 알고리즘(예: TTC 계산, 객체 추적 등)이 ECU 프로세서의 계산 부하를 크게 높이진 않을지 분석합니다. 만약 AEB 관련 연산으로 CPU 사용률이 80%에서 95%로 올라갈 것으로 예상된다면, MCU 업그레이드가 필요할 수 있고 이는 별도 하드웨어 요구사항으로 반영되거나 아키텍처 변경으로 이어질 수 있습니다. 또 메모리, 저장공간 사용 등도 점검 대상입니다.
  
  
• 센서 성능/통신 영향: AEB 소프트웨어는 센서로부터 데이터를 자주 받아야 하므로 통신버스(CAN/LIN 등)에 추가 부하를 줄 수 있습니다. 예를 들어 레이더 센서 데이터가 기존엔 100ms 주기로만 필요했는데 AEB 기능으로 50ms 주기로 처리하게 되면, CAN 버스 로드율이 상승할 수 있습니다. 이러한 통신 지연이나 데이터 병목이 발생하지 않을지 평가합니다. 또한 악천후 등 환경 요인으로 센서 성능이 저하될 경우 (예: 레이더 센서에 비가 심하게 오면 노이즈 증가) AEB 요구사항을 만족시키기 어려울 수 있음을 인지하고 대책이 필요합니다.
  
  
• 브레이크/차량 시스템 영향: AEB 소프트웨어가 자동 제동을 거는 것은 차량의 물리적인 동작에 직접 영향합니다. 잦은 자동제동으로 인해 브레이크 패드 마모가 빨라지거나, 급제동 시 차량 안정성이 영향을 받는지도 고려합니다. 예를 들어 “0.6g 이하로 제동”이라는 요구사항 SWR-3은 차량의 안정성을 위해 넣은 제한일 텐데, 혹시 이로 인해 충돌을 완전히 피하지 못할 가능성은 없는지 등을 고민해야 합니다. 또한 타이어/노면 상태 (마찰계수)에 따라 0.6g 감속이 달성되지 않을 수 있는데, 이런 환경 조건에 따라 AEB 성능이 제한됨을 인지하고 요구사항에 “노면 상태가 건조한 기준” 등의 범위를 명시할 수도 있습니다.
  
  
• 다른 시스템과의 인터랙션: AEB 기능은 차량의 다른 ADAS 기능 (예: 어댑티브 크루즈 컨트롤 ACC, ESC 안정성 제어 등)과 동시에 작동할 수 있습니다. 이때 상호간 간섭이나 영향이 없는지 검토합니다. 예를 들어 ACC가 속도를 유지하려 가속중인데 AEB가 갑자기 제동 명령을 보내는 상황에서 우선순위는 어떻게 할 것인지(일반적으로 AEB가 우선), ESC 모듈이 긴급 제동 시 차체 안정을 위해 개입할 텐데 우리 AEB 알고리즘과 충돌은 없는지 등을 생각합니다. 이러한 부분은 주로 시스템 아키텍처 단계에서 정의되지만, 소프트웨어 요구사항 단계에서도 “동시동작 시 우선순위 규칙” 같은 요구사항을 명시하도록 피드백할 수 있습니다.
  
  
• 운전자/HMI 영향: AEB 소프트웨어가 작동하면 운전자에게 경고음이나 경고등으로 알려야 할 필요가 있습니다. 이는 HMI 요구사항인데, 시스템 요구사항에 정의되어 있다면 소프트웨어 요구사항으로 흡수되거나 인터페이스 요구사항으로 포함되어야 합니다. 예를 들어 “AEB 제동 동작 시 클러스터 경고등 점멸” 같은 부분을 요구사항에 추가할지 검토합니다.

BP4 활동을 통해, 소프트웨어 요구사항이 둘러싼 환경과 조화를 이루는지 확인하고 필요하면 관련 부서(하드웨어팀, 시스템팀 등)와 협의합니다. 만약 “현재 하드웨어로는 어려움”이라는 결론이 나오면, 요구사항을 조정하거나 시스템 레벨의 대안(센서 스펙 업그레이드 등)을 제안하게 됩니다. 예를 들어 AEB에 추가 센서가 필요하거나, 더 높은 성능 ECU가 필요하다면 이를 시스템 요구사항 변경으로 요청할 수 있습니다.

BP4 산출물과 정보 항목: 이 단계의 결과는 운영 환경 영향 분석 보고서나 체크리스트의 형태로 남습니다. 이것도 BP3의 결과와 함께 Analysis Results (15-51) 정보 항목에 포함될 수 있습니다. 특히 여기서는 각 요구사항이 “어떤 환경 요소에 영향을 주는지”를 명시하고, 그 영향에 대한 분석 결과를 기술합니다. 예컨대 “SWR-4 (센서 주기 50ms) – 분석 결과: 기존 CAN 대역폭으로 수용 가능 (버스 부하 40% → 50% 증가 예상, 허용 범위)” 또는 “SWR-2 (긴급제동) – 분석 결과: ESC 모듈과 사전 협의 필요, 급제동 시 ESC 알고리즘과 충돌 우려 없음 (ESC 담당자 확인완료)” 등의 코멘트가 남을 수 있습니다. 이러한 내용은 Consistency Evidence (13-51)와도 연관되는데, 시스템 아키텍처나 다른 영역과 정합성 측면에서 검토한 증빙으로 활용될 수 있습니다.

 

정보 항목 특성으로 보면, BP4의 결과물 역시 완전하고 일관되어야 합니다. 모든 관련 환경 요소를 빠뜨리지 않고 검토해야 하며, 그 결과가 앞선 요구사항 명세와 모순되지 않아야 합니다. 적합성도 중요한데, 이는 특정 요구사항이 현재 운영환경에서 적절한지를 판단하는 것이므로, 부적합한 부분은 요구사항을 수정하게 됩니다. 예를 들어 “운전자가 개입해도 항상 AEB가 제동” 같은 요구사항이 있었다면, 이는 실제 운전자 신뢰성 측면에서 적합하지 않아 (운전자 개입시 취소되어야 정상) 수정되는 식입니다.

 

BP4를 거치면서 SRS에는 필요시 환경 제약에 대한 명시(예: “본 요구사항은 노건이 건조한 경우를 기준으로 한다”)나 참고(예: “ESC와 연동 동작은 SYS.5 요구사항 참조”) 등이 추가될 수 있습니다. 최종적으로, 이 단계까지 완료되면 소프트웨어 요구사항은 내용적 타당성과 실행 가능성이 한층 높아지게 됩니다.

 

SWE.1.BP5: 요구사항 검증 기준 설정 (Develop Verification Criteria)

BP5의 핵심 목표: 각각의 소프트웨어 요구사항이 나중에 제대로 구현되었는지 확인할 수 있도록 검증 기준(Verification criteria)을 정립하는 것입니다. 다시 말해, 요구사항 하나마다 “이 요구사항이 만족되었음을 어떻게 증명할 것인가?”에 대한 방법이나 기준을 미리 정의해두는 작업입니다. 요구사항 자체가 검증가능하게 쓰여야 함은 BP1에서 언급되었지만, BP5에서는 한 걸음 더 나아가 각 요구사항별 테스트 케이스나 검증 방법의 윤곽을 잡아둡니다. 이렇게 해두면 이후 테스트팀이 상세 테스트를 설계하기 수월하고, 요구사항이 모호한지 여부도 다시 한번 점검할 수 있습니다. ASPICE에서는 요구사항의 verifiability를 강조하며, 가능하면 요구사항 텍스트 자체에 검증 기준이 포함되거나 연결되도록 권장합니다.

 

실무 활동 예시: AEB 요구사항에 대한 검증 기준을 몇 가지 살펴보겠습니다:

• SWR-1 (TTC 계산) – 검증 기준: 요구사항 테스트를 통해 여러 조합의 거리/상대속도 입력값에 대해 계산된 TTC가 정확한지 확인한다. 예를 들어 거리 30m, 상대속도 -10m/s (접근중)인 경우 TTC=3.0초로 계산되는지를 테스트한다. 또한 상대속도가 0이거나 마이너스(멀어지는 경우)일 때 처리 로직이 요구사항에 부합하게 동작(예: TTC 무한대 처리 또는 특정 값 제한)하는지 확인한다.
  
  
• SWR-2 (긴급 제동 조건) – 검증 기준: 시뮬레이터 상의 시나리오 테스트를 설계한다. 초기속도 50km/h로 주행중 전방 정지차량 발견 상황에서, 운전자가 브레이크를 밟지 않으면 TTC=1.6초 남은 시점에 제동 명령이 출력되는지 확인한다. 이때 운전자가 직접 브레이크를 밟는 경우에는 제동 명령을 내지 않음을 별도 시나리오로 검증한다. 또한 다양한 속도(30km/h, 100km/h 등)에서 TTC 임계값 동작을 시험한다.
  
  
• SWR-3 (제동 감속도 제한) – 검증 기준: HIL(Hardware-in-the-Loop) 실험으로 AEB 제동 시 생성되는 실제 감속도를 측정한다. 마찰계수가 높은 시험장 노면에서 AEB를 트리거해보고 차량의 최대 감속G가 0.6g를 넘지 않는지 센서로 기록하여 검증한다. 다른 노면 (젖은 노면 등)에서도 이 요구사항이 유효한지(넘지 않는지) 관찰한다.
  
  
• SWR-4 (센서 인터페이스) – 검증 기준: 소프트웨어 통합테스트에서 레이더 센서 시뮬레이터를 통해 50ms 주기로 CAN 메시지를 보낸 후, 소프트웨어 로그에 해당 메시지를 빠짐없이 수신 처리했는지 체크한다. 또한 메시지 유실이나 지연이 발생하면 요구사항 미준수로 간주하여 원인(버퍼 오버런 등)을 파악한다.
  
  
• SWR-6 (예외 처리) – 검증 기준: 센서 신호 두절 상황을 인위적으로 만들어(예: 센서 입력 값을 일정 시간 0으로 유지) 소프트웨어가 자동제동을 억제하고 운전자 경고등을 켜는지 테스트한다. MIL(Model-in-the-Loop) or SIL (Software-in-the-Loop) or HIL (Hardware-in-the-Loop) 환경에서 Fault Injection 기법을 활용해 센서 오류를 주입하고 해당 요구사항 동작을 검증한다.

위와 같이 요구사항마다 하나 이상의 검증 시나리오나 방법을 미리 정의해두면, 요구사항이 충분히 구체적이고 테스트 가능한지 재점검할 수 있습니다. 만약 검증 방법을 생각하기 어려운 요구사항이 있다면 이는 애매모호하거나 과도하게 추상적일 수 있다는 신호입니다. 예를 들어 “운전자에게 적절히 경고한다” 같은 요구사항은 “적절히”의 기준이 없으면 검증할 수 없기 때문에, 이를 “TTC 1.6초 시 경고음, 1.4초 시 경고음+경고등” 등 구체 기준으로 바꿔야 합니다 – 이러한 변화가 바로 BP5 단계에서 이루어질 수 있습니다.

 

BP5와 테스트 부서 협업: 이 활동은 소프트웨어 테스트 팀(혹은 검증 담당자)과의 협업으로 이루어지는 경우가 많습니다. 요구사항 작성자가 초안을 잡고, 테스트 엔지니어가 현실적인 검증 가능 여부를 피드백해주는 식입니다. 테스트 엔지니어는 각 요구사항에 대해 “이걸 시험하려면 이런 장비나 시나리오가 필요한데 현실적으로 가능한가?”를 검토하여, 너무 검증이 힘든 요구사항은 구현 방식 조정이나 시뮬레이션 도구 확충 등을 제안합니다. ASPICE에서도 요구사항 검증을 염두에 두고 작성하도록 강조하고 있으며, 특히 ISO 29148 같은 요구사항 작성 표준에서도 각 요구사항에 명시적 또는 암묵적 수용 기준(acceptance criteria)이 포함되도록 권장합니다.

 

BP5 산출물과 정보 항목: 각 요구사항의 검증 기준은 요구사항 명세서 자체에 포함되거나, 별도의 Requirements Verification Matrix 형태로 정리될 수 있습니다. ASPICE PAM에서는 별도로 “Verification measure”에 대한 정보 항목을 SWE.1에서 요구하지는 않지만, 실질적으로는 요구사항 속성 중 “검증 방법” 혹은 “수용 기준” 필드를 운영할 수 있습니다. 예를 들어 DOORS 툴에서 각 요구사항 객체에 “Verification Method”라는 속성을 달아 Test (동적시험), Analysis (분석로 검증), Inspection (리뷰로 검증), Demonstration (시연) 같은 방법을 지정해두는 사례가 있습니다. 혹은 수동으로 엑셀 매트릭스를 만들어 요구사항 ID별 검증 계획을 적어둘 수도 있습니다. 어떤 형태이든 중요한 것은 모든 요구사항이 검증 방법과 연결되어 있다는 점입니다. 이는 ASPICE의 추적성 관점에서도 볼 수 있는데, 이후 SWE.4/5/6 (테스트 프로세스)에서 각 요구사항이 하나 이상의 테스트 케이스와 연결되어 있어야 하므로, BP5 단계에서 미리 그 연결의 초석을 다지는 셈입니다.

 

품질 특성 측면에서 BP5 산출물은 적합성과 완전성이 핵심입니다. 각 요구사항에 맞는 검증 방법이 적절히 선정되어야 하고(예컨대 SW 성능 요구사항은 실차 테스트보다는 시뮬레이션/분석이 더 적절할 수 있음), 모든 요구사항이 빠짐없이 대응되어야 합니다. 일관성도 중요하여, 요구사항과 검증 기준 간에 모순이 없어야 합니다. (만약 요구사항 내용이 바뀌면 검증 기준도 바뀌어야 하는데 이런 부분이 누락되지 않아야 함) 그리고 추적 가능성 측면에서, 요구사항-테스트 케이스의 연결고리가 명확히 수립되어야 합니다.

 

BP5를 완료하면 소프트웨어 요구사항 명세서는 단순한 기능 나열을 넘어, 각 항목이 어떻게 확인될 수 있는지까지 정보를 담게 되어 더욱 정형화되고 검증 준비된 상태가 됩니다. 이는 추후 개발팀과 테스트팀이 공통 이해를 갖게 해 주며, 요구사항 변경 시 영향 분석에도 도움을 줍니다.

 

SWE.1.BP6: 추적성 확립 (Establish Bidirectional Traceability)

BP6의 핵심 목표: 소프트웨어 요구사항과 상위 수준 산출물 간의 양방향 추적성(bidirectional traceability)을 수립하는 것입니다. 상위 수준 산출물이란 주로 시스템 요구사항과 시스템 아키텍처를 말하며, 필요에 따라 고객/제품 요구사항까지 포함됩니다. 추적성 확립이란 각 소프트웨어 요구사항이 어떤 상위 요구사항으로부터 유래되었는지를 연결(link)하고, 반대로 상위 요구사항 각각이 어떤 소프트웨어 요구사항들로 구현되는지 추적할 수 있게 하는 것을 의미합니다. 또한 소프트웨어 요구사항과 소프트웨어 아키텍처 구성요소 간의 연결도 이 단계에서 고려될 수 있습니다 (예: 특정 요구사항을 어떤 소프트웨어 컴포넌트/모듈이 담당하는지 초기 매핑)

 

실무 활동 예시: AEB 시스템의 사례에서 추적성을 구축하는 방법을 생각해보겠습니다:

• 시스템 요구사항 ↔ 소프트웨어 요구사항 추적: 예를 들어 시스템 요구사항 “시스템은 60km/h 이하 속도에서 정지 차량과의 충돌을 피하기 위해 자동비상제동을 수행해야 한다”가 있다고 하면, 이를 만족시키는 소프트웨어 요구사항들(SWR-1~SWR-6 등)이 무엇인지 링크를 겁니다. SYS-REQ-3.2.1 (AEB 작동)에는 SWR-1, SWR-2, SWR-3, SWR-6 등이 추적 연결될 것입니다. 또한 “운전자 경고를 제공해야 한다”는 시스템 요구가 있다면 SWR-6 (경고등 점등)이 연결됩니다. 이처럼 하나의 상위 요구사항이 여러 하위 SW 요구사항으로 분해될 수 있고, 그 반대(여러 상위 요구가 하나의 SW 요구사항에 연결되는 경우)는 지양해야 합니다. 만약 SWR 하나에 여러 상위 요구가 링크된다면 해당 SWR을 더 세분화하는 것이 좋습니다.
  
  
• 하드웨어-소프트웨어 인터페이스(HSI) ↔ 소프트웨어 요구사항 추적: 시스템 아키텍처 문서에서 AEB MCU와 레이더 센서 (MMIC) 간 인터페이스, AEB MCU와 CAN Tranceiver 간 인터페이스가 정의되어 있다면, 이들과 관련된 요구사항(SWR-4, SWR-5 등)을 연결합니다. 
  
  
• 추적성 도구 활용: 현실적으로 요구사항이 수백 개가 넘어가면 수작업 추적은 어려우므로, DOORS, Polarion, Jama, Jira 등의 요구사항 관리 도구에서 제공하는 링크 기능을 사용합니다. (Jira 는 이슈 관리 도구지만, 요구사항 관리 플러그인 등을 사용하여 DOORS, Polarion 과 비슷한 요구사항 관리 도구의 기능을 구현 및 사용할 수 있습니다.) 예를 들어, Jira를 사용한다면 시스템 요구사항 이슈와 소프트웨어 요구사항 이슈를 만들고 링크(“relates to” 등)로 연결할 수 있습니다. DOORS에서는 상위 객체와 하위 객체 간의 링크셋을 생성하고 매트릭스를 추출할 수 있습니다. 엑셀을 이용하는 경우 피벗 테이블로 요구사항 ID를 매핑하거나, 간단히 표를 만들어 “상위 ID - 하위 ID”로 일일이 기록하기도 합니다. 중요한 것은 양방향으로 추적 가능해야 한다는 것입니다. 한쪽 방향(예: 하위 요구사항에 상위 ID를 적어두는 것)만으로는 나중에 상위에서 하위로의 영향 분석이 누락될 수 있습니다.

추적성의 가치: 이렇게 연결 고리를 만들어두면 변경 관리와 영향 분석에서 큰 이점을 얻습니다. 예를 들어 시스템 요구사항이 변경되어 AEB 작동 속도 범위가 80km/h로 늘어났다면, 추적 링크를 통해 어떤 소프트웨어 요구사항(SWR-3 등의 값 제한 부분)이 영향 받는지 즉시 파악할 수 있습니다. 반대로 소프트웨어 요구사항 측에서 어떤 구현상 제약으로 요구사항을 변경해야 할 경우, 연결된 상위 요구사항을 근거로 변경 승인을 받게 됩니다. 또한 검증 커버리지 추적에도 유용하여, 각 상위 요구사항이 적절히 하위 요구사항으로 구현되고 다시 테스트까지 되었는지 V-모델 상의 확인을 할 수 있습니다. ASPICE에서는 이런 추적성을 일관성 확보의 주요 수단으로 강조하며, 요구사항 간 연결 관계 증빙을 중요시합니다.

 

BP6 산출물과 정보 항목: 이 단계의 직접 산출물은 추적 매트릭스(Traceability Matrix) 또는 요구사항 관리 도구 상의 링크 데이터입니다. ASPICE 정보 항목으로는 Consistency Evidence (13-51)에 해당하는 부분으로 볼 수 있습니다. 추적성 자체의 수립은 증빙으로서, 나중에 평가 시 요구사항 관리 툴에서 추적 링크 화면을 보여주거나, 엑셀 매트릭스를 제출하는 식으로 증명하게 됩니다. Consistency Evidence의 정의에 따르면, 도구 링크, 하이퍼링크, 명시적 참조 등으로 산출물 간 추적 연결이 되어 있어야 하고, 연결된 내용들이 의미적으로도 일관됨을 보여주는 근거가 포함되어야 합니다.

 

품질 특성 측면에서 추적성 산출물은 완전성이 가장 중요합니다. 하나라도 빠진 링크가 있다면 요구사항 누락이나 불일치의 위험이 생깁니다. 정확성도 필수여서, 링크가 잘못 걸려 엉뚱한 상위-하위가 연결되지 않아야 합니다. 예를 들어 AEB와 관계없는 다른 시스템 요구사항에 AEB SWR이 연결되어 있다면 이는 잘못된 것이므로 발견 즉시 수정해야 합니다. 일관성은 추적 링크가 있다는 것만으로는 확보되지 않고, 그 내용이 서로 모순 없는지 사람이 리뷰하여 확인해야 합니다. 이는 다음 BP7의 범위이긴 하지만, BP6 단계에서도 링크를 걸면서 “이 SWR은 정말 이 SYS-REQ의 해석이 맞나?”를 자연스럽게 검토하게 됩니다. 마지막으로 형식성/정형성 관점에서는, 추적 매트릭스는 표 형식, 트리 구조 등 이해하기 쉬운 형태로 관리되어야 하고, 변경 시 자동으로 업데이트되는 등 체계적인 관리가 되어야 합니다.

 

정리하면 BP6을 통해 “모든 소프트웨어 요구사항은 상위 요구사항/설계와 연결되고, 모든 관련 상위 항목은 대응되는 소프트웨어 요구사항을 갖는다”는 상태를 이루는 것이 목표입니다. 이러한 추적성은 이후 단계의 일관성 검증과 변경 영향 분석의 토대가 됩니다.

 

SWE.1.BP7: 요구사항 일관성 검증 (Ensure Consistency)

BP7의 핵심 목표: 앞서 구축한 요구사항의 내용과 추적 연결이 일관성(Consistency) 있게 유지됨을 확인하고 보증하는 것입니다. 여기서 말하는 일관성은 여러 측면이 있습니다:

• 상위 대 하위 간 내용 정합성: 시스템 요구사항을 소프트웨어 요구사항으로 전개하면서 의미가 달라지거나 왜곡된 부분은 없는지 확인합니다. 예를 들어 시스템 요구가 “비상제동 후 차량이 완전히 정지할 것”인데 소프트웨어 요구사항에는 감속만 언급되고 정지까지 언급이 빠졌다면 일관성 문제가 있습니다. 또한 시스템 아키텍처에서 정한 인터페이스 조건과 소프트웨어 요구사항 내용이 어긋나지 않는지도 봅니다.
  
  
• 요구사항 상호 간 일관성: 소프트웨어 요구사항들끼리 모순되는 부분이 없는지 확인합니다. BP3에서 내용 점검을 했더라도, 추적성 연결 이후 다시 한번 전체를 조망하며 검사합니다.
  
  
• 추적성 링크의 일관성: 링크가 형식적으로 걸려 있을 뿐만 아니라, 연결된 양쪽 항목의 내용이 실제 서로 부합하는지를 검토합니다. 예를 들어 어떤 시스템 요구사항에 대응되는 SW 요구사항이 너무 부분적인 내용만 담고 있다면 나머지 부분이 누락된 것이므로 일관하지 않습니다. 또는 시스템 요구사항의 수치를 SW 요구사항이 다르게 쓰고 있다면 불일치입니다.
• 변경 상태의 일관성: 요구사항과 추적성은 시시각각 업데이트되므로, 이력 관리 상 서로 다른 버전 간 불일치가 없도록 해야 합니다. 예를 들어 상위 요구사항이 변경되었는데 하위가 아직 구버전인 상태라면 일관성 깨짐입니다. BP7에서는 이러한 변경 관리 측면도 확인하게 됩니다 (변경관리 프로세스와 연계).

 

실무 활동 예시: AEB 요구사항의 일관성 검증은 주로 검토 회의(Review) 형태로 이루어집니다. BP6에서 추적 매트릭스가 완성되었으면, 이를 기반으로 관련자들이 모여 하나씩 확인합니다. 예를 들어:

• 일관성 리뷰 1: 시스템 요구사항 “차량은 AEB 작동 시 최대 0.6g 감속도로 제동할 것” ↔ SWR-3 “감속도 0.6g 이하”가 잘 맞는지 검토. 내용이 부합하므로 OK. 만약 SWR-3이 0.5g로 써있었다면 불일치이므로 상위/하위 중 어디를 맞출지 결정해야 합니다.
  
  
• 일관성 리뷰 2: 시스템 요구 “AEB 경고음은 충돌 2.0초 전에 울릴 것” ↔ 소프트웨어 요구사항에 해당 내용 없음. 이 경우 SWR에 경고음 요구사항이 누락된 것이므로 새 요구사항을 추가하거나, 혹은 해당 시스템 요구가 차량 HMI 팀 소관이면 SW 요구에 포함하지 않는다는 것을 명확히 해야 합니다. 어느 쪽이든 추적성 매트릭스에 빈 링크로 남아있어서는 안됩니다.
  
  
• 일관성 리뷰 3: 소프트웨어 요구사항 간에 모순이 없는지 최종 점검. 예: SWR-2는 “TTC<=1.6초 시 브레이크”, SWR-6은 “센서 이상 시 브레이크 안 함”. 서로 조건이 다르지만 모순은 아님 (동시에 적용될 수 있음). 만약 “TTC<=1.6초 시 반드시 브레이크” 같은 절대적 표현이 있었다면 센서 이상 상황을 배제하지 않으므로 수정을 요합니다.
  
  
• 일관성 리뷰 4: 요구사항과 시스템 아키텍처 간. 예를 들어 아키텍처 상 AEB ECU에는 전방 카메라 입력은 없는데, 소프트웨어 요구사항에 “카메라 영상 분석하여 물체 인식” 같은 내용이 들어가 있다면 아키텍처와 불일치합니다. 이 경우 요구사항을 제거하거나 시스템 아키텍처를 변경해야 합니다.

 

이런 식의 리뷰를 통해 발견된 불일치는 즉시 수정하거나 Change Request로 남깁니다. 특히 추적성 링크가 있지만 내용 불일치한 경우 (예: 상위 요구에 없는 내용이 SWR에 있거나, 값 차이 등)은 오류로 간주하고 꼭 해소해야 합니다. ASPICE 가이드에서도 “단순히 링크가 있다고 일관성이 확보되는 것은 아니다. 내용의 일치 여부를 검증해야 한다”고 강조합니다. 이를 위해 동료 검토(peer review), 워크스루(walkthrough), 감사(audit) 등의 방법이 활용될 수 있습니다. 자동차 분야에서는 종종 요구사항 평가 회의를 열어 시스템, 소프트웨어, 테스트 부서가 함께 모여 이런 일관성을 체크하고 승 인절차를 거칩니다. 이 과정을 통해 모든 관련자들이 요구사항 세트가 상위 의도와 완벽히 부합함을 확인하게 됩니다.

 

BP7 산출물과 정보 항목: BP7의 결과는 일관성 검증 기록으로 남습니다. 이는 Consistency Evidence (13-51) 정보 항목의 일부로 볼 수 있으며, 추적성 링크에 대한 리뷰 기록, 체크리스트, 변경 이력 등이 해당됩니다. 예를 들어 요구사항 관리 도구에서 “Consistency Review”라는 필드를 두어 각 링크마다 검토자와 검토 일자, 상태를 남길 수도 있습니다. 또는 단순히 회의록에 “모든 링크 확인 완료 – 3건 수정 필요, 수정 후 재검토함”처럼 기록할 수도 있습니다. Change Request(변경요청)가 발행되었다면 그것도 추적되어야 합니다. ASPICE는 이러한 증빙을 통해 요구사항 세트가 일치되고(consistent) 있음을 보여주도록 요구합니다.

 

일관성 증빙의 특성으로는, 완전성 – 해당 검증이 모든 추적 관계와 요구사항을 다 다루었는가, 객관성 – 서로 다른 팀이나 담당자가 교차 확인하였는가, 정형성 – 일정한 기준(예: DoD, Definition of Done 목록)에 따라 일관성 체크가 수행되었는가 등이 있습니다. Note로, ASPICE에서는 종종 Definition of Done 활용도 언급하는데, 요구사항이 “Done” 되기 위한 체크리스트에 일관성 검토 항목이 포함되는 식입니다.

 

BP7까지 완료되면 소프트웨어 요구사항은 내용적으로도, 형식적으로도 품질이 보증된 상태가 됩니다. 상위 요구사항과 어긋나는 부분 없이 잘 정렬되었고, 불필요한 요구사항도 제거되었으며, 명세서와 추적 매트릭스가 서로 정확히 들어맞게 됩니다. 이는 이후 구현단계에서 “요구사항대로 만들었는데 잘못된 요구사항이었다”라는 위험을 크게 줄여줍니다.

 

SWE.1.BP8: 요구사항 합의 및 소통 (Communicate Agreed Software Requirements)

BP8의 핵심 목표: 최종 확정된 소프트웨어 요구사항을 모든 관련 이해관계자들에게 전달하고, 이들이 요구사항을 이해하고 동의하도록 하는 것입니다. 이전 단계들에서 여러 부서와 협업하며 요구사항을 다듬었겠지만, 공식적으로 승인되고 공유되는 절차를 거치는 것이 중요합니다. 형상관리 측면에서 요구사항 문서를 베이스라인(Baseline)으로 관리하기 시작하는 것도 이 단계에서 이루어집니다.

 

실무 활동 예시: AEB 소프트웨어 요구사항이 최종 확정되었다면, 다음과 같은 소통/합의 활동이 있을 수 있습니다:

• 내부 승인 회의: 소프트웨어 팀은 시스템 엔지니어 팀과 함께 요구사항 최종본을 검토하여 상호 승인합니다. 이 자리에는 품질 담당자나 프로젝트 매니저도 참여하여 요구사항 범위와 구현 계획을 확인합니다. 특히 안전 관련 요구사항이 있다면 기능안전 팀의 승인이 필수입니다. AEB의 경우 ISO 26262에 따라 요구사항이 안전 목표를 만족하는지도 검토되었을 것입니다. 이 모든 관련자가 요구사항에 동의하면 공식적으로 “승인” 도장이 찍힙니다.
  
  
• 대외 커뮤니케이션: 만약 개발사가 부품업체(Tier1)이고 고객(OEM)이 있는 상황이라면, 정리된 SW 요구사항을 고객에게 제출하여 합의를 받습니다. 예를 들어 OEM으로부터 받은 시스템 요구사항을 기반으로 Tier1이 SW 요구사항을 만들었으면, 이를 OEM과 리뷰하면서 “이런 소프트웨어 동작으로 귀사가 원하는 기능을 충족시킬 예정”이라고 상호 확인합니다. 필요시 고객의 추가 의견을 반영하여 수정한 뒤 최종 합의합니다.
  
  
• 개발팀 전파: 요구사항이 확정되었으므로, 이를 개발팀 전체에 공지합니다. 모든 소프트웨어 설계자, 코더, 테스트 엔지니어에게 최신 요구사항 문서를 배포하고 접근할 수 있게 합니다. 보통은 요구사항 관리 도구 자체가 중앙 저장소 역할을 하므로, 거기에 Baseline 버전을 설정해두고 모든 사람이 열람하도록 합니다. 변경 시 알림이 가도록 세팅하거나, 주간 미팅에서 요구사항 베이스라인 버전이 나왔음을 알리기도 합니다.
  
  
• 다른 관련 부서 통보: SW 요구사항은 향후 하드웨어팀(만약 보드 변경 필요), 검증팀(테스트 케이스 설계), 생산/서비스팀(진단 요구사항 포함 시) 등과도 연관될 수 있습니다. 예를 들어 AEB 기능 추가로 차량 사용설명서에 변경이 필요할 수 있다면, 그 관련 부서에도 알려야 합니다. 이러한 cross-functional 커뮤니케이션은 프로젝트 차원에서 이루어지지만, 요구사항 담당자로서 챙겨야 할 수도 있습니다.

 

소통 수단: BP8에서는 다양한 커뮤니케이션 수단을 활용할 수 있습니다. 공식 서한이나 메일, 회의록 같은 문서화된 방식이 권장됩니다. 예컨대 “SWE.1 완료 회의록”을 작성하여 참석자, 주요 합의사항, 요구사항 베이스라인 버전, 남은 액션 아이템 등을 기록해 둡니다. Jira/Confluence 같은 협업툴을 쓰는 조직이라면 Confluence 페이지에 요구사항 목록을 게시하고 관련자 모두를 watcher로 등록해 업데이트 시 알림을 보내는 방법도 있습니다. 일부는 단체 채팅이나 구두로 전하기도 하지만, Communication Evidence (13-52)를 남기려면 이메일이나 회의록처럼 형태가 남는 수단이 바람직합니다. ASPICE는 메일, 미팅, wiki, chat 등 어떤 형태든 좋으니 요구사항이 해당자에게 전달되었다는 증거를 유지하라고 하고 있습니다.

 

BP8 산출물과 정보 항목: 이 단계의 산출물은 커뮤니케이션 증적으로, ASPICE 정보 항목 13-52: Communication Evidence에 속합니다. 예를 들면 “요구사항 명세서 v1.0 배포 이메일 (수신자: 팀 전원, 날짜/시간)”, “고객 요구사항 승인 회의록 (서명본)”, “Confluence 변경 이력 페이지” 등이 해당합니다. 이러한 증적 자료는 나중에 “정말 관련자들에게 알렸는가?”라는 질문에 답할 수 있게 해줍니다. 정보 항목 특성으로서는 명확성(누가 받았고 언제 전달되었는지 분명히), 적시성(개발이 시작되기 전에 전달되었는지), 포괄성(모든 관련 부서를 포함했는지)이 중요합니다. 예를 들어 핵심 테스트팀 한 명이 누락되어 전달을 못 받았다면 커뮤니케이션 완전성이 떨어지는 것이죠.

 

마지막으로 요구사항 베이스라인 승인이 이루어졌다면, 이를 형상관리 툴에 버전으로 태그하고 읽기전용으로 보존합니다. 이후 변경이 생기면 Change Request 프로세스(ASPICE SUP.10)에 따라 관리될 것입니다. BP8까지 완료됨으로써 SWE.1 프로세스의 산출물들은 공식적인 엔지니어링 입력물로 자리매김하고, 개발 사이클의 다음 단계(SWE.2 소프트웨어 아키텍처 설계 등)로 넘어갈 준비가 됩니다.

 

4. 결론: AEB 사례를 통해 본 SWE.1의 중요성

지금까지 ASPICE 4.0의 SWE.1 소프트웨어 요구사항 분석 프로세스를 AEB 시스템 예시로 상세히 살펴보았습니다. 요구사항의 정의부터 구조화, 분석, 검증, 추적 및 소통에 이르는 전 과정을 거치면서, 초기의 막연한 기능 아이디어가 명확하고 검증가능한 요구사항 명세로 다듬어졌습니다. 특히 AEB와 같이 안전-critical한 ADAS 기능에서는 이 요구사항 단계에서의 철저한 작업이 더욱 중요합니다. 잘못되거나 모호한 요구사항은 나중에 심각한 결함이나 안전 문제로 이어질 수 있기 때문입니다. 실제로 “AEB 모델은 객체와의 TTC가 임계값 이하로 떨어질 때 브레이크를 활성화한다”는 것이 수학적으로, 또 시스템적으로 제대로 명문화되어야만 올바른 구현과 테스트가 가능합니다. SWE.1 프로세스를 충실히 수행하면 이러한 요구사항 품질이 확보되어 개발팀과 테스트팀, 그리고 고객이 공통된 이해를 가지고 프로젝트를 진행할 수 있습니다.

 

AEB 사례에서 보았듯, TTC 계산 로직, 센서/액추에이터 인터페이스, 브레이크 제어 조건 등의 구체적인 요구사항들이 SWE.1의 각 활동과 밀접히 연관되어 다루어졌습니다. 요구사항 하나하나를 깊이 검토하는 과정에서 성능 한계치나 안전 여유를 재검토하게 되고, 이는 더 나은 설계 선택으로 이어지기도 합니다. 또한 요구사항 추적성 구축과 일관성 검증은, 변경이 불가피한 자동차 개발 프로젝트에서 변경 영향 분석과 품질 관리의 확실한 기반이 되어줍니다.

 

요구사항 단계는 지루하거나 형식적으로 느껴질 수도 있지만, “소프트웨어 개발의 시작은 곧 끝을 결정한다”는 말이 있듯이 매우 중요합니다. 초보 개발자라도 SWE.1 프로세스의 각 스텝을 이해하고 따르면, 복잡한 ADAS 기능 구현도 한 걸음 한 걸음 체계적으로 밟아나갈 수 있습니다. 요구사항 명세서를 작성하고, 팀과 함께 리뷰하며, 추적 매트릭스를 관리하는 일련의 작업은 초기엔 시간과 노력이 들지만 결과적으로 재작업을 줄이고 오류를 예방하여 프로젝트 전체 효율을 높입니다.

 

마지막으로, SWE.1에서 만들어진 산출물들은 이후 SWE.2 아키텍처 설계, SWE.3 상세설계/코딩, SWE.4~6 테스트 단계의 출발점이 됩니다. 예컨대 아키텍트는 요구사항을 보고 어떤 모듈이 필요할지 설계를 하고, 테스터는 요구사항을 근거로 테스트 케이스를 작성하게 됩니다. 따라서 SWE.1 산출물이 잘 정리되어 있고 품질 특성을 만족하고 있는지는 프로젝트 성공의 열쇠라고 해도 과언이 아닙니다. “쓰레기가 들어오면 쓰레기가 나간다(Garbage In, Garbage Out)”는 격언처럼, 처음 요구사항이 부실하면 아무리 좋은 프로세스를 적용해도 좋은 소프트웨어가 나오기 어렵습니다. 반대로 견고한 요구사항 기반 위에서는 이후 개발 과정의 시행착오가 크게 줄어들 것입니다.