스티뮬러스의 모델 기반 요구사항 검증 방법
산업 디지털 전환을 가속화하는 버추얼 트윈 (7)
현대 산업 시스템이 복잡해지면서 개발 초기 단계의 정확한 요구사항 검증이 중요해졌다. 특히 안전이 중요한 시스템에서 발생하는 오류는 치명적인 결과를 초래할 수 있다. 하지만 자연어 기반의 전통적인 요구사항 명세는 모호하여 해석 오류를 낳고, 요구사항 간 충돌이나 누락을 발견하기 어렵다는 한계를 갖는다.
이번 호에서는 모델 기반 시스템 엔지니어링(MBSE) 접근법을 지원하는 다쏘시스템의 요구사항 시뮬레이션 도구 스티뮬러스(STIMULUS)를 통해 개발 초기부터 정확성, 완전성, 일관성을 검증하는 새로운 해결책을 살펴본다.
■ 신효주
다쏘시스템코리아의 Industry Process Consultant로 모델 기반 시스템 엔지니어링 설루션을 담당하고 있다. 자동차, 항공, 전자제품 등 다양한 산업 분야에서 프로젝트를 수행하며 복잡한 시스템 개발 과정에서의 어려움을 파악하고 이를 해결하기 위한 방법론과 MBSE 기반의 설루션을 제안하고 있다. 특히, 요구사항 검증 및 시스템 아키텍처 방법론을 중심으로 고객의 개발 효율성과 품질 향상을 지원하는 역할을 수행한다.
홈페이지 | www.3ds.com/ko
MBSE 접근을 통한 요구사항 검증
현대의 산업 시스템은 점점 더 복잡해지고 있으며, 이에 따라 시스템 개발 초기 단계에서의 정확한 요구사항 정의와 검증의 중요성이 커지고 있다. 특히 항공우주, 자동차, 철도, 의료기기 등 안전이 중요한 산업 분야에서는 시스템 오류가 치명적인 결과로 이어질 수 있어, 개발 초기 단계에서의 철저한 요구사항 검증이 필수이다.
그러나 전통적인 요구사항 관리 방식은 여러 가지 심각한 한계점을 가지고 있다. 가장 근본적인 문제는 자연어를 사용한 요구사항 명세에서 시작된다. 자연어의 본질적 모호성으로 인해 동일한 요구사항에 대해 서로 다른 해석이 가능하며, 이는 개발 과정에서 심각한 오해와 실수로 이어질 수 있다. 예를 들어 “시스템은 빠르게 응답해야 한다”와 같은 요구사항은 ‘빠르게’라는 단어의 모호성으로 인해 개발자와 사용자 간에 기대치의 차이를 초래할 수 있다.
또한, 수백 혹은 수천 개의 요구사항이 존재하는 대규모 시스템에서는 요구사항 간의 상충 관계를 수동으로 발견하는 것이 거의 불가능하다. 시스템의 특정 상태나 조건에 대한 요구사항이 누락되었을 때도 이를 문서 검토만으로는 발견하기 어렵다. 더욱 심각한 문제는 대부분의 요구사항 오류가 설계 단계나 심지어 구현 단계에서야 발견된다는 점이다. 이 시점에서의 수정은 많은 비용과 시간을 필요로 하며, 전체 프로젝트의 지연으로 이어질 수 있다.
현대의 복잡한 시스템에서는 이러한 문제가 더욱 심화된다. 정적인 문서로는 여러 컴포넌트가 동시에 상호작용하는 시스템의 동적 동작을 완전히 이해하고 검증하는 것이 불가능하다. 특히 실시간 시스템에서 중요한 타이밍 제약조건을 문서만으로는 충분히 검증할 수 없으며, 요구사항 변경이 시스템의 다른 부분에 미치는 영향을 파악하고 추적하는 것도 매우 어려운 과제이다.
이러한 한계를 극복하기 위해 선진 기업에서는 MBSE 접근법을 주목하고 있으며, 그 중에서도 다쏘시스템의 스티뮬러스(STIMULUS)는 혁신적인 요구사항 시뮬레이션 기능을 통해 새로운 해결책을 제시한다. 스티뮬러스의 Requirement-In-the-Loop(RIL) 시뮬레이션을 통해 요구사항을 형식화 하고 실행 가능한 모델로 변환하여, 개발 초기 단계에서 요구사항의 정확성, 완전성, 일관성을 검증할 수 있다.
모델 기반 요구사항 검증 방법
시스템 개발에서 요구사항의 정확한 명세와 검증은 성공적인 프로젝트 수행을 위한 핵심 요소이다. 이번 호에서는 먼저 스티뮬러스의 핵심 기능인 Requirement-In-the-Loop(RIL) 시뮬레이션에 대해 살펴보려고 한다.
그림 1. 랜딩기어 시스템 핸들 명령 요구사항 모델링
요구사항 모델링
시스템의 기능을 검증하기 위해서는 두 가지 주요 요구사항 관점을 이해해야 한다. 첫 번째는 ‘What’ 관점으로, 시스템이 수행해야 하는 구체적인 동작이나 특정 기능을 명시하는 요구사항을 의미한다. 예를 들어 랜딩기어(landing gear) 시스템에서 “핸들 명령이 down일 때, 모든 랜딩기어는 15초 이내에 확장되고 모든 도어는 닫혀야 한다”와 같은 요구사항이 이에 해당된다.
두 번째는 ‘How well’ 관점으로, 시스템이 기능 요구사항을 얼마나 잘 충족하는지 즉 안전성과 성능, 사용성 등 시스템의 품질 속성을 정의하는 요구사항을 의미한다. 랜딩기어 시스템이 15초 이내에 모든 기어를 확장하고 모든 도어를 닫는 데 성공하는지 여부가 이러한 관점의 예시가 될 수 있다.
RIL 시뮬레이션에서는 두 가지 관점 중에서도 ‘What’ 관점의 기능 요구사항을 주로 사용한다. 스티뮬러스는 이러한 기능 요구사항을 형식화하기 위해 일련의 문장 템플릿을 제공하며, 이를 레고 블록처럼 조합하여 정형화된 요구사항을 만들 수 있다. 랜딩기어 시스템에서 ‘핸들 명령이 down일때, 모든 랜딩 기어는 15초 이내에 확장되고 모든 도어는 닫혀야 한다’라는 요구사항을 스티뮬러스에서 형식화하기 위해 ‘When’, ‘is’, ‘shall be’와 같은 기본 템플릿을 조합하게 된다.
‘When’, ‘is’, ‘shall be’와 같은 템플릿은 단순한 문장 구조를 넘어 정확한 의미를 내포하고 있다. 예를 들어 ‘When’ 템플릿은 조건이 참일 때 특정 동작을 활성화하는 상태 기계(state machine)로 정의되어 있으며, ‘is’ 템플릿은 수학적 동등성을 의미한다. 이렇게 명확한 의미가 정의되어 있기 때문에 특정 기능 요구사항에 대해 모두가 동일한 방식으로 스티뮬러스 요구사항 모델을 정의하고, 동등한 의미로 해석할 수 있다.
■ 자세한 기사 내용은 PDF로 제공됩니다.
작성일 : 2025-10-02