페이퍼요약 - 유명 실패 사례로 본 요구사항 개발, 검증, 확인 by Bahill

제목: 유명 실패 사례로 본 요구사항 개발, 검증, 확인(Requirements Development, Verification, and Validation Exhibited in Famous Failures)

저자: A. Terry Bahill 외 1인, 미국

문서유형: 온라인 저널 페이퍼(총 14페이지), 2005년

 

요구사항 개발, 요구사항 검증, 요구사항 확인, 시스템 검증, 시스템 확인의 5개 용어를 설명하고 유명 실패 사례에서 이와 관련 어떤 실수가 있었는지를 논의한 자료

---

 

요구사항 개발(Requirements Development)

• 요구사항 개발에는 아래의 5개 작업이 포함되며, 이것들이 반드시 순차적일 필요는 없다(즉, 병렬적으로 그리고 반복적으로 이루어질 수 있음)
  (1) 이해관계자의 니즈를 도출(eliciting), 분석(analyzing), 확인(validating), 의사소통(communicating) 함
  (2) 고객 요구사항(customer requirements)을 파생 요구사항(derived requirements)으로 변형함
  (3) 요구사항을 하드웨어, 소프트웨어, 바이오웨어, 테스트, 그리고 인터페이스 요소로 할당(allocating)함
  (4) 요구사항을 검증(verifying)함
  (5) 요구사항 집합을 확인(validating)함
• 점점 더 많은 상세 사항이 추가되면서 요구사항 레벨(requirement levels)에 연속 변이가 일어나지만 대개 ‘상위 레벨’과 ‘하위 레벨’의 두 개 카테고리로 구분함
  - “무엇(what)”에 중점을 둔 상위 레벨 요구사항(High-level requirements)을 지칭하는 용어로 고객 요구사항(customer requirements), 최상위 레벨 요구사항(top-level requirements), 시스템 요구사항(system requirements), 운영적 요구사항(operational requirements), 운영 개념(concept of operations), 사명서(mission statement), 이해관계자 니즈(stakeholder needs), 이해관계자 기대사항(stakeholder expectations), 제약사항(constraints), 외적 요구사항(external requirements) 등이 존재
  - “어떻게(how)”에 중점을 둔 하위 레벨 요구사항(Low-level requirements)을 지칭하는 용어로 파생 요구사항(derived requirements), 설계 요구사항(design requirements), 기술적 요구사항(technical requirements), 제품 요구사항(product requirements), 할당된 요구사항(allocated requirements), 내적 요구사항(internal requirements) 등이 존재

 

Verification과 Validation 용어 정의

• 요구사항 검증(Verifying requirements): 각 요구사항이 충족되었음을 증명하는 일
• 요구사항 확인(Validating requirements): 아래 사항들을 보장하는 일
  (1) 요구사항 집합이 정확하고, 완전하고, 일관적이며,
  (2) 요구사항을 충족하는 모델이 생성될 수 있으며,
  (3) 현실 세계 솔루션이 구축 및 테스트(요구사항을 충족함을 증명하기 위해) 될 수 있다.
• 시스템 검증(Verifying a system): “Building the system right.” 시스템이 시스템 요구사항을 준수하고 설계와 일치함을 보장
• 시스템 확인(Validating a system): “Building the right system.” 시스템이 의도된 환경에서 의도된 일을 함을 보장. Validation은 최종 제품의 정확성과 완전성을 판단하고 시스템이 이해관계자의 실제 니즈를 충족시킬 것임을 보장한다.

 

시스템 검증(system verification)과 요구사항 검증(requirements verification) 간의 중복이 존재함. 양쪽 프로세스에서 공통적으로 시스템 요구사항(system requirements)을 체킹하는 일이 수행됨

요구사항 확인(requirements validation)과 시스템 확인(system validation) 간에도 중복이 존재함. 최상위 시스템 요구사항(top-level system requirements)을 확인하는 일은 시스템을 확인하는 일(validating the system)과 유사하지만 하위 레벨 요구사항을 확인하는 일은 상당히 다름

 

시스템 엔지니어나 소프트웨어 엔지니어가 위 용어의 의미를 다르게 사용하는 경우가 많으므로 “verification”과 “validation”의 정의에 대해 의견 일치를 보는 것이 필수적임

 

요구사항 검증(Requirements Verification)

각 요구사항이 아래 방법에 의하여 검증될 수 있음

• 논리적 주장(logical argument): 일련의 논리적 연역법(logical deductions)
• 인스펙션(inspection): 결함(flaws)을 찾기 위해 주의 깊게 그리고 비판적으로 조사
• 모델링(modeling): 시스템의 일부 측면의 단순화된 표현(a simplified representation)
• 시뮬레이션(simulation): (대개 컴퓨터 프로그램을 통한) 모델의 실행
• 분석(analysis): 수학과 모델을 사용한 일련의 논리적 연역법
• 전문가 검토(expert review): 전문가 그룹에 의한 요구사항 조사
• 테스트(test): 통제된 조건(예, 실험실 환경) 하에서 입력을 적용하고 출력을 측정
• 시연(demonstration): 실험이나 실용적 적용(예, 비행, 노상 성능 테스트)을 통해 보이기

 

요구사항 검증 예 1: 통신 채널에서 부정확한 비트를 수신할 확률이 0.001 미만이어야 한다. à 이 요구사항은 실험실 테스트 또는 실제 시스템 상의 시연을 통해 검증될 수 있음   요구사항 검증 예 2: 화성 유인 탐사선의 인명 손실 확률이 0.001 미만이어야 한다. à 분명 합당한 요구사항이지만 테스트를 통해 검증될 수 없음. 분석과 시뮬레이션을 통해 이 요구사항의 검증이 가능할 수도 있음   요구사항 검증 예 3: 정치적 이유로 시스템이 취소될 확률이 0.001 미만이어야 한다. à 이것이 좋은 요구사항일 수도 있지만 일반 엔지니어링 테스트나 분석으로는 검증될 수 없음. 논리적 주장(logical arguments)을 통해 검증이 가능할 수도 있음

 

요구사항 확인(Requirements Validation)

만약 시스템 엔지니어링에서 고객이 영구 작동 기계(a perpetual-motion machine)를 요청한 것이 발견되었다면 프로젝트가 중단되어야 한다.

 

만약 요구사항이 에너지 소비 없이 엔트로피(entropy)를 줄이는 시스템을 명세하면 이 요구사항은 유효하지(valid) 않으며 프로젝트가 중단되어야 한다.

 

전자 온수기 컨트롤러의 유효하지 않은 요구사항 집합 예: If 70° < 온도 < 100°, then 3000 Watts 출력. If 100° < 온도 < 130°, then 2000 Watts 출력. If 120° < 온도 < 150°, then 1000 Watts 출력. If 150° < 온도, then 0 Watts 출력.  à 위 요구사항 집합은 불완전함(온도 < 70°이면 무슨 일이 일어나는가?) à 위 요구사항 집합은 비일관적임(온도 = 125°이면 무슨 일이 일어나는가?) à 단위(units)가 주어지지 않았으므로 요구사항이 부정확(온도가 섭씨인가 화씨인가?)

 

유명 실패 사례

이 장에서는 몇몇 잘 알려진 실패 사례의 이유를 추측해 본다. 각 실패의 정확한 근본 원인(root cause)을 찾는 것이 목적이 아니라 요구사항 개발, 요구사항 검증, 요구사항 확인, 시스템 검증, 시스템 확인에서의 결점이 어떻게 직접, 간접적으로 실패를 야기하는지를 보이려는 의도

 

HMS Titanic

타이타닉의 연철 리벳(wrought iron rivets) 제조 시 품질 통제(quality control)가 좋지 않았음. 1912년 4월 14일 배가 빙산에 부딪혔을 때 많은 리벳이 제 역할을 못하면서 선체가 조각남

à 배를 올바르게 구축하지 못하였으므로 검증(verification)에 문제가 있었음

à 충분하지 않은 수의 구명정(lifeboats)은 요구사항 개발에 있어 실패로 볼 수 있지만 (침몰이 있기 전까지는) 선주와 승객의 니즈를 만족시켰으므로 확인(validation)도 적절했음

 

Tacoma Narrows Bridge

워싱턴의 Tacoma Narrows 현수교(Suspension Bridge)는 기존 다리 설계의 크기만 늘려서 구축됨(a scaleup of an old design). 하지만 이 다리가 위치한 해협이 강한 측풍(crosswinds)이 부는 곳이라 구축된 다리가 심하게 흔들리다가 결국 붕괴됨

à 설계 엔지니어가 기존 다리의 요구사항을 재사용함에 따라 그 당시의 표준에 부합하는 요구사항들이었음. 다리가 잘 구축되었으므로 검증(verification)에도 문제가 없었음

 

à 하지만 그 환경에 적합하지 않은 다리이므로 확인 에러(a validation error)

 

[1940년 7월 1일 오픈하여 같은 해 11월 7일 무너진 Tacoma Narrows 현수교 붕괴 장면]

 

Apollo 13

존 케네디는 1961년 듀크 대학 졸업식 연설에서 아폴로 프로그램의 최상위 요구사항이 “10년 내에 사람을 달에 보내고 무사 귀환시키는 것”이라고 언급함

à 이 요구사항과 기타 파생 요구사항들이 적절했으며 아폴로 프로그램이 미국인들의 니즈를 나타냈으므로 확인(validation)이 적절했음

 

à Apollo 13의 산소 탱크 히터 온도조절 스위치가 운영 전압을 28V에서 65V로 변경했지만 전압 명세서나 스위치 테스트에서 이를 반영하지 않음. 이는 검증(verification)에 의해 발견되었어야 하는 구성 관리 실패(a configuration management failure). 하지만 Apollo 13은 견고한 달착륙선(lunar module), 우주비행사, 백업시스템 백업승무원 덕분에 임무를 마치고 성공을 거둠

 

Concorde Supersonic Transport (SST)

60년, 70년대에 영국과 프랑스에 의해 설계되고 구축된 콩코드는 1976년부터 2003년까지 상업 비행함

à 이 비행기의 요구사항이 적절했고 잘 구축되었지만 상용 비행기의 목적은 돈을 버는 것인데 콩코드는 그러지 못했으므로 확인(validation)의 실패. 하지만 비즈니스 측면이 아닌 정치적, 기술 전략적인 면에서는 콩코드 프로그램을 성공으로 볼 수도 있다는 의견도 존재

 

Coca Cola

코카콜라 회사의 마케팅 부서가 눈을 가리고 Coca Cola와 Pepsi Cola를 시음하는 테스트를 했는데 다수가 펩시를 선호함. 따라서 코카콜라 측이 Coke를 Pepsi의 맛과 유사하게 변경했지만 기존 Coke 제품에 강한 애착을 가진 고객들이 이 New Coke를 거부하고 불만을 표출함. 4개월 후 회사는 Classic Coke라는 이름으로 원래 제품을 되돌려 놓았으며 New Coke는 완전 중단함

à 회사가 마케팅 조사를 하여 다수의 사람들이 선호하는 맛을 찾았으므로 요구사항 개발은 적절했음. 좋은 제품을 제조했으므로 검증(verification)도 문제가 없었음

à 하지만 회사의 고객이 원하는 것을 만들지 않았으므로 확인 에러(a validation mistake)

 

Ariane 5

프랑스의 위성 발사용 Ariane 4 미사일이 성공한 후에 미사일을 더 크게 만든 Ariane 5가 구축되었지만 첫 발사에서 10억 달러의 위성과 함께 폭파됨. Ariane 5 시스템에는 여러 문제가 존재. Ariane 4의 소프트웨어를 더 큰 미사일에 재사용 하면서 적절한 테스팅이 이루어지지 않아 가속도계(accelerometer)가 발사 후 40초 동안 작동되었고, 32-비트 수평 속도 저장 레지스터의 오버플로우가 에러로 표시되지 않았으며, CPU가 이미 셧다운 되었는데 다른(백업) CPU가 셧다운 되는 것을 허용함

à Ariane 5의 요구사항이 Ariane 4의 것과 유사하므로 요구사항을 올바르게 얻는 것은 어렵지 않았음. 단지 더 높은 탑재중량(payload)을 가진 미사일이 필요하였고 이 부분에 대한 확인(validation)은 문제가 없었음. 하지만 기존 설계를 큰 시스템으로 스케일업 하는데 있어서 나쁜 설계가 될 수도 있는 위험이 있었으며 이는 확인 에러(a validation mistake)

à 스케일업된 소프트웨어를 적절하게 테스트하는데 실패한 것은 검증 에러(a verification mistake)

 

화성 기후 탐사선(Mars Climate Orbiter)

주사업자 Lockheed Martin이 위성 추진기(thrusters)에 English 단위를 사용하는 반면 오퍼레이터인 JPL은 추진기 모델에 SI 단위를 사용함에 따라 우주 기반 위성과 지상 기반 모델간의 불일치가 발생함. 태양 전지판이 비대칭이라 추진기가 자주 발사되어야 했고 위성과 모델 간의 에러가 축적되게 됨. 이는 화성의 궤도 고도 계산을 틀리게 만들었으며 결국 탐사선이 궤도를 선회하는 대신 대기권에 진입하여 타버리게 됨(비용 절약을 위해 추적 데이터를 수집하고 지구로 보내는 일을 생략하여 탐사선의 확실한 종말은 알 수 없음)

à 측정 단위를 부여하는 것이 요구사항 개발의 기본적인 부분인데 이를 정확하게 명세하지 않았으므로 요구사항 개발 에러(a requirements-development mistake)

à 우주 기반 위성과 지상 기반 모델간의 불일치는 확인 에러(a validation error)

à 위 실수를 발견했을 수도 있는 테스트를 하지 않은 것은 검증 에러(a verification error)

 

화성 극지방 착륙선(Mars Polar Lander)

하강 중 착륙선 다리가 전개될 때 불요 신호(spurious signals)가 생성됨. 이로 인해 착륙선이 이미 착륙한 것으로 잘못 인지되어 엔진이 너무 일찍 셧다운되었고 결국 착륙선이 화성 표면에 충돌하여 파괴됨

à 센서가 불요 신호를 생성하는 것이 드문 일은 아님. 착륙선 시스템의 테스트 동안 설계 에러로 인해 센서 배선이 부정확하게 되면서 이 불요 신호가 시스템 테스트에 의해 식별되지 못함. 이후 제대로 배선된 터치다운 센서를 가지고 시스템 테스트를 반복하지도 않음

à 이 실패의 직접 원인으로 조기 엔진 셧다운을 들 수 있지만 그 기저에 깔린 원인은 부적절한 소프트웨어 설계와 시스템 테스트임

 

미 북동지역 정전

2003년 8월 미 북동지역 정전으로 수백만 명이 전기 없이 지냄(일부의 경우 여러 날 동안 정전이 지속됨). 이 실패의 원인으로는 (1) 오하이오 전력회사가 고전압 송전선 주변의 나뭇가지 손질을 게을리하였고, (2) 의도한 기능을 하지 못한 소프트웨어를 사용하였고, (3) 4개의 자발적 표준을 무시한 것을 들 수 있음

 

à 해당 시스템이 사람들이 필요로 하는 것이었고, 지난 정전 이후로 26년 동안 잘 작동했으므로 검증(verification)과 확인(validation)은 문제가 없었음. 진짜 문제는 산업 전반의 강제적 표준이 없었다는 점이며 이는 요구사항 실패(a requirements failure)로 볼 수 있음