시스템 엔지니어링 (126)

요구 도메인 솔루션은 시스템, 제품, 하부체계 등 개체의 솔루션 영역이 기법, 기술, 비용 및 일정 제약사항과 리스크에 달려있다. 요구도메인 솔루션은 이하와 같은 사항으로 나타난다.

· 어떤 능력과 성능 특성이 시스템, 제품, 용역으로부터 요구되는가
· 어떤 성능 수준을 기대하고 있는가. 그리고 얼마나 잘 수행하는가
· 요구사항에 근거하여 능력 이행을 위한 시스템 요소 수행책임이 있는가
· 그 능력은 언제 요구되는가
· 어떤 운용환경 상태와 상호작용 아래에서 수행되는가
· 사용자 운용요구를 충족하고 시스템과 임무 목표를 성공적으로 달성하기 위해 어떤 결과와 산출물을 기대하고 있는가
 
이 글은 앞서 SE 프로세스 모델에서 논의된 바와 같이 요구사항 도메인 솔루션을 기술토록 한다. 따라서 요구도메인 솔루션의 목적, 주요 요소, SE 프로세스 모델 업무 흐름 순서, 개발책임, 의존성, 개발방법, 도전 및 산출물을 다룬다.
 
1. 얻고자 하는 내용
· 요구 도메인 솔루션의 목적은 무엇인가
· 요구 도메인 솔루션의 주요 요소는 무엇인가
· 요구 도메인 솔루션과 SE 프로세스 모델의 연관성은 무엇인가
· 요구 도메인 솔루션과 운용, 거동 및 물리적 도메인 솔루션과의 연관성은 무엇인가
· 요구 도메인 솔루션 개발을 위해 사용되는 방법은 무엇인가
· 요구 도메인 솔루션을 도출하기 위해 사용되는 방법론의 단계란 무엇인가
· 아키텍처 개발은 어떻게 하는가
· 요구 도메인 솔루션 출구 판단 기준은 무엇인가
· 요구 도메인 솔루션 개발을 위해 어떤 도전이 필요한가
· 요구 도메인 솔루션 활동을 통해 어떤 산출물을 얻게 되는가
· 요구 도메인 솔루션은 어떻게 검증되고 확인되는가

2. 요구 도메인 솔루션 개발 활동 목적
요구 도메인 솔루션 개발 활동 목적은 이하와 같다.

· 솔루션 영역을 정확, 간결, 일관 그리고 완전하게 나타내며 기능과 성능에 관한 요구 능력과 사용자(콘텍스트 역할)의 확인된 운용요구를 충족하는 데 필요한 특성을 식별함에 있다.
· 개체 검증과 공식적인 수락을 지원하는 문서로서의 목적을 입증함에 있다.

위에서 콘텍스트 역할로 사용한다는 것은 다중 레벨 개발에 참조한다는 의미이다. 예를 들어, 시스템 레벨에서 획득자와 시스템 개발자 조직은 시스템 성능 규격(SPS)에 따른 계약 요구사항 합의를 제공한다. 이때 시스템 개발자 프로그램 조직 내에서 시스템 엔지니어링 및 통합팀(SEIT)은 제품 개발을 위한 제품레벨 통합제품팀(IPT), 기타 개발팀, 또는 이슈 사항에 대한 하부계약자와 함께 제품개발규격(IDS)을 설정한다. 후자의 경우, SEIT는 획득자 역할을 수행하고 IPT, 개발팀 또는 하부계약자는 제품을 대표하는 시스템 개발자 역할을 수행한다.

3. 요구 도메인 솔루션의 주요 요소
요구 도메인 솔루션 주요 요소와 상호 관계는 문제점 영역, 솔루션 영역, 운용 제약사항, 능력, 시계열 임무 이벤트(MET), 규격서, 검증방법, 기능, 성능 측정(MOP), 주요 운용/기술 이슈(COI/CTI) 및 입증과 같은 요소를 다루게 된다.

4. 요구 도메인 솔루션 의존성
앞서 논의한 바와 같이 요구 도메인 솔루션 개발은 운용, 거동, 물리적 도메인 솔루션으로 진화하기 위해서는 밀접한 협력과 협조를 요구하는 다중레벨 고도의 반복 과정을 거쳐야 한다. 대상시스템(SOI)이 기술, 비용, 일정 지원, 리스크 항목으로 전반적인 개발과 수명주기 관점으로부터 최적의 개념으로 적절한 균형이 이루어져 있는지를 확인하기 위하여 객관적인 검토자로 하여금 반복적인 분석과 기술 검토가 수행되어야 한다.

 

5. 요구 도메인 솔루션 개발 순서
시스템 및 개체 개발 초기단계에서 요구 도메인 솔루션 개발은 운용, 거동, 물리적 도메인 솔루션에 앞서 이루어진다. 계약 또는 업무활동 합의를 위한 기술규격에 따라 궁극적으로 이 솔루션은 획득자와 사용자에 의한 물리적 시스템, 제품 또는 서비스에 대한 공식적인 계약에 근거한 수락을 결정하기 위하여 법적근거를 마련해 준다.

6. 요구 도메인 솔루션 책임
요구 도메인 솔루션에 대한 책임은 프로그램 기술이사 또는 프로젝트 엔지니어에게 있으며 통상 프로그램의 리드 시스템 엔지니어에게 위임되어 있다. 리드 시스템 엔지니어는 모든 운용 및 전문 분야 이해관계 사항이 시스템 성능규격(SPS)과 개체별 품목 개발규격(IDS) 개발과 검토로 나타내고 있음을 확인하기 위하여 요구 도메인 솔루션 개발을 관장하게 된다.
한 번 규격 요구사항 기준 베이스라인이 승인 및 배포되고 나면, 형상관리(CM) 담당자가 시스템 및 개체 이해관계자 형상관리 위원회(CCB)나 소프트웨어 형상관리위원회(CCB)의 지침에 따라 공식 변경 관리를 수행하게 된다.

‌요구 솔루션 아키텍처 개발

시스템, 제품 또는 서비스에 대한 설계, 개발, 수락을 위한 중점 인프라 구조는 요구사항에 의존하고 있다. 요구사항은 각 개체의 운용, 거동, 물리적 능력, 성능 특성 및 속성에 대한 범주를 정해주고 있다. 최저 시스템 설계 레벨(볼트, 너트, 코드 등)을 통해 운용 목적이나 필요성을 기술한 개략적인 첫 번째 요구사항으로부터 요구사항은 소스 또는 최초 요구사항으로 추적되면서 연계된다. 이러한 점은 시스템 설계 솔루션 형성을 위한 기초가 되며 추적성에 대한 기본 법칙을 형성한다.
각 요구사항은 계약이나 업무 비용과 일정 성능 측정 베이스라인 제약사항 범위 내에서 적용되는 비용을 지닌다. 만약 어떠한 요구사항이 소스나 최초 요구사항으로 추적되지 않을 경우, 그 요구사항을 제거하거나 비용과 일정 제약사항을 재협의한 다음 계획을 수정하게 된다.
우리는 요구사항 아키텍처로서 계층적이고 수평적인 요구사항 인프라 구조를 알아보도록 하자. 실제, 규격서 트리는 다중 레벨 규격 요구사항을 연결하는 구조를 제공하게 된다. 규격에 대해 보다 많은 정보는 앞서 시스템 규격 실무를 참조한다.

 

‌요구 솔루션 개발방법

요구 도메인 솔루션은 시스템 엔지니어링 프로세스 모델의 주요 요소로 개발된다. 운용, 거동, 물리적 솔루션과 함께 운용 도메인 솔루션의 고도의 반복과 협력적 통합이 매우 혼란스럽고 복잡할 수 있다.
요구 도메인 솔루션을 만들어 내기 위해 반복적인 방법을 사용함으로써 혼돈과 복잡성을 줄일 수 있다. 그 방법은 요구 도메인 솔루션 개발에 있어 연관된 여러 방법 중의 하나이다. 하나의 사례로써 몇 가지 단계로 전략을 요약할 수 있다. 그리고 당신의 비즈니스 도메인과 시스템 적용에 알맞게 테일러링 할 수 있다.

· 1단계 : 문제와 솔루션 영역 이해
· 2단계 : 개체 요구사항을 생성하고 표현
· 3단계 : 개체 규격 요구사항을 분석하고 종합
· 4단계 : 개체 능력을 생성하고 작성
· 5단계 : 요구사항 쟁점사항 해결 및 명료화
· 6단계 : 요구사항 솔루션 검증 및 확인
· 7단계 : 요구사항 솔루션 베이스라인 설정 및 유지

1. 문제와 솔루션 영역 이해
요구 도메인 솔루션 개발의 첫 단계는 다음 사항을 이해함에 있다.

· 사용자가 무슨 문제점이나 쟁점사항을 해결하려고 하는가
· 어떤 규격 요구사항을 기술, 비용, 일정 및 리스크 제약사항 내에서 솔루션 영역을 제시하도록 요구하고 있는가

임무 및 운용분석 수행, 사용자와 실무현장 인터뷰, 기존의 시스템 문제 보고서 분석, 운용환경을 이해하고 작동하는 사람과 위협을 이해하라

2. 개체 요구사항을 생성하고 표현
만약 개체의 품목개발 규격 요구사항이 정의되지 않았다면, 개체의 상위 레벨 요구사항을  생성, 할당 및 분할할 필요가 있다. 개체 요구 능력과 이와 연관된 성능레벨을 운용, 물리적, 설계, 생산 제약사항 관련 문서와 같이 정확, 간결, 일관 및 완전하게 나타내어야 한다. 규격 요구사항 우선순위를 설정하기 위해 요구사항 이해관계자와 함께 작업하라.
개체 요구사항이 생성됨에 따라 개체 운용 요구 능력과 특성을 개체 구조 내에서 개별 요구사항을 표현하도록 하라. 각 요구사항은 다음과 같이 무엇을 기술하고 있는지 나타내라.

· 무슨 활동이 수행되어야 하는가.
· 누가 무슨 메커니즘으로 그 활동을 수행하도록 해야 하는가
· 언제 그 활동이 수행되어야 하는가
· 그 활동이 얼마나 잘 수행되어야 하는가
· 어떤 운용 시나리오와 상태 아래서 수행되는가
· 그 활동으로부터 어떤 산출물과 결과를 기대하고 있는가

최종적으로 각 요구사항의 타당성 검토를 해 보라. 우리는 이를 어떻게 하고 있는가? 미니 검증 계획을 형성해 보라. 그 요구사항이 주어진 예산, 일정, 설비, 시험환경 제약사항 내에서 할당된 자원 제약 하에 측정, 시험 및 실제로 달성 가능한지를 확인하기 위해 하나 또는 둘 이상의 검증 문장을 작성해 보라.

3. 개체 규격 요구사항을 분석하고 종합
개체 요구사항이 설정됨에 따라 다음 사항에 대한 이해 여부를 확인하기 위하여 요구사항을 분석하라.

· 납품 시스템, 제품 또는 서비스에 대하여 어떤 능력을 요구하고 있는가
· 그 능력을 표현하기 위한 성능레벨
· 물리적 특성-크기, 중량, 신뢰성
· 설계 및 생산 제약사항이 그러한 능력에 부과되고 있는가
· 각 능력 달성여부를 검증하기 위하여 요구되는 검증방법은 무엇인가

가끔 규격에는 누락, 중복 또는 마찰되거나 잘 못 놓인 요구사항을 포함하고 있기 때문에 요구분석을 통해 이와 같은 결함, 쟁점사항, 고려사항을 발견, 명확 또는 해결하도록 해야 한다. 예제로서의 연관 제품은 개체 운용, 거동 및 물리적 도메인 솔루션 개발을 지원하기에 필요 충분한 규격 요구사항이어야 한다.

4. 개체 능력을 생성하고 작성
이상적으로 공식적인 사업제안서(RFP) 요청 시, 초기 시스템 요구문서(SRD), 시스템 성능 규격(SPS) 및 개체 품목 개발규격은 요구사항 문장으로 요구된 제안 솔루션 능력을 식별하고 외형적으로 표현한다. 일반적으로 요구사항과 요구능력 사이에 일대일 연계가 되어야 한다. 가장 좋은 사례는 그림 1에서와 같이 하나의 능력에 대하여 오직 한 가지 요구사항으로 요구규격으로 기술되는 것이 바람직하다.

그림 1. 요구사항 도출 능력

요구사할 생성을 위한 보다 많은 정보는 앞서 제시한 요구사항 작성 실무를 참조한다.
실제 시스템 개발에 있어서는 항상 이와 같은 과정으로 수행되지는 않는다. 규격 개발자가 복합 요구사항에 대한 다중 문장으로 구성된 요구사항을 작성할 때, 시스템 엔지니어가 요구능력을 도출해야만 한다. 가끔 이러한 과정이 쉽지만 그렇지 않은 경우도 있다.
만약 당신이 임의로 작성된 형상 위주의 규격서를 접할 경우, 그림 1에 나타난 방법에 따라 능력 세트를 도출해야 한다. 그리고 그 능력을 역으로 규격 요구사항으로 연결하게 된다. 물리적인 연결은 스프레드시트나 또는 연관 데이터베이스에 기초한 객체지향(OO) 요구사항 추적 도표를 사용하여 수행할 수 있다. 보다 많은 형상 위주 규격에 대해서는 규격개발 실무를 참조한다.
이러한 일이 어떻게 수행되는지를 알아보려면 그림 2에 나타난 도표를 사용토록 하라. 좌측은 참조 식별자(REQ_ID), 규격 문장 번호, 요구사항 내용을 포함한 도표로 나타낸 규격 요구사항 목록을 포함하고 있다. 이상적으로 규격 요구사항은 오직 하나의 운용 또는 기능 능력을 나타낸 단일 요구사항 문장으로 작성된다.
우리는 그림 2의 오른쪽에 나타낸 단일 및 복합 요구사항을 포함하고 있는 요구사항 문장으로부터 개별 능력을 도출할 수 있다.

그림 2. 규격 요구사항으로부터 FCI 도출

그 능력은 능력 계층구조로 나타내며, 각 능력은 적용되고 있는 규격 요구사항으로 연결될 수 있다.

5. 요구사항 쟁점사항 해결과 명료화
다중레벨 의사결정은 상위레벨에서의 쟁점사항이 보다 빨리 해결될 것을 요구하고 있다.

· 요구사항 세트에 대한 정확성, 일관성, 완전성과 다른 요구사항 세트와의 인터페이스를 점검하라.
· 어떠한 치명적인 쟁점사항(COI) 또는 주요 기술 쟁점사항(CTI)을 해결토록 하라.
· 누락, 마찰, 중복, 오해 또는 복합 요구사항을 해결토록 하라.
· 각 요구사항이 개체에 적용되고 있음을 검증하라. 만약 아니라면, 이를 적합한 개체의 품목 개발 규격에 위치토록 하라.
· 상응되지 않거나 별로 가치가 없는 요구사항은 제거토록 하라. 모호한 요구사항을 명확히 하도록 하라.
· 각 요구사항이 실제적이고, 달성 가능하며, 측정 가능하고 시험 및 검증 가능한지 여부를 검증토록 하라.

6. 요구사항 솔루션 검증과 확인
요구 도메인 솔루션 개발을 통해 당신은 지속적으로 다음 사항을 검증토록 해야 한다.

사용자 소스와 계약문서에 대한 SPS 또는 품목개발 규격 요구사항의 통합
개별 요구사항이 계약이나 업무 범위에 적합하게 상응되고 있는지 여부
개별 요구사항이 기술, 비용, 일정, 및 리스크 제약사항 내에서 달성 여부
모든 요구사항 쟁점 및 관심사항이 모든 이해관계에 만족하게 해결되었는지 여부
운용, 거동 및 물리적 도메인 솔루션으로 진화되어 가면서 요구 도메인 솔루션과 완전하게 일치하고 있는지를 추적

요구 도메인 솔루션은 사용자 및 기타 주요 이해관계자와의 기술교류회의(TIM), 인터뷰, 데모, 신속 생산, 모델링, 시뮬레이션을 통해 확인되어야 한다.
요구 도메인 솔루션이 성숙해짐에 따라 시스템 요구 검토(SRR), 하드웨어 규격 검토(HSR), 소프트웨어 규격 검토(HSR), 공정간 검토(IPR)와 같은 기술 검토가 수행되어야 한다. 이러한 이벤트는 요구 도메인 솔루션에 대한 주요 이해관계자로부터 동의가 이루어지도록 상호 협의해야 한다. 보다 많은 정보를 위해 다음 기술 검토 실무를 참조토록 하라.

7. 요구사항 솔루션 베이스라인 설정과 유지
한 번 요구 도메인 솔루션이 승인되고 나면, 하위레벨 요구사항 할당, 미래 의사결정, 요구사항 변경 통제를 위해 시스템 요구사항 베이스라인과 같은 개체 요구사항 기준을 설정해야 한다. 각 개체 요구사항 기준과 진화되고 있는 개발 형상과 비교 검토하라. 이러한 방법을 사용하여 요구 도메인 솔루션 변경사항을 식별하도록 하자.

‌요구사항 도출 프로세스

다양한 여러 레벨에서의 시스템 품목에 대한 요구사항 식별과 도출은 단순히 텍스트를 기술한 문서 그 이상을 요구한다. 그 프로세스는 수많은 제약사항을 고려하고, 조종하며, 조화를 이루어야 하는 고도로 반복적이고 골몰하게 생각해야 하는 환경 속에서 이루어진다. 이러한 프로세스를 기술하기 위해 가장 좋은 방법은 그림 3과 같은 그래픽에 제시된 환경을 활용하는 것이 바람직하다.

그림 3. 요구사항 도출 프로세스 환경

그림 3에 나타난 프로세스를 보다 구체적으로 설명해 보자.

1. 요구사항 도출과 시스템 엔지니어링 프로세스
요구사항 도출과 식별을 위한 구심점은 그림 3의 중앙에 그려진 SE 프로세스 모델이다. SE 프로세스 모델이 추상적 레벨과 속성에 적용됨에 따라 요구사항이 할당되고 상위레벨 규격으로부터 하위레벨 품목 개발규격(IDS: Item Development Specification)으로 분할된다. 다중 레벨의 시스템 솔루션이 진화함에 따라 요구사항도 함께 할당되고 하위레벨 IDS로 분할된다.
이때 의사결정 지원 프로세스가 SE 프로세스 모델에 함께 적용된다. 요구사항 도출과 연계된 기술에 대한 의사결정은 심층 분석과 함께 절충연구 수행을 요구하고 있다. 의사결정 지원 분석과 절충연구를 종료하기 위하여 최종적인 의사결정에 도움을 제공하는 시제품, 모델 및 모의활동이 요구된다. 

2. 기타 프로세스와의 관계 및 인터페이스
그림 3의 상단에 그려진 요구사항 도출 프로세스는 SE 프로세스 모델 내에서의 ‘요구사항 도메인 솔루션 개발’의 한 부분이다.
단순한 순차적인 의사결정 단계 이상의 요구사항 도출 프로세스는 ‘구름형상’으로 표시된 바와 같이, 다음과 같은 SE 프로세스 활동과 함께 고도의 반복적인 인터페이스 특성으로 나타난다.

· 실체의 문제점과 솔루션 영역을 숙지
· 실체의 운용 도메인 솔루션을 개발
· 실체의 거동, 기능적 도메인 솔루션을 개발
· 실체의 물리적 도메인 솔루션을 개발

품목의 문제점 영역과 솔루션 영역을 숙지하는 활동에 있어서 요구사항 개발자가 다음 사항을 철저하게 이해할 것을 요구하고 있다.

· 요구사항이 개발되어야 할 시스템 또는 품목이 주어진 솔루션 영역을 어떻게 나타내려고 하는지를 이해한다.
· 솔루션 영역이 상위레벨 문제점 영역과 어떻게 연계되어 있는지를 이해한다.

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

3. 고객 요구사항과 예산 가능 금액 조정
상위레벨 규격서로부터 요구사항을 분할하는 것은 획득자 또는 상위레벨 시스템 개발팀이 무엇을 원하는지를 나타내는 것이다. 요구사항 도출 프로세스는 그림 4에서와 같이 사용자가 원하는 것과 필요로 하는 것, 얼마나 예산이 가용한지와 기꺼이 지급하고자 하는 금액이 얼마인지를 조정해야 한다.

그림 4. 고객 요구 변화

이와 같은 콘텍스트를 통해 시스템 실체에 대한 솔루션 영역에서 궁극적으로 무엇을 요구하고 있는지를 이해하게 된다.

· 사용자가 시스템 실체를 통해 사용하려고 하는 방법
· 사용자가 원하는 것, 사용자가 필요로 하는 것, 사용자의 가용 예산 및 사용자의 실제 지급 금액과 연관된 시스템 실체의 운용 효과, 유틸리티, 적합성을 제시하려는 방법

4. 개별 요구사항에 대한 의도와 의미 숙지
상위레벨 규격의 요구사항이 시스템 실체로 분할 및 할당됨에 따라, 시스템 엔지니어링은 개별 요구사항을 시스템 실체의 솔루션 영역으로 나타내기 위한 관계와 연관성을 이해하기 위하여 분석을 수행해야 한다. 정의에 의하면, 개별 요구사항은 시스템 품목의 능력과 성과레벨을 식별하고, 규정하며, 범위를 나타내는 것이다. 다음과 같은 사항을 분석해야 한다.

· 이 요구사항을 충족하기 위해 달성해야 할 결과물이 무엇인지?
· 원하는 결과물을 달성하기 위해 언제 그 능력이 제공되어야 하는지?
· 각 요구능력이 얼마나 잘 수행되어야 하는지?
· 어떠한 시나리오와 조건아래 각 성능이 수행되어야 하는지?
· 이 능력과 다른 사항과의 관계는 무엇인지?

이러한 질문에 대한 답은 해당 품목의 운용개념(ConOps: Concept of Operations), 품목의 모드와 상태, 품목의 거동과 논리적 솔루션 및 품목의 물리적 솔루션과 같은 예비적인 그래픽과 텍스트를 통해 조화롭게 진화해 간다. 이러한 분석방법은 도메인의 범주와 요구사항의 콘텍스트에 대한 다양한 관점을 살펴볼 수 있는 요구사항을 도출하기 위한 시스템 엔지니어링 활동을 나타내고 있다.

5. 소결론
우리가 살펴본 바와 같이, 요구사항을 도출하는 활동은 전 프로세스의 일부에 속한다. 다른 부분은 다음과 같은 사항을 수행할 수 있는 능력과 성능레벨을 기술하는 요구사항을 개발하는 것이다.

· 적용하는 사람으로 하여금 쉽게 이해하고 서로 소통 가능
· 상위레벨 소스 요구사항을 추적 가능
· 물리적으로 검증 가능

이와 같이 사전에 정의된 ‘사용 적합성’에 대한 요구사항 평가기준이 요구사항 추적에 대한 통합성을 유지하는 것과 마찬가지로 품질 레벨을 확인하기 위해 설정되어야 한다. 요구사항 도출이 의사결정 체인으로 주어질 경우, 모(母) 요구사항 도출에 대한 통합성과 품질에 의존한 요구사항 추적은 시스템 통합성을 확인하는 첩경이다. 이와 같이 기본적인 요구사항 도출 환경 이해를 기반으로 다음 요구사항 도출방법론을 논의하도록 하자.

 ‌

요구사항 도출 방법

요구사항을 도출함에 있어서 반복적이고 예측 가능한 결과를 가져오기 위해 쉽게 소통할 수 있는 방법론이 필요하다. 방법론을 이해하기 위해 프로세스와 연관된 환경을 이해토록 하자.

1. 도출 패러다임
추상적인 의미에서의 요구사항 도출은 일상생활에서 사용되는 어휘 중의 하나다. 그러나 요구사항을 도출하기 위해 무엇이 필요한지를 아는 엔지니어는 그리 많지 않다. 이와 같은 사실을 입증하는 내용으로서 다양한 레벨에서 주어지는 규격을 한 예로 들 수 있다. 
문제는 이를 알고도 신입사원에게 근원적인 내용을 교육하지 않고 있다는 사실이다. 아이러니하게도 수많은 사람들은 그 어휘가 무엇을 뜻하는지를 이해하지 않고 시스템 엔지니어링 용어를 동료들에게 나타내기 위해 전문용어 사용을 과시하고 있다는 사실이다.
시스템 엔지니어링에서 요구사항 도출은 추상적인 모(母) 요구사항을 하위레벨, 목표와 성과 중심의 자(子) 요구사항 세트로 기술하는 것을 말한다. 이때 모든 자(子) 요구사항을 통합하면 모(母) 요구사항을 충족해야 한다.

2. 요구사항 도출 방법
요구사항 도출의 한 가지 접근방법은 경험과 관찰을 바탕으로 한 일련의 질문을 통해 수행하는 방법이 있다. 이러한 질문사항의 목적은 요구사항 도출방법으로 사용될 주요 요소를 식별함에 있다. 당신의 특정 비즈니스 요구와 적용에 따라 이 방법론을 읽어보고, 숙지하며, 테일러링 및 적용하라. 이러한 방법론을 단계적으로 제시하면 다음과 같다.
1단계: 요구사항 분석(1)
2단계: 결과물 식별(2)-거동, 산출물, 부산물 및 서비스
3단계: 능력, 결과물로부터 획득된 거동 반응과 성능 (3)
4단계: ‌시나리오와 조건을 나타내는 운용 능력 식별과 범위 설정(4)
5단계: 성능 능력레벨을 제시(5)
6단계: 요구사항 기술(6)
7단계: 요구사항에 대한 검증방법 식별(7)
8단계; 요구사항 확인(8)
9단계; 요구사항 일치 여부 검증(9)
10단계: 다음 요구사항으로 전이(10)
그림 5는 이러한 단계를 그래픽으로 제시하고 있다.

그림 5. 성과 요구사항 ID와 도출

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