15. 확인 프로세스 (Section 6.1)

앞절에서 확인 프로세스(Validation Process)가 DO-254에서는 파생 요구사항에 국한된 개념이라고 설명한 바가 있다. 좀 더 구체적인 내용을 살펴보자.

 

 

해석을 보자.

 

여기에서 논의되는 확인 프로세스는 객관적인 그리고 주관적인 프로세스의 조합의 사용을 통해서 하드웨어 아이템에 할당된 시스템 요구사항에 대해서 파생 요구사항이 정확하고 완전한지를 보장하기 위한 의도이다.

 

위의 설명의 요지는 결국 파생 요구사항이 시스템 요구사항에 영향을 미치는 부분이 없는지를 확인한다는 것이다. 이 경우 이렇게 추가된 파생 요구사항으로 인해서 시스템 요구사항이 변경되어야 할 수도 있고 혹은 전혀 영향을 받지 않을 수도 있다. 이와 관련해서 파생 요구사항에 대해서 추가로 설명하는 부분이 있다.

 

 

해석을 보자.

 

시스템의 다른 영역에 할당된 시스템 안전성 혹은 기능 요구사항에 영향을 주는 설계 결정은 파생 요구사항으로써 구분되어야 하며 확인되어야 한다. 추가적으로, 이어지는 설계 태스크들을 제한하는 설계 결정과 가정은 파생 요구사항으로써 확인되어야 한다.

 

일반적으로 파생 요구사항은 설계를 하는 과정에서 새롭게 추가되는 경우가 대부분이다. 즉, 설계 관점에서 필요한 부분이 식별되고 그것을 기존 요구사항으로 커버하지 못하는 경우에는 파생 요구사항으로 정의해서 공식적인 요구사항으로 관리하는 것이다. 이렇게 추가된 파생 요구사항이 만약 시스템 안전성이나 기능과 관련되는 것으로 판단되면 시스템 레벨에서 그 요구사항에 대한 분석부터 다시 시작하게 되는 것이다. 대신 그것이 아니라면 대개는 설계 과정에 대한 요구사항의 하나로만 국한되는 경우일 수 있다. 이 때에는 하드웨어 요구사항의 하나로 처리되는 것이다.

 

15.1. 파생 요구사항 관련 설계 결정(Design decision)의 예

 

DO-254 가이드라인에서는 파생 요구사항과 관련된 설계 결정(Design decision)에 대해서 2가지 예를 들고 있다. 구체적인 내용을 확인해 보자.

 

첫 번째 예시는 ‘특정한 기능을 수행하는 회로를 위해 분리된 전원 공급 장치를 사용하기로 설계 결정(Design decision)’하는 경우이다.

 

 

해석을 보자.

 

특정한 기능을 수행하는 회로도를 위한 분리된 전원 공급 장치를 포함하는 설계 결정은 그 전원 공급의 설계를 가이드하기 위한 요구사항에 차이를 가져올 수 있다. 이러한 파생 요구사항은 그 전원 공급 장치로부터 전원을 공급받는 회로에 의해서 지원되는 기능의 오류 혹은 실패로부터 발생할 수 있는 실패 조건에 기반한 안전성 요구사항을 포함할 수 있다. 이러한 요구사항은 확인되어야 한다.

 

위의 설명을 기준으로 보자면 아래와 같은 두 가지 중요한 고려사항이 발생하게 된다.

 

- 전원 공급 장치에 대한 기존 요구사항에 영향을 줄 수 있음

- 분리된 전원 공급 장치를 통해서 동작하는 회로의 고장에 대한 안전성 요구사항이 포함되어야 할 수 있음

 

물론 기존 기능 요구사항이나 안전성 요구사항에 영향을 미치지 않고 단순히 하드웨어 설계 관점에서 몇 가지 추가되는 것으로 넘어갈 수도 있을 것이다. 하지만 그것을 확인하기 위해서라도 시스템 관점에서의 검토와 확인이 필요하게 된다.

 

두 번째 예시는 ‘메모리 주소 할당과 관련된 설계 결정(Design decision)’이다.

 

 

해석을 보자.

 

파생 요구사항이 되는 설계 결정의 또 다른 예는 주변장치에 대한 메모리 주소 할당이다. 그러한 할당에 대해서는 대개 할당에 대한 요구사항 기준이 없다. 하지만 일단 만들어 지면 그러한 설계가 올바로 동작하기 위해 이어지는 설계 태스크들이 그러한 할당을 따르도록 제약하게 된다. 이 파생 요구사항은 확인될 필요가 없을 수도 있다.

 

처음 본 예시와 다른 점은 바로 메모리 할당과 관련된 시스템 요구사항이 없다는 점이다. 아마도 어떠한 주변 기기가 사용되어야 한다는 정도의 요구사항은 있겠지만 그것들을 어떤 메모리 주소에 할당하라는 요구사항까지는 존재하지 않을 것이다. 바로 이런 것이 설계 레벨 자체에서 결정될 수 있는 파생 요구사항이 된다. 두 번째 예시는 이렇게 결정되는 파생 요구사항에 대해서는 시스템 차원의 확인(Validation)이 필요 없다는 것을 설명하고 있다.

 

이번 예시를 통해서 파생 요구사항이 무엇을 말하는 것인지 그리고 어떤 관점으로 바라봐야 하는 지가 어느 정도는 이해되었을 것이다. 이제 이러한 파생 요구사항을 확인하는 확인 프로세스의 목표(Objectives)와 활동(Activities)에 대해서 알아보자.

 

15.2. 확인 프로세스 목표(Objectives)

 

먼저 확인 프로세스의 목표(Objectives)이다.

 

 

해석을 보자.

 

1. 검증되어야 하는 하드웨어 아이템에 대해서 파생된 하드웨어 요구사항이 정확하고 완전하다. 2. 파생 요구사항은 안전에 대한 충격이 평가된다. 3. 누락과 에러는 해결을 위해 적절한 프로세스로 피드백된다.

 

결론적으로 앞에서 이야기한 것들이 목표로 제시되고 있는 것을 확인할 수 있다.

 

15.3. 확인 프로세스 활동(Activities)

 

확인 프로세스의 목표(Objectives)를 만족하기 위한 활동(Activities)의 방법으로써 DO-254 가이드라인에서는 다음과 같은 것들을 제시하고 있다.

 

 

해석을 보자.

 

하드웨어 확인 목표는 리뷰, 시뮬레이션, 프로토타입, 모델링, 분석, 서비스 경험, 엔지니어링 평가, 혹은 시험의 개발 및 실행과 같은 활동들의 조합을 통해서 만족될 수 있다.

 

DO-254에서는 확인(Validation)을 위해 다양한 방법들을 허용하고 있다는 것을 확인할 수 있다. 이러한 방법들을 활용해서 수행하는 확인 프로세스의 활동에 대해서 DO-254 가이드라인에서는 다음과 같이 7가지를 제시하고 있다.

 

① 확인이 필요한 파생 요구사항의 식별

② 확인 기준의 식별
a. 리뷰, 분석 혹은 시험에 의해 계층적인 레벨에서 각각의 요구사항을 확인
b. 특히 안전에 대해서 적절한지를 확인
c. 리뷰, 분석 혹은 시험 결과물의 정확도와 차이점 확인

③ 파생 요구사항의 안전에 대한 충격을 평가

④ 파생 요구사항의 완전성(Completeness)에 대한 평가
정의된 모든 특성(Attribute)의 필요성이 확인되고, 필요한 모든 특성(Attribute)이 정의된 경우

⑤ 파생 요구사항의 정확성(Correctness)에 대한 평가
요구사항에 모호함(Ambiguity)이 없고 정의된 특성(Attribute)에 에러가 없는 경우

⑥ 파생된 하드웨어 요구사항과 확인 활동(Activities) 그리고 결과 사이의 추적성 생성

⑦ 요구사항 누락 및 에러의 해결을 위해 적절한 프로세스로 피드백

 

파생 요구사항 역시 하나의 요구사항이므로 요구사항이 갖추어야 할 모든 조건을 동일하게 가지고 있어야 한다. 위의 활동들은 결국 그것을 확보하기 위한 것이라고 할 수 있다.