요구사항 기술 방법(1)

민성기  시스템체계공학원장(sungkmin0@gmail.com)


솔루션 영역이 식별되고 나면 시스템 엔지니어는 시스템 성능규격(SPS) 또는 개별 개발 규격을 보다 간결하게 그리고 분명하게 어떻게 작성할 것인가를 도전해야 한다. 우리는 앞서 규격서 개발 실무에서 규격 요구사항 형태를 알아보는 방법을 제시했다.
이 글은 이러한 요구사항을 기술하는 데 필요한 개발 방법에 초점을 두고 있다. 우리는 다양한 요구사항 기술방법을 알아보려고 한다. 우리는 요구사항을 정의하기 위하여 문장구성법을 식별해야 한다. 이는 문법에 치중하기보다 요구사항 내용을 정의하는 것이 무엇보다 중요하다. 요구사항을 준비하기 위하여 요구사항 개발 지침을 제공하고 요구사항 ‘시험’ 방법을 논의토록 한다.
이 글은 또 언제 요구사항 세트가 필요충분하게 도출되었는지를 알기 위하여 규격서 요구사항 개발 도전방향을 논의하려고 한다. 우리는 요구사항 개수를 최대로 줄이고 과도하거나 부족한 규격서가 되지 않도록 해야 한다.

1. 얻고자 하는 내용
· ‘좋은’ 요구사항 속성이란 무엇인가
· ‘요구사항’이 언제 공식적인 요구사항으로 인식되는가
· ‘좋은’ 요구사항을 준비하기 위한 추천사항은 무엇인가
· 요구사항 기술에서 빠지기 쉬운 공통적인 함정은 무엇인가
· 요구사항을 기술하기 위해 무슨 방법을 사용하는가
· 요구사항을 ‘시험’하기 위해 무슨 판단 기준을 사용하는가
· 요구사항 검증방법을 어떻게 식별하는가
· 요구사항 검증 매트릭스(RVM)란 무엇인가
· RVM을 어떻게 개발하는가
· 요구사항 최소화란 무엇인가
· 요구사항을 어떻게 최소화하는가

2. 주요 용어정의
· 요구사항 사용언어 : ‘자연어와 공식어로 복합적으로 나타낸 자동적으로 사용할 수 있는 언어란 시스템이나 컴포넌트에 대한 요구사항, 설계, 거동 또는 기타 특성을 나타내기 위해 사용된다. 예를 들면, 설계 언어 또는 요구사항 규격 언어를 들 수 있다.’ (출처 : IEEE 610.12-1990)

‌좋은 요구사항 구조

사람들은 일반적으로 규격은 좋은 요구사항 세트로 구성되어 있다고 말한다. ‘좋다’라는 주관적인 사용은 시스템 엔지니어를 비굴하게 만든다. 누구에게 ‘좋은 것’인지는 무슨 ‘사용 적합성’에 대한 표준을 사용하고 있는지에 달려있다. 사용자? 시스템 개발자? 만일 좋은 요구사항이 사용자에게 연관되어 있다면, 나쁜 요구사항을 ‘나쁘다’라고 말하는 것은 무엇인가? ‘나쁘다’라고 한다면, 잘못 기술, 해석하기 나름, 달성 곤란, 측정 곤란, 검증 곤란 및 시험 곤란을 의미하고 있는가?
따라서 이러한 사람들이 말하는 ‘좋다’라는 뜻은 잘 정의되고, 분명하게 기술되었으며 재해석해야 할 경우가 없는 경우를 말한다. 그들은 잘 숙련된 기술을 지닌 둘 또는 그 이상의 사람들이 동일하게 이해할 수 있도록 분명하고 간결하게 잘 정의되어 기술되어 있다는 것을 말한다.

1. 능력 요구사항 내용
잘 정의된 요구사항은 적용방법에 따라 여러 주요 특성으로 구성되어 있다. 외형적으로 다음 사항을 제시해야 한다.

· 유스 케이스에 근거한 운용수행 능력
· 활동 소스
· 활동 수행 시나리오 또는 상태
· 성능에 근거한 산출물 기대사항(예를 들면, 제시되어야 할 제품이나 서비스)
· 피해야 할 부산물
· 능력 또는 활동 시작시기
· 기대되는 활동 주체
· 기대되는 결과 또는 산출물
· 측정 또는 검증되어야 할 방법

1) 유스 케이스에 근거한 운용수행 능력 : 기술된 요구사항은 유스 케이스에 의한 운용능력 근거를 제시해야 한다. 하위 레벨 요구사항은 가상적인 시나리오와 같이 유스 케이스 달성에 기여하는 특정 활동 근거 산출물로 표현되어야 한다.
2) 활동 소스 : 능력 요구사항에 대한 활동 소스는 능력을 표현하기 위하여 명사로 표현된 객체(사람, 장소, 사물)로 나타낸다.
3) 운용환경 조건 및 시나리오 : 각 능력 요구사항은 능력에 대한 거동 반응을 시작하거나 자극하는 이벤트, 한계점을 나타내는 미리 정해진 운용환경 시나리오에 의해 구속되어야 한다.
4) 활동 능력에 따라 생성된 산출물 : 능력이 나타나게 되면 활동이 시작된다. 요구에 따른 산출물이 능력에 따라 나타나는 제품 또는 용역을 의미하는 거동 활동을 식별할 수 있다.
5) 제품 또는 용역 산출물 : 요구사항의 기본은 정보, 에너지 또는 데이터를 산출물이나 제품/용역, 거동 특성으로 전환하기 위해 기대되는 반응활동을 나타내는 능력을 말한다.
6) 활동 반응 시간 : 큐 또는 이벤트와 같은 자극 시점에서 요구능력에 대한 체계 반응 시점까지 시간제약을 말한다. 이러한 이벤트 시작에서 산출물 반응 시점까지 허용된 성능 수행기간이란 무엇인가?
7) 활동 수령자 : 능력에 대한 의도하는 산출물 수령자는 그 활동을 수용하기 위한 능력을 포함하여 식별되고, 추천되며 구속되어야 한다.
8) 활동 반응 포맷 : 상호작용에 대한 협동, 우군 또는 적군을 구분하기 위한 활동 반응 포맷은 약속된 법칙에 따라 협력하거나 상호작용해야 한다. 다음 두 가지 사례를 살펴보자.

[예제 #1] 두 개의 컴퓨터가 상호간에 연계될 때, 두 컴퓨터는 인터페이스 통제문서(ICD), 인터페이스 요구사항 규격(IRS), 또는 산업표준에 따라 포맷 처리된 메시지를 포함한 인터페이스 프로토콜을 적용해야 한다.
[예제 #2] 반대로 적군 활동을 해야 할 경우, 방어자는 약속된 법칙(예를 들면, 허용된 활동과 측정된 반응)에 따라 근거 활동을 수행해야 한다.

9) 활동에 대한 기대 산출물과 결과 : 능력에 대한 반응을 산출하는 것이 단순하게 목적이 달성되었다고 보지 않는다. 따라서 요구사항은 수량이나 우선순위처럼 측정 가능한 성능 레벨과 같은 거동의 반응을 제시하여 기대 산출물이나 활동이 무엇인지를 정의해야 한다.

2. 요구사항 검증
제시된 모든 요구사항은 하나 또는 그 이상의 네 가지 검증 요구사항(검사, 분석, 데모, 시험)으로 연결되어야 한다. 

공식적인 요구사항 반영시기

우리는 이전에 잘 정의된 요구사항이란 무엇인지를 논의해 왔다. 이제 다음과 같은 질문을 하게 된다. 언제 그 요구사항이 실제 요구사항으로 나타나는가? 여기에 대한 답은 두 가지가 있다. 하나는 비공식, 다른 하나는 공식적인 경우이다.
이를 단순하게 식별하는 방법은 공식적인 이해관계자 인정과 수락이 이루어졌느냐에 달려있다. 첫 번째 단계는 요구사항으로 제시할 수 있고 상응한 내용으로 기술될 경우를 말한다. 그다음 단계는 이를 공식적으로 승인하여 제시하는 단계이다.
대부분 시스템 엔지니어는 단순하게 요구사항 문서를 작성하고 나면 끝났다고 생각한다. 이와 같이 요구사항 문서를 준비하는 일이 요구사항 완전성에 대한 종료 기준을 통과했다고 할 수 없다. 왜 이와 같이 완전성을 요구하게 되는가? 여기에는 두 가지 중요한 사항이 있다.
첫째, 요구사항 검증방법을 제시하는 일이 필요하다. 이는 개발자로 하여금 어떻게 그 요구사항을 검증할 수 있는지를 생각하도록 한다. 만일 당신이 하나 또는 둘 이상의 검증방법을 제시할 수 있다면 당신은 그 요구사항에 대한 법적근거를 가지게 된다. 역으로 만일 시험계획 마련이 어려울 경우, 그 요구사항 문장을 재작성하거나 수정해야 한다.

[유의사항] 엔지니어들은 검증방법을 시스템 통합, 시험 평가 단계 이전에 제시하지 않으려고 한다. 이는 적합하지 않다는 사실을 명심하기 바란다. 당신은 검증방법을 요구사항 작성 시기에 식별해야 한다. 이에 따라 비용 추정뿐만 아니라 요구사항 최종 확인 방법이 연계되어야 하기 때문이다.

둘째, 만약 검증방법을 미리 제시하지 않으면 기준 규격을 자주 수정해야 하기 때문이다. 대부분 시스템은 다중레벨로 구성되어 있으므로 상위 레벨 요구사항을 검증하는 방법을 이해하고 하위 레벨로 분할할 수 있는 분석활동을 수행해야 한다.
두 번째 이유에 대하여 요구사항을 도출할 때부터 검증방법을 함께 생각해야 한다는 점이다. 바로 이것이 요구사항에 대한 초기 완전성을 체크하는 일이다. 그다음 하위 레벨 분석을 단계적으로 수행해야 한다. 상위 레벨 요구사항 기준을 제시하기 전에 상위 레벨에서의 예비 검증방법을 검토하고 조정해야 한다.
잠재적 세분화가 일어나면서 안정된 의사결정에 따른 비용증가 요인이 발생함에 따라 인간적인 망설임에 따른 리스크가 자리 잡을 수 있다. 의도적이건 아니건 간에 시스템 엔지니어로 하여금 검증방법 식별 우선순위에서 밀려나게 되므로 프로그램 일정 지연에 대해 변명을 하게 된다.
일반적으로 사람은 그들이 기술관리 중요성을 인지하거나 그렇게 하라고 지시하지 않는 한 활동에 집중하는 노력을 않는다. 이에 따라 검증방법은 시스템 통합, 시험평가 단계 이전에 함께 결정해야 한다. 만일 시스템 개발자가 사전에 규격 검증방법을 식별하지 않는다면, 시스템 통합 단계에서 어려움을 겪게 된다는 사실을 반드시 유의해야 한다.

요구사항 문서 준비

규격서 개발자는 한꺼번에 너무 많은 요구사항을 기술하기 위해 많은 시간을 허비하게 된다. 당신이 요구사항을 개발할 때, 지켜야 할 세 가지 단계가 있다.

제1단계 : 요구사항의 주요 사항 식별
앞서 우리는 대부분 요구사항 내용을 기술하는 주요 속성 (활동 소스 등)을 알아보았다. 이러한 각 속성에 대하여 무슨 요구사항 속성이 상호간에 기술되어야 하는지를 단순한 동사-명사 형식으로 식별토록 한다. <표 1>에 그 사례를 살펴보자.



여기에 우리는 자동차 설계 시, 시스템 레벨 요구사항에 대한 기본 내용을 보여주고 있다.
<표 1>은 무엇을 수행해야 하는지를 보여주고 있다. 이에 대한 요구사항 문장은 다음 예제를 참조해 보라.

[예제 #3] 자동차는 전천후에 대하여 목적지 200마일에 이르기까지 드라이버와 승객 4명에게 안전하고 편리한 운송을 제공해야 한다.

제2단계 : 요구사항 초안 개발
사람은 무의식적으로 성능 및 개발 규격 요구사항 절차를 복잡하게 만든다. 요구사항 문장 개발 및 작성은 1) 내용 2) 문장 3) 문법으로 된 세 가지 사항을 내포하고 있다. 요구사항 개발에 있어서 가장 공통된 문제점 중 하나는 사람들이 이 세 가지 사항을 동시에 처리하려고 한다는 점이다. 그 결과로 당신이 문장과 문법에 초점을 두고 있을 때, 당신은 그 내용을 놓치기가 쉽다. 이러한 문제를 해결하는 길은 원시적인 요구사항 문장을 개발하는 것이다.
1) 원시 요구사항 내용 제시
원시 요구사항은 요구사항 내용에 집중하고 있다. 이러한 원시 요구사항을 개발하는 방법은 <표 2>에서와 같은 도표 형태로 접근하는 방법을 사용하는 길이다.
여기 사례는 특정 유스 케이스로 나타낸 능력 24에 대한 요구사항 ID-SPS-136을 살펴본다. 나머지 항목은 운용 관계자 형태, 영역 제약사항, 편차, 또는 상태 및 주기와 같은 종속적 내용으로 구성되어 있다.
<표 2>는 원시 요구사항 내용에 초점을 두고 있음을 주목하고 문법을 고려하지 않도록 해야 한다.



한번 요구사항 요소가 설정되고 나면, 다음 단계는 그 내용을 문장 항목으로 전환하는 것이다.
2) 문장작성 구조 개발
제2단계는 원시 요구사항을 <표 3>에서와 같이 텍스트 형태로 전환한다.



제3단계 : 요구사항 문법 적용
세 번째 단계는 문장을 쉽게 읽고 이해할 수 있는 분명하고 간결한 문법을 사용하여 전환된 문장으로 작성하는 것을 요구한다.

요구사항 검증방법 식별

규격서 개발의 가장 중요한 요소 중의 하나는 획득자와 개발자 사이에 규격서 분야 3.0 요구사항이 어떻게 충족될 수 있는지를 입증하는 방법에 대해 상호 동의하는 일이다. 시스템 개발에 있어서 잠재된 가장 큰 리스크 사항 중의 하나는 시스템 개발자가 획득자에 대한 수락시험을 준비하거나 이행함에 쌍방 간의 검증방법에 대한 불일치성이다. 수락시험에 대한 불일치는 시스템 개발자의 계약비용, 일정, 획득자 야전배치 및 지원비용 일정에 큰 차질을 나타내게 된다.
이러한 시나리오를 배제하기 위하여 규격서는 분야 4.0 품질인증 조항에 획득자와 개발자는 검증방법에 있어서 상호간에 일치가 되어야 함을 포함하고 있다. 이러한 동의는 요구사항 검증 매트릭스(RVM)로 문서화되어 있어야 한다.

[유의사항] 획득자와 개발자는 자신의 역할을 기준으로 한 콘텍스트에서 사용되고 있음을 유의해야 한다. 앞에서와 같이 이러한 항목은 계약 레벨에서의 역할과 관계를 기억해야 한다. 이러한 사실은 시스템과 제품, 제품과 하부시스템 개발팀인 시스템 개발자와 하부계약자 등에서도 유사한 관계를 지니고 있다. 왜냐하면, 각 팀이 요구사항을 하위 레벨 품목개발 규격으로 할당해 감에 따라 이러한 요구사항 적용은 해당 요구사항이 충족되도록 그들의 획득자(역할)에게 동일하게 제시해야 하기 때문이다.
우리가 요구사항 검증 매트릭스(RVM)를 살펴보기 전에 어떻게 검증방법이 선정되었는지를 알아보자.

1. 검증방법 선정 프로세스
일반적으로 시스템 엔지니어는 시스템, 제품 또는 용역이 특정 요구사항을 충족하는지를 나타내기 위하여 네 가지 기본적인 검증방법을 지니고 있다. 여기에는 검사 또는 실험, 분석, 데모 및 시험이 있다. 다섯 번째는 일부 조직에서 유사성을 사용하고 있다.
검증방법 선정은 통찰력을 요구하고 있다. 왜냐하면 검증에 대한 의사결정은 단순한 외부관찰에서부터 분석을 포함한 고도로 복잡한 시험까지 다양하기 때문이다. 이는 매우 비싸기도 하고 오랜 시간이 필요하기도 한다. 또 상식적으로 단순한 외부관찰을 통한 검사면 충분한데 일부러 왜 시험을 수행하게 함으로써 돈도 들고 문제점도 더 발생하는 길을 택하느냐는 것이다. 
그러면 시스템 엔지니어는 어떻게 이러한 방법을 선정하게 되는가? 시간-비용 상관 방법은 그림 1에서와 같이 검증방법 의사결정에 대한 기초를 제공해 주고 있다.



2. 유사성에 의한 검증
일부 조직이나 계약자는 유사성에 의한 검증방법을 허용한다. 이 경우는 이전에 검증된 설계가 신규 시스템이나 제품을 만드는 데 재사용하도록 허용된다. 그 설계를 통한 성능 데이터와 품질기록(CM, QA 등)이 여전히 유효하다는 것이다. 이는 다음과 같은 의미를 가진다.

· 지난 공식 검증 이후 설계변경이 전혀 없었다.
· 야전 배치된 장비에 치명적인 안전 문제가 아무것도 발생하지 않았다.
· 신규 시스템이나 제품에 대한 설계 요구사항이 재사용 컴포넌트의 ‘검증’된 요구사항 범위를 초과하지 않았다.

대부분 조직에서 유사성에 대한 검증을 싫어하는 이유 중의 하나는 더 이상 가용하지 않은 기록에 대한 검사 또는 실험을 요구하기 때문이다. 가장 좋은 접근방법은 검사/실험에 의해 요구사항을 검증함으로써 재사용된 설계가 변경되지 않았음을 보여주는 것이다.

3. 검사 또는 실험에 의한 검증
검사에 의한 검증방법은 다음 두 가지 잠재된 질문을 해보는 것이다.

· 검사 및 실험이 물리적 개체가 제시된 규격 요구사항과 일치되고 있는지를 아는 데 필요한가? 만약 그렇다면, 검사 및 실험을 검증방법으로 선정하라.
· 검사 및 실험이 요구사항과 이와 연관된 성능 레벨이 성공적으로 이행되고 있는지를 입증하기 위해 충분한가? 만약 그렇다면, 검증방법으로 선정하고 다음 요구사항으로 넘어가라. 만약 아니라면, 분석에 의한 검증으로 넘어간다.

4. 분석에 의한 검증
분석에 의한 검증은 다음 두 가지 잠재된 산출물을 지니고 있는 질문을 요구한다.

· 분석이 공식적인 시험으로부터 수집된 물리적 개체나 데이터가 제시된 규격 요구사항 일치 여부를 입증하는 데 필요한가? 만약 그렇다면, 분석을 검증방법으로 선정하라.
· 분석이 요구사항과 이와 연관된 성능 레벨이 성공적으로 이행되고 있는지를 입증하기 위해 충분한가? 만약 그렇다면, 검증방법으로 선정하고 다음 요구사항으로 넘어가라. 만약 아니라면, 데모에 의한 검증으로 넘어간다.

5. 데모에 의한 검증
데모에 의한 검증은 다음 두 가지 잠재된 산출물을 지니고 있는 질문을 요구한다.

· 데모가 공식적인 시험으로부터 수집된 물리적 개체나 데이터가 제시된 규격 요구사항 일치 여부를 입증하는 데 필요한가? 만약 그렇다면, 분석을 검증방법으로 선정     하라.
· 데모가 요구사항과 이와 연관된 성능 레벨이 성공적으로 이행되고 있는지를 입증하는 데 충분한가? 만약 그렇다면, 검증방법으로 선정하고 다음 요구사항으로 넘어가라. 만약 아니라면, 시험에 의한 검증으로 넘어간다.

6. 시험에 의한 검증
앞서 했던 질문사항이 공식 시험으로 기술된 규격 요구사항과 일치됨을 입증하기 위해 물리적 개체가 반복적이고 예측 가능한 산출물을 제시하고 있음을 검증하기 위해 데이터 수집이 필요하다고 인정된다면, 그때 시험이 특정 요구사항에 대한 검증방법으로 선정되어야 한다.
검증방법이 어떻게 선정되는지를 이해했다면 다음으로는 이러한 사항을 어떻게 RVM으로 문서화 하는지를 알아보자.

요구사항 검증 매트릭스 정의

요구사항 검증 매트릭스(RVM)는 각 3.X절 요구사항이 특정 절 4.X 검증방법-검사, 분석, 데모 및 시험 항목으로 대응시켜 표로 제시한 것이다.

1. RVM 사례
RVM 구조를 이해하기 위하여 하나의 가정 사례를 사용해 보자. 능력 A에 대한 요구사항 3.1.1이 ‘그 시스템은 다음 하위 절에 제시된 능력으로 구성된 능력 A를 수행해야 한다’고 하자.

· 3.1.1.1 능력 A1은 .......... 해야 한다.
· 3.1.1.2 능력 A2는 .......... 해야 한다.
· 3.1.1.3 능력 A3는 .......... 해야 한다.
· 3.1.1.4 능력 A4는 .......... 해야 한다.

<표 4>는 이 요구사항에 대한 RTM 사례를 보여주고 있다.



도표에 나타난 바와 같이 능력 A는 다음 네 가지 하위 능력 3.1.1.1, 3.1.1.2, 3.1.1.3, 3.1.1.4가 검증된 후 검사로 검증된다. 하위 능력은 다음과 같이 검증된다.

· 3.1.1.1 능력 A1은 검사로 검증된다.
· 3.1.1.2 능력 A2는 검사와 분석으로 검증된다.
· 3.1.1.3 능력 A3은 데모로 검증된다.
· 3.1.1.2 능력 A4는 검사와 시험으로 검증된다.
 
능력 A의 요구사항이 하위 요구사항 검증에 의해 검사로 충족됨으로 능력 A의 검증방법은 하위 요구사항이 검증된 검사 방법이 된다.
대부분 시스템 엔지니어는 RVM 구조를 개발하고 검증 방법 박스를 검토하면서 동시에 한 품목씩 하위 단계로 내려간다. 당신은 이를 모든 시스템에 적용할 수가 없다. 요구사항 검증 방법 식별은 고도로 반복적이며 요구사항의 중복 레벨 또는 체인으로 조정된다.

2. 요구사항 관리 도구
전통적인 규격서는 4.0 품질인증 조항절을 별도 표로 삽입하고 있다. 이러한 접근 방법의 어려운 점은 규격 개발자와 독자가 3.0 요구사항 절과 4.0 품질인증 절을 왔다 갔다 하면서 확인해야 한다는 점이다. 시스템 엔지니어링 관점에서 이는 매우 비효율적이다.
가장 효율적인 방법은 도구를 사용하는 것이다. 이는 객체 지향적인 관계 데이터베이스를 사용하는 것이다. 이러한 도구는 요구사항에 대한 추가 항목을 포함한 스프레드시트 디스플레이로 기술된 검증방법을 사용하도록 한다. 어떤 도구는 이를 간결하게 함으로써 다섯 가지 항목 대신에 각 셀에 한 가지 항목으로 볼 수 있는 ‘항목 보기’란을 사용하기도 한다.
위의 사례에서 다음사항을 살펴보자.

· 각 요구사항은 고유의 인식번호, 예를 들면 SYS_136 또는 4692xxx와 같은 번호를 지니고 있다.
· 각 요구사항의 전체 문장이 기술되어 있다.
· 각 요구사항은 각 검증방법과 쉽게 연동되어 있다.

<표 5>는 객체 지향 연관 데이터베이스 도구로부터 획득된 상태를 보여주고 있다. 만일 당신이 소규모 프로그램을 수행한다면, 이러한 도구를 사용하지 말고 단순한 스프레드시트를 사용하면 동일한 효과를 가져 올 수 있다.



3. 요구사항 관리 도구에 대한 견해
통념적으로 획득자는 워드 프로세서로 된 문서를 선호한다. 왜냐하면, 그들은 계약의 일환으로 통제하기가 쉽고 대부분 이해관계자가 가지고 있는 소프트웨어를 사용할 수 있기 때문이다.
그러나 문제는 시스템 엔지니어링 측면에서 당신이 어떻게 요구사항을 워드 프로세서 문서인 다른 규격서, 엔지니어링 도면, 그래픽 등을 연결할 수 있느냐 하는 점이다.
오늘날 웹에 기초한 기술로서, 이는 매우 쉽게 수행할 수 있게 되었다. 그러나 재래식 문서 연계는 문서 상호간 추적성을 제공하기 위한 텍스트의 ‘스레드’를 전개하거나 복사할 수가 없다. 요구사항 관리 도구가 이를 쉽게 해결해 주고 있다.
당신은 요구사항 관리 도구 없이 업무를 수행할 수 있다. 그러나 도구를 사용함으로써 요구사항 추적 여부를 검증할 때 많은 시간을 단축해 준다. 이것이 바로 도구를 사용하는 이점이며 이를 통해 시간과 비용을 감소할 수 있다. 당신 스스로 도구 사용이 수용성을 높일 수 있음을 깨닫게 된다. 그러나 대형 복합 사업 추진 시, 당시 조직과 인원의 능력과 생산성을 높이기 위해 보다 많은 도구를 사용해야 한다는 점을 인식해야 한다.

4. 검증 레벨
단순하게 우리는 요구사항에 대한 검증방법을 식별하는 것으로 충분하다고 생각해 왔다. 그러나 몇몇 요구사항은 각 개체나 CI 레벨에서 검증하기가 어렵다. 다음 예제를 생각해 보자.

[예제 #4] 당신이 하부시스템 A 개발규격을 생성해야 한다고 하자. 이상적으로 하부시스템 A는 연관제품으로 검증하려고 한다. 하부시스템 A는 상위 레벨 시스템으로 통합될 때까지 연관제품으로 검증하기가 실제로는 어려운 경우가 발생한다. 예를 들면, 하부 시스템 레벨에서 검증시험 기간 중 하부 시스템 A의 인터페이스 중 하나를 자극하는 것이 현실적이지 못하다. 이러한 결과로 특정 요구사항에 대한 검증이 수행되는 추상적 레벨과 내부 기록 보관용으로 RVM을 소유하기를 원하게 된다. <표 6>은 이러한 사례를 보여주고 있다.



<표 6>에서와 같이 3.1.1.1은 하부 시스템 레벨에서 검증된다. 하부 시스템 A와 하부 시스템 B를 통합한 3.1.1.4 요구사항은 시스템 레벨에서 검증되어야 한다. 따라서 검증 요구사항 3.1.1은 3.1.1.4 시험이 시스템 레벨 통합이 되기 전에 종료될 수가 없다