[시스템 거동 도메인 개발 1] 거동 도메인 솔루션 개발 목표
[시스템 거동 도메인 개발 2] 거동 도메인 기능 분석과 할당
[시스템 거동 도메인 개발 3] 거동 도메인 기능 분석과 할당 프로세스 주요 단계

기능 분석과 할당

기능은 요망하는 성과를 달성하기 위하여 반드시 수행해야 하는 특성을 나타내는 업무, 행위, 또는 활동으로서 요구하는 시스템 거동(system behavior)을 말한다. 이러한 기능은 장비(하드웨어), 소프트웨어, 펌웨어, 설비, 요원 그리고 절차상의 자료 등으로 구성되는 하나 또는 그 이상의 시스템 요소에 의해 달성되며 기능 분석/할당(functional analysis/allocation)의 범위는 다음과 같이 정의된다.

(1) 기능 분석/할당은 기능 달성에 필요한 모든 하부 기능을 식별하기 위해 정의된 기능에 대하여 검사하는 것이다. 하부 기능은 그들 관계와 (내부 및 외부)인터페이스를 나타내기 위하여 기능아키텍처 내에서 배열된다. 상위레벨 성능 요구사항은 하위레벨 하부 기능으로 하향 세분화되며 할당된다.     

(2) 이 활동은 설계 대상 시스템 제품과 프로세스에 대한 기능아키텍처를 정의하고 통합하기 위해 수행된다. 기능 분석/할당은 요구되는 조합 결과를 지원하는데 필요한 레벨까지 반드시 수행되어야 한다. 식별된 기능 요구사항은 모 요구사항을 달성하기 위해 요구되는 하부레벨 기능을 결정하기 위해 분석되어야 한다. 모든 사용모델은 기능 분석에 포함되어야 한다. 기능 분석은 하위레벨 기능 요구사항이 상위레벨 요구사항의 일부로서 인지되도록 배열되어야 한다. 기능 요구사항은 논리적 순서로 배열되며, 입력, 출력 그리고 정의된 (내부 및 외부) 기능 인터페이스 요구사항을 갖고 시작부터 마지막 조건까지 추적될 수 있어야 한다. 또한, 시간에 민감한 요구사항(time critical requirements)을 분석해야 한다.

(3) 성능 요구사항은 각 기능 요구사항과 인터페이스에 대하여 최상위레벨부터 최하위레벨까지 연속적으로 설정되어야 한다. 하나의 기능 또는 일련의 기능에 대하여 형성된 필수인 시간 요구사항을 결정하여 할당해야 한다. 결과적인 요구사항 집합은 설계 판단기준으로 사용하기 위해 측정 가능한 용어로 충분히 상세하게 정의되어야 한다. 성능 요구사항은 할당에 의한 분석을 통하여 현 기능아키텍처의 최하위레벨부터 지원하고자 하는 최상위레벨 요구사항까지 추적이 가능해야 한다.      

(4) 기능 분석/할당은 다음 사항을 위해 반복적으로 수행되어야 한다.
· 상위레벨 기능 요구사항을 충족시키는 하위레벨 기능의 연속적 정의 및 기능 요구사항 대안의 정의
· 성능 주도의 임무와 환경을 정의하고 상위레벨 요구사항의 만족 여부를 결정하기 위한 요구사항 분석
· 성능 요구사항과 설계 제약사항의 하향 세분화
· 제품과 프로세스 솔루션의 정의를 정제하기 위한 설계조합

(5) 절충연구는 다음 사항을 위하여 기능 내 또는 기능 간에 수행되어한다.
· 기능 분석과 성능 요구사항의 할당 지원
· 식별된 기능 인터페이스를 만족하는 성능 요구사항의 결정
· 상위레벨 성능과 기능 요구사항이 하위레벨로 쉽게 분해되지 않는 하위레벨 기능 성능 요구사항의 결정
· 기능아키텍처의 대안에 대한 평가

기능아키텍처는 기능의 계층화된 배열, 그들의 내부 및 외부 (그 집합체 자체에 대한 외부) 기능인터페이스와 외부 물리인터페이스, 각각의 기능과 성능 요구사항, 그리고 설계 제약사항으로 정의된다. 시스템 엔지니어링 프로세스의 초기단계로서 기능 분석/할당은 기능과 하부 기능의 기준(baseline) 그리고 분해된 성능 요구사항의 할당으로 정의된다.

생산, 배치, 로지스틱스 지원 그리고 운영 등을 포함한 시스템 기능의 모든 측면에서 다루어져야 한다. 기능 분석과 분해는 시스템아키텍처와 독립적으로 수행될 수 있으나, 기능할당은 명확하게 시스템아키텍처 구조를 필요로 한다. 기능 요구사항은 시스템 요소에 대한 선정과 설계기준에 대하여 공통 기반을 제공하며, 입력 요구사항과 엔지니어링 개발 사이의 심도 깊은 절충이 고려되어야 할 분야를 식별하도록 한다.

시스템 엔지니어링 프로세스 흐름에서, 대안설정(candi-date implementation)은 기능 분석/할당 다음에 이루어지는 시스템조합 단계에서 개발된다. 독립적인 기능 분석과 분해는 조합이 시작되기 전에 기능 요구가 보다 잘 이해되기 때문에 때때로 창의적인 수행 접근방법을 이끌어 낸다. 기능분해의 여러 단계 후, 평가에 대해 하나 또는 그 이상의 후보아키텍처를 정의하기 위하여 조합프로세스를 시작하는 것이 적합하다. 

기능은 여러 대안방법으로 분해된다. 어떤 방법은 논리적일 수 있고, 그렇지 않을 수도 있다. 어떤 대안은 더 많은 분해가 가능하지만, 그렇지 않을 수도 있다. 어떤 대안은 경제적인 구현이 가능하지만 더 복잡해질 수도 있다. 이러한 이유 때문에, 시스템 엔지니어는 절충연구를 통해 희망하는 기능아키텍처를 비교 평가할 필요가 있다.

예를 들어, COTS(Commercial Off-the-Shelf) 제품을 많이 사용하는 강한 경향이 있다. 또는 기존에 존재하는 소프트웨어 코드 모듈 또는 NDE(Non- Developmental Equipment)를 재사용하기 위한 요구사항이 있을 수도 있다. 시스템 엔지니어는 기능아키텍처가 개발될 때 또는 하드웨어나 소프트웨어 아키텍처 그 결과로 결론 나지 않을 때 제약사항을 깨달아야 한다. 절충활동은 시스템 엔지니어가 여러 설계제약을 해결하도록 도와주는 기능 분석/할당 수단이다.

1. 기능 분석/할당의 목적
기능 분석/할당(Functional Analysis/Allocation) 업무의 목적은 하드웨어/소프트웨어와 운용(즉, 요원)에 대한 기능과 하부기능의 할당을 통하여 시스템아키텍처를 정의하는데 기초가 되는 기능아키텍처를 만들어 내는 것이다. 기능아키텍처는 분해된 기능의 계층구조와 계층구조 내의 기능에 성능 요구사항을 할당하는 내용만을 기술하고 있다. 이것이 시스템의 하드웨어아키텍처나 소프트웨어아키텍처를 기술하고 있는 것은 아니다. 이들 아키텍처는 시스템 엔지니어링 프로세스의 시스템조합 단계에서 개발된다.

기능 분석/할당은 시스템이 무엇을 할 것인가(what)에 대하여 기술하는 것이지 어떻게(how) 해야 하는지를 기술하는 것은 아니다. 운용 요구사항의 충족을 위하여 시스템에 의해 이루어져야 하는 모든 기능은 할당된 기능, 성능, 그리고 기타 제한 요구사항의 관점에서 식별되고 정의되어야 한다. 

그다음, 각 기능은 하부기능으로 분해되며, 기능으로 할당된 요구사항들은 각각 기능과 함께 분해된다. 이 프로세스는 시스템이 완전하게 기본 하부기능으로 분해되고, 최하위레벨의 각 하부기능이 주어진 요구사항에 대해 완전하고, 간단하며, 명확하게 하나의 의미를 가질 때까지 반복된다. 이 프로세스에 있어서, 각각의 기능과 하부기능 사이의 인터페이스는 외부시스템에 대한 인터페이스로 완전하게 정의되어야 한다.

기능 분석/할당 업무는 기능아키텍처 개발뿐만 아니라 다음과 같은 부가적인 기능을 수행한다. 부가적인 기능에는 누락된 기능 요구사항의 식별, 도출 요구사항의 개발, 그리고 비현실적 또는 모호하게 기술된 요구사항의 식별 등이 포함된다.  

기능 분석/할당은 기능영역, 순서 및 인터페이스를 정의하는 데 있어 임무와 운영개념 분석을 지원한다. 또한, 기능 분석/할당은 시스템을 완성, 시험 및 배치하기 위하여 장비, 소프트웨어, 요원, 설비 및 운용 절차에 대한 도출 요구사항을 개발하기 위하여 엔지니어링 전문가와 지원조직에 의하여 수행된다.

2. 입력 판단기준
시스템에 대해 많이 알면 알수록 보다 좋은 시스템이 만들어진다. 이상적이라면, 기능 분석/할당은 모든 시스템 요구사항이 완전히 식별된 후에만 시작되어야 한다. 이는 요구사항 분석이 기능 분석/할당을 시작하기 전에 완료되어야 한다는 것을 의미한다. 물론, 이는 가끔 가능하지 않는 경우가 있다. 그리고 이 업무는 시스템 요구사항이 진화됨에 따라 보다 구체적으로 정의되는 기능아키텍처를 가지고 반복적으로 이루어져야 한다. 

요구사항 분석 업무의 산출물이 완전하지 않을 수도 있다. 또한, 생략된 표현이 잘 이해될 수도 있지만, 전혀 이해되지 못할 수도 있다. 기능 분석/할당 업무는 누락된 요구사항을 알 수 있도록 도와주며, 다른 요구사항을 보다 세분화하고 명확하게 하는데 도움이 되어야 한다. 사용자/고객 또는 프로그램 관리자로부터의 대표적인 입력은 다음과 같다.

· 고객요구, 목적 및 요구사항
· 기술기반
· 프로그램 의사결정 요구사항(어떠한 하드웨어와 소프트웨어를 재사용하는 목적 등)
· 규격서와 표준 요구사항
· 운용개념 

요구사항 분석, 기능 분석/할당, 시스템아키텍처 조합, 그리고 시스템 분석 및 통제 등과 같은 시스템엔지니어링 프로세스는 시스템 수명주기 동안에 걸쳐 반복적으로 여러 번  수행된다. 이것은 시스템설계 동안 구체적인 다양한 레벨을 포함한다. 이것은 초기 개념개발 동안에 수행되며 시스템 조달기간 중 순환되기도 한다. 

또한, 부문으로부터 형상품목 레벨 아래까지 반복된다. 이러한 이유 때문에, 기능 분석/할당 프로세스를 시작하고 종료하기 위해 필수적으로 인용할 수 있는 단일 요구사항 문서는 없다. 최상위레벨에서는 시스템레벨 규격서가 바람직하다. 하위레벨에서는 부문레벨 규격서, 형상품목 또는 컴퓨터 소프트웨어 형상품목 규격서이면 충분하다.

하위레벨에 대한 시스템 요구사항의 하향 세분화(flow down)는 임무영역 분석과 시스템레벨의 기능흐름도(FFD: Functional Flow Diagrams)에 기반을 두고 있다. 초기 소스 요구사항은 고객에 의해 결정된다. 만약 미국 정부라면, 그 소스는 JMSNS(Justification for Major System New Start), SON(Statement of Need), PMD(Program Management Directive) 또는 대통령, 의회로부터 승인을 얻은 미국정부 또는 국방 상위부서에서 승인된 유사문서로 거슬러 올라간다. 

JMSNS 또는 그와 동등한 문서는 임무요구를 정의하고, 경계조건을 식별하며, 초기 획득전략에 대한 윤곽을 만들어 낸다. JMSNS 또는 그와 동등한 문서는 개념탐색(CE: Concept Exploration)단계에서 이루어지는 정부/고객 임무영역 연구를 통하여 만들어진다.

만약 고객이 민간 또는 상업적 분야일 경우에도 임무 요구사항을 개발하는 프로세스는 비슷하다. 새로운 능력 또는 시스템에 대한 요구사항을 고려하고 있는 실체(entity)는 “시장성이 있는가?”라는 질문에서 비롯된다. 이 제품은 실체가 시장점유율을 향상시키기 위해 또는 사업을 유지하기 위해 설정되는 전략을 만족할 수 있는지 물어보아야 한다. 만일 그 대답이 긍정적이라면, 그 실체는 단골손님, 잠재적 고객 또는 시장조사가 제공하는 요구사항을 고려하여 시작하게 된다. 이것은 분석, 절충연구, 그리고 개념개발 및 시제 제조활동을 통해 만들어 지는 최종 요구사항을 결정하기 위한 단계를 설정한다. 

정부가 주관하는 시스템에 대하여, 이들 요구사항은 종종 제안요구서(RFP: Request for Proposal)의 기초가 되는 시스템요구서로 요약된다. 개념탐색과 프로그램 정의 단계 동안에, 이 문서에 대한 요구사항은 시스템 엔지니어링 프로세스를 통하여 보다 세부적으로 분석되고 시스템 규격서(미국 국방성 A형)로 통합되며 하위레벨 개발규격서(미 국방성 B형)로 하향세분화 분석된다.

민수 분야는 기능과 성능 요구사항을 획득하기 위한 뚜렷한 기본절차와 구조는 없지만, 이러한 세부항목을 제공하는 문서와 계획을 수립하는 형태가 있을 수 있다. 이 문서와 계획은 분석을 달성하는데 필요한 자금과 자원을 확보하고 시스템개발의 다음 단계로 진행토록 하는데 필수적인 요소이다.

3. 출력 판단기준
성공적으로 기능 분석/할당 활동을 종료한다는 것은 곧 시스템 엔지니어링 프로세스의 시스템조합 단계의 시작을 의미한다. 기능 분석/할당 활동의 완료에 대한 최종 판단기준은 완전한 문제정의에 달려 있다. 이것은 임무에 의해 수행될 그 기능이 식별되고 기능이 얼마나 잘 수행되어야 하는 가에 대한 요구사항 정의프로세스이다. 

산출물(output product)은 임무요구와 앞에서 논의되었던 시스템 요구사항을 만족시키기 위해 수행되어야 하는 기능순서와 관련이 있다. 이들은 성공적인 임무수행을 위해 시간과 관계로 나타내어야 한다. 이러한 기능이 얼마나 잘 수행되어야 하는지를 명시하는 성능과 품질 요구사항은 고객사회 또는 법적 요구사항에 의해 시스템에 주어지는 임무요구와 제약사항뿐만 아니라 시스템 요구사항에 대한 추적성이 보장되어야 한다.
기능 분석/할당 작업의 산출물은 프로세스 특정 단계와 기능아키텍처를 개발하는 데 사용되는 특정기술에 따라 선택되는 다음과 같은 다양한 형식이 있다.

· 거동도(Behavior Diagrams) : 거동도는 시간시퀀스, 동시성, 조건, 동기점, 상태정보 및 성능구조를 사용하여 시스템레벨의 반응을 구체화한 거동으로 기술한다. 이 표기는 시스템의 데이터 흐름, 상태 전이그리고 상태 머신 특성에 대한 구조를 제공한다.

· 콘텍스트도(Context Diagrams) : 특정 레벨의 시스템 분해와 관련된 데이터 흐름도(DFD: Data Flow Diagram)의 최상위레벨 그림을 나타낸다. 이 그림은 시스템의 모든 입력과 출력을 표현하지만 어떠한 분해도 나타내지 않는다. 

· 통제흐름도(Control Flow Diagrams) : 시스템 또는 소프트웨어 프로그램에 의해 실행되는 가능한 모든 운용순서를 묘사한 그림을 나타낸다. 여기에는 박스도(box diagrams), 흐름도표, 입력-프로세스-출력(IPO)도표, 상태전이도를 포함한 여러 가지 형태의 통제흐름도가 있다.

· 데이터 흐름도(Data Flow Diagrams) : 데이터 흐름도는 시스템이 수행해야 할 각각의 거동에 대한 상호연결을 제공한다. 거동 지정자(behavior designator)에 대한 모든 입력과 생성되어야만 하는 모든 출력은 각각 접근해야 하는 자료저장소와 함께 식별된다. 각각의 데이터 흐름도는 콘텍스트도 또는 상위레벨 데이터 흐름도와의 일치성을 검증하기 위해 대조된다. 

· 데이터 종합목록(Data Dictionaries) : 특정레벨의 시스템 분해에 대한 데이터 흐름도 내에서 찾게 되는 데이터 흐름, 데이터 요소, 파일, 데이터베이스 및 프로세스의 정의에 대한 표준을 제공하는 문서로, 개발 조직 간의 의사소통에 도움이 된다. 

· 상태전이도(State Transition Diagrams) : 시스템이 한 상태에서 다른 상태로 전이해 가는 방법과 가능한 상태를 보여주는 그림으로, 사용되는 기호는 시스템 상태를 나타내는 원과 한 상태에서 다른 상태로 어떻게 변화하는지를 나타내는 선분(line segments)으로 이루어진다. 

· 실체 관계도(Entity Relationship Diagrams) : 실체 관계도는 실체(기능 또는 아키텍처 요소)의 집합과 이들 사이의 논리적 관계를 묘사한다. 실체의 속성도 함께 나타낼 수 있다.
· 기능 블록선도(Functional Block Diagrams) : 기능 블록선도는 시스템에 의해 서로 수행되는 거동(behaviors)에 관련된 그림으로 입력과 출력을 나타내며 시스템 기능 사이의 흐름에 대한 통찰을 제공한다. 

  
· 모델(Models) : 시뮬레이션을 포함한 모델은 이해, 의사소통, 설계 및 평가의 수단으로 사용되는 시스템의 관계특성에 대한 추상적 개념이다. 모델은 시스템이 만들어지기 전에 사용되는 반면, 시험 또는 사용 중에 사용되기도 한다. 좋은 모델은 실제 나타나는 시스템/상황과 일치되는 필수 특성을 지니고 있다. 나타나는 특성의 본질이 곧, 모델사용 여부를 결정한다. 모델은 기능적, 물리적, 그리고/또는 수학적으로 표현할 수 있다. 

· 타이밍 분석(Timing Analysis) : 타이밍 분석결과는 필요한 다음 기능에 입력을 제공하는 기능을 동시적으로 수행하는데 필요한 시간분석 결과이다. 기능의 동시성을 고려해야할 때 시스템이 원하는 출력거동을 달성하기 위해 요구되는 시간평가를 제시하라.
· 시뮬레이션(Simulation) : 시뮬레이션 결과는 통제된 입력을 제공하여 관심 대상 시스템처럼 동작하거나 운용할 때 시스템 모델로부터 얻어지는 출력이다. 

· 기능/동시적 스레드 분석(Functional and Concurrent Thread Analysis) : 기능/동시적 스레드 분석결과는 시스템 목적을 위해 함께 동작하는 기능의 특정한 순서를 나타내는 시스템 또는 모델의 출력사항을 나타낸다. 시스템의 전반적인 거동은 초기조건, 환경 그리고 통제(모드) 파라미터에 대하여 시간에 따라 반응하는 모든 스레드를 말한다.

· IDEF도(IDEF Diagrams) : IDEF도는 순차적 입력과 출력흐름에 의해 기능 간의 관계를 보여주는 프로세스 통제도이다. 프로세스 통제는 표현된 각 기능의 상부로부터 입력되고 아래로 들어가는 선은 기능에 의해 요구되는 지원 메커니즘을 나타낸다. IDEF는 통합정의(Integrated DEFinition)에 대한 두문자어(acronym)이다. 이것은 ICAM (Integrated Computer- Aided Manufactur-ing)이 통합 컴퓨터 지원 제조를 의미하는 곳에서 ICAM DEFinition의 의미로 사용되기도 한다.

이들 다양한 산출물은 기능아키텍처를 특성화한 것이다. 이러한 분석을 통하여 지원할 수 있는 산출물은 없다. 많은 경우, 다양한 산출물은 기능아키텍처 및 향후 시스템아키텍처 조합 내에 내재되어 있는 위험을 이해하는데 필수적이다. 하나 이상의 이러한 형식을 사용하는 이유는 분석프로세스의 점검과 균형(check and balance)을 가능하게 하며 시스템설계 팀 상호간의 의사소통에 도움을 주기 위함이다.

민성기 원장 _ 시스템체계공학원