9. 요구사항 캡처 프로세스 (Section 5.1)

하드웨어 설계 프로세스에서 가장 먼저 나오는 것이 아래 그림과 같이 요구사항 캡처 프로세스(Requirements Capture Process)이다.

 

그림 11 요구사항 캡처 프로세스와 파생 요구사항

이름만으로도 ‘요구사항(Requirements)’을 얻는 단계라는 것은 누구나 짐작할 수 있을 텐데 여기에서 한 가지 주목할 부분이 있다. 바로 아래쪽에 연결된 화살표에 표시되어 있는 ‘파생 요구사항(Derived Requirements)’이다. DO-254 가이드라인에서는 파생 요구사항을 다음과 같이 설명하고 있다.

 

 

해석을 보자.

 

이것은 시스템 안전성 평가에 의해서 부과된 요구사항뿐만 아니라 제안된 하드웨어 아이템 아키텍처, 기술 선택, 기본적인 그리고 선택적인 기능성, 환경, 그리고 성능 요구사항에 의해서 부과되는 그러한 파생된 요구사항을 포함한다.

 

설명이 복잡한 것 같지만 위의 내용은 시스템에서 결정해서 할당해 준 기본적인 요구사항 뿐만 아니라 하드웨어 설계 과정 자체의 필요에 의해서 발생한 요구사항을 파생요구사항이라고 하고 그것 역시 요구사항 캡처 프로세스에서 정해져야 한다는 것을 의미한다. 참고로 이는 소프트웨어 인증인 DO-178에도 동일하게 적용되는 개념이다.

 

파생 요구사항에 대해서 한 가지 더 기억해야 할 것이 있다. 파생 요구사항(Derived Requirements)에 대한 DO-254 가이드라인의 용어 정의를 보면 다음과 같이 설명되어 있다.

 

 

해석을 보자.

 

파생 요구사항 – 하드웨어 설계 프로세스로부터 나온 추가적인 요구사항, 이것은 상위 레벨 요구사항으로의 직접적인 추적성이 없을 수 있다.

 

즉, 파생 요구사항은 상위레벨, 즉 시스템 요구사항과의 추적성이 없을 수 있다는 말이다. 참고로 이 부분은 DO-178에서는 아예 상위레벨로의 추적성이 없는 것을 ‘파생 요구사항’이라고 단정적으로 정의하는 것과는 다소 뉘앙스의 차이가 있는 부분이다.

 

참고로 위의 그림을 보면 파생 요구사항이 모든 프로세스와 연결되어 있는 것을 볼 수 있다. 이것은 어느 단계에서든 필요에 의해서 파생 요구사항이 생성될 수 있다는 의미이다. 그리고 그렇게 되면 이전 단계로 전달되어 생성된 파생 요구사항이 적절한지에 대한 검토가 이루어 진다는 것까지 포함하고 있다.

 

9.1. 요구사항 캡처 프로세스 목표(Objective)

 

요구사항 캡처 프로세스에서는 다음과 같은 목표를 준수해야 한다.

 

 

해석을 보자.

 

1. 요구사항이 식별되고 정의되며 문서화된다. 이것은 PSSA로부터 할당된 요구사항과 하드웨어 안전성 평가로부터의 파생 요구사항을 포함한다. 주의: 검증 결과의 하드웨어 요구사항으로의 추적성은 Section 6에 설명된다. 요구사항 캡처 프로세스 동안에 추적성의 이러한 방법을 세우는 것이 바람직하다.   2. 생성된 파생 요구사항은 적절한 프로세스로 피드백된다. 3. 요구사항 누락과 에러는 해결을 위해서 적절한 프로세스로 제공된다.

 

요구사항은 일단 한 번 결정되면 반드시 실제로 구현되어야 한다는 점에서 두 말할 필요없이 가장 중요한 항목이다. 그것은 요구사항이 하드웨어 설계 라이프 사이클 전반에 영향을 미친다는 것을 의미한다. 따라서 요구사항이 새로 만들어 지든, 수정되든, 혹은 누락되든 그것은 반드시 충분한 검토가 되어야 한다. 위에서 제시된 목표들은 그것을 모두 함축하고 있다. 그리고 추적성(Traceability)은 그런 활동과정에서 거의 필수라고 할 수 있는 산출물이다. 하드웨어 요구사항이 만들어 질때마다 반드시 상위레벨로의 추적성을 연결해서 요구사항의 근거를 확인해야 한다.

 

9.2 요구사항 캡처 프로세스 활동(Activities)

 

요구사항 캡처 프로세스 활동(Activities)의 핵심은 캡처된 요구사항이 설계의 구현, 시스템 요구사항 그리고 소프트웨어 요구사항과 일관성을 가진다는 것을 보장하는 것이다. 참고로 이는 활동의 반복을 통해서 이루어 진다. DO-254 가이드라인에서는 총 8가지의 활동을 제시하고 있다.

 

① 하드웨어 아이템으로 할당된 시스템 요구사항을 문서화
기능 및 성능과 같은 요구사항 그리고 분리, BIT, 시험가능성, 외부 인터페이스, 환경, 시험 및 유지 고려사항, 전원, 물리적 특성 등의 아키텍처 고려사항을 포함

② PSSA로부터의 안전성 요구사항 식별
a. 설계 보증 레벨(Design Assurance Level)
b. 오동작 혹은 기능 상실에 대한 발생확률 요구사항
c. 하드웨어의 아키텍처 및 기능적 안전성 식별

③ 설계 제약사항의 식별
생산 프로세스, 표준, 절차, 기술, 설계 환경, 설계 지침 등으로 인한 제약

④ 파생 요구사항 결정
주의: 파생 요구사항이 가질 수 있는 조건 10가지를 제시하고 있음, DO-254 가이드라인 참고

⑤ 파생 요구사항을 SSA 프로세스로 피드백하기: 시스템 요구사항 평가 고려

⑥ 요구사항 데이터를 정량화하기

⑦ 요구사항 누락 혹은 에러를 시스템 개발 프로세서로 전달하기

⑧ 상위레벨로의 추적성 확인하기

 

위의 활동은 기본적으로 하드웨어 요구사항 하나가 캡처될 때마다 수행되어야 하는 활동이라고 할 수 있다. 그렇게 본다면 정말 광범위한 활동이 아닐 수 없다. 과연 현실적으로 가능할까 싶기도 하지만 그 만큼 요구사항의 결정이 중요하다는 점을 반증하는 것이기도 하다. 더 자세한 내용은 가이드라인을 참고하자.