5.4 요구사항 확인

요구사항 확인(Validation)은 제품이 항공기, 시스템 그리고 아이템 개발자뿐만 아니라 고객, 사용자, 공급업체, 유지보수 담당자 및 인증 당국의 요구를 충족할 수 있도록 지정된 요구사항이 충분히 정확하고 완전하다는 것을 확인하는 프로세스이다. (예를 들어, 사용자로서 비행 승무원은 추력 제어를 위한 특정 시스템 동작과 해당 동작에 대한 성능 수준이 필요할 수 있다. 인증 당국은 바람직하지 않은 운영 동작에 대한 제한이 필요할 수 있다) 확인 노력의 방식은 개발자에게 맡겨지지만 구조화된 프로세스가 확인 계획(5.4.7.1 참조)에 정의되어야 한다.

 

이러한 요구를 충족하는 요구사항을 효과적으로 캡처하는 것이 중요하다는 점에서 다음 지침이 도움이 될 수 있다.

 

• 요구사항 인터페이스(즉, 항공기와, 다른 시스템과, 아이템과, 사람과, 프로세스와)를 식별한다,
• 인터페이스에 대한 주된 이해 관계가 있거나 인터페이스가 필요한 개인을 식별한다,
• 인터페이스는 합의(예: SOW(Statement of Work), 계획, 매뉴얼, 요구사항 문서, 인터페이스 문서, 법적 계약)를 통해서 공식화되어야 한다,
• 합의는 인터페이스가 실현될 수 있도록 기본 원칙을 정의해야 한다(누가 인터페이스의 어느 쪽을 소유하는가? 문제를 식별하고 수정하는 수단은 무엇인가? 인터페이스와 관련된 형식 혹은 제약은 무엇인가?),
• 합의는 입력이 수신될 때 제공될 인터페이스 동작을 정의해야 한다,
• 합의는 적절한지 평가하는 데 필요한 정도로 인터페이스의 배경과 맥락을 정의해야 한다,
• 데이터 제공자는 데이터 사용자에 대한 가시성과 함께 인터페이스가 목적에 맞다는 것을 보장하도록 어떻게 사용될 것인지에 대한 가시성을 가지고 있어야 한다,
• 조직 혹은 기업의 경계를 넘을 때는 더욱 엄격하게 적용해야 한다(지침에 대해서는 섹션 5.3.1.1과 5.3.1.2 참조),
• 독립적인 검토자는 이러한 요구사항이 요구사항을 만든 사람과 요구사항을 받는 사람에게 동일한 의미를 가지는지 확인하기 위해 이상적으로는 요구사항이 캡처됨에 따라서 캡처된 요구사항의 가정과 해석을 요구사항을 만든 사람에게 이의를 제기하고 함께 확인해야 한다.
• 복잡하지 않은 아이템이 테스트와 분석의 조합을 통해 완전히 보장되는 경우 IDAL A의 엄격성을 충족하는 것으로 간주될 수 있지만 이러한 아이템에 대한 요구사항은 기능의 FDAL에 해당하는 엄격성으로 검증되어야 한다.

 

이상적으로는 설계 구현이 시작되기 전에 요구사항을 확인해야 한다. 하지만 실제로는, 특히 복잡하고 통합된 시스템의 경우 시스템 구현이 사용 가능하고 운영 컨텍스트에서 테스트될 수 있을 때까지는 요구사항의 확인이 가능하지 않을 수 있다. 결과적으로 확인은 일반적으로 개발 사이클을 통해 계속되는 단계적 프로세스이다. 각 단계에서 확인 활동은 요구사항의 정확성과 완전성에 대한 신뢰를 높여준다.

 

요구사항 계층의 각 레벨에서 확인 프로세스는 안전성 평가 프로세스를 포함해서 모든 관련 기술 분야를 포함해야 한다. 경험에 따르면 요구사항 개발 및 확인에 대한 세심한 주의는 개발 사이클 초기에 미묘한 오류 혹은 누락을 식별하고 후속 재설계 혹은 부적절한 시스템 성능이 나타나는 상황을 줄일 수 있다.

 

시스템 구현이 요구사항 확인 프로세스의 일부로 사용될 때 테스트는 확인과 검증의 목적을 동시에 수행할 수 있다. 이 활동의 한 가지 목적은 구현된 시스템이 요구사항을 충족하는지 확인하는 것이지만, 별도의 목적은 요구사항이 시스템이 동작하는 상황에 적합한지 확인하는 것이다. 그런 이중 목적은 검증 및 확인 계획의 조정에 의해서 반영되어야 한다.

 

5.4.1. 확인 프로세스 목표

 

요구사항의 정확성과 완전성을 보장하는 것이 요구사항 확인 프로세스의 목표다. (즉, 우리가 올바른 항공기를 만들고 있는가?)

 

요구사항이 필요하고 충분하다는 것 모두를 조사하는 것이 확인의 핵심 측면이다. 확인 프로세스의 또 다른 목표는 시스템에서 의도되지 않은 기능 혹은 인터페이스 시스템에서 의도되지 않은 기능이 유도될 가능성을 제한하는 것이다.

 

5.4.2. 확인 프로세스 모델

 

요구사항 및 가정은 요구사항 정의의 각 계층적 레벨에서 확인되어야 한다. 여기에는 항공기 기능, 시스템 및 아이템 레벨에서의 요구사항 확인뿐만 아니라 FHA의 확인이 포함된다.

 

시스템 개발에 대한 확인의 관계는 그림 5에서 볼 수 있다. 확장된 확인 프로세스 모델이 그림 12이다. 확인 프로세스에 대한 입력에는 시스템 설명(운영 환경 포함), 시스템 요구사항, 시스템 아키텍처 정의 그리고 개발 보증 레벨이 포함될 수 있다.

그림 12 확인 프로세스 모델

 

요구사항 확인 프로세스의 개요는 아래에 설명되어 있다. 이러한 프로세스는 다양한 계층 레벨에서 확인에 사용될 수 있다. 이러한 프로세스는 인증을 지원하는 데 사용될 수 있다.

 

a. 확인 계획:

 

확인 계획은 요구사항, 수집할 데이터, 데이터 보관 요구사항 그리고 확인 일정과 같은 확인에 사용할 특정 방법을 정의해야 한다. (확인 계획에 대한 추가적인 정보는 5.4.7.1과 5.4.6에 제시된다)

 

b. 확인 엄격성의 결정:

 

일단 개발 보증 레벨이 안전성 평가 프로세스에 의해 할당되고 확인되면 필요한 확인의 엄격성이 요구사항에 적용된다. (5.4.5 참조)

 

c. 정확성 및 완전성 체크

 

정확성은 개별 요구사항이 명확하고 검증 가능하며 다른 요구사항과 일치하고 요구사항 집합에 필요한 정도이다.

 

완전성은 요구사항이 일련의 정확한 요구사항이 시스템에 의해서 충족되었을 때 정의된 운영 환경에 대한 모든 운영 모드 및 라이프 사이클 단계에서 항공기, 시스템 및 아이템 개발자뿐만 아니라 고객, 사용자, 유지보수 담당자, 인증 당국의 이익을 충족시키는 정도이다. (이러한 체크에 대한 추가적인 정보는 5.4.3과 5.4.4에 제시된다)

 

d. 가정의 관리 및 확인

 

대부분의 시스템 개발 프로그램에서는 정보가 필요한 시점에 직접 증명할 수 없는 많은 가정(혹은 판단)이 만들어진다. 부정확한 가정의 결과가 평가되고 문서화된다면 그러한 가정의 존재 자체는 인증에 문제가 되지 않는다. 하지만 그러한 가정의 근거와 범위에 대한 잘못된 커뮤니케이션이 이루어 질 가능성이 많으며 관련 결과는 안전성 요구사항의 만족스러운 구현을 위태롭게 할 수 있다. 따라서 가정(명시적이든 묵시적이든)을 식별하고 특정 시스템과 해당하는 개발 보증 레벨을 기반으로 그 합리성과 근거를 확립해야 한다.

 

가정은 나중에 사용할 수 있게 되는 보다 명시적인 지식을 대신하여 개발 프로세스 초기에 사용할 수 있다. 항공기 및 시스템 개발은 반복적이고 동시적이며 하향식일뿐만 아니라 상향식으로도 영향을 미칠 수 있다. 또한 시스템 내의 모든 인터페이스 시스템 및 아이템이 시스템 설계 프로세스를 지원하기 위한 동일한 개발 단계에 있지 않을 수 있다. 요구사항은 특정 시스템에서 작업을 진행하기 위한 추적 가능한 요구사항보다는 가정에 기반해야할 수 있다. 이러한 경우에, 확인은 명시적인 지식 혹은 수용 가능한 근거가 실제로 획득되었으며 명시적인 지식과 관련 가정 간의 불일치가 해결되었음을 보여주는 것으로 구성된다.

 

가정된 부모 요구사항을 기반으로 하는 모든 요구사항을 식별하고 역으로 추적해야 한다. 가정된 상위 레벨의 요구사항에 기반한 요구사항은 인증 시점까지 해결되어야 한다.

 

가정에 대한 확인 프로세스는 가정이 다음과 같은지 확인하는 데 초점을 맞춘다.

 

• 명시적으로 언급됨,
• 적절히 전파됨,
• 지원 데이터로 정당화됨.

 

가정을 확인하는 데 사용되는 프로세스에는 리뷰, 분석 그리고 테스트가 포함될 수 있다. 잘못된 가정의 결과가 안전성을 감소시킬 수 있는 상당한 잠재력을 가지고 있는 것으로 보이는 경우 한 가지 가능한 확인 전략은 실제로 가정의 오류로 인해서 나타날 수 있는 결과를 제한하거나 묶는 방법을 시스템 설계로 보여주는 것이다.

 

이 섹션의 나머지 부분에서는 가정의 합리성을 식별하고 판단하기 위한 지침을 제공한다. 이러한 목적을 용이하게 하기 위해 가정은 아래와 같이 분류된다.

 

- 항공 교통, 유지보수, 화물, 인력, 비행 역학, ATC 시스템, 성능, 운영 절차 그리고 승객과 관련된 운영/환경 가정(예: 노출 시간, 트래픽 밀도, 유지보수 간격, 성능 제한)이 고려되어야 한다. 이러한 시스템의 주요 소유자와 요구사항을 합의하는 것이 어렵거나 불가능한 경우가 많다. 이것은 항공기 설계자가 운영 상황에 대한 가정을 하도록 요구할 수 있다. 운영 상황에 동의하는 경우 다른 개인이나 문서 그리고/혹은 표준이 이러한 시스템 소유자를 대신할 수 있다. 예를 들어, 규정 당국은 규정뿐만 아니라 교통 밀도 수준에 대한 가정에 동의하는 항공 교통 관제 시스템의 관심사를 대표할 수 있다.

- 승무원 인터페이스, 시스템 인터페이스 그리고 신뢰성과 관련된 설계 가정이 고려되어야 한다. 이 영역에서 가정을 수용하는 것은 기존 업계 경험과 관행에 대한 리뷰를 통해 이루어질 수 있다.

• 승무원 인터페이스 가정에는 정상 및 비상 상황에서의 장비 및 운영 환경과 승무원의 상호 작용, 승무원의 퍼포먼스 특성(반응 시간, 디스플레이 해석, 육체적 한계) 그리고 승무원 상호 작용이 포함될 수 있다. 승무원 인터페이스에 대한 가정의 몇 가지 예는 다음과 같다. 다양한 유형의 메시지에 대한 승무원 응답 시간, 이벤트 인식 시간(예: 하드오버 인식), 의사 결정 전략, 신체적 형태, 시각적 형태, 색상 혹은 역동적인 퍼포먼스에 기반한 식별 정확도.
• 시스템 인터페이스 가정은 교환되는 데이터의 의미 혹은 논리적 해석과 관련된 이슈(예: 형식, 무결성, 지연 시간, 해상도)를 다루거나 데이터 신호의 물리적 특성(예: 전압 레벨, 임피던스, 신호 대 잡음비)에 초점을 맞출 수 있다. 시스템 인터페이스에 대한 가정의 몇 가지 예로는 데이터 버스 정보의 오독 확률, 모든 관련된 인터페이스 시스템에 의한 오류 데이터의 올바른 처리, 오류 억제 그리고 부정확한 입력 특성이 포함된다.
• 가정이 자주 만들어지는 신뢰성 주제는 다음과 같다. 수명 주기에 걸친 고장률 모델링의 적절성, 디스패치 비작동 고려사항, 예정된 유지보수 작업과 그 빈도의 적절성, 부품 부하경감의 적절성, 잠재적 고장 잠복 시간 및 노출 기간의 고려, 고장 모드 분석의 완전성, MTBF 예측 수립 혹은 증명을 위한 테스트 데이터의 적절성 그리고 사용 중인 검증된 부품의 적용가능성.

- 서비스가능성 가정은 일반적으로 서비스 및 수리 조항이 안전을 저하시키지 않는다고 가정한다. 이 가정은 서비스 및 유지보수 절차와 관련 장비를 리뷰하여 검증할 수 있다.

- 설치 가정(예: 분리, 절연, 케이블 바인딩, 전선 크기, 환경, 전원 연결, 회로 차단기 크기, 환기, 배수, 오염원, 마운트 무결성, 접지 및 차폐)이 고려되어야 한다. 이 영역에서 가정을 확인하는 것은 산업 표준 및 관행에 대한 리뷰 그리고 모형, 프로토타입 혹은 생산 도면/하드웨어의 선택적 테스트 그리고/혹은 조사를 통해 달성될 수 있다.

 

설계 프로세스 중 가정을 관리하는 수단이 확인 계획에 정의되어야 한다.

 

e. 확인 매트릭스

 

확인 프로세스는 적절하게 하드웨어/소프트웨어 성능, 파생 요구사항, 환경 및 운영 고려사항, 가정 및 지원 데이터에 기반한 요구사항을 포함해서 요구사항 및 확인 결과를 참조하는 확인 매트릭스(5.4.7.2 참조)의 준비를 포함한다. 각 요구사항의 출처를 식별할 수 있어야 한다. 이 매트릭스는 개발 중에 정기적으로 업데이트되어야 하며 확인 요약에 포함되어야 한다.

 

f. 확인 요약

 

결과뿐만 아니라 프로세스를 설명하는 데이터. (5.4.7.3 참조).

 

5.4.3. 정확성 체크

 

확인 프로세스 동안 고장 조건 분류의 정확성과 명시된 요구사항 내용의 정확성 모두를 검토하고 정당화해야 한다. 정확성 체크는 요구사항 계층 구조의 각 레벨에서 수행되어야 한다. 다음 질문들이 요구사항의 정확성을 평가하는 데 도움이 될 수 있다. 이 목록은 특정 응용에 맞게 조정되고 확장되어야 한다.

 

a. 요구사항이 정확하게 명시되어 있는가? (예를 들면)

(1) 요구사항이 유일한 해석을 가지는가? (명확한)

(2) 요구사항으로 식별할 수 있는가?

(3) 요구사항이 중복되는가?

(4) 요구사항이 다른 것들과 충돌하는가?

(5) 요구사항이 사실의 오류를 포함하고 있는가?

(6) 요구사항을 충족하는 것이 물리적으로 가능한가?

(7) 요구사항의 진술이 가능한 경우 "어떻게"가 아니라 무엇을, 언제 그리고 "얼마나 잘"로 표현하는가?

(8) 시스템에 이해 관계가 있거나 인터페이스하는 사람들에게 미치는 영향에 대한 가시성과 함께 미래의 변경이 완전하고 일관되게 이루어질 수 있도록 하는 충분한 정보가 있는가?

(9) 요구사항에 특정 허용 오차가 포함되어 있는가?

(10) 요구사항이 섹션 5.5에 설명된 대로 검증가능한가?

(11) 파생 요구사항이라면 근거에 의해서 뒷받침되는가?

(12) 요구사항의 출처가 식별되고 정확한가?

(13) 요구사항이 개별 요구사항으로 더 잘 나열될 수 있는 여러 특성을 포함하고 있는가?

 

b. 요구사항 집합이 완성되기 위해 해당 요구사항이 필요한가?

c. 요구사항 집합이 단일 요구사항으로 결합되는 것이 더 적합한가?

d. 요구사항 집합이 안전성 분석을 정확하게 반영하는가?

(1) 안전성 평가에서 파생된 요구사항이 모두 포함되는가?

(2) 모든 시스템 고장 조건이 정확하게 식별되고 분류되는가?

(3) 안전하지 않은 설계 혹은 설계 오류의 영향이 고려되는가?

(4) 신뢰성, 가용성 그리고 고장 허용 요구사항이 포함되는가?

 

5.4.4. 완전성 체크

 

요구사항 집합의 완전성은 본질적으로 입증하기 어려울 수 있다. 요구사항의 완전성 체크를 수행하기 위한 기초로서, 가능한 요구사항 유형(5.3.1 참조) 목록을 사용할 수 있다. 시스템에 대해 일반적으로 언급된 요구를 가지고 있는 개인에게는, 언급되지 않았거나 예상하지 못한 특정 요구와 기대치가 있을 수 있다. 완전성은 실제 고객, 사용자, 유지보수 담당자, 인증 당국 그리고 개발자의 참여뿐만 아니라 템플릿과 체크리스트의 조합을 포함할 수 있는 확인 프로세스를 따랐을 때 가능한 결과로 간주된다.

 

완전성 평가를 위한 특정 확인 프로세스가 확인 계획(5.4.7.1 참조)에 정의되어야 한다.

 

5.4.4.1 템플릿과 체크리스트

 

교훈을 기반으로 하는 표준 규격 형식의 템플릿은 누락을 드러내고 불완전한 요구사항을 방지하는 데 도움이 될 수 있다.

 

체크리스트는 완전성 체크를 위해 작성자와 검토자에 의해서 사용될 수 있다. 체크리스트는 요구사항에 대한 요구와 기대치가 충족되는 것을 보장하기 위해 시스템과 해당 인터페이스에서 주된 이해 관계가 있는 모든 영역을 다루어야 한다.

 

다음 자료는 요구사항의 각 계층적 레벨에서 완전성을 평가하기 위한 체크리스트 질문을 개발하는 데 도움이 된다. 이 목록은 특정 응용에 맞게 조정되어야 한다.

 

a. 요구사항이 부모 요구사항을 충족한다는 것이 추적성과 뒷받침하는 근거로 명백한가?

b. 인터페이스 시스템 혹은 프로세스의 모든 소유자가 시스템 요구사항 집합에 나타나 있는가?

(1) 이 시스템에 할당되는 모든 상위 레벨 기능이 완전히 커버된다.

(2) 안전성 요구사항이 표현된다.

(3) 규정 표준과 지침이 표현된다.

(4) 업계 및 회사 설계 표준이 표현된다.

(5) 비행 운용 및 유지보수 시나리오가 표현된다.

 

c. 다른 시스템, 사람 그리고 프로세스에 대한 모든 인터페이스가 식별되는가?

d. 각각의 인터페이스와 관련된 제약(예: 프로토콜, 마운팅 구성, 그리고 타이밍)이 인터페이스가 실현될 수 있도록 충분히 상세하게 정의되어 있는가?

e. 인터페이스로부터 비롯되는 시스템, 사람 혹은 프로세스 동작이 인터페이스의 양쪽 요구사항으로 합의되고 포착되는가? 예를 들어 엔진 시스템은 비행 디스플레이 시스템에 데이터를 제공할 수 있다. 해당 데이터가 비행 디스플레이 시스템에서 사용되는 방법과 승무원이 해당 데이터에 응답하는 방법은 엔진 제어 시스템 소유자와 인터페이스 요구사항으로 합의되어야 한다. 또 다른 예는 스로틀에 대한 승무원 입력, 엔진 추력 동작을 초래하는 엔진에 대한 스로틀 입력이다. 여기서 예상되는 추력 동작은 비행 승무원 혹은 일반적으로 비행 승무원을 대표하는 사람과 합의되고 요구사항으로 캡처되어야 한다.

f. 필요한 행동에 대해 관련된 금지 행동이 정의되어야 하는가? 그리고 만약 그렇다면 금지 행동이 정의되어 있는가?

g. 기능 요구사항이 시스템 아키텍처에 완전히 할당되고 추적되는가?

h. 기능 할당이 시스템 아키텍처에서 전자 하드웨어와 소프트웨어 간에 명확하게 할당되는가?

i. 가정이 적절하게 정의되고 다루어지는가?

 

5.4.4.2 사용자, 운영자 그리고 유지보수 담당자 참여

 

완전한 요구사항 집합을 달성하는 데 있어서 어려움 중 하나는 시스템이 원하는 혹은 원하지 않는 동작이 무엇인지 사용자가 항상 알지는 못한다는 것이다. 이는 특히 새로운 혹은 지금껏 보지 못한 특성일 경우 그렇다. 사용자로부터 요구사항을 끌어내는 여러 가지 수단이 있다. 프로토타이핑뿐만 아니라 운영 및 유지보수 시나리오의 조기 포착은 요구사항을 끌어내는 예시적인 수단이다. 이들이 최선의 수단으로 제안되지는 않지만 누락된 요구사항을 식별하는 데 도움이 되는 방법으로 제안된다. (5.3 참조)

 

a. 운영 및 유지보수 시나리오

 

설계 프로세스 초기에 누락된 요구사항을 식별하는 효과적인 방법은 해당 시스템 사용자의 입력에 대한 응답으로 원하는 목표를 달성하기 위해 시스템이 어떻게 기능해야 하는지에 대한 시나리오를 작성하는 것이다. 시나리오가 어떻게 사용될 수 있는지에 대한 한 가지 예는 개발 프로세스 초기에 운영 및 유지보수 매뉴얼에 대한 절차를 정의하는 것이다. 이것은 시스템과 상호 작용하는 사용자에게 여러 가지의 운영 시나리오에서 시스템이 어떻게 작동하도록 제안되는지에 대한 가시성을 제공한다. 이러한 가시성은 시나리오 및 이어지는 요구사항에서 캡처되어야 하는 누락된 원하는 동작 혹은 보호 특성을 식별하는 데 도움이 될 수 있다. 이러한 시나리오에서 사용자는 다른 시스템일 수 있지만 일반적으로 사용자는 사람이다.

 

다양한 조건 및 운영 모드에서 동작을 설명하기 위해 주어진 기능에 대해 여러 시나리오를 탐색해야 할 수 있다. 각각의 시나리오는 사용자가 행동을 시작하는 단계부터 최종 목표에 이르는 과정에서 식별된 시스템이나 사람이 취한 각각의 행동 단계를 통해 일련의 단계를 조사한다.

 

시나리오는 가능한 운영 환경과 운영 모드뿐만 아니라 비정상적인 운영 조건도 다루어야 한다. 시나리오의 각 단계에서 발생할 수 있는 오작동이 고려될 수 있다. 이 오작동을 관리하거나 방지하는 방법이 정의되며 그 자체가 또 다른 시나리오가 될 수 있다. 각각의 상호 작용 시스템의 동작이 각 단계에서 설명됨에 따라 시나리오가 기능 할당(4.1.2 참조)의 동의에 사용될 수 있다.

 

엔진을 시동하는 조종사가 시나리오의 한 예가 될 것이다. 주요 시나리오는 시동을 시작하기 위해 조종사가 취하는 조치, 각각의 협력 시스템이 취하는 후속 조치, 엔진이 유휴 상태에 도달하는 모든 방법을 설명하는 것이다. 추가 시나리오에는 에어 보조 스타터 시동 그리고 윈드밀 시동이 포함될 수 있다. 비정상적인 조건과 관련된 시나리오는 조종사가 시동을 잘못 시작하고 협력 시스템이 이에 어떻게 반응하는가로 시작될 수 있다. 뿐만 아니라 시동 중에 엔진이 멈추는 이상 현상이 발생할 수도 있다. 이러한 시동 멈춤은 시스템 혹은 사람이 엔진 시동을 확보하기 위해 취해야 하는 단계를 정의하는 시나리오에 의해서 다루어 질 수 있다.

 

시나리오를 개발하고 문서화하는 방법에는 여러 가지가 있다(예: 상태 다이어그램, 타임라인 다이어그램). 개별 접근 방식은 개발자에게 맡겨진다.

 

b. 프로토타이핑 혹은 모델링

 

프로토타입은 하드웨어 그리고/혹은 소프트웨어 기반일 수 있으며, 시스템의 개발 버전일 수도 있고 아닐 수도 있는, 원하는 시스템의 모델이다. 프로토타입은 시스템 사용자가 시스템의 제안된 모델과 상호 작용하여 누락된 요구사항, 금지되어야 할 시스템의 동작 그리고 사용자 상호 작용의 잠재적 문제를 발견할 수 있도록 한다.

 

프로토타입이 실제 시스템을 얼마나 잘 나타내는지에 따라 누락된 요구사항을 식별할 가능성이 높아질 수 있다. 프로토타입을 만드는 데 사용되는 도구는 개발 시간을 최소화해야 한다.

 

모델은 구조화된 방식으로 개발되어야 한다. 예를 들어, 두 번 이상 사용될 수 있는 모델 요소의 서브셋은 유닛 혹은 전체 콘텐츠로 처리 및 표시될 수 있다.

 

요구사항 확인을 위한 모델 사용은 일반적으로 개발 중인 시스템 환경의 모델을 사용하며, 이는 해당 요구사항에 대한 설계 솔루션의 프로토타입과 인터페이스된다. 개발 중인 시스템의 환경을 대표하는 환경 모델은 시뮬레이션된 혹은 실제 시스템을 실행하는 것에 대해서 높은 수준으로 기능을 커버하게 된다.

 

5.4.5. 확인 엄격성

 

확인 엄격성의 수준은 항공기 혹은 시스템에 대한 기능 개발 보증 레벨(들)(FDAL)과 아이템에 대한 아이템 개발 보증 레벨(들)(IDAL)에 의해서 결정된다. 요구사항 확인 방법은 5.4.6에서 식별되며 각각의 허용 가능한 사용은 5.4.6.1에서 설명된다.

 

확인 프로세스에서의 독립성 적용 또한 개발 보증 레벨에 따라 달라진다. 이 독립성은 요구사항 캡처(5.3)와 섹션5.4의 확인 활동 사이에 적용되어야 한다. 확인 계획(5.4.7.1 참조)에는 독립성이 적용된 확인 활동에 대한 설명이 포함되어야 한다.

 

요구사항 확인에서 독립성을 달성하는 가장 일반적인 수단은 요구사항의 정확성과 요구사항 집합의 완전성을 주장하기에 충분한 증거가 있는지를 결정하기 위해 요구사항 데이터와 뒷받침하는 근거를 독립적으로 리뷰하는 것이다. 여기에는 엔지니어링 리뷰(5.4.6.1 참조)와 고객, 사용자, 유지보수 담당자 및 인증 당국 그리고 아이템 개발자에 의한 리뷰(5.4.4.2 참조)가 포함된다.

 

비록 분석, 시나리오, 유사성 그리고 요구사항 추적과 같은 모든 확인 방법이 직접적으로 독립성을 적용할 수 있는 것은 아닐 수 있지만, 이러한 확인 방법 활동의 결과와 그 적절성은 리뷰가 가능하며 개발 보증 레벨에 명시된 독립성(부록 A 참조)과 함께 수행되어야 한다.

 

5.4.6. 확인 방법

 

확인을 지원하려면 여러 방법이 필요할 수 있다. 이러한 방법에는 추적성, 분석, 모델링, 테스트, 유사성, 그리고 엔지니어링 리뷰가 포함된다. 확인은 의도된 기능과 의도되지 않은 기능을 모두 고려해야 한다. 의도된 기능 요구사항 확인은 목표의 PASS/FAIL 기준에 대한 평가가 포함된다. 의도되지 않은 시스템/아이템 동작 혹은 사이드이펙트를 식별하기 위해 분석과 테스트의 모든 과정에서 주의를 기울여야 한다. 의도되지 않은 기능이 없는지 직접 확인할 수는 없지만 임시 테스트 및 표적 분석을 사용하여 그것이 존재할 가능성을 줄일 수 있다.

 

a. 추적성 (요구사항의 양방향 흐름):

 

추적성은 항공기, 시스템 그리고 아이템 요구사항 확인의 필수 요소이다. 요구사항은 부모 요구사항으로 추적할 수 있거나 요구사항이 파생된 특정 설계 결정 혹은 데이터를 식별하여 추적할 수 있어야 한다.

 

추적성 자체는 더 낮은 레벨의 요구사항이 완전성과 관련하여 더 높은 레벨의 요구사항을 충족한다는 것을 입증하기에 충분할 수 있다. 하지만 설계 결정 혹은 세부 사항을 통해 추가적인 가치가 더해진 경우 추가 근거가 캡처되어야 한다. 이 근거는 더 낮은 레벨의 요구사항이 부모 요구사항을 어떻게 충족하는지를 문서화해야 한다. 일부 더 낮은 레벨의 요구사항이 부모 요구사항으로 추적되지 않을 수 있다.(즉, 파생 요구사항) 이러한 요구사항은 그 타당성을 문서화할 근거가 있어야 한다.

 

추적되지 않는 요구사항이 다음에 해당하는지를 결정하기 위해 리뷰되어야 한다.

 

• 개발 프로세스의 일부로써 파생됨(섹션 5.3.1.4 참조) 혹은,
• 추가되어야 할 수 있는 누락된 부모 요구사항으로부터 개발됨 혹은,
• 관리될 필요가 있는 가정(섹션 5.4.2 (d) 참조).

 

b. 분석:

 

요구사항 수용가능성을 결정하기 위해 광범위한 분석 방법 및 기술이 사용될 수 있다. 몇 가지 특정 안전성 관련 분석 방법이 ARP4761에 설명되어 있다. FHA 및 PSSA의 수용가능성에 대한 규정 당국과의 조기 논의는 안전성 관련 요구사항의 확인에 도움이 될 것이다.

 

c. 모델링:

 

시스템/아이템의 모델을 사용하여 요구사항을 확인할 수 있다.

 

d. 테스트:

 

요구사항을 확인하기 위해 특수 테스트, 시뮬레이션 혹은 시연을 사용할 수 있다. 이러한 활동은 목업, 프로토타입, 시뮬레이션 혹은 실제 하드웨어 및 소프트웨어의 가용성을 기반으로 개발 중 언제든지 발생할 수 있다. 모든 시뮬레이션이 실제 시스템, 해당 인터페이스 그리고 설치 환경을 충분히 대표할 수 있도록 주의를 기울여야 한다.

 

아이템 검증 테스트 또한 아이템을 설계하기 위해 파생된 요구사항의 확인을 지원하는 데 사용할 수 있다.

 

e. 유사성 (경험):

 

이 방법을 사용하면 유사하게 인증된 시스템의 요구사항과 비교하여 요구사항을 확인할 수 있다. 유사성 주장은 시스템과의 경험 기간이 길어질 수록 힘을 얻는다. 경험 기간이 만족스럽다는 충분한 확신이 있을 때까지는 유사성에 대한 주장을 사용해서는 안 된다. 다음과 같은 경우 유사성을 주장할 수 있다.

 

• 두 시스템/아이템이 동일한 기능 및 고장 조건 분류를 가지며 유사한 용도로 동일한 환경에서 작동한다,
• 두 시스템/아이템이 동등한 환경에서 유사한 기능을 수행한다.

 

f. 엔지니어링 리뷰

 

리뷰, 조사 및 시연을 통한 개인 경험의 적용은 완전성(5.4.4 참조) 및 정확성(5.4.3 참조)의 결정을 지원할 수 있다. 적절하게 정당화된 근거 혹은 논리를 문서화해야 한다. 요구사항에 대한 공동 리뷰는 검증 중에 구현을 테스트할 기회에 앞서 검토자의 경험 내에서 시스템이 이전 시스템과 유사한 경우 파생된 요구사항을 확인하는 효과적인 수단이다. 리뷰 참여자와 그 역할을 포함하여 리뷰를 문서화해야 한다. 리뷰의 가치는 리뷰에 대한 주의와 검토자의 경험 수준에 따라 달라진다.

 

5.4.6.1 추천 방법

 

표 6은 할당된 개발 보증 레벨 A ~ E의 기능에 따른 확인 방법 및 데이터를 식별한다. 예를 들어 레벨 A 혹은 B에 대한 요구사항을 확인하기 위해 분석, 의도된 기능 테스트 그리고 직접 적용 가능한 유사성을 사용하여 정확성과 완전성을 확립할 수 있다. 일부 요구사항의 확인은 정확성 체크를 위한 한 가지 방법과 완전성 체크를 위한 다른 방법을 사용할 수 있다.

 

표 6 요구사항 확인 방법 및 데이터

참고: R - 인증을 위해 추천됨, A- 인증을 위해 협의된 대로, N-인증에 필요하지 않음

 

각각의 요구사항에 대해 해당 요구사항의 확인에서 요구되는 신뢰도를 설정하기 위해 필요한 권장되는 그리고 허용되는 방법의 조합을 식별한 다음 적용해야 한다.

 

5.4.7. 확인 데이터

 

5.4.7.1 확인 계획

 

개발 프로세스 전반에 걸쳐 요구사항 확인 계획이 마련되어 있어야 한다. 이 계획은 요구사항이 어떻게 완전하고 정확하게 보이도록 할 것인지 그리고 가정이 어떻게 관리될 것인지에 대한 개요를 제시해야 한다. 계획에는 다음에 대한 설명이 포함되어야 한다.

 

a. 사용할 방법

b. 수집하거나 생성할 데이터

c. 기록해야 할 사항(요약, 리뷰, 혹은 조사와 같은)

d. 요구사항 확인 정보에 적시에 접근할 수 있는 수단

e. 요구사항이 변경될 때 확인 상태가 유지 혹은 관리되는 방법

f. 확인과 관련된 역할과 책임

g. 핵심 확인 활동 일정

h. 다양한 설계 레벨 및 개발 단계에서 가정을 관리하는 수단.

i. 확인 활동으로부터 요구사항 정의의 독립성을 제공하기 위해 사용되는 수단

 

검증의 일부로도 사용될 수 있는 확인 프로세스의 측면은 검증 계획과 조정되어야 한다.

 

5.4.7.2 확인 추적

 

확인 매트릭스 혹은 기타 적절한 접근 방식은 요구사항 확인 프로세스의 상태를 추적하기에 바람직하다. 상세화 수준은 요구사항에서 다루는 기능의 개발 보증 레벨에 따라 달라야 하며 확인 계획에 설명되어야 한다. 인증 계획에 예비 추적 프로세스를 설명하고 필요에 따라 업데이트하는 것이 좋다. 최종 데이터는 확인 요약에 포함되어야 한다. 구체적인 형식은 지원자에게 달려 있지만 최소한 다음을 포함해야 한다.

 

a. 요구사항

b. 요구사항의 소스

c. 관련된 기능(들)

d. 개발 보증 레벨

e. 적용되는 확인 방법(들)

f. 확인 지원 증거 참조(들)

g. 확인 결론(유효한/유효하지 않은)

 

5.4.7.3 확인 요약

 

확인 요약은 요구사항이 적절하게 확인되었다는 보증을 제공해야 한다. 요약에는 다음이 포함되어야 한다.

 

a. 확인 계획에 대한 참조 및 계획과의 중대한 차이점에 대한 설명

b. 5.4.7.2에 설명된 확인 매트릭스

c. 지원 데이터 혹은 데이터 소스에 대한 식별 (5.4.7.2 참조)