자동차 소프트웨어 개발을 처음 접하면 ASPICE에서 SYS.1과 SYS.2가 어떻게 다른지 헷갈릴 수 있다. 둘 다 요구사항과 관련된 프로세스처럼 보이지만 역할은 분명히 다르다. SYS.1은 고객 요구사항을 이해하고 관리하는 활동이고, SYS.2는 그 고객 요구사항을 바탕으로 시스템 요구사항을 분석하고 정의하는 활동이다. 쉽게 말해 SYS.1은 “고객이 무엇을 원하는지 확인하는 단계”이고, SYS.2는 “그 요구를 시스템 관점에서 어떻게 정리할지 결정하는 단계”라고 볼 수 있다.
SYS.1은 Stakeholder Requirements Elicitation, 즉 이해관계자 요구사항 도출 프로세스다. 여기서 이해관계자는 완성차 업체, 고객사, 내부 개발팀, 품질팀, 안전 담당자, 검증 담당자 등 프로젝트에 영향을 주는 여러 관계자를 의미한다. SYS.1의 목적은 다양한 이해관계자의 요구를 수집하고, 빠진 내용이나 모호한 내용을 확인하며, 프로젝트에서 다루어야 할 요구사항의 기준을 정리하는 것이다.
예를 들어 고객이 “차량 경고 기능이 운전자에게 빠르게 전달되어야 한다”고 요구했다고 가정해보자. SYS.1 단계에서는 이 요구가 어떤 상황에서 필요한지, 어떤 운전자 알림을 의미하는지, 관련 법규나 안전 요구사항이 있는지 확인한다. 또한 고객 요구사항 사이에 충돌은 없는지, 개발 범위에 포함되는지, 추가 확인이 필요한 부분은 없는지 검토한다. 즉 SYS.1은 요구사항을 기술적으로 설계하기 전, 고객과 이해관계자의 의도를 정확히 파악하는 과정이다.
반면 SYS.2는 System Requirements Analysis, 즉 시스템 요구사항 분석 프로세스다. SYS.1에서 정리된 고객 요구사항을 바탕으로 시스템 수준에서 구현 가능한 요구사항을 작성한다. 이때 시스템은 소프트웨어만 의미하지 않는다. ECU, 센서, 액추에이터, 통신, 하드웨어, 소프트웨어가 함께 동작하는 전체 기능 구조를 말한다. 따라서 SYS.2에서는 기능 동작, 입력과 출력, 성능 기준, 진단 조건, 통신 조건, 고장 처리, 제약 사항 등을 시스템 요구사항으로 구체화한다.
앞의 예시를 SYS.2 관점으로 바꾸면 “위험 조건 감지 후 300ms 이내에 클러스터 경고 메시지를 표시해야 한다”처럼 검증 가능한 요구사항으로 정리할 수 있다. 또한 어떤 신호를 입력으로 받을지, 어떤 ECU가 판단할지, 어떤 통신 메시지를 사용할지, 오류 상황에서는 어떻게 동작할지도 함께 정의할 수 있다. SYS.2는 고객의 요구를 실제 개발과 검증이 가능한 시스템 요구사항으로 변환하는 과정이라고 이해하면 쉽다.
SYS.1과 SYS.2의 가장 큰 차이는 관점이다. SYS.1은 고객과 이해관계자 관점에서 요구를 도출하고 합의하는 데 초점이 있다. 반면 SYS.2는 시스템 엔지니어링 관점에서 요구사항을 분석하고 구체화하는 데 초점이 있다. SYS.1이 부족하면 고객이 원하는 기능을 잘못 이해할 수 있고, SYS.2가 부족하면 이해한 요구를 실제 시스템으로 구현하기 어렵다.
또 다른 차이는 산출물이다. SYS.1의 주요 산출물은 이해관계자 요구사항, 고객 요구사항 분석 결과, 요구사항 합의 내용, 미해결 이슈 목록 등이 될 수 있다. SYS.2의 주요 산출물은 시스템 요구사항 명세서, 요구사항 검토 결과, 요구사항 간 추적성, 검증 가능성 검토 결과 등이 될 수 있다. 두 산출물은 서로 분리된 문서가 아니라 연결되어야 한다. 고객 요구사항이 어떤 시스템 요구사항으로 반영되었는지 확인할 수 있어야 ASPICE에서 요구하는 추적성을 확보할 수 있다.
결론적으로 SYS.1과 SYS.2는 모두 자동차 개발 초기에 매우 중요한 프로세스다. SYS.1은 고객과 이해관계자의 요구를 정확히 파악하는 단계이고, SYS.2는 그 요구를 시스템 수준의 명확하고 검증 가능한 요구사항으로 정리하는 단계다. 두 프로세스가 제대로 수행되어야 이후 SYS.3 시스템 아키텍처 설계, SWE.1 소프트웨어 요구사항 분석, 검증 단계가 안정적으로 이어질 수 있다. ASPICE를 실무에서 이해하려면 SYS.1은 요구의 출발점, SYS.2는 개발 기준을 만드는 단계로 구분해서 보는 것이 좋다.