규격서 도출·분할·할당·추적

민성기  시스템체계공학원장(ise@seinstitute.co.kr)


전형적으로 시스템 성능규격서(SPS)를 개발하는 활동은 대형 복합 시스템의 요구사항 계층구조의 일부분에 속한다. 시스템 엔지니어들은 궁극적으로 시스템 개발자가 부품 레벨 설계를 위한 하위 레벨 규격을 어떻게 만들 것인지 골몰한다.
이 장에서는 시스템 요구사항의 규격 기반 계층구조를 생성하기 위한 요구사항 도출, 할당, 분할 및 추적 실무를 설명한다.
먼저 요구사항 도출, 할당, 분할에 대한 용어를 정의한다. 우리는 어떻게 요구사항이 도출되며, 파생 요구사항 생성 방법을 식별하고, 그리고 이러한 방법을 어떻게 적용하느냐를 설명한다.

1. 얻고자 하는 내용
· 요구사항 도출이란 무엇인가
· 당신은 요구사항을 어떻게 파생하는가
· 요구사항 할당이란 무엇인가
· 요구사항을 어떻게 할당하는가
· 요구사항을 어떻게 분할하는가
· 요구사항을 어떻게 추적하는가. 어디에 이를 저장하는가

2. 주요 용어정의
· 리프(Leaf) 요구사항 : 특정 능력에 대하여 가장 낮은 레벨에서 도출된 요구사항을 말한다.
· 요구사항 할당 : 장비, 인력 및 설비와 같은 하나 또는 여러 개의 하위 레벨 시스템 요소 또는 이러한 요소에 내장된 품목으로 요구사항을 적합하게 맡기는 활동을 말한다.
· 요구사항 도출 : 추상적인 상위 요구사항을 하위 레벨 목표, 성능 기반 하위 활동으로 분할하는 행위를 말한다. 파생된 하위 활동의 총합은 상위 요구사항 수행을 만족하게 이행해야 한다.
· 요구사항 분할 : 시스템에서 제품으로, 제품에서 하위 시스템 추상적 레벨로 요구사항이나 분야를 분할 적용하는 활동을 말한다.
· 요구사항 시험 : 미리 정의된 요구사항 개발 기준에 따라 요구사항 구성 체계, 문장에 대한 내용과 품질을 평가하는 활동을 말한다. 이러한 목적은 요구사항의 모호, 시험 가능 여부, 측정 가능 여부, 검증 가능성과 추정 가능성을 결정함에 있다.
· 요구사항 추적 : 상향식, 하위 레벨 규격서 요구사항 사이에 다중 레벨 연결성을 하나 또는 그 이상의 소스나 원천 요구사항으로 추적하는 활동을 말한다.
· 요구사항 검증 : 논리적이거나 물리적인 품목이 분명하게 성능 또는 품목 개발 규격으로 문서화된 할당 능력과 성능 요구사항과의 일치 여부를 검사, 분석, 데모 또는 시험과 같은 검증방법에 따라 입증하는 활동을 말한다. 요구사항 검증은 시스템/제품 수명주기의 시스템 조달 단계와 시스템 개발 단계를 통해 일어난다.
· 요구사항 확인 : 제시된 요구사항이 완전하게, 정확하게, 그리고 분명하게 문제영역을 바르게 표현하고, 솔루션 영역에서 나타난 내용이 사용자가 의도하고 있는 운용요구를 충족하게 제시하고 있는지를 사용자 또는 획득자에 의해 수행하는 활동을 말한다.

‌요구사항 도출방법 이해

다양한 다중 레벨 체계 품목의 요구사항 식별과 도출은 단순한 요구 문장을 문서화하는 이상의 의미를 지닌다. 그 절차는 수많은 제약사항을 고려하고 화해하며 조정하는 빈번한 반복과 요구되는 환경에 달려있다. 아마도 이러한 절차를 기술하는 최선의 방법은 그림 1과 같은 환경을 만드는 것이 중요하다.



다음 토픽으로 그림 1의 상위 중간에 있는 요구사항 도출 프로세스를 살펴보도록 하자.

1. 시스템 엔지니어링 프로세스에 따른 요구사항 도출
요구사항 식별과 도출의 초점은 차트 중앙에 있는 SE 프로세스 모델에서 비롯된다. SE 프로세스 모델이 각 추상적 개체 레벨에 적용되기 때문에 요구사항은 상위 레벨 규격으로부터 하위 레벨 품목 개발규격(IDS)에 이르기까지 할당되고 분할된다. 다중 레벨 시스템 솔루션이 진화함에 따라 요구사항이 하위 레벨 품목개발 규격으로 할당되고 분할된다.
당신은 그림 1과 같이 의사결정 지원 프로세스가 SE 프로세스 모델을 지원하도록 연계해야 한다. 요구사항 도출과 연관된 기술적 의사결정은 수행될 절충연구와 심층 분석이 요구된다. 차례로 의사결정 지원 분석과 절충연구 완료 후, 의사결정 지원 데이터를 제공하기 위해 시제, 모델, 시뮬레이션 개발을 하게 된다.   

2. 기타 프로세스와의 관계 및 인터페이스
그림 1의 상위 가운데에 나타낸 요구사항 도출 프로세스는 실제 SE 프로세스 모델 내에 있는 요구사항 도메인 솔루션 개발활동의 일부분이다.
안갯속과 같은 순차적인 의사결정 스텝의 일부인 요구사항 도출 프로세스는 다음과 같은 SE 프로세스 활동과의 고도의 반복적인 인터페이스로 이루어진다.

· 개체의 문제점과 솔루션 영역의 이해
· 개체의 운용 도메인 솔루션 개발
· 개체의 거동 도메인 솔루션 개발
· 개체의 도메인 솔루션 개발
품목 문제점과 솔루션 영역 활동을 이해하기 위해서는 다음과 같은 사항에 대하여 요구사항 개발자의 철저한 심사숙고가 이루어져야 한다.

· 요구사항 개발을 위한 시스템이나 품목이 주어진 솔루션 영역에 어떻게 나타날 것인지를 분석
· 솔루션 영역이 어떻게 상위 레벨 문제점 영역으로 연계되는지를 분석

이를 통해 우리는 요구사항 도출 프로세스가 환경 내에서 어떻게 적합한지를 알게 해준다. 이와 같이 시스템 엔지니어는 문제점 영역 내에서의 솔루션 영역의 콘텍스트, 순서 및 의존을 이해하기 위한 임무 분석 방법과 기법을 적용해야 한다.

3. 고객 요구 수용과 예산 지급 여부
상위 레벨 규격으로부터 요구사항을 분할하는 것은 획득자나 상위 레벨 시스템 개발팀이 원하는 것을 표현하고 있다.
요구사항 도출 프로세스는 그림 2와 같이 고객의 필요성에 대한 변화 과정은 사용자가 무엇을 원하는지, 무엇을 필요로 하는지, 무엇을 수용하는지, 무엇을 기꺼이 지급하려고 하는지에 따라 변경된다.



최종적으로 동일한 콘텍스트 내에서 무엇을 요구하고 있는지를 나타내는 고객 요구사항으로부터 시스템 개체 솔루션 영역을 알아보자.
사용자는 어떻게 시스템을 사용하려고 하는가.
우리는 어떻게 시스템의 운용 효과, 유틸리티, 적합성을 사용자 요구와 수용, 지급조건과 연계하여 생각하고 있는가.

4. 개별 요구사항의 목적과 의미에 대한 이해
상위 레벨 규격 요구사항이 시스템 개체로 할당되고 분할됨에 따라 시스템 엔지니어는 시스템 개체의 솔루션 영역에 대한 관계와 연관성을 이해하기 위하여 개별 요구사항을 분석해야 한다.
정의에 따른 각 요구사항은 체계 품목의 능력과 성능 레벨을 식별하고 규정짓고 구속한다. 이 분석을 통해 다음과 같은 사항에 대한 답을 해야 한다.

· 이 요구사항을 충족하기 위해 무슨 산출물을 달성해야 하는가
· 원하는 산출물은 언제 그 능력을 달성해야 하는가
· 각 요구능력은 얼마나 잘 수행되어야 하는가
· 무슨 시나리오와 조건으로 각 능력이 수행되어야 하는가
· 이 능력과 기타 사항과의 관계는 무엇인가

이 질문의 답은 품목의 운용개념(ConOps), 품목의 모드와 상태, 품목의 거동/논리적 솔루션, 품목의 물리적 솔루션과 같은 예비 그래프 및 텍스트 기술을 통해 조화롭게 진화해 간다.
이러한 기술은 시스템 엔지니어로 하여금 도메인과 요구사항 콘텍스트를 보여주는 다중 구상 관점을 얻기 위한 요구사항으로 도출할 수 있다.

5. 소결론
요구사항 문장 도출은 이와 같은 프로세스의 일부분이다. 다른 일부분은 다음과 같은 사항을 포함한 능력과 성능 레벨에 대한 요구사항 문장을 개발함에 있다.

· 적용자로 하여금 쉽게 이해되고 상호 연계
· 상위 레벨 소스 요구사항으로 추적
· 물리적으로 검증

이리하여 사전에 정의된 사용 적합성 요구사항 평가 기준이 요구사항 추적성 통합 유지와 함께 품질 레벨을 확인하기 위하여 설정되어야 한다. 요구사항 도출은 의사결정 체인을 통해 주어짐으로 상위 요구사항 도출의 통합성과 품질에 따라 요구사항 추적이 시스템 통합을 확인하는 길잡이가 된다.
이러한 기본적인 요구사항 도출환경을 이해한 다음 요구사항 도출방법을 논의해 보자.

요구사항 도출방법

요구사항 도출은 반복적이고 예측 가능한 내용을 쉽게 이해하고 상호 의사소통할 수 있는 방법을 요구한다. 이러한 방법을 모색하기 위하여 먼저 이러한 프로세스를 구성하고 있는 환경을 이해해 보자.

1. 도출 패러다임
요구사항 도출은 추상적 의미에서 우리가 일상적으로 사용하는 어휘 분류와 유사하다. 지금까지 소수 엔지니어만 요구사항 도출 시 무엇이 필요한지를 이해하고 있다. 이러한 관점에 대한 객관적인 증거는 다중 레벨의 Wiley & CW 형상 기준 규격을 근간으로 한 규격서에서 볼 수 있다.
문제는 이러한 라벨은 이에 대한 원론을 이해하지 않고 신입생을 가르쳐서는 안 된다는 점이다. 아이러니하게도 수많은 사람이 그 라벨이 무엇을 의미하는지를 알지 못한 채  SE 용어를 어깨너머로 이해하고 전문용어를 사용하려고 한다는 점이다.
SE에서 요구사항 도출이란 여러 개의 요구 기능 수행이 상위 요구사항을 충족시킬 수 있는 하위 레벨, 목적, 성능 기반 요구사항 세트로 된 추상적인 상위 요구사항 내용을 제시함에 있다.

2. 요구사항 도출 방법
요구사항 도출방법은 관측과 경험에 따른 질문을 제시하는 선상에 초점을 두고 있다. 이러한 질문의 목적은 요구사항을 도출하는 방법으로 사용될 주요 요소를 식별함에 있다. 이러한 방법을 당신의 특정 비즈니스 필요성과 애플리케이션에 따라 이해하고 적용토록 하라. 이러한 방법은 다음과 같은 단계로 적용된다. 그림 3에서 다음과 같은 단계별 그래픽 사례를 볼 수 있다.

· 1단계 : 요구사항 분석(1)
· 2단계 : 산출물 식별(2)-거동, 제품, 부산물, 용역
· 3단계 : 산출물로부터 능력, 거동 반응, 성능 도출(3)
· 4단계 : 능력운영 시나리오와 상태 식별 및 제시(4)
· 5단계 : 성능 능력 레벨 제시(5)
· 6단계 : 요구사항 서술(6)
· 7단계 : 각 요구사항에 대한 검증방법 식별(7)
· 8단계 : 요구사항 확인(8)
· 9단계 : 검증 일치 여부 확인(9)
· 10단계 : 다음 요구사항 레벨로 진입(10)

‌요구사항 도출방법 적용

앞서 요구사항 도출방법을 이해한 다음 과연 우리는 어떻게 수백 개의 요구사항을 포함하고 있는 규격서를 개발하기 위해 이 방법을 적용하느냐 하는 것이다. 그 답은 SE를 적용해 온 경험에서 비롯된다.
대부분 시스템 엔지니어는 그들의 마음속에 이러한 방법을 품고 있다. 그리고 규격서를 개발하기 시작할 때, 그들은 이러한 방법을 반복적이고 자동적으로 그 절차를 생각하고 있다.

1. 사용자 인터페이스 요구사항 도출
요구사항 도출방법은 대부분의 요구사항 상황에 적용된다. 그러나 사용자 인터페이스 요구사항을 도출할 때 몇 가지 의문을 제기하는 경우가 있다.
시스템 레벨에서의 임무 요구사항을 표현할 때, 우리는 ‘사용자 편의성, 직관적이고 명백한, 효과적인 교육훈련, 상황을 실제적으로 대표하는, 유지보수하기에 편리한, 미학적으로 만족스럽게’와 같은 특유의 요구사항 문장을 사용한다.
사람으로서 엔지니어는 이러한 용어에 대한 표현은 현명하거나 불확실한 두 가지 견해를 지니고 있다. 일반적으로 우리는 규격 작성자가 무엇을 나타내려고 하는지에 대하여 자기 자신의 경험과 달성 불능을 통한 ‘내적 본능’을 지니고 있다. 역으로 이러한 용어나 구절이 무엇을 요구하고 있는지에 대한 불확실성을 지니고 있다. 우리는 시스템의 사용자 편의성과 직관적으로 명백한 상호관계, 효율적인 교육훈련, 유사한 사례들을 어떻게 검증할 수 있는가에 대한 문제를 다루는 방법이 있다.
일반적으로 엔지니어가 주관적 요구사항을 개발하는 데 다음 두 가지 질문이 있다.

① 규격서에 주관적인 요구사항을 포함시키는 것이 문제가 없는 것인가?
② ‌만일 이러한 문장을 기술하려고 한다면, 어떻게 시스템 일치 여부를 검증할 수 있는가?

첫 번째 질문에 대한 답은 상황에 따라 긍정적으로 받아들인다. 그러나 두 번째 질문에 대한 답은 사용자 편의성을 고려해야함은 물론 직관적으로 명백해야한다. 그리고 효율적인 교육훈련이 사용자에게 무엇을 의미하고 있는지에 대해 외형적으로 명백하게 종속된 요구사항을 제시해야 한다. 상위 요구사항을 충족시킬 수 있는 모든 하위 요구사항의 일치 여부를 나타낼 수 있도록 상위 요구사항을 기술해야 한다.
그러나 실제 상황은 완전하지 못한 세상이므로 이는 놀랍게 여겨진다. 비록 우리가 요구사항을 객관적으로 나타내려고 하지만, 사용자가 원하는 것을 주관적인 요구사항을 통해 보다 적합하게 그리고 분명하게 전달하는 경우가 있다.
시스템성능 규격서(SPS) 작성의 주요 목적 중의 하나는 사용자, 획득자 및 시스템 개발자를 포함한 이해관계자를 설득할 수 있는 쉬운 언어로 요구사항에 대한 의사를 소통하는 것임을 기억하도록 하라.
통합제품팀(IPT)과 같은 내부 시스템 개발팀을 위해 작성된 하위 레벨 규격서는 달리 작성되며 상호 다른 이해관계자로 형성된다.
아이러니하게도 이해관계자에 의해 친숙하지 않거나 이해가 잘 안 되는 언어로 제시된 객관적인 요구사항은 주관적인 요구사항을 제시하는 것보다 더 나쁠 수 있다. 예를 들어, 획득자와 사용자가 규격서의 사용자 편의성에 대하여 ‘부드럽고 불명확한 느낌’을 제시하고 있다면 하위 요구사항이 주관적 요구사항의 일치성을 지원하는 모든 이해관계자의 동의가 이루어지면 수락되고 만다. 따라서 획득자와 사용자가 사용자 편의성을 수락할 때, 이해관계자가 어떻게 알 수 있는지를 분명하게 제시해야 한다.

2. 시각적인 형상 요구사항
규격서를 개발할 때, 텍스트를 사용하는 것보다 그래픽으로 나타내는 요구사항도 있다. 다음과 같은 경우를 생각해 보라.

[예제 1] 시각 전개 레이아웃, 패널 레이아웃, 안정 아이콘, 그래픽 및 그래픽으로 나타낸 점들은 잘못 제시하거나 오해하기 쉬운 문장의 그래픽으로 제시함으로써 어려운 점을 극복할 수 있다.

실제로 디스플레이와 패널 레이아웃을 문장으로 기술하려 하면, 불편하거나 모호한 결과를 가져오기 쉽다. 따라서 디스플레이, 패널 레이아웃 및 기타 레이아웃과 연관된 그림을 참조하도록 제시하는 것이 보다 쉽다. 이때 그 해당되는 그림을 규격서에 첨부하면 된다.
이러한 문제 형태의 가장 좋은 방법은 디스플레이, 패널, 안전 및 기타 레이아웃에 대한 인간공학적 요구사항을 나타내는 성능규격을 통해 이루어진다. 이러한 접근방법은 시스템 개발자에 의하여 ‘오픈’상태로 둔다. 사용자가 의사결정을 하기 위해 옵션을 제시함으로써 시스템 개발자로 하여금 설계 대안을 나타내거나 무엇을 원하는지에 대한 사용자가 몇 가지 아이디어를 가질 수 있다는 점이다.
상호간에 동의를 가져오기 위한 최선의 방법은 사용자가 평가하고 확인하며 추천사항을 제시하기 위하여 기존의 소프트웨어 도구를 사용하는 실질적인 디스플레이, 뷰 그래프 및 기타와 같은 ‘신속 시제’를 간단하게 개발해 보는 방법이다.
이는 요구사항을 아직 제시하지 못한 경우에 수행된 고전적 나선형식 개발 방법으로써, 여러 번의 반복적인 수행으로 ‘올바른 요구사항’을 만드는 것이다. 연습용 제품은 규격서 내에서 사용자가 원하는 사항을 그래픽으로 도출함에 있다.

3. 성능 특성 요구사항
시스템을 개발하려면 광범위한 엔지니어링 분석과 데이터가 필요하며 이는 참조 모델, 실험 및 데이터 수집을 통해 가능하다.

[예제 2] 예를 들면, 추진 체계에 대한 성능 특성과 사용되는 자재의 거동분석을 들 수 있다.

문제는 당신이 어떤 방법으로 성능 특성을 언어로 규격서에 표현할 수 있느냐에 달려있다. 하나의 방법은 데이터나 성능 그래픽으로 제시된 점과 표를 포함한 언어 기반 성능 규격서를 개발함에 있다.
유의할 사항은 만일 당신이 여러 범위의 값을 선형 또는 비선형으로 나타낸 거동 반응을 지닌 능력을 제시하려면, 각 입력사항 라인에 따라 각 점에서의 시스템 반응을 검증토록 해도 좋다. 따라서 규격서의 점과 같은 내용으로 표현할 때, 최종 및 중간점에서와 같이 공식적으로 검증될 곡선을 따라 특정 데이터 포인트만 제공토록 한다.

4. 소결론
요구사항 도출은 설계 요구사항으로 전환될 수 있는 하위 레벨 지원 능력으로 상위 레벨 능력을 분할하는 데 그 목적이 있다. 표면적으로는 각 요구사항은 다음 요구사항으로 진전되는 프로세스로 나타난다. 당신이 아셈부리/컴포넌트 레벨에 근접한 하위 레벨 요구사항을 도출함에 따라 모든 능력 사항이 도출될 수 있도록 적용해야 한다는 사실을 기억해야 한다. 이를 위해 앞서 논의했던 시스템 능력 분해에 대한 사항을 다시 한 번 생각해 보아야 한다. 이를 통해 요구사항 도출을 하부 시스템이나 하위 레벨 시스템 규격개발에 관한 내용을 숙고해야 한다.

요구사항 할당, 분할 및 추적

요구사항 규격 개발에 대한 중심은 요구사항 할당, 분할 및 추적의 통합성에 있다.

1. 요구사항 할당과 분할
요구사항 할당, 분할 및 추적은 그림 4와 같이 이루어진다.



이를 보면, 하부시스템 개발 규격서는 능력 요구사항 A-11에 근거한 유스 케이스를 포함하고 있다. 이 요구사항은 입력, 프로세스 및 디스플레이 데이터로 그 능력을 나타내고 있다.
시스템 엔지니어는 유스 케이스 분석을 수행하고 유스 케이스 스레드를 형성하며 이 능력을 수행할 수 있는 방법을 제시한다. 이를 통해 요구된 성능 기반 산출물을 얻어낸다. 이러한 분석을 통해 각 유스 케이스를 A-111, A-112와 A-113으로 능력 요구사항을 분할하여 전환한다.
이러한 예제는 규격서 내에서 능력 요구사항 도출에 통찰력을 제공해 준다. 이제 각 개발 규격서를 가지고 있는 여러 하부 시스템에 적용되어야 할 시스템 레벨 요구사항을 가지고 있다고 하자.
당신이 요구사항을 할당하고 분할함에 따라 기본적으로 왜, 그리고 어떻게 형성되어야 하는지를 관찰토록 하라. 상위 및 하위 사이 계층구조 내에 있는 한 요구사항으로부터 계층구조 내에서의 상부로 올라갈 경우, 이 요구사항이 왜 존재해야 하는지를 표현한다. 아래 방향으로 내려갈 경우, 그 요구사항이 어떻게 수행되어야 하는지를 볼 수 있다.

2. 개체 영역에서의 요구사항 도출, 할당 및 분할
당신이 요구사항을 할당하거나 분할할 때, 개체 규격 영역을 가로 지른다. 이 프로세스는 그림 5와 같이 매우 도전적으로 나타난다.



요구사항 할당 및 분할 프로세스의 주관자로서 시스템 엔지니어는 유스 케이스 스레드가 적용 규격과 연관된 모든 요구사항을 가로 지르며 추적성을 제공해야 한다.
우리가 시스템 레벨 능력 요구사항, SYS-11을 지니고 있다고 하자. SEIT 시스템 엔지니어링 통합팀은 요구사항을 분석하고 유스 케이스 분석을 수행하며, 하위 요구사항, A-11과 B-11을 도출한다.
여기서 SEIT는 A-11과 B-11 요구사항을 하부시스템 A와 B로 할당하지 않는다. 우리는 각 요구사항의 고유성을 나타내기 위하여 A-11과 B-11로 제시한다.
유스 케이스 분석은 요구사항 A-11과 B-11이 추가적인 분할을 요구하고 있다고 제시한다. 따라서 A-11이 하부시스템 A 또는 B로 할당되지 않은 채 시스템 엔지니어는 유스 케이스 스레드를 형성한다. 이러한 분석을 배경으로 시스템 엔지니어는 다음 사항을 도출한다.

· 요구사항 A-11로부터 A-111 및 A-112
· 요구사항 B-11로부터 B-111, B-112 및 B-113

결과적으로 이러한 요구사항은 하부시스템 A와 B로 할당되고 각 개발 규격서로 분할된다. 따라서 시스템이 수행해야 할 사항으로 할당한다는 의미는 무엇인가?

· 시스템 요구사항 SYS-11로 제시된 성능 기반 산출물을 수행하려면, 하부시스템 A는 요구사항 A-11을 수행해야 하며 그 결과를 하부시스템 B로 입력한다. 이는 하부시스템 B가 B-11 요구사항을 충족하며 이에 대한 최종 결과를 나타내어야 한다.

하부시스템 A와 B는 요구사항 A-11과 B-11을 각자 어떻게 수행하는가?

· 하부시스템 A는 요구사항 A-111과 A-112를 수행함으로써 A-11 요구사항을 수행한다.
· 하부시스템 B는 요구사항 B-111, B-112 및 B-113을 수행함으로써 B-11 요구사항을 수행한다.

다음 예제를 생각해 보자.

[예제 3] 원격센서(하부시스템 A)를 가지고 있는 단순한 시스템을 생각해보자. 이 센서는 입력 데이터를 수집하고 이를 그림 5와 같이 중앙 사이트로 전송한다고 하자.

중앙 사이트(하부시스템 B)는 보고서를 산출하기 위해 데이터를 수신하고 처리 절차를 밟는다. 따라서 원격센서 개발규격은 1) 데이터 수집(A-111), 2) 중앙 사이트로 데이터 송신(A-112) 내용을 기술해야 한다.
중앙 사이트 개발규격은 유스 케이스 스레드를 1) 데이터 수신(B-111), 2) 데이터(B-112) 처리, 3) 데이터를 보고(B-113)하는 나머지 요구사항을 포함하여 제시한다.

요구사항 추적

요구사항이 도출될 때, 할당 및 분할 절차가 상위 레벨 요구사항과 궁극적으로 소스 또는 기원 요구사항으로 연계성을 추적하기 위해 상향식 요구사항으로 검증해야 한다.

1. 개별, 계약 및 조직 요구사항 추적성
엔지니어와 연관된 조직 기관은 요구사항 추적을 세 단계 프로세스를 통해 학습하고 성숙해지고 있다는 일화를 증거로 제시하고 있다. 학습 진화의 정도는 개발될 시스템의 사이즈, 복잡도, 그리고 위험 정도에 달려 있으며, 개인과 조직은 그 능력을 기꺼이 향상시키려고 노력한다.

· 제1단계 : 표준 규격으로 요구사항을 구조화하여 체계적인 필요성을 일반적으로 인식하고 있다. 시간이 경과함에 따라 개인적으로나 조직적으로 습득한 교훈으로서 누락, 위치 불량, 충돌 요구사항과 같은 내용은 새로운 요구사항 적용 능력이 요구되고 있음을 보여주고 있다. 다음 제2단계로 넘어간다.
· 제2단계 : 개인이나 조직은 다중 레벨 시스템 요구사항은 상위 레벨 요구사항과 연결하여 수직적 요구사항 추적을 포함하고 있다. 규격 요구사항을 적용하면서 시간이 지나감에 따라 여러 가지 뼈아픈 경험을 통해 수직적 요구사항 추적이 일차원적이라는 사실을 인식하게 된다. 다음 제3단계로 넘어간다.
· 제3단계 :  개인과 조직은 이차원적인 요구사항 추적의 필요성을 인식하게 된다. 이는 수직적으로 소스 또는 근본 요구사항의 뿌리를 찾아가는 요구사항 계층구조를 통하여 수행하고, 유스 케이스 스레드 추적을 통한 수평적 추적을 수행하게 된다.

2. 만일 이를 수행하기가 곤란하다면 무엇을 해야 하는가?
당신은 “왜 이러한 스레드 체크를 일관되게 수행하지 못하는가?”라는 질문을 해 보아야 한다. 만일 우리가 능력 요구사항 B-11로부터 능력 요구사항 B-111, B-112 및 B-113에 이르기까지 단지 수직적으로 요구사항 도출, 할당 및 분할을 제한한다면 다음과 같은 질문을 해 보아야 한다.

· 이러한 요구사항에 대하여 사용될 언어의 텍스트는 무엇인가?
· 능력 요구사항 B-111이 적용될 때 무슨 산출물을 기대할 수 있는지에 대한 객관적인 증거가 있는가? 그리고 이러한 산출물은 능력 요구사항 A-112와 B-112 상호간에 무슨 관계가 있는가?
· 능력 요구사항 A-112는 능력 요구사항 A-111로부터 무엇을 기대하고 있다고 보는가? 그리고 무슨 전환절차가 요구사항 B-111을 수락할 수 있는 산출물을 내도록 요구되고 있는가?

일반적으로 그렇지 않다. 수직적인 개체 관계로 요구사항 할당과 분할을 제한할 경우, B-113을 통한 B-111 요구사항을 적용하는 팀은 다음과 같은 활동을 보장해 주지 못한다.

· 상호간 커뮤니케이션
· 상호 의견을 교환한다고 하지라도 그 결과를 설계문서로 반영하지 못한다.

불행하게도 수많은 시스템 엔지니어는 그 시스템이 통합되거나 시험될 때까지 시스템 유스 케이스 스레드에서의 모순을 발견하지 못한다. 이때는 이미 보완하기 위해 엄청난 대가를 지급해야만 한다는 것이다.

‌지침

앞서 논의한 모든 내용은 요구사항 도출, 분할, 할당 및 추적 실무에 관한 여러 가지 지침 설정 기준을 제시하고 있다.

[지침 #1] 시스템/개체 요구사항을 도출할 때, 다음 사항을 이해하고 있어야 한다.
· 사용자 니즈는 무엇인가?
· 사용자가 원하는 것은 무엇인가?
· 사용자에게 가용한 자원은 무엇인가?
· 사용자가 흔쾌하게 지급할 수 있는 대가는 무엇인가?

[지침 #2] 규격서 요구사항 할당은 수직적 요구사항 추적을 제시한다. 유스 케이스 스레드는 이러한 할당을 시스템 레벨 성능 기반 산출물로써 수평적인 활동을 통해 통합하여 간다.

‌요약

우리가 논의한 요구사항 도출, 할당, 분할 및 추적 실무에서 우리는 다중 레벨 규격 요구사항을 도출하기 위한 방법을 제시했다.
우리는 요구사항 할당과 분할에 기초한 수직적 요구사항 추적의 중요성을 생각해 보았다. 또한, 지속적인 유스 케이스 스레드 체크에 근거한 수평적 요구사항 추적의 중요성을 함께 제시했다.

1. 일반적 예제
1) 개요에서 우리가 이해해야 할 질문에 대하여 한 번 생각해 보아라.
2) 앞에서 제시한 시스템 목록을 참조하라. 앞서 제시된 시스템을 개발하거나 전혀 새로운 시스템을 선정할 때, 이 장에서 언급된 사항을 참조토록 하라.
(a) 앞서 생성된 시스템 아키텍처를 사용하여 개발규격에 요구되는 제품과 하부체계를 식별해 보라.
(b) 시스템 운용에 관한 시스템 레벨의 유스 케이스 기반 요구사항을 생성해 보라.
(c) 하위 요구사항을 도출해 보라.
(d) 그 요구사항을 제품이나 하부체계에 할당하고 분할해 보라.
(e) 각 제품 또는 하부체계 상호간에 유스 케이스 지속 I/O 스레드 체크를 수행해 보라.

2. 조직 중심 예제
1)당신 조직의 수행된 여러 가지 계약 프로그램을 살펴보라. 그리고 요구사항을 도출, 할당, 분할 및 추적하기 위해 무슨 지침과 규정을 제공하고 있는지 살펴보라.
2) 당신 조직의 수행된 여러 가지 계약 프로그램을 살펴보라. 그리고 기술책임자, 프로젝트/수석 엔지니어, 또는 SE 책임자와 상의하여 다음 질문사항에 답해 보라.
(a) 요구사항을 어떻게 도출하였는지
(b) 계약상 요구사항 추적을 의무화하고 있는지
(c) 프로그램은 규격 상호간에 추적성을 제공하기 위해 요구사항 관리도구를 사용하고 있는지. 만일 없다면, 요구사항 추적을 어떻게 할 것인지.
(d) 성능을 균형적으로 할당하기 위하여 무슨 분석도구를 사용하고 있는지
(e) 이 예제를 통해 무엇을 배웠는지