소개
불가피하게 시스템 개발과 연관되는 요구사항 계층 구조가 생깁니다. 이 계층 구조는 시스템에 대한 사용자 목적이나 목표 요약 또는 미션을 정의하는 가장 덜 세부적인 층으로부터 아래로 내려가서 몇 개의 중간 레벨을
거쳐 가장 세부적인 층으로 이루어집니다. 가장 세부적인 레벨에서는 시스템에 사용되는 기술의 용어로 한층 더 자세히 요구사항을 표현할 수 있습니다. 반면 최상위 레벨에서는 일반적으로 시스템에서 제공되는 도메인 언어를
사용하여 기능, 서비스, 동적, 함수, 특징 등으로(임의로 단어 선택) 더 추상적으로 표현됩니다. 다른 의미가 이 단어에 속해 있다고 생각하여 표현되는 것을 한층 더 명확하게 할 수 있는 것은 분명히
가능하지만(예: 시스템의 특정 동작에 대한 설명이 목적이나 의도를 잘 보여주지 못하므로 다른 설명 유형이 필요함) 여기에 목적이 있는 것은 아닙니다.
요구사항 정제(최상위 레벨로부터 정밀도를 더 추가)은 기능적 방식으로 순수하게(아키텍처 실현에 관여하지 않고 기능을 하위 기능이나 이 기능을 지원하는 서브타스크로 분할하여) 진행할 수 있습니다. 그리고
설명된 사항이 시스템 내에서 깊이 위치되어 시스템 외부와의 직접 통신이 없는 레벨(시스템이 생성된)로 이동할 수 있습니다. 이는 예를 들어, 가능한 한 깊게 원시 변환 버블로 이동된 구조화된 분석 접근
방식에서의 사례입니다.
이 접근 방식은 무모합니다. 첫 번째로, 전혀 요구사항 아닌 것(단지 분해의 중간 산출물)을 요구사항으로 식별하기 때문입니다. 두 번째는 디자이너가 실현(realization)을 매우 근접하게 분해에 맵핑할 경우
잘못된 아키텍처가 생성될 수 있기 때문입니다(예: 다른 비기능적 요구사항을 충족시키지 못하거나 이에 대해 제대로 수행되지 않음). 그러나 분해 깊이를 인식할 수 있는 기능으로 제한하면서(즉, 이해
당사자(stakeholder)에게 중요한 모든 동작, 기능 등을 캡처하여 디자이너가 올바르게 실현할 수 있을 만큼 충분히 세부적임) 상위 레벨에서 비전 목적이 표현될 때 일부 기능 분해를 수행하는
올바른 이유가 있습니다. 상위 레벨 요구사항에서 정제(거의 바로)된 요구사항은 한 가지 유형의 파생 요구사항이기 때문입니다.
파생된 요구사항
다음은 간단한 예제입니다.
사용자 요구사항이 "시스템은 알라스카에서 1년 12달 동안 외부에서 작동해야 합니다."라고 가정해 보십시오.
파생되는 몇몇 요구사항은 다음과 같습니다.
-
시스템은 32 F / 0 C 이하 온도에서 작동해야 합니다.
-
시스템은 눈 속에서 작동해야 합니다.
또 다른 유형의 파생된 요구사항이 있습니다. 시스템 레벨 요구사항을 실현(realization)에 적절한 세부사항으로 표현한 경우 다음을 수행합니다.
-
시스템(model)을 요소로 파티션합니다(예: OOAD 메소드 사용).
-
이 요소들이 협업을 통해 원하는 시스템 동작을 구현하는 방법을 판별합니다.
-
협업에서 하위 레벨 동작을 집계하여 요소 레벨 요구사항을 생성합니다.
이와 같은 하위 레벨 요구사항은 파생된 요구사항입니다. 이 요구사항은 시스템 분해를 통해 나타났습니다. 이는 소개에 설명된 대로 아키텍처 분해 및 시스템 레벨 요구사항 정제에 관계없이 파티션이 발생하는 기능 기반
접근 방식과 대조적입니다.
할당된 요구사항
할당된 요구사항은 하드웨어 또는 소프트웨어 서브시스템과 같은 시스템 컴포넌트에 지정된(기능 고려사항을 기초로) 요구사항입니다. 예를 들어, 복합 시스템(system-of-systems)에 대한 미션
레벨 요구사항에 대해 추론할 때, 이와 같은 요구사항을 기능적으로 정제한 다음 파생된 요구사항을 파티션하고 그룹을 시스템에 할당하는 것이 여전히 적절할 수 있습니다(실현 전에 더 정제될 수 있음). 이
시점 이후부터는, 파생된 요구사항에서와 같이 진행됩니다. 복합 시스템(system-of-systems) 레벨에서도 비즈니스 모델링 접근 방식을 사용하여 이 방식으로 진행하는 것을 고려할 수 있습니다.
파생된 접근 방식에서는 시스템을 엔티티로 분해하고 엔티티가 더 상위 레벨의 요구사항을 충족시키기 위해 협업하는 방법을 학습하여 엔티티의 요구사항을 판별합니다. 기능적 할당 접근 방식에서는 요구사항을 분해하고 더
낮은 레벨의 요구사항을 충족시키는 엔티티를 지정합니다.
사용할 접근 방식은 상황, 문화 및 계약상의 기대에 따라 다릅니다. 예를 들어, NASA(National Aeronautics and Space Agency)[Software Assurance
Guidebook, NASA Goddard Space Flight Center Office of Safety, Reliability, Maintainability and Quality Assurance,
9/89]는 요구사항이 네 레벨의 정밀도로 존재하도록 정의합니다.
-
레벨 1, 미션 레벨 - 아주 상위 레벨이며 매우 일찍 안정됩니다.
-
레벨 2, 시스템 레벨(할당됨) - 이 레벨에서도 매우 일찍 안정됩니다. 요구사항은 미션 레벨에서 파생된 후 세그먼트에 할당됩니다.
-
레벨 3, 서브시스템(또는 세그먼트) 레벨(파생됨) - 이 레벨의 요구사항은 세그먼트에 할당된 시스템 레벨 요구사항에서 파생됩니다.
-
레벨 4, 형상 항목(하드웨어 형상 항목[HWCI], 소프트웨어 형상 항목[CSCI]) 레벨(세부적) - 다시, 이전 레벨에서 할당된 후 정제됩니다.
요구사항 레벨 및 RUP에 맵핑
일반적으로, 계약은 레벨 3에서 선언됩니다. NASA는 이 방식으로 요구사항을 처리하는 데 익숙하므로 유사한 분류를 채택하기 위해 NASA와 관계를 맺고 있는 조직에게도 자연스럽습니다. 여전히 하위 레벨 요구사항이
파생되는 방법에서 개발자가 사용할 수 있는 고려할 만한 융통성이 있지만 미션 레벨 요구사항(이 요구사항은 프로그램 레벨 요구사항과 아주 유사함)에 대해 아주 상위 레벨의 추상이 제공될 경우 기능적
라인에 따라 자연적으로 시스템 레벨 요구사항 파생이(세그먼트에 할당도) 발생할 수 있습니다. 그래도, 엔터프라이즈 아키텍처에 관심이 있으면 아키텍처 고려사항을 사용하여 파생되는 시스템 요구사항에 대해서도 점점
일반화되고 있습니다. 위의 그림은 이와 같은 사실을 보여주며 RUP 중간 산출물(비즈니스 모델링 포함)에 NASA 레벨을 맵핑한 것을 보여줍니다. RUP 프로세스에서 전형적인 플로우에 표시된 할당이 유스 케이스
실현(realization) 프로세스와 후속 동작 집계에서 수행됩니다. 파란색 점선은 유사한 레벨에 있는 중간 산출물을 링크합니다.
|