5.3 요구사항 캡처

요구사항은 관련된 위험과 함께 필수 프로세스에 대한 공통 기반을 제공한다. 위험은 중요도가 다를 수 있기 때문에 시스템 아키텍처를 통한 요구사항 할당은 인증 입증의 용이성에 상당한 영향을 미친다.

 

항공기 개발 사이클의 최상위 레벨 프로세스에는 항공기 기능의 식별 및 이러한 기능과 관련된 요구사항이 포함된다. 기능 인터페이스 및 그에 상응하는 안전성 요구사항을 포함한 항공기 기능은 시스템 아키텍처를 설정하기 위한 기초를 형성한다. 아키텍처의 선택은 해당 아키텍처를 구현하기 위해 필요한 추가적인 요구사항을 설정한다. 요구사항 식별 및 할당 프로세스의 각 단계(즉, 시스템 및 아이템)에서 기존 요구사항과 새로 파생된 요구사항에 대한 추가적인 세부 사항이 모두 식별된다. 구현 중에 만들어지는 선택과 마주치는 문제는 파생 요구사항의 주요 소스이며 새로운 시스템 안전성 요구사항의 식별을 가져올 수 있다. 상세 설계 활동은 항상 새로운 요구사항을 주입하거나 기존 요구사항을 변경한다.

 

요구사항은 다양한 형식으로 캡처될 수 있으며, 텍스트 혹은 그래픽이 가장 일반적이다. 형식에 관계없이 요구사항 개발 계획 및 표준은 요구사항 집합 전반에 걸쳐 일관성을 확립하고 요구사항 캡처에 대해서 기대하는 부분을 개발팀 전체가 커뮤니케이션하도록 하기 위해 개발되어야 한다. 이는 그래픽 혹은 모델 요구사항 캡처 형식을 사용할 때 특히 중요하다.

 

그래픽 요구사항 캡처가 계획되면, 다음 주제들 또한 포함되어야 한다.

 

• 모델/모델링 사용 식별,
• 개발 중 의도된 도구와 그 사용법을 식별,
• 사용될 모델링 언어를 기반으로 모델 사용에 대한 공통된 이해를 확립하기 위해 모델링 표준 및 라이브러리를 정의. 모델 내용은 읽을 수 있는 그래픽 형식이어야 한다. 표시된 실제 신호 및 인터페이스와 관련된 기호 혹은 이름을 명확하게 식별할 수 있는 수단이 제공되어야 한다. 모델은 계층 방식으로 개발되어야 한다. 예를 들어, 두 번 이상 사용될 수 있는 모델 요소의 서브셋은 유닛 혹은 전체 콘텐츠로 처리 및 표시될 수 있다.

 

요구사항을 캡처하고 임베디드 코드(소프트웨어 혹은 HDL)를 직접 생성하는 데 사용되는 모델은 인증 신뢰를 받을 때부터 시스템 검증을 위해 소프트웨어 혹은 하드웨어를 시스템 프로세스에 반환할 때까지 DO-178B/ED-12B 그리고 DO-254/ED-80의 범위 내에 있게 된다.

 

5.3.1. 요구사항 유형

 

주어진 기능과 관련된 요구사항은 해당 기능이 해당 환경에서 작동하는 방식을 정의하고 사용자/머신 인터페이스의 정의를 포함한다. 아래에 자세히 설명된 요구사항 유형은 개발 활동의 다양한 단계(즉, 항공기, 시스템 그리고 아이템)에서 고려되어야 한다. 비즈니스 혹은 경제적 이슈를 엄격하게 다루고 안전성 혹은 인증 요구사항에는 영향을 미치지 않는 요구사항이 있을 수 있다.

 

5.3.1.1 안전성 요구사항

 

항공기 및 시스템 레벨 기능에 대한 안전성 요구사항에는 기능의 가용성과 무결성 모두에 대한 최소 성능 제약이 포함된다. 이러한 안전성 요구사항은 섹션 5.1의 프로세스와 일치하는 안전성 평가를 수행하여 결정해야 한다.

 

항공기 및 시스템 기능에 대한 안전성 요구사항은 관련 기능 고장 조건을 식별하고 분류하여 결정된다. 모든 기능은 그 분류가 "No Safety Effect(안전성 영향 없는)"인 경우에도 관련 고장 모드 및 관련 항공기 영향을 가진다. 안전성 관련 기능 고장 모드는 항공기 안전성에 기여하거나 직접적인 영향을 미칠 수 있다.

 

고장 조건을 방지하거나 안전성 관련 기능을 제공하기 위해 정의된 요구사항은 개발 과정의 레벨을 거치면서 고유하게 식별되고 추적 가능해야 한다. 이를 통해 소프트웨어 및 전자 하드웨어 설계 레벨에서 안전성 요구사항을 확인할 수 있을 것이다.

 

5.3.1.2 기능 요구사항

 

기능 요구사항은 지정된 조건에서 시스템의 원하는 성능을 얻는 데 필요한 요구사항이다. 이는 고객 욕구, 운용상의 제약, 규정 제한 그리고 구현 현실의 조합이다. 이러한 요구사항은 고려 중인 시스템의 모든 중요한 측면을 정의한다. 원천이 되는 소스에 관계없이 모든 기능은 안전성 관련 속성에 대해 평가되어야 한다.

 

5.3.1.2.1 고객 요구사항

 

고객 요구사항은 항공기 유형, 특정 기능 혹은 고려 중인 시스템 유형에 따라 달라질 것이다. 요구사항에는 운영자의 의도된 페이로드, 경로 시스템, 운용 관행, 유지보수 개념 그리고 원하는 특성과 관련된 것들이 포함될 수 있다.

 

5.3.1.2.2 운용 요구사항

 

운용 요구사항은 비행 승무원과 각 기능 시스템 간의, 정비사와 각 항공기 시스템 간의, 다양한 기타 항공기 지원 인력과 관련 기능 혹은 장비 간의 인터페이스를 정의한다. 조치, 결정, 정보 요구사항 그리고 타이밍이 운용 요구사항의 대부분을 구성한다. 운영 요구사항을 정의할 때는 정상 및 비정상 상황을 모두 고려해야 한다.

 

5.3.1.2.3 성능 요구사항

 

성능 요구사항은 항공기와 항공기 운용에 유용한 기능 혹은 시스템의 속성을 정의한다. 예상되는 성능 유형을 정의하는 것 외에도 성능 요구사항에는 정확도, 충실도, 범위, 해상도, 속도 그리고 응답 시간과 같은 기능 세부 사항이 포함된다.

 

5.3.1.2.4 물리적 및 설치 요구사항

 

물리적 및 설치 요구사항은 시스템의 물리적 속성을 항공기 환경과 연계한다. 여기에는 크기, 장착 조항, 전력, 냉각, 환경 제한, 가시성, 접근, 조정, 취급 그리고 보관이 포함될 수 있다. 생산 제약 또한 이러한 요구사항을 수립하는 데 중요한 역할을 할 수 있다.

 

5.3.1.2.5 유지보수성 요구사항

 

유지보수성 요구사항에는 예정된 유지보수 및 예정되지 않은 유지보수 요구사항과 특정 안전성 관련 기능에 대한 링크가 포함된다. 고장 탐지 비율 혹은 결함 격리 비율과 같은 요인도 중요할 수 있다. 외부 테스트 장비 신호 및 연결에 대한 조항이 이러한 요구사항에 정의되어야 한다.

 

5.3.1.2.6 인터페이스 요구사항

 

인터페이스 요구사항에는 전달되는 특정 정보의 관련 특성과 함께 물리적 시스템 및 아이템 상호 연결이 포함된다. 인터페이스는 정의된 소스가 있는 모든 입력과 정의된 목적지를 가지는 모든 출력과 함께 정의되어야 한다. 인터페이스 설명은 신호의 동작을 완전하게 설명해야 한다.

 

5.3.1.3 추가적인 인증 요구사항

 

추가 기능, 기능 속성 혹은 구현이 감항 규정에 의해 요구되거나 감항 규정 준수를 보여주기 위해 필요할 수 있다. 이러한 유형의 요구사항은 적절한 인증 당국과 함께 정의 및 합의되어야 한다

 

5.3.1.4 파생 요구사항

 

개발 활동의 각 단계에서 특정 요구사항 혹은 요구사항 그룹을 충족하는 방법에 대한 결정이 내려진다. 이러한 설계 선택의 결과는 개발의 다음 단계를 위한 요구사항이 된다. 이러한 요구사항은 설계 프로세스 자체의 결과이므로 더 높은 레벨의 요구사항과 고유하게 관련되지 않을 수 있으며 이러한 요구사항을 파생 요구사항이라고 한다.

 

파생 요구사항은 적절한 고장 조건 분류가 할당되고 요구사항이 확인될 수 있도록 지원하는 항공기 레벨 기능(혹은 기능들)을 결정하기 위해 조사되어야 한다. 파생 요구사항은 더 높은 레벨의 요구사항에 영향을 미치지 않지만 일부는 더 높은 레벨에 암시를 줄 수 있다. 파생 요구사항은 더 이상의 영향이 전파되지 않는 것으로 결정될 때까지 점진적으로 더 높은 시스템 레벨에서 안전성 관점(즉, 안전성 영향 분석)으로 검토되어야 한다.

 

예를 들어, 파생 요구사항은 특정 기능을 수행하는 장비에 대해 별도의 전원 공급 장치를 선택하기로 결정한 결과일 수 있다. 안전성 요구사항을 포함해서 이 전원 공급 장치에 대한 요구사항은 파생 요구사항이 된다. 그리고 전원 공급 장치가 지원하는 기능의 결함 혹은 고장으로 인한 고장 조건이 필요한 개발 보증 레벨을 결정한다.

 

파생 요구사항은 또한 아키텍처 선택에서 비롯될 수 있다. 예를 들어, 높은 무결성 기능 목표를 달성하기 위해 삼중 아키텍처를 선택하는 것은 동일한 목표를 달성하기 위해 이중으로 모니터링되는 아키텍처를 선택하는 것과 다른 결과와 다른 파생 요구사항을 가질 수 있다.

 

파생 요구사항은 보다 심각한 고장 조건 분류를 갖는 기능 구현을 덜 심각한 고장 조건 분류를 갖는 시스템의 고장 영향으로부터 분리하기 위한 설계 결정에서 비롯될 수 있다.

 

파생 요구사항에는 전자 하드웨어-소프트웨어 인터페이스를 정의하는 요구사항도 포함된다. 이러한 요구사항 중 일부는 시스템 레벨에서 중요할 수 있다. 전자 하드웨어-소프트웨어 인터페이스의 세부적인 측면을 다루는 나머지 부분은 DO-178B/ED-12B 그리고 DO-254/ED-80의 지침에 따라 처리될 수 있다.

 

파생 요구사항은 해당 개발 단계에서 적용할 수 있는 다른 요구사항과 일관된 방식으로 캡처 및 처리되어야 한다. 파생 요구사항은 적용 가능한 설계 표준에 대한 이유 그리고/혹은 참조가 포함되어야 한다.

 

5.3.1.5 기존 인증된 시스템 및 아이템의 재사용

 

다른 항공기에서 사용된 시스템 및 아이템은 종종 신규 혹은 파생 항공기에서 재사용된다. 이러한 시스템 및 아이템의 성숙도는 이점이 있지만 새로운 설치의 요구사항을 충족한다고 가정해서는 안 된다. 시스템 혹은 아이템에 대한 설계 변경이 없어도 해당 시스템 혹은 아이템의 인증된 요구사항은 새로운 응용에 따라서 확인되고 필요에 따라서 수정되어야 한다. 파생 요구사항, 가정, 인터페이스 및 운영 환경의 호환성 또한 확인되어야 한다. 광범위하고 이전 응용에서 충족되었을 수 있지만 서로 다른 케이블 로딩 혹은 버스 종단 규약과 같은 이유로 재사용 인스턴스에서 충족되지 않을 수 있다는 점에서 인터페이스 정의에 주의해야 한다.

 

그런 다음 필요에 따라 항공기와의 통합을 포함하여 이러한 요구사항에 대해 검증 활동을 수행해야 한다.

 

5.3.2. 안전성 분석으로부터 안전성 관련 요구사항 도출하기

 

항공기, 시스템 혹은 아이템 레벨에서의 각각의 기능에 대한 안전성 관련 요구사항의 유형은 일반적으로 독립성 요구사항, 확률적 가용성 및 무결성 요구사항, 단일 고장 기준 없음, 모니터링 성능 요구사항, 안전성 혹은 보호 특성, 개발 보증 레벨 그리고 운용 및 유지관리 제한 사항이다. 확률적 요구사항은 일반적으로 비용 프로세스(budgeting process)를 통해 처리된다.

 

주어진 기능에 대한 안전성 요구사항은 안전성 평가 결과를 사용하여 도출된다. 이러한 안전성 요구사항은 일반적으로 해당 기능 고장의 결과를 기반으로 하는 고장 범주로부터의 직접 할당이다. 그러나 일부 조합을 고려해야 하는 상황이 있으며, 이때 선택하는 조합은 기하급수적으로 증가하는 관련 없는 조합은 고려하지 않고 필요한 조합을 다루는 방식으로 선택되어야 한다.

 

여러 기능에 공통 리소스가 사용되는 경우 조합을 고려해야 한다. 관련 조합이 식별되고 이렇게 식별된 기능 조합에 대한 요구사항을 도출하기 위해 분석이 반복된다. 항공기 아키텍처에서 사용되는 공유 리소스가 증가함에 따라 이런 경우가 자주 발생한다.

 

부모 기능이 어느 한 자식보다 더 심각한 영향 범주를 갖는 형제(sibling) 기능이 있는 경우에도 조합이 고려되어야 한다. 일반적으로는 여러 시스템이 함께 작동하거나 보완적인 방식으로 항공기 기능을 충족할 때 발생한다.

 

5.3.3. 서비스 중 사용을 위한 유지보수 요구사항 캡처하기

 

일단 항공기 개발을 위해 사용되는 요구사항이 파악되면 적절한 유지보수 요구사항 개발을 통해서 인증을 위해 설정된 안전성 레벨이 항공기 수명 동안 유지되도록 보장하는 것을 신중하게 고려하게 된다. 그런 다음 이러한 요구사항은 ICA(Instructions for Continued Airworthiness)에 포함될 수 있다. 시스템의 무결성을 유지하거나 안전성 보호 특성을 유지하는 데 필요한 주기적인 유지보수, 검사 혹은 점검이 ICA로 캡처되어야 한다. 중요도에 따라 일부 ICA는 의도하지 않은 삭제 혹은 수정에 대해 더 높은 수준의 가시성과 보호가 필요할 수 있다. 그러한 경우 유지보수 매뉴얼의 감항한계 부분(Airworthiness Limitations Section)에 적절하게 포함한다.