시스템 요구 도메인 솔루션 개발

요구사항 도출 방법 적용

방법론을 숙지한 다음, 우리가 수백 개의 요구사항을 수록하고 있는 규격서를 개발함에 있어 요구사항 도출 방법론을 어떻게 적용할 것인지를 생각해 보라. 이는 시스템 엔지니어의 경험과 수행 능력에 달려있다.
대부분 시스템 엔지니어는 그들의 마음속에 이와 같은 방법을 염두에 두고 있다. 그리고 규격서를 개발할 때에 그들의 생각은 이미 이러한 방법을 통한 생각을 프로세스로 자동적으로 구상하고 있다. 경험이 더해 갈수록 이러한 방법론은 더욱더 숙련되어 간다.

1. 사용자 인터페이스 요구사항 도출
요구사항 도출 방법론은 대부분의 요구사항 상황에 적용된다. 그러나 사용자 인터페이스 요구사항을 도출할 때 발생되는 몇 가지 의문사항이 있다. 예를 들면, 시스템 레벨 임무 요구사항을 나타낼 때, 요구사항 문장에 “사용자에게 친숙하게, 직관적으로 분명하게, 효과적인 훈련으로, 실제 상황을 그대로 나타내는, 유지보수가 쉽게, 미학적으로 아름답게”와 같은 내용이다. 사람인 이상 엔지니어도 이러한 항목에 대해서 스마트하거나 불확실하거나 두 가지 마음을 가지고 있다.
일반적으로 사람은 우리 자신의 경험과 실패를 통해 규격 작성자의 의도와 달리 ‘충동적 본능’을 지니고 있다. 역으로 주어진 요구사항이 무엇을 뜻하고 있는지에 대한 불확실성을 지니고 있다.
우리가 사용자에게 친숙한 시스템, 직관적으로 분명한 상호간섭, 효과적인 교육훈련 등을 어떻게 검증할 수 있을까? 이러한 문제를 다루는 몇 가지 방법이 있다.
일반적으로 엔지니어는 주관적인 요구사항을 개발함에 있어 두 가지 질문을 가지고 있다.

첫째, 규격에 주관적으로 기술된 요구사항을 포함해도 괜찮은 것인가?
둘째, 만일 이를 기술하게 될 경우, 시스템 일치 여부를 어떻게 검증할 것인가?

첫 번째 질문에 대한 답은 상황에 따라 다르지만, 일반적으로 수용 가능하다. 두 번째 질문에 대한 답은 예를 들면, 사용자 친숙, 직관적으로 분명, 효과적인 교육훈련이 사용자에게 의미하는 바가 무엇인지를 외적으로 나타내는 부속적인 요구사항으로 표현하는 것이 바람직하다. 그때 모(母) 요구사항 내용이 모(母) 요구사항 성취를 나타내는 모든 자(子) 요구사항과의 일치 여부를 볼 수 있도록 기술하라. 
이러한 방법은 조금 황당한 것 같지만, 우리가 사는 세상은 현실적으로 완전함과는 거리가 있다. 요구사항을 객관적으로 작성하려고 노력하지만, 주관적으로 작성하거나 적절하게 표현할 경우, 실제 사용자가 무엇을 원하는지를 표현함에 있어서 보다 효과적임을 볼 수 있다. 시스템 성능 규격(SPS: System Performance Specification)의 주요 목적 중의 하나는 사용자, 획득자, 시스템 개발자를 포함한 모든 이해관계자에게 쉽게 이해될 수 있는 언어로 소통할 수 있어야 함을 기억하라. 내부적인 시스템 개발팀-통합제품팀(IPT)을 위해 작성된 하위 레벨 규격은 이해관계자와 상이한 요소 세트로 기술된다.
아이러니하게도 이해관계자와 익숙하지 않거나 잘 못된 언어로 기술된 객관적인 요구사항은 오히려 주관적인 요구사항보다 더 나쁠 때가 많다. 만약 획득자와 사용자가 규격에 포함된 “사용자 친숙”이라는 구절에 대하여 “부드럽고 희미한 느낌”을 가지고 있다면, 이는 지원하고 있는 모든 자(子) 요구사항과의 일치는 주관적인 요구사항 일치에 대한 기본을 형성해 주는 모든 이해관계자의 동의가 이루어질 때 수용 가능하다. 사용자 친숙이 획득자와 사용자 요구 충족이 달성된 때를 이해관계자가 어떻게 알 수 있는지를 외적으로 분명하게 요구사항이 제시되어야만 한다.

2. 가시적인 형상 요구사항
규격을 개발할 때, 텍스트를 사용하는 것보다 그래픽으로 나타내는 것이 더 좋은 경우의 요구사항이 있다. 다음과 같은 예제를 생각해 보자.

[예제 1] 가시적인 디스플레이 레이아웃, 패널 레이아웃, 안전 아이콘, 그래픽 그리고 그래픽 용지는 워드로 그래픽 이미지를 기술함에 있어 잘 못 표기되었을 때 수정 및 해설에 따른 어려운 점을 극복해 주고 있다.

텍스트 언어를 사용하여 디스플레이와 패널 레이아웃을 기술할 경우, 가끔 비현실적이고 모호한 결과를 초래하게 된다. 디스플레이, 패널 레이아웃 및 기타 레이아웃은 그림 XX를 하나의 지침으로 제시하는 단순한 솔루션으로 사용된다. 따라서 그림 XX를 그래픽으로 규격서에 포함해도 좋다.
이와 같은 문제점을 해결하는 점근방법은 디스플레이, 패널, 안전 및 기타 레이아웃에 대한 인간공학적인 요구사항을 유일하게 제시하고 있는 성능규격을 통해 나타난다. 이러한 접근방법은 시스템 개발자에 의한 협력 활동 의사결정 시 ‘오픈’사항으로 남게 된다.
실제 사용자는 그들이 원하는 것에 대한 아이디어를 가지고 있거나 아니면 사용자가 결정할 수 있도록 옵션을 제시할 인간공학적 설계 전문가를 보유한 시스템 개발자를 기대하고 있다.
사고에 공통점과 수렴을 가져오는 최선의 방법은 ‘신속 시제’를 개발하는 것이다. 이는 사용자로 하여금 평가, 확인 및 추천을 위한 전통적인 소프트웨어 도구인 실제 디스플레이, 그래프 및 기타 도구를 사용한다. 이는 고전적인 나선형식 개발방법으로서, 요구사항이 완전하게 정의되지 못했거나, ‘올바른 요구사항을 확보’하기 위해 수많은 반복이 이루어져야 하는 경우이다. 여기에서 나타나는 산출물은 규격 내에서 사용자 요구의 동의를 나타내는 그래픽 세트이다.

2. 성능 특성 요구사항
시스템 개발은 참조 모델, 실험 및 데이터 수집으로부터 도출된 광범위한 엔지니어링 분석 데이터를 요구한다.

[예제 2] 이 예제는 추진 시스템의 성능 특성과 거동 특성을 포함한다. 여기서 우리의 관심은 성능 특성을 언어로 규격서에 어떻게 표현하느냐에 있다. 한 가지 해법은 데이터나 성능 요소로 나타나는 그래프와 테이블로 주어진 언어로 나타낸 규격 요구사항을 개발함에 있다.

유의사항으로는, 만약 성능 값에 대하여 선형 또는 비선형 그래프로 거동 특성을 나타내는 능력을 제시한다면, 각 입력에 대하여 라인상의 각 포인트에서 시스템 반응 검증이 수행된다는 사실을 기대한다.
따라서 규격에 점 표식을 포함할 때, 종료점과 중간점과 같은 공식적 검증 곡선을 따라 특정 데이터 포인트만 제공해 준다.

3. 소결론
요구사항 도출은 상위 레벨 목표나 능력을 설계 요구사항으로 전환될 수 있는 하위 레벨 지원능력으로 분할하는 데 초점을 두고 있다. 표면적으로는 각 요구사항이 다음 요구사항을 이끌고 가는 평범한 프로세스로 나타난다.
어셈블리 또는 CSC 레벨에서의 하위 레벨 요구사항을 도출함에 따라 능력에 관한 모든 사항이 도출되어 있는지를 확인하기 위해 다른 방법을 사용토록 한다. 한 가지 방법은 시스템 능력을 분해하는 방법이다. 이는 하부시스템 또는 하위 레벨에서의 규격 개발과 같은 요구사항 도출하는 방법을 사용한다.

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

규격서의 요구사항 개발을 위한 시금석은 요구사항의 할당, 분할 및 추적을 통합함에 있다.

1. 요구사항 할당과 분할
요구사항 할당, 분할 및 추적은 그림 1에서와 같이 매우 간단한 구조로 설명할 수 있다. 예를 들면, 하부시스템 A 개발규격에서 능력 요구사항 A_11에 근거한 유스케이스를 포함하고 있다고 하자. 요구사항은 입력, 프로세스 및 데이터 전개로 하나의 능력을 특정 짓고 묶어 준다. 시스템 엔지니어는 유스케이스 분석을 수행하고, 유시 케이스 스레드를 형성하며, 이 능력을 달성하는 방법을 제시해 준다.
이와 같이 요구된 성능기준 결과물을 얻기 위해 관리한다. 분석에 따라 능력 요구사항 A_111, A_112 및 A_113으로 각 유스케이스 단계로 전환해 간다.
이 예제는 규격 범위 내에서 능력 요구사항을 도출하기 위한 통찰력을 제공해 준다. 시스템 레벨 요구사항은 여러 개의 하부시스템으로 전환되어야 하며, 이는 개발 규격으로 각각 제시되어야 한다는 사실을 생각해 보라.
요구사항을 할당하고 분할함에 있어 기본적으로 왜-어떻게(why-how) 구조를 관찰하게 된다. 상부와 하부 사이의 계층구조 내에 있는 그 어느 요구사항 위치로부터 계층구조의 상향식 접근은 왜(why) 그 요구사항이 존재하는지 이유를 설명해 주고, 하향식으로 내려가면 어떻게(how) 그 요구사항이 달성되는지를 알려준다.

2. 실체 영역을 넘어선 요구사항 도출, 할당 및 분할
요구사항을 할당하고 분할할 때 실체 규격 영역을 넘어간다. 이 프로세스는 더욱더 도전적이다. 요구사항 할당과 프로세스 분할의 조종자로서의 시스템 엔지니어는 유스케이스 스레드가 모든 적용 규격과 개별 요구사항을 넘어서 추적 여부를 확인해야 한다.
이제 시스템 레벨 능력 요구사항을 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_11을 요구사항 A_111과 A_112를 수행함으로써 충족된다. 하부시스템 B는 요구사항 B_11을 요구사항 B_111, B_112 및 B_113을 수행함으로써 충족된다.
다음과 같은 예제를 생각해 보자. 원격 센서(하부시스템 A)를 가지고 있는 단순 시스템을 고려해 보자. 그 센서는 입력 데이터를 수집하고, 그림 2와 같이 중앙 사이트로 보낸다.
중앙 사이트(하부시스템 B)는 보고서를 출력하기 위하여 데이터를 수신하고 처리한다. 따라서 원격 센서 개발 규격서는 다음과 같이 기술한다. 1) 데이터를 수집한다(A_111), 2) 데이터를 중앙 사이트로 전송한다(A_112).
중앙 사이트 개발 규격서는 유스케이스 스레드의 나머지 사항을 포함하여 기술한다. 1) 데이터를 수신한다(B_111), 2) 데이터를 처리한다(B_112), 3) 데이터를 보고한다(B_113).

 ‌

요구사항 추적

요구사항이 도출될 때, 할당과 분할 프로세스는 상향식 요구사항 추적을 통해 상위 레벨 요구사항과 궁극적으로 소스 또는 근원적인 요구사항에 이르기까지 검증되어야 한다.

1. 개별, 계약 및 조직부서의 요구사항 추적
경험적으로 보아 엔지니어와 조직부서는 세 가지 단계 프로세스를 통해 요구사항 추적을 습득하는 것이 바람직한 것으로 알려졌다. 진화 정도는 사이즈, 복잡도, 그리고 개발될 시스템과 성능 향상을 위한 개인 및 조직의 욕망과 요구에 대한 위험도에 달려있다.

· 단계 1 : 표준 규격서 지침을 사용하여 요구사항을 구조화할 필요성을 인식하는 단계이다. 오랫동안 요구사항에 대한 누락, 위치 오류 및 충돌과 같은 개인과 조직의 경험을 통한 교훈은 새로운 요구사항 적용 능력이 필요하다고 요구된다. 이때 2단계로 전환한다.
· 단계 2 : 개인 또는 조직은 여러 레벨의 시스템 요구사항은 상위 레벨 요구사항과의 연결에 대한 수직적 요구사항 추적을 포함하고 있다. 규격서 요구사항을 적용하는 데 있어 수많은 시간과 노력을 해왔기 때문에 수직적 요구사항 추적은 한 방향에 불과하다는 견해를 가지고 있다. 이때 3단계로 넘어간다.
· 단계 3 : 능력 요구사항 A_112는 능력 요구사항 A_111과는 어떠한 관계가 있는지, 요구사항 B_111과는 데이터를 처리하고 전송함에 있어서 산출물에 대한 요구가 어떠한 것이 있는지를 알아본다.

일반적으로 수직적 관계로 요구사항을 할당하고 분할하도록 제한하게 되면, 요구사항 B_111과 B_113과의 연계성을 보장할 수 없다.

(1) 요구사항 상호간에 대화를 유지하라.
(2) 만일 쌍방 간에 서로 대화가 된다면, 그 결과를 설계문서로 연계시켜라.

불행하게도 수많은 시스템 엔지니어는 시스템 유스케이스 스레드에서 시스템 보완 비용이 상당히 많이 드는 통합 및 시험단계에서야 비로서 이러한 연계성 부족현상을 발견하게 된다는 사실이다.

그림 1. 요구사항 할당, 분할 및 추적 사례

요구 도메인 솔루션 변경

요구 도메인 솔루션이 개발될 때, 사용자, 획득자 및 시스템 개발자가 추가적으로 요구하는 여러 가지 경우가 발생된다. 다음과 같은 경우를 생각해 보자.

· 도전 1 : 문제 영역 이해. 우리가 문제 영역에서 철저하게 문제점이나 쟁점사항을 다루고 있는지를 이해하고 사용자는 이를 해결하려고 노력하고 있는가?
· 도전 2 : ‘원하는’ 시스템 개발. 요구사항이 솔루션 영역을 충족시키는 시스템, 제품 또는 서비스에 대한 필요 충분한 능력, 성능 및 특성을 제시하고 있는가?
· 도전 3 : 이해관계자 운용요구. 만약 우리가 요구사항에 의해 시스템을 개발한다면, 납품 시스템, 제품 또는 서비스가 사용자가 의도하는 운용 요구 충족 여부에 대해 성과 확인을 어떻게 해야 할 것인가?
· 도전 4 : 이해관계자 관심 표현. 그 요구사항이 이해관계자의 동의와 우선순위 설정 및 자원 제약사항 내에서 수명주기 단계를 나타내고 있는가?
· 도전 5 : 요구사항 검증 가능성. 요구사항은 실현, 달성, 시험, 측정 및 검증 가능한가?
· 도전 6 : 사용 적합성 판단기준. 요구사항은 운용, 거동 및 물리적 도메인 솔루션에서 요구된 ‘사용적합성’기준을 충족하고 있는가?
· 도전 7 : 개발 리스크. 요구사항이 수락 불가능한 기법, 기술, 운용, 지원, 비용 및 일정 리스크를 지니고 있는가?
· 도전 8 : 계약 리스크. 요구사항은 허용 가능한 비용과 일정 제약사항 내에서 주어진 능력 레벨을 지닌 유능한 조직에 의해 적용될 수 있는가?

 

그림 2. 내부 규격 요구사항 추적 사례

‌요구 도메인 솔루션 연관제품

요구 도메인 솔루션은 다음과 같은 연관제품을 포함한다.

(1) 다중 레벨 개체 개발, 프로세스, 자재규격, 사용자 운용 요구와 마찬가지로 시스템 성능규격(SPS)에 대하여 계층구조로 규격 트리를 통해 나타내고 있다.
(2) 규격 요구사항으로 연계하여 도출 능력 세트로 구성된다.
(3) 하위 레벨로 요구 할당, SPS로 추적, 사용자 운용요구 및 요구사항 상호 간 수평추적을 문서화한 요구추적 매트릭스(RTM)를 포함한다.
(4) 제시된 의사결정을 위해 기술 및 과학적인 기준을 문서화하는 분석, 모델, 시뮬레이션과 같은 문서와 도구로 지원된다.

 

‌원칙

요약해서 앞서 논의한 내용은 개체 요구 도메인 솔루션 실무 개발에 있어서 중요한 원칙을 설정하기 위한 기본개념을 설명했다. 

[원칙 1] 시스템/개체 솔루션 개발에서 첫 번째 단계는 도메인 솔루션 요구사항을 도출, 구속 및 규격화 하는 업무로 시작된다.
[원칙 2] 모든 요구사항은 소스 또는 근원적인 요구사항과 적용 비용을 추적할 수 있어야 한다. 따라서 추적 불가능한 요구사항은 제거되거나 소스 요구사항에 연결된다.
[원칙 3] 시스템/실체에 대한 요구사항을 도출할 때 원칙은 다음과 같다.
· 사용자가 무엇을 필요로 하는가.
· 사용자가 원하는 것은 무엇인가.
· 사용자에게 허용 가능한 것은 무엇인가.
· 사용자가 기꺼이 지불하고자 하는 것은 무엇인가.

 ‌

요약

이 글에서 논의된 요구 도메인 솔루션은 솔루션 영역에서의 주요 요소와 연관제품을 설명했다. 요구 도메인 솔루션은 운용, 거동 및 물리적 도메인 솔루션과 고도로 협력하며 반복된다. 이러한 솔루션을 위해 설정된 요구사항은 운용, 거동, 물리적 솔루션이 개발되는 솔루션 영역을 구속시킨다.
또한, 우리는 요구사항에 대한 도출, 분할, 할당 및 추적을 위한 여러 가지 주요 원칙을 설정하는 방법을 살펴보았다.
할당에 대한 원칙으로 규격서 요구사항 할당은 수직적인 요구사항 추적을 제시하고 있다. 유스 케이스 스레드는 할당된 요구사항을 시스템 레벨 성능 기준 결과물을 산출하는 수평적 업무 흐름을 통합하고 있다.
요구사항 도출, 할당, 분할 및 추적 절차에 대한 논의를 통해, 우리는 여러 레벨의 규격서 요구사항 도출을 위한 방법을 이해하게 되었다. 요구사항 할당과 분할과정에서 수직적 요구사항 추적의 중요성을 이해하고, 유스케이스 연속적인 스레드 검토를 기준으로 수평적 요구사항 추적의 중요성도 함께 이해하게 되었다. 

1. 일반적 예제
(1) 개요에서 우리가 이해해야 할 질문에 대하여 한 번 생각해 보아라.
(2) 앞에서 제시한 시스템 목록을 참조하라. 앞서 제시된 일반적 예제 또는 신규 시스템 선정 시, 이 글에서 논의된 사항을 적용토록 하라. 그리고 다음 사항을 식별해 보라. 

· 다중 레벨 시스템 아키텍처 계층 도표를 만들어 보라.
· 시스템 아키텍처로부터 시스템 규격 트리를 도출해 보라.
· 무슨 개발규격이 시스템에 요구되는지를 기술하고 그 이유를 설명해 보라.

2. 조직 중심 예제
(1) 당신 조직의 지휘체계와 미디어를 연구해 보라.
· 요구 도메인 솔루션을 위해 무슨 원칙이 요구되는가.
· 그 결과를 문서화하고 보고토록 하라.
(2) 당신 부서 내에 있는 계약 프로그램을 살펴보라. 리드 시스템 엔지니어와 상의하여 해당 프로그램이 어떻게 되어 있는지를 조사해 보라.
· 형성된 요구 도메인 솔루션을 살펴보라.
· 요구사항 베이스라인을 관리하고 있는가.
요구 도메인 솔루션을 운용 도메인 솔루션과 연계하고 있는가.
(3) 당신 조직 내에 있는 시스템 규격을 선정한 다음, 요구 도메인 솔루션에 대한 아키텍처 구조(계층)를 개발해 보라.
· 얼마나 잘 요구사항과 능력 맵을 수행하고 있는가.
· 누락, 오해, 마찰, 또는 중복 요구사항은 없는가.
· 각 요구사항에 대한 시험방법을 기술해 보라. 요구사항 세트가 요구사항 기술 작성기준과 일치하고 있는가.
· 요구사항 세트에서 기술적 쟁점사항은 없는지 식별해 보라.

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