활동:
|
목적
|
|
역할: 요구사항 지정자 | |
빈도: 반복에 자세히 설명된 각 유스 케이스 및 유스 케이스 플로우의 경우, 반복당 한 번 | |
단계
|
|
자세한 정보: |
입력물: | 결과물: |
툴 강좌: |
워크플로우 세부사항: |
개발 주기에서 다루게 될 시나리오의 검토 및 정제에서부터 시작하십시오. 이는 초기에 활동: 액터 및 유스 케이스 찾기에서 이미 식별되었을 수도 있습니다. 기술할 플로우의 범위를 결정할 때 이 열거된 시나리오를 시작 시점으로 사용하십시오.
스토리보드는 유스 케이스 플로우를 이해하고 설명하는 데 도움이 됩니다 이미 개발된 시나리오가 있을 경우, 고려할 다른 입력은 사용자 인터페이스 프로토타입입니다.
이벤트의 유스 케이스 플로우는 이미 윤곽이 드러나 있고 단계별로 설명이 되어 있어야 합니다. 이는 활동: 액터 및 유스 케이스 찾기에서도 작성됩니다. 이 단계별 윤곽을 시작점으로 사용하고 점차적으로 세부사항을 작성하십시오.
프로젝트에 지정된 표준에 따라 유스 케이스를 기술하십시오. 유스 케이스에서 일관성을 유지할 수 있도록 유스 케이스를 기술하기 전에 다음과 같은 지점을 결정하십시오.
" 액터는 다음 중 하나를 한 번 이상 선택합니다.
a) . . .
b) . . .
c) . . ." 등
시스템 내부에 해당하는 특정 문제점을 해결하는 방법이 아니라 유스 케이스 내에서 수행되는 작업을 기술하는 데 중점을 두십시오. 객체 모델에 대해 작업할 때 작업 방법에 대한 세부사항으로 설명을 보완하여 이 시점에 설명이 지나치게 자세해지지 않게 하십시오. 나중에도 변하지 않을 내용만 기술하십시오.
이벤트의 유스 케이스 플로우가 너무 광범위하거나 복잡할 경우 또는 다른 부분과 독립된 부분이 있는 경우, 유스 케이스를 여러 개의 유스 케이스로 나누십시오.
설명 텍스트를 작성할 때 용어집을 참조하십시오. 새로운 개념에서 새로운 용어가 생기기 때문에 용어집에 이를 포함시키십시오. 해당 프로젝트 구성원에게 알리지 않고 용어의 정의를 변경하지 마십시오.
이벤트 플로우 설명은 다음을 탐색합니다.
"사용자가 '주문 관리' 기능을 활성화하면 유스 케이스를 시작할 수 있습니다. "
"새 주문을 작성하기 위해 사용자는 '새로 작성' 기능을 활성화한 다음 주문과 관련된 필수 데이터(이름, 네트워크 요소(최소한 하나) 및 측정 기능의 유형)를 지정합니다. 주문: 설명과 관련된 선택적 데이터를 지정할 수도 있습니다(간단한 텍스트 설명). 그런 다음 사용자가 '확인' 기능을 활성화하면 시스템에 새 주문이 작성됩니다. "
참고: 액터 및 유스 케이스 간에 교환하는 데이터를 명시해야 합니다. 그렇지 않으면 고객 및 사용자가 유스 케이스 설명을 이해하지 못할 수도 있습니다.
"사용자는 '수정' 기능을 활성화하여 기존의 주문을 수정하고 주문 번호(작은 정수)를 지정합니다. 그러면 시스템은 주문 이름, 해당 네트워크 요소 및 특정 기능 유형으로 주문 양식을 초기화합니다. 이 데이터는 보조 기억장치에서 검색됩니다. "
"주문자가 '종료' 기능을 활성화하면 유스 케이스가 종료됩니다."
특별하거나 예외적인 이벤트 플로우도 기술해야 합니다. 예외 플로우는 유스 케이스의 정상 또는 기본 작동을 따르지 않는 유스 케이스의 서브플로우입니다. 유스 케이스의 작동에 대해 완벽히 설명하려면 이 플로우가 반드시 필요합니다. 첫 번째 예에 제공된 플로우가 예외 플로우의 일반적인 예입니다. 유스 케이스가 예상치 않은 데이터를 받으면(액터가 특정 컨텍스트에서 예상한 액터가 아님) 종료됩니다. 잘못된 액터가 있어서 미리 종료하는 것은 이벤트의 일반 플로우에는 있지 않습니다.
유스 케이스를 기술할 때 고려할 기타 "할 것과 하지 말아야 할 것"에는 다음이 포함됩니다.
자세한 정보는 가이드라인: 유스 케이스, 컨텐츠에 대한 토론 및 이벤트 플로우 양식을 참조하십시오.
이벤트의 유스 케이스 플로우를 여러 개의 플로우로 나눌 수 있습니다. 유스 케이스가 활성화된 경우, 다음이 참이면 서브플로우를 여러 가지 방법으로 결합할 수 있습니다.
현금 자동 지급기 시스템에서의 예금 인출 유스 케이스에 대한 설명의 일부는 "고객이 계좌에서 인출하고자 하는 금액을 잔액과 비교합니다. 인출 금액이 잔고보다 많으면 고객에게 알리고 유스 케이스를 종료합니다. 그렇지 않으면 계좌에서 금액을 인출합니다."일 수 있습니다.
이러한 모든 선택적 또는 대체 플로우를 기술해야 합니다. 각 서브플로우를 이벤트 플로우 섹션에 대한 별도의 부록으로 기술하는 것이 바람직하며 다음과 같은 케이스에는 필수입니다.
서브플로우가 전체 이벤트 플로우 중 사소한 부분에만 관련된 경우, 텍스트의 본문에 이를 기술하는 것이 더 좋습니다.
"유스 케이스는 액터인 주문자 또는 성능 관리자를 관리하는 사람 중 하나에 의해 '주문 관리' 기능이 호출되면 활성화됩니다. 신호가 이 두 액터 중 하나로부터 수신되지 않으면 유스 케이스는 작업을 종료하고 사용자에게 적절한 메시지를 표시합니다. 그러나 액터가 인식되면 유스 케이스는 ...에 따라 진행합니다. "
활동 다이어그램을 사용하여 이벤트 플로우의 구조를 표시할 수 있습니다. 가이드라인: 유스 케이스 모델 내의 활동 다이어그램을 참조하십시오.
자세한 정보는 가이드라인: 유스 케이스, 이벤트 플로우의 구조를 참조하십시오.
유스 케이스 및 액터와 기타 유스 케이스에 대한 관계를 표시하는 유스 케이스 다이어그램을 작성하시시오. 이 유형의 다이어그램은 유스 케이스의 로컬 다이어그램으로 작동하며 여기에 관련되어 있어야 합니다. 유스 케이스에 설명이 필요한 유스 케이스 관계가 없거나 관련된 액터 사이에 유난히 복잡한 관계가 있으면, 이 유형의 로컬 유스 케이스 다이어그램은 가치가 거의 없습니다.
자세한 정보는 가이드라인: 유스 케이스 다이어그램을 참조하십시오.
유스 케이스에 관련될 수 있으나 유스 케이스의 이벤트 플로우에서 고려하지 않아도 되는 모든 요구사항은 유스 케이스의 특수 요구사항에 기술해야 합니다. 이러한 요구사항은 작동하지 않을 가능성이 있습니다.
자세한 정보는 가이드라인: 유스 케이스, 특수 요구사항을 참조하십시오.
다른 시스템 또는 외부 하드웨어에 있는 모든 액터에 대해 사용할 통신 프로토콜을 정의하십시오. 일부 기존 프로토콜(특히 인식된 프로토콜 또는 표준으로 간주되는 프로토콜)을 사용할 경우, 유스 케이스의 설명에서는 단순히 프로토콜 이름을 지정합니다. 프로토콜이 새 프로토콜이면 객체 모델 개발 중에 완전히 설명해야 하는 프로토콜 정의가 있는 위치를 지정해야 합니다.
유스 케이스에 대한 전졔 조건에서는 유스 케이스를 시작하기 위해서는 시스템이 어떤 상태에 있어야 하는지에 대해 설명합니다.
ATM 시스템이 현금을 지급할 수 있으려면 다음과 같은 전제 조건을 만족해야 합니다.
- ATM 네트워크에 액세스할 수 있어야 합니다.
- ATM이 트랜잭션 승인 준비 상태에 있어야 합니다.
- ATM에 최소한 지급할 수 있는 만큼의 현금이 준비되어 있어야 합니다.
- ATM에 최소한 하나의 트랜잭션에 대한 영수증을 인쇄할 수 있는 용지가 남아 있어야 합니다.
이는 현급 지급 유스 케이스에 대해 올바른 전제 조건입니다.
시스템 상태를 기술할 때 주의를 기울이십시오. 이 유스 케이스 이전에 발생했을 수 있는 다른 우발적인 활동에 대해 자세히 기술하지 마십시오.
전제 조건은 연속된 유스 케이스를 작성하는 데 사용되지 않습니다. 이벤트 플로우에 의미를 부여하기 위해 하나의 유스 케이스를 먼저 수행한 다음 다른 유스 케이스를 수행해야 하는 케이스가 있어서는 안 됩니다. 이를 수행해야 할 필요성을 느낀다면 유스 케이스 모델을 너무 많이 분해했을 가능성이 있습니다. 순차적으로 의존하는 유스 케이스를 하나의 유스 케이스로 결합하여 이 문제점을 정정하십시오. 이렇게 함으로써 결과 유스 케이스가 너무 복잡해지면, 위의 유스 케이스에 대한 이벤트 플로우 구축 또는 활동: 유스 케이스 모델 구축에 제시된 대로 유스 케이스 구축에 필요한 기법을 고려해 보십시오.
자세한 정보는 가이드라인: 유스 케이스, 전제 조건 및 사후 조건을 참조하십시오.
유스 케이스에 대한 사후 조건에는 유스 케이스 종료시 시스템이 놓일 가능성이 있는 상태가 나열됩니다. 시스템은 유스 케이스 실행 종료시 이러한 상태 중 하나에 놓여 있어야 합니다. 이는 유스 케이스에서 어떤 상황이 발생했는지에 관계없이 유스 케이스 종료시 시스템이 수행하던 조치를 설명하는 데 사용됩니다.
ATM이 유스 케이스 종료시 항상 '환영' 메시지를 표시할 경우, 이는 유스 케이스의 사후 조건에 문서화되어 있을 수 있습니다.
마찬가지로 현금 인출과 같은 유스 케이스를 종료할 때 ATM이 항상 고객의 트랜잭션을 종료하면, 발생한 이벤트 과정에 관계 없이 유스 케이스의 사후 조건으로서 그 사실을 기록해야 합니다.
사후 조건은 복잡도를 줄이고 유스 케이스에 대한 이벤트 플로우의 이해도를 향상시키는 데 사용됩니다.
어떠한 조건에서도 사후 조건을 연속된 유스 케이스를 작성하는 데 사용해서는 안됩니다. 이벤트 플로우에 의미를 부여하기 위해 하나의 유스 케이스를 먼저 수행한 후 다른 유스 케이스를 수행하는 하는 케이스가 있어서는 안 됩니다. 이를 수행해야 할 필요성을 느낀다면, 후속 종속 유스 케이스를 단일 유스 케이스에 결합시켜야 합니다. 이렇게 함으로써 결합된 유스 케이스가 너무 복잡해지면, 위의 유스 케이스에 대한 이벤트 플로우 구축 또는 활동: 유스 케이스 모델 구축에 제시된 대로 유스 케이스 구축에 필요한 기법을 고려해 보십시오.
자세한 정보는 가이드라인: 유스 케이스, 전제 조건 및 사후 조건을 참조하십시오.
다른 유스 케이스에 의해 유스 케이스가 확장될 경우(가이드라인: 확장 관계 참조) 확장 지점이 무엇인지에 대해 기술해야 합니다(가이드라인: 유스 케이스, 확장 지점 참조).
스테이크홀더가 유스 케이스에 대해 명확히 이해하고 해당 설명에 동의할 수 있도록 스테이크홀더와 함께 유스 케이스를 검토하고 논의하십시오.
유스 케이스 설명은 유스 케이스가 수행하고 구현하는 모든 것을 설명하거나 시작부터 끝까지 모든 것을 허용할 경우에만 완료됩니다. 완료하기 전에 유스 케이스가 "우수한" 유스 케이스로 규정한 특성을 제시하는지 확인하십시오. 활동: 요구사항 검토의 유스 케이스 및 유스 케이스 보고서에 대한 체크포인트를 참조하십시오.
Rational Unified Process
|