RUP Core workflows[3] 요구사항 웍플로우

가) 목적

    요구사항 웍플로우의 목표는 다음과 같다.

• 시스템이 무엇을 해야 하는가에 대한 고객과 사용자의 동의 획득
• 개발자에게 시스템의 요구사항에 대해 충분히 이해할 수 있게 함
• 시스템의 기능(functionality)을 정의
• 반복의 계획과 기술적인 내역(technical contents)을 위한 기초 제공
• 시스템을 개발하는 데 필요한 시간과 비용을 측정하기 위한 기초 제공
• 시스템의 사용자 인터페이스 정의

    이와 같은 목표를 달성하기 이루기 위해서 요구사항 웍플로우는 시스템의 비전을 어떻게 정의할 것이며 비전으로부터 시스템의 상세 요구사항을 기술하는 유스 케이스 모델을 어떻게 만들 것인지에 대해 설명한다. 이외에도 요구사항 웍플로우는 시스템의 범위를 관리하는 방법과 변화하는 요구사항을 관리하는 방법을 정의하고 또한 사용자 인터페이스의 프로토타입을 정의하는 방법을 정의한다.

 

나) 작업자와 산출물

요구사항 웍플로우에서 작업자와 산출물의 관계

    앞의 그림에서 볼 수 있는 것과 같이 요구사항 웍플로우의 주요 작업자와 산출물에는 다음과 같은 것이 있다.

주요 작업자

• 시스템 분석가(System Analyst) : 시스템 분석가의 역할을 하는 사람은 시스템의 범위를 정의하고 시스템의 기능의 초안을 작성한다. 그리고, 이를 통해 요구사항을 추출하고 유스 케이스를 모델링하는 작업을 주도적으로 수행하며 때로는 조정자의 역할을 한다.
• 유스 케이스 명세 담당자(Use-case specifier) : 유스 케이스 명세 담당자는 유스 케이스의 요구사항을 상세히 기술함으로써 시스템의 기능(전체 혹은 일부)을 구체적으로 명시한다.
• 아키텍트(Architect) : 요구사항 웍플로우에서 아키텍트는 아키텍쳐의 관점에서 중요한 유스케이스와 요구사항을 식별하고 정의하는 책임을 진다.

   이외에도 다음과 같은 작업자들이 존재한다.

• 사용자 인터페이스 설계자(User-Interface Designer)
• 요구사항 검토 담당자(Requirement Reviewer)

 

   요구사항 웍플로우의 주요 산출물에는 다음과 같은 것이 있다.

• Stakehoder needs
• 비전 문서(Vision Document)
• 유스 케이스 모델(Use-Case Model)
• 보충 사양(Supplementary specification : 유스 케이스로 표현되지 않는 요구사항을 기술)
• 요구사항 속성(Requirement attributes) : 다양한 요구사항의 특징과 요구사항간의 의존관계를 정의
• 유스 케이스 Storyboard
• 사용자 인터페이스 프로토타입(User-Interface prototype)
• 경계 클래스(Boundary class) : 분석 모델에서 어떻게 사용자 인터페이스가 실현되는가를 보여 준다.

다) 웍플로우

   앞의 그림은 요구사항 웍플로우 구성을 나타낸다. 웍플로우에서 시스템 분석가는 시스템이 어떤 기능을 제공해야 하는가를 식별(시스템의 범위를 식별)하고, 또한 성능과 같은 기능 외적인 요구사항을 식별한다. 그런 다음 시스템 분석가는 프로젝트의 비전을 작성한다. 비전은 프로젝트에 관련된 이해당사자의 입장에서 작성한 기능으로 표현되며 유스 케이스 모델의 초안을 개발하는 데 밑거름이 된다.

   유스 케이스 명세 담당자에게는 유스 케이스와 보충 요구사항이 할당되며, 유스 케이스 명세자는 이를 상세화한다. 또한 이 과정에서 요구사항 웍플로우의 다른 산출물과 일관성을 유지해야 한다. 따라서 유스 케이스 명세 담당자는 독립적으로 일하지 않고 일반적으로 다른 유스 케이스 명세 담당자, 그리고 시스템 분석가와 의견을 교환하면서 작업한다.

   사용자 인터페이스 설계자는 유스 케이스 명세 담당자가 작업할 때 시스템의 사용자 인터페이스 설계작업을 수행한다. 많은 경우에 이들 작업자들이 상호작용을 함으로써 상승(synergy) 효과를 낼 수 있다.

    아키텍트는 주로 초기의 반복에 관련되어 있으며 시스템 분석가와 유스 케이스 명세 담당자와 공동으로 작업하여 아키텍쳐의 관점에서 중요한 유스 케이스의 무결성을 보장한다. 한편 요구사항 검토 담당자는 개발 팀이 요구사항을 올바르게 인지했는가를 검증한다.

라) 도구 지원

   Rational RequisitePro는 요구사항을 추출하고 추출한 요구사항을 문서와 데이터베이스로 체계화할 수 있게 하며, 요구사항의 범위와 변경에 대한 관리를 수행한다. 유스 케이스를 사용하는 경우에는 RequisitePro를 이용하여 유스 케이스 중 문서로 표현할 수 있는 측면을 자유롭게 기술할 수 있다.

   요구사항의 산출물(예를 들어 유스 케이스 모델, 유스 케이스 시나리오 등)을 비주얼 모델링하기 위해서는 Rational Rose를 사용할 수 있다. 이때 RequisitePro와 Rose는 요구사항의 산출물과 설계 모델간의 일관성을 보장한다. 또한 Rational SoDA는 문서를 자동으로 생성해 준다. SoDA를 이용하여 필요한 문서의 Template을 정의할 수 있으며, SoDA는 Template에 명시된 대로 알맞은 곳에서 정보를 추출하여 문서를 생성한다. SoDA는 특히 여러 종류의 Rational 툴을 사용할 때 유용하게 쓰일 수 있다.

마) 요약

• 요구사항은 시스템이 만족시켜야 하는 조건(condition) 또는 능력(capacity)을 말한다.
• 일반적으로 프로젝트를 수행할 때에는 기능에 대한 요구사항,  성능과 같은 비기능적 요구사항 등 여러 가지 유형의 요구사항을 고려해야 한다.
• Rational Unified Process는 사용자 인터페이스 설계를 사용자 인터페이스를 비주얼하게 형상화하는 것으로 정의한다. 사용자 인터페이스 설계를 통해 다양한 사용편의성(usability)에 대한 요구사항을 다룰 수 있다.
• 기본적인 요구사항 웍플로우에서는 다양한 작업자가 문제를 분석하고, 이해당사자의 요구(needs)를 도출해 내고, 시스템을 정의하고, 프로젝트의 범위를 관리하고, 변경된 요구사항을 관리하는 작업을 수행한다.
• 요구사항 추출과 관리는 Rational사의 도구를 사용하여 효과적으로 수행할 수 있다.

본 글의 모든 저작권은 Rational에 있습니다.