소프트웨어의 성공적인 개발을 위해서는 체계적이고 명확한 요구분석이 이루어져야 한다. UML에서는 유스케이스모델링을 통해 사용자 또는 고객의 요구사항을 파악하고 업무 시스템의 범위를 결정하는 방법을 제공하고 있다. 본 논문에서는 효율적이며 정확한 유스케이스 모델링을 위한 연구의 일환으로, 요구사항 기술서로부터 정형화된 규칙을 적용해 가면서 단계적으로 유스케이스 다이어그램을 추출하는 기법을 제시하였다. 요구사항 기술서 관련규칙( $R_{A}$; Rules for Requirements Specification)을 적용하여 요구사항 기술서를 변경하고, 변경된 요구사항 기술서에 액터 추출 규칙( $R_{A}$ ; Rules for Actors), 유스케이스 추출 규칙( $R_{U}$ ; Rules for Use Cases), 관계 추출 규칙( $R_{R}$ ; Rules for Relationships)을 각각 적용하여 액터, 유스케이스, 관계를 추출하여 최종적으로 유스케이스 다이어그램(Use Case diagram)을 작성하게 된다. 본 논문에서 제시한 규칙을 인사관리 요구사항 기술서에 적용해 본 결과, 정형화된 규칙이 없이 서술적인 몇몇 조언을 바탕으로 유스케이스 다이어그램을 추출해야하는 기존의 어려움을 줄일 수 있는 효과를 확인하였다.확인하였다.
소프트웨어의 성공적인 개발을 위해서는 체계적이고 명확한 요구분석이 이루어져야 한다. UML에서는 유스케이스 모델링을 통해 사용자 또는 고객의 요구사항을 파악하고 업무 시스템의 범위를 결정하는 방법을 제공하고 있다. 본 논문에서는 효율적이며 정확한 유스케이스 모델링을 위한 연구의 일환으로, 요구사항 기술서로부터 정형화된 규칙을 적용해 가면서 단계적으로 유스케이스 다이어그램을 추출하는 기법을 제시하였다. 요구사항 기술서 관련규칙( $R_{A}$; Rules for Requirements Specification)을 적용하여 요구사항 기술서를 변경하고, 변경된 요구사항 기술서에 액터 추출 규칙( $R_{A}$ ; Rules for Actors), 유스케이스 추출 규칙( $R_{U}$ ; Rules for Use Cases), 관계 추출 규칙( $R_{R}$ ; Rules for Relationships)을 각각 적용하여 액터, 유스케이스, 관계를 추출하여 최종적으로 유스케이스 다이어그램(Use Case diagram)을 작성하게 된다. 본 논문에서 제시한 규칙을 인사관리 요구사항 기술서에 적용해 본 결과, 정형화된 규칙이 없이 서술적인 몇몇 조언을 바탕으로 유스케이스 다이어그램을 추출해야하는 기존의 어려움을 줄일 수 있는 효과를 확인하였다.확인하였다.
We have to carry out systematic, definite requirements analysis for the successful development of software. The UML gives the ways to grasp user or customer requirements and decide the boundary of business systems from the use case modeling. This paper presents how to extract use case diagram from t...
We have to carry out systematic, definite requirements analysis for the successful development of software. The UML gives the ways to grasp user or customer requirements and decide the boundary of business systems from the use case modeling. This paper presents how to extract use case diagram from the requirements specification systematically by applying the standardized rules as a part of the study for use case modeling. We modify requirements specification by applying $R_{RS}$ (Rules for Requirements Specification) and extract actor, use case, relationship by applying $R_{A}$(Rules for Actors), $R_{U}$(Rules for Use Cases) and $R_{R}$(Rules for Relationships) to the modified requirements specification separately and then become to make out use case diagram in the end. By applying the rules presented in this paper to the requirements specification for personnel management, we can reduce the existing difficulties of extracting use case diagram based on the narrative descriptions without any standardized rules.rules.
We have to carry out systematic, definite requirements analysis for the successful development of software. The UML gives the ways to grasp user or customer requirements and decide the boundary of business systems from the use case modeling. This paper presents how to extract use case diagram from the requirements specification systematically by applying the standardized rules as a part of the study for use case modeling. We modify requirements specification by applying $R_{RS}$ (Rules for Requirements Specification) and extract actor, use case, relationship by applying $R_{A}$(Rules for Actors), $R_{U}$(Rules for Use Cases) and $R_{R}$(Rules for Relationships) to the modified requirements specification separately and then become to make out use case diagram in the end. By applying the rules presented in this paper to the requirements specification for personnel management, we can reduce the existing difficulties of extracting use case diagram based on the narrative descriptions without any standardized rules.rules.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
요구공학은 소프트웨어공학 단계에서 사용자가 원하는 시스템을 찾아내고, 설계에 들어가기 전에 문서화하는 모든 공정을 포함한다. 보통 요구공학에서 사용되는 공정은 (그림 1) 과 같이 표현할 수 있으몌6], 본 절에서는 UML 기반 요구 공학 프로세서로서 요구사항 추출, 요구사항 분석, 요구사 항 명세, 요구사항 검증, 요구사항 관리, 요구사항 변경관리의 여섯 단계로 나누어 각 프로세스가 갖는 특징을 살펴 보고자 한다[7].
본 논문에서는 요구사항 파악 후 최종적으로 작성된 요구사항 기술서로부터 고객의 요구를 정확히 반영하여 명백한 의사소통을 도울 수 있는 정형화된 유스케이스 다이어 그램 추출 기법을 제안하고자 한다. 2장에서는 관련 연구로서 요구분석의 공학적 접근 방법인 요구공학의 공정과 유스 케이스 다이어그램 작성에 관련된 각 요소의 개념을 설명한다.
가설 설정
. 누가 시스템을 시작, 유지관리, 종료할 것인가?
규칙 3 : Ru 3~Ru 6의 내용은 이벤트 흐름이 두 개 이상의 유스케이스에 걸쳐 진행되는 경우에 해당되므로 유 스케이스와 유스케이스 간의 관계로서 표현한다. [Rr3].
규칙 3 : 주어가 동작의 상태를 나타내는 경우 상태에 능동적인 역할을 할 수 있는 주체는 잠재적 액터로 간주한다[Ra 3],
규칙 4: 동일한 기능을 담당하는 역할의 명칭은 통일한다[RRC 4],
규칙 4: 정의된 유스케이스 중 동일 기능을 수행하는 유스케이스가 구체화되어 있는 경우는 인터페이스를 고려하여 일반화 할 수 있다[Ru 4],
규칙 5:동작의 주체이지만, 의도적이지 않은(우연한, 의미 없는) 동작을 수행하는 경우는 엑터 후보로 간주하지 않는다[Ra 5],
규칙 5:정의된 유스케이스 중 하나의 유스케이스가 세분화되어 있어 포괄적 의미의 유스케이스와 세분화된 유스케이스가 공존한다면 포괄적 의미를 가지는 유스케이스로 통합할 수 있다[Ru 5],
제안 방법
①정규직 경력사원 개인 신상자료 입력 유스케이스와 임시직 경력사원 개인 신상 자료 입력 유스케이스를 사원 개인 신상자료 입력 유스케이스로 일반화하였다.
⑥정규직 신입사원 자료를 등록유스케이스와 임시직 신입사원 자료를 등록유스케이스를 신입사원 자료 등록 유스케이스로 일반화하였다.
결과 2 : 구체화된 유스케이스를 일반화하기 위해 Ru 4를 적용하였다
포함관계(Include) : 여러 개의 유스케이스들이 동일한 기능을 공유하는 경우가 있다. 공통 기능을 별도의 독립 된 유스케이스로 생성하고 이를 필요로 하는 유스케이스들과 연관성을 형성하도록 한다. UML에서는 공통된 유스케이스 방향으로 색칠 안 된 삼각형 화살표에 스테레오 타입을 이용하여<<include>>로 표현한다.
UML에서 유스케이스는 항상 액터에 의해 시작되몌 10] 유스케이스를 초기화하는 액터의 입장에서 보통 서술형으로 명명된다. 그러므로 요구사항 기술서에서 액터와 시스템 간의 상호작용을 찾아 서술어를 중심으로 하여 유스케이스를 추출한다. 이와 같은 방법을 통해 시스템을 파악하는 방법은 최종적으로 시스템을 사용할 사람의 입장에서 시스템을 파악한다는 중요한 의미를 가진다.
이와 더불어 각 요구사항 명세가 후보 유스케이스 및 액터와 어떻게 연관되고 추적 되는지를 기술하여야 하며, 분석단계의 검증과 검정계획으로 요구공학 프로세스의 형상과 어떻게 연관할 것인지에 대한 계획을 수립하여야 한다. 또한 소프트웨어 산출물이 완전히 사용자의 요구사항에 부합하도록 검증과 검정 또는 다른 관리 활동을 진행함으로써 품질 보증이 이루어지도록 한다.
이에 본 논문에서는 작성된 요구사항 기술서의 문장을 분석단위로 하여 액터, 유스케이스 및 관계를 추출하는 데 필요한 규칙을 제안하고, 그 규칙을 적용하여 유스케이스 다이어그램을 추출하는 과정을 단계별로 제시하였다. 또한 유스케이스 다이어그램의 추출 과정의 단계별 결과를 제시된 양식에 맞게 기술하여 각 요소들의 선택 여부 및 다음 단계의 기초를 제공하게 하였다. 현재 사용되고 있는 방법들과는 달리 본 논문에서 제안하고 있는 규칙들의 구체적 특징들은 다음과 같다.
변경된 요구사항 기술서를 바탕으로 Ra를 적용하여 액터 후보 목록을 추출하였다.
본 논문에서는 요구사항 기술서로부터 유스케이스 다이어그램을 추출하는 과정을 4단계로 구성하고 각 단계에서 유용하게 사용될 규칙을 제안하였다. 1단계에서는 요구사항 기술서에 Rrs를 적용하여 문장 단위를 기준으로 분석 및 정제된 요구사항 기술서로 변경할 수 있었다.
<표 7>에서 선택된 액터 후보만을 대상으로 하여 활동을 기술하고 유스케이스를 생성한다. 생성된 각 유스케이스가 수행한 결과를 넘길 대상이 있는지를 결정하고 적용 규칙 및 규칙 적용 결과에 따른 선택 여부를 기술하였다. 유스 케이스 다이어그램은 순차적, 반복적 과정을 거치므로 일련번호를 부여하여 추출과정을 순서적으로 볼 수 있게 하였다.
액터와 유스케이스를 추출한 후 유스케이스를 상세 기술하는 과정에서 관계를 추출하여 액터와 유스케이스 간의 관계를 기술한다. 관계의 유형으로는 '연관 관계', '확장 관계', 포함관계', '일반화 관계로 구분할 수 있으며 이들 관계는 '액터와 유스케이스 간의 관계', '유스케이스와 유스케이스 간의 관계', '액터들 간의 관계'를 표현할 때 사용된다.
여섯째, 기존의 각 방법들은 유스케이스를 추출하고 그 유스케이스를 상세화하여 시나리오를 작성하는 과정에서 관계가 추출되는데 본 논문에서는 유스케이스와 관계를 추출하는 과정을 분리하였다.
요구사항 분석은 객체지향 분석과정에 적합하도록 요구 사항을 재명세하기 위하여 분석하는 단계로서, 사용자의 요구를 이해하고 문제 해결의 여러 제약조건들을 정리하여 무슨(what) 시스템을 구현할 것인가를 분석하게 된다. 요구 사항 추출단계를 통해 요구사항 획득 후 분류한 요구사항과 추출한 공통어휘를 기반으로 시스템의 영역을 정의하고, UML 도구인 유스케이스와 액터를 사용하여 요구사항을 구 조화하고, 활동도(Activity Diagram)를 통해 시스템을 재이 해한다. 요구사항에서 시스템의 경계의 정의 및 제한 그리고 시스템에 부과되는 제약사항을 식별함으로써 영역을 분석한 후, 요구사항에서 외부 인터페이스를 찾는데 인터페이스는 일반적으로 유스케이스 다이어그램에서 액터로 존재하게 된다'.
요구사항 기술서를 바탕으로 액터, 유스케이스, 관계를 추출하기 위해 요구사항 기술서를 문장 단위로 분석한 후 필요에 따라 제시된 규칙에 의해 문장을 변경한다. 이때, 각 문장 단위로 '문장번호'를 부여하며 적용되는 규칙은 Rrs (Rules for Requirements Specification) e}JI 정의하고 그 내용은 다음과 같다.
요구사항을 파악하기 위해『인사 기본 정보 관리』요구사 항 기술서의 각 문장에 '문장 번호'를 부여하고 문장 번호순으로 Rrs 규칙 적용 여부를 분석하였다.
생성된 각 유스케이스가 수행한 결과를 넘길 대상이 있는지를 결정하고 적용 규칙 및 규칙 적용 결과에 따른 선택 여부를 기술하였다. 유스 케이스 다이어그램은 순차적, 반복적 과정을 거치므로 일련번호를 부여하여 추출과정을 순서적으로 볼 수 있게 하였다.
2에서 살펴보았다. 이 장에서는 요구공학적인 접근으로 작성된 요구사항 기술서를 바탕으로 개발자들이 좀 더 쉬운 방법으로 유스케이스 다이어그램을 작성할 수 있도록 유스케이스 다이어그램의 각 요소를 추출할 수 있는 규칙을 제안하고, 유스케이스 다이어그램을 추출하는 과정을 정의하였다.
따라서 인터뷰 결과 혹은 이미 작성된 요구사항 기술서의 내용을 몇몇 유용한 질문들을 사용하여 액터와 유스케이스 및 관계를 추출하여 유스케이스 다이어그램을 작성하는 데는 어려움이 따른다. 이에 본 논문에서는 작성된 요구사항 기술서의 문장을 분석단위로 하여 액터, 유스케이스 및 관계를 추출하는 데 필요한 규칙을 제안하고, 그 규칙을 적용하여 유스케이스 다이어그램을 추출하는 과정을 단계별로 제시하였다. 또한 유스케이스 다이어그램의 추출 과정의 단계별 결과를 제시된 양식에 맞게 기술하여 각 요소들의 선택 여부 및 다음 단계의 기초를 제공하게 하였다.
요구사항 검증 단계에서는 재명세 요구사항과 공통어휘를 검증하게 된다. 재명세한 요구사항을 기존 요구사항과 비교, 검토하고 추출된 공통어휘를 검증한다.
지금까지 제시한 요구사항 기술서 관련 규칙, 액터 추출 규칙, 유스케이스 추출 규칙, 관계 추출 규칙을 인사 기본 정보 관리 시스템 구축 사례[9]에 적용하여 유스케이스 다이어그램을 작성하고자 한다.
첫째, 유스케이스 다이어그램을 추출하는 과정을 (그림4)와 같이 단계별로 제시하여 각 단계의 핵심 행위와 단계별 연관성을 알 수 있게 하였다. 뿐만 아니라 초보자들도 각 과정에서 제안한 규칙에 따라 순서적으로 유스케이스 다이어그램을 작성할 수 있다.
요구사항에서 시스템의 경계의 정의 및 제한 그리고 시스템에 부과되는 제약사항을 식별함으로써 영역을 분석한 후, 요구사항에서 외부 인터페이스를 찾는데 인터페이스는 일반적으로 유스케이스 다이어그램에서 액터로 존재하게 된다'. 추출한 액터가 시스템에 어떤 기능을 요구하는지를 중심으로 유스케이스를 추출하고, 추출된 유스케이스 간의 공통범위와 기능식별 및 관리를 위하여 서로 관련된 유스케이스를 큰 기능 군으로 클러스터링한다. 그리고 관련된 유스케이스 안에서 업무들 간의 중요도, 위험요소와 복잡 성의 포함 정도, 새롭거나 개발에 검증되어 있지 않은 기술의 적용 유무에 따라 요구사항 등급을 부여한다.
이론/모형
관계 추출 규칙 RHRules for Relationships)를 적용하여 최종적으로 추출된 액터와 유스케이스 간의 관계를 의 형태로 작성한다.
성능/효과
다섯째, 관계 추출 과정에서는 과 같은 양식을 통해 액터 추출 단계와 유스케이스 추출 단계의 결과를 이용하여 관련성을 쉽게 추출할 수 있다.
둘째, 요구사항 기술서로부터 액터, 유스케이스, 관계를 추출함에 있어서 문장을 분석단위로 취급하여 각 문장마다 문장번호를 부여하고 요구사항 기술서 관련 규칙을 적용함으로써 액터와 유스케이스를 쉽게 추출할 수 있다.
셋째, 액터 추출 규칙을 적용한 결과를 과 같이 정리하고 각 액터 후보별 역할 기술과 선택 여부 항목을 통해 객관적으로 액터를 추출할 수 있다.
후속연구
향후 과제로는 액터를 추출함에 있어 역할의 범위를 어디까지 설정할 것인가에 대한 자세한 기준과 유스케이스를 추출함에 있어 활동의 세분화 정도나 비슷한 기능을 어떻게 묶을 것인가에 대한 정밀한 기준을 제공하는 것이 필요하다. 더 나아가 유스케이스 다이어그램의 패키지화, 유스케이스의 시나리오를 작성하고 시나리오에 따라 액티비티 다이어그램을 작성하는 기법 등에 대한 연구가 필요할 것으로 보인다.
요구사항 관리는 요구사항 문서와 후보 액터, 유스케이스, 활동도 분석 결과 등의 형상에 대한 관리가 필수적으로 시행되어야 하고, 분석단계의 형상 관리 계획도 수립하는 단 계이다. 이와 더불어 각 요구사항 명세가 후보 유스케이스 및 액터와 어떻게 연관되고 추적 되는지를 기술하여야 하며, 분석단계의 검증과 검정계획으로 요구공학 프로세스의 형상과 어떻게 연관할 것인지에 대한 계획을 수립하여야 한다. 또한 소프트웨어 산출물이 완전히 사용자의 요구사항에 부합하도록 검증과 검정 또는 다른 관리 활동을 진행함으로써 품질 보증이 이루어지도록 한다.
향후 과제로는 액터를 추출함에 있어 역할의 범위를 어디까지 설정할 것인가에 대한 자세한 기준과 유스케이스를 추출함에 있어 활동의 세분화 정도나 비슷한 기능을 어떻게 묶을 것인가에 대한 정밀한 기준을 제공하는 것이 필요하다. 더 나아가 유스케이스 다이어그램의 패키지화, 유스케이스의 시나리오를 작성하고 시나리오에 따라 액티비티 다이어그램을 작성하는 기법 등에 대한 연구가 필요할 것으로 보인다.
참고문헌 (18)
Leszek A. Maciaszek, Requirements analysis and system design Developing information systems with UML, Addison-Wesley Pub. Co., 2001
Martin Fowler, Kendall Scott, UML Distilled Second Edition : A Brief Guide to the Standard Object Modeling Language, Addison-Wesley Pub. Co., 2000
Joseph Schmuller, Teach Yourself UML in 24 Hours, SAMS Pub. Co., 1999
Ian Sommervlle & Pete Sawyer, Requirements Engineering, John Wiley & Sons, Inc., 1997
Klaus Pohl, Process-Centered Requirements Engineering, John Wiley & Sons, Inc., 1996
Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Overgaard, Object-Oriented Software Engineering-A Use Case Driven Approach, Addison-Wesley Pub. Co., 1998
Cockburn Alistair, Writing Effective Use Case, Addison-Wesley Pub. Co., 2000
Doug Rosenberg, Kendall Scott, Use Case Driven Object Modeling with UML : A Practical Approach, Addison-Wesley Pub. Co., 1999
Armour Frank, Miller Granville, Advanced Use Case Modeling, Addison-Wesley Pub. Co., 2001
김민선, 김수동, '전사적 프로젝트의 Use Case 모델링을 위한 실무 지침', 정보처리학회 추계학술발표논문집, 제6권 제2호, pp.1-4, 1999
※ AI-Helper는 부적절한 답변을 할 수 있습니다.