타스크: 유스 케이스 분석
이 타스크는 유스 케이스에서 분석 레벨 유스 케이스 실현(realization) 개발 방법을 설명합니다.
목적
  • 유스 케이스 이벤트 플로우 수행 클래스 식별.
  • 유스 케이스 동작을 분석 유스 케이스 실현(realization)을 사용하여 클래스에 분배.
  • 클래스 책임, 속성 및 연관 식별.
  • 아키텍처 메커니즘 사용법 노트.
관계
단계
분석 유스 케이스 실현(realization) 작성
목적 유스 케이스 동작 표현에 사용되는 모델 요소 작성. 

유스 케이스는 초반의 분석 및 디자인 작업 대부분에 초점을 맞춥니다. 요구사항 중심 타스크에서 분석/디자인 중심 타스크로 전이하기 위해 중간 산출물: 유스 케이스 실현(realization)은 분석 및 디자인 모델의 동작을 유스 케이스 모델로 역추적하는 방법을 제공하고 유스 케이스 개념의 협업을 조직하는 브릿지로 사용됩니다.

유스 케이스 실현이 없는 경우 유스 케이스에 대한 분석 모델에 분석 유스 케이스 실현을 작성하십시오. 분석 유스 케이스 실현 이름은 연관된 유스 케이스와 동일해야 하며 "실현" 관계는 분석 유스 케이스 실현에서 연관된 유스 케이스로 작성되어야 합니다.

유스 케이스 실현에 대한 자세한 정보는 기법: 유스 케이스 실현을 참조하십시오.

유스 케이스 설명 보충
목적 필수 시스템 내부 동작을 이해하는 데 필요한 추가 정보 중 시스템의 고객을 위해 작성된 유스 케이스 설명에서 누락된 캡처. 

각 유스 케이스 설명이 항상 분석 클래스 및 해당 오브젝트를 찾는 데 충분한 것은 아닙니다. 고객은 일반적으로 시스템의 내부에서 발생하는 사소한 정보에는 관심이 없으므로 유스 케이스 설명에는 해당 정보가 포함되지 않을 수 있습니다. 이런 경우 유스 케이스 설명은 '블랙 박스' 설명과 같은 내용을 제공하며, 여기에는 액터의 조치에 대한 응답으로 시스템이 수행하는 내부적인 세부사항이 누락되거나 매우 요약적으로 제공됩니다. 유스 케이스를 수행하는 오브젝트를 찾으려면 내부 관점에서 시스템이 수행하는 내용을 설명하는 '화이트 박스' 설명이 필요합니다.

예제

현금 자동 인출기(ATM)의 경우 시스템 고객은 다음과 같이 말할 것입니다.

"ATM이 은행 고객 카드의 유효성을 검증합니다."

시스템의 사용자 인증 동작 설명. 이 정보로도 고객에게는 충분할 수 있지만 실제로 ATM에서 카드 유효성 검증을 위해 내부적으로 어떤 작업을 수행하고 있는지는 알려주지 않습니다.

오브젝트를 식별하기 위해 시스템 작업의 내부 상황을 충분히 자세한 레벨로 알려면 추가 정보가 필요합니다. 예를 들어 ATM 카드 유효성 검증 활동에서의 추가 설명은 다음과 같습니다.

"ATM이 고객 계정 번호 및 PIN을 ATM 네트워크로 송신하여 유효성을 검증합니다. ATM 네트워크가 고객 번호 및 PIN 일치를 확인하고 고객이 트랜잭션을 수행하도록 인증되며 작업에 성공했음을 리턴하고 그렇지 않은 경우 ATM 네트워크가 실패를 리턴합니다."

이런 레벨의 세부사항은 필요한 정보(계정 번호 및 PIN) 및 인증 책임자(ATM 네트워크, 유스 케이스 모델의 액터)에 대한 명확한 아이디어를 제공합니다. 이 정보를 사용하여 두 개의 잠재적 오브젝트(계정 번호 및 PIN 속성을 포함하는 고객 오브젝트 및 ATM 네트워크 인터페이스)와 해당 오브젝트의 책임을 식별할 수 있습니다.

시스템의 내부 동작이 명확하게 정의되어 있는지 유스 케이스 설명을 점검하십시오. 시스템의 내부 동작이 명확해야만 시스템에서 수행해야 하는 작업이 명확해집니다. 해당 동작 수행을 책임지는 시스템(오브젝트) 내에 요소를 정의할 필요는 없으며 수행해야 하는 작업의 명확한 정의만 필요합니다.

해당 세부사항의 정보 소스에는 시스템 수행 작업 정의를 도와주는 도메인 전문가가 포함됩니다. 시스템의 특정 동작을 고려할 때 적용할 수 있는 좋은 질문은 "시스템이 해당 작업을 수행하는 의미가 무엇입니까?"입니다. 시스템에서 수행해야 하는 동작이 이 질문에 명확한 대답을 해줄 수 있을 만큼 제대로 정의되어 있지 않은 경우 알아내야 하는 정보가 더 있는 것입니다.

다음은 이벤트 플로우 설명을 보충하는 대안입니다.

  • 전혀 설명하지 마십시오. 상호작용 다이어그램으로 바로 알 수 있거나 해당 유스 케이스의 이벤트 플로우에서 충분한 설명을 제공하는 경우가 이에 해당합니다.
  • 기존 이벤트 플로우 설명을 보충하십시오. 시스템에서 실행되는 조치에 대한 기존 텍스트가 충분히 명확하지 못한 경우 이벤트 플로우에 설명을 보충하십시오.
  • "외부" 유스 케이스 이벤트 플로우 설명과 독립적으로 완전한 텍스트 플로우로 설명하십시오. 시스템 내부 동작이 시스템 외부 동작과 비슷한 부분이 거의 없는 경우에 적용됩니다. 이 경우 유스 케이스가 아닌 분석 유스 케이스 실현(realization)과 연관된 완전히 독립된 설명이 보증됩니다.
유스 케이스 동작에서 분석 클래스 찾기
목적 유스 케이스에 설명된 동작을 수행할 수 있는 모델 요소(분석 클래스) 후보 세트 식별. 

분석 클래스 후보 세트 찾기는 필수 동작의 단순한 설명에서 시스템의 작업 방법에 대한 설명으로 시스템을 변환하는 첫 번째 단계입니다. 이 노력에서 분석 클래스는 유스 케이스에 지정된 기능적 요구사항 및 보충 요구사항에 지정된 비기능적 요구사항을 수행하는 필수 동작을 제공하는 모델 요소 역할을 표시하는 데 사용됩니다. 프로젝트 초점이 디자인으로 옮겨지면서 해당 역할은 유스 케이스를 실현하는 디자인 요소 세트를 전개합니다.

유스 케이스에 식별된 역할은 주로 시스템 응용프로그램 특정 동작 및 도메인 특정 동작의 최상위 계층 동작을 표현합니다. 경계 클래스 및 제어 클래스는 일반적으로 응용프로그램 계층 디자인 요소로 전개되고 엔티티 클래스는 도메인 고유 디자인 요소로 전개됩니다. 하위 계층 디자인 요소는 일반적으로 여기에 식별된 분석 클래스에 사용되는 분석 메커니즘에서 전개됩니다.

여기에 설명된 기법에서는 시스템의 세 가지 다른 관점을 사용하여 후보 클래스 식별을 가져옵니다. 세 가지 관점은 시스템과 액터의 경계, 시스템에서 사용되는 정보 및 시스템의 제어 로직입니다. 해당 클래스 스테레오타입, 경계, 엔티티 및 제어는 분석 시 사용되고 디자인 시 사라지는 편이성입니다.

클래스 식별은 클래스가 식별되고 이름이 지정되며 몇 문장으로 간략하게 설명되어야 함을 의미합니다.

분석 클래스 식별에 대한 자세한 정보는 기법: 분석 클래스를 참조하십시오. 분석 유스 케이스 실현(realization)에 대한 자세한 정보는 기법: 유스 케이스 실현을 참조하십시오.

특정 분석 메커니즘 및/또는 분석 패턴이 프로젝트 가이드라인에 문서화되어 있는 경우 이는 분석 클래스의 또 다른 소스로 사용됩니다.

동작을 분석 클래스로 분배
목적 분석 클래스 협업으로 유스 케이스 동작 표현. 분석 클래스 책임 결정. 

각 독립 서브플로우(시나리오)에 대해 다음을 수행하십시오.

  • 하나 이상의 상호작용(커뮤니케이션 또는 시퀀스) 다이어그램을 작성하십시오. 유스 케이스 기본 이벤트 플로우에 대해 최소 하나의 다이어그램이 필요하며 각 대체/예외 플로우에 대해 최소 하나의 다이어그램이 필요합니다. 일반적으로 복잡한 타이밍 또는 결정 지점을 포함하는 서브플로우의 경우 또는 하나의 다이어그램으로 쉽게 파악하기에는 너무 길고 복잡한 플로우를 단순화하기 위해 독립 다이어그램이 필요합니다.
  • 시나리오의 이벤트 플로우를 단계별로 진행하여 필수 동작을 처리하며 유스 케이스에서 필요한 모든 동작이 분석 유스 케이스 실현(realization)에 제공되도록 하는 분석 클래스를 식별하십시오.
  • 상호작용 다이어그램의 분석 클래스 상호작용을 표시하십시오. 상호작용 다이어그램은 시스템과 액터의 상호작용을 표시해야 합니다(항상 액터가 유스 케이스를 호출하기 때문에 상호작용은 액터에서 시작됨).
  • 사용된 유스 케이스의 제어 클래스를 나타내는 클래스를 포함하십시오. (각 확장 유스 케이스에 대해 독립 상호작용 다이어그램을 사용하고 확장 유스 케이스의 변형 동작만 표시하십시오.)

커뮤니케이션 다이어그램 예제

폐품 받기 유스 케이스의 커뮤니케이션 다이어그램

특정 분석 메커니즘 및/또는 분석 패턴이 프로젝트 가이드라인에 문서화되어 있는 경우 이는 책임 할당 및 결과적인 상호작용 다이어그램에 반영되어야 합니다.

책임 설명
목적 유스 케이스 동작에 식별된 오브젝트 클래스 책임 설명. 

책임은 오브젝트에게 제공하도록 요청할 수 있는 내용에 대한 설명입니다. 책임은 디자인 시 클래스에서 하나의(일반적으로 하나 이상) 오퍼레이션으로 전개되며 다음과 같이 특성이 정의됩니다.

  • 오브젝트가 수행할 수 있는 조치
  • 오브젝트가 유지보수하고 기타 오브젝트에 제공하는 지식

각 분석 클래스는 여러 가지 책임을 가집니다. 하나의 책임만 있는 클래스는 너무 단순하고 책임이 너무 많은 클래스는 책임 제한이 필요하며 잠재적으로 여러 클래스로 분할되어야 합니다.

모든 오브젝트가 작성 및 삭제될 수 있음은 당연합니다. 오브젝트의 작성 및 삭제 시 다른 특수한 동작을 수행하지 않는 이상 이런 명백한 사실을 다시 언급하지는 마십시오. (특정 관계가 존재하는 경우 일부 오브젝트는 제거할 수 없습니다.)

책임 찾기

책임은 상호작용 다이어그램의 메시지에서 파생됩니다. 각 메시지에 대해 메시지가 송신되는 오브젝트 클래스를 점검하십시오. 아직 해당 책임이 없는 경우 요청된 동작을 제공하는 새 책임을 작성하십시오.

기타 책임은 비기능적 요구사항에서 파생됩니다. 새 책임을 작성할 때 적용되는 연관된 요구사항이 있는지 비기능적 요구사항을 확인하십시오. 책임 설명을 늘리거나 이를 반영하는 새 책임을 작성하십시오.

책임의 문서화

책임은 책임의 짧은 이름(최대 몇 단어) 및 짧은 설명(최대 몇 문장)으로 문서화됩니다. 설명은 오브젝트가 수행해야 하는 책임과 책임이 호출될 때 리턴되는 결과를 명시합니다.

속성 및 연관 설명
목적 분석 클래스가 의존하는 기타 클래스 정의.
클래스가 인식해야 하는 기타 분석 클래스의 이벤트 정의.
분석 클래스가 유지보수해야 하는 정보 정의. 

책임을 수행하기 위해 클래스는 종종 기타 클래스에 의존하여 필요한 동작을 제공합니다. 연관은 클래스 간 관계를 문서화하고 클래스 결합의 이해를 돕습니다. 클래스 결합의 이해를 높이고 가능한 경우 결합을 줄여서 더욱 탄력적이고 우수한 시스템을 빌드할 수 있습니다.

다음 단계는 클래스 속성 및 클래스 간 연관을 정의합니다.

속성 정의

속성은 클래스의 정보 저장에 사용됩니다. 특히 속성은 다음과 같은 정보에 대해 사용됩니다.

  • "값"으로 참조됩니다. 즉 속성은 중요한 오브젝트 ID나 정보의 위치가 아니라 단지 정보의 값입니다.
  • 속성이 속해있는 오브젝트가 고유하게 "소유하며" 기타 오브젝트는 이 정보를 참조하지 않습니다.
  • 정보를 가져오고 설정하거나 정보에 대한 단순한 변환만을 수행하는 오퍼레이션에서 액세스합니다. 정보는 값을 제공하는 이외의 "실제" 동작은 포함하지 않습니다.

반면 정보에 복잡한 동작이 포함되어 두 개 이상의 오브젝트에서 공유되거나 두 개 이상의 오브젝트에서 "참조용"으로 전달되는 경우 정보는 독립 클래스로 모델링되어야 합니다.

속성 이름은 속성에 보유된 정보를 명확하게 설명하는 명사여야 합니다.

속성의 설명은 속성에 저장되는 정보를 설명해야 합니다. 속성 이름으로도 저장된 정보를 알 수 있는 경우 이는 선택적입니다.

속성 유형은 속성의 단순 데이터 유형입니다. 예제로는 string, integer, number가 포함됩니다.

분석 클래스 간 연관 작성

동작을 분석 클래스에 분배에서 작성된 상호작용 다이어그램 링크를 연구하여 시작하십시오. 클래스 간의 링크는 두 개의 클래스 오브젝트가 서로 커뮤니케이션하여 유스 케이스를 수행함을 나타냅니다. 시스템 디자인을 시작하면 해당 링크는 여러 방식으로 실현됩니다.

  • 오브젝트가 "글로벌" 범위를 가지며 시스템의 모든 오브젝트가 메시지를 글로벌 범위로 송신할 수 있습니다.
  • 하나의 오브젝트가 매개변수로서 두 번째 오브젝트에 전달되고 나중에 이는 전달된 오브젝트에 메시지를 송신할 수 있습니다.
  • 오브젝트가 메시지가 송신된 오브젝트와 영구적인 관계를 가집니다.
  • 오브젝트는 오퍼레이션 범위 내에서 작성 및 파기되고(즉 '임시' 오브젝트) 해당 오브젝트는 오퍼레이션에서 로컬로 간주됩니다.

그러나 클래스 "수명" 초반에 이러한 결정을 내리기는 너무 이릅니다. 제대로 된 결정을 내리기 위해 필요한 정보가 부족합니다. 결과적으로 분석 시 연관 및 집계를 작성하여 두 개 클래스 오브젝트에서 송신되는 모든 메시지를 표시(및 "전송")합니다. (특별한 연관 형식인 집계는 오브젝트가 "전체/파트" 관계에 참여함을 나타냅니다(기법: 연관기법: 집계 참조).)

해당 연관 및 집계는 타스크: 클래스 디자인에서 정제됩니다.

각 클래스에 대해, 각 클래스가 기타 클래스에 대해 갖는 연관을 표시하는 클래스 다이어그램을 그리십시오.

연관 및 집계를 표시하는 클래스 다이어그램 예제

주문 입력 시스템 파트에 대한 분석 클래스 다이어그램 예제

유스 케이스 실현에 필요한 연관에만 초점을 맞추십시오. 상호작용 다이어그램을 기반으로 필요하지 않은 이상, 있을 "수도" 있는 연관은 추가하지 마십시오.

연관 역할 이름 및 다중성을 지정하십시오.

  • 역할 이름은 연관 오브젝트와 관련하여 연관된 오브젝트가 수행하는 역할을 표시하는 명사여야 합니다.
  • 명확한 증거가 있지 않은 이상 다중성을 0..*(0에서 다수)으로 가정하십시오. 다중성 0은 연관이 선택적임을 의미합니다. 오브젝트가 없는 경우 연관을 사용하는 오퍼레이션을 알맞게 조정해야 합니다.
  • 다중성의 범위를 더 제한할 수 있습니다(예: 3..8).
  • 다중성 범위에서 확률이 지정됩니다. 즉, 다중성이 0..*인 경우 85%의 경우가 10 - 20 사이에 있을 것으로 예상됩니다. 이 정보는 디자인 시 매우 중요하므로 적어 두십시오. 예를 들어 지속적 저장영역이 관계형 데이터베이스를 사용하여 구현되는 경우, 한계를 더 좁히면 데이터베이스 테이블 구성에 더 많은 도움이 됩니다.

연관의 간략한 설명을 입력하여 연관이 사용되는 방법 또는 연관에서 표시하는 관계를 표시하십시오.

분석 클래스 간 이벤트 종속성 설명

오브젝트는 때때로 몇몇 "대상" 오브젝트에서 이벤트가 발생하는 경우 "대상"에서 이벤트 발생 시 알림을 수신해야 하는 모든 오브젝트를 알 필요 없이 이를 인식해야 합니다. 해당 이벤트 알림 종속성을 간단히 표시하기 위해 등록 연관을 통해 압축된 간결한 방식으로 종속성을 표현할 수 있습니다.

두 오브젝트 간의 등록 연관은 등록된 오브젝트에서 특정 이벤트가 발생할 때 이를 등록 오브젝트에게 알림을 표시합니다. 등록 연관에는 등록자에게 알림이 송신되는 이벤트를 정의하는 조건이 포함됩니다. 자세한 정보는 기법: 등록 연관을 참조하십시오.

등록 연관은 특정 속성 또는 오퍼레이션이 아닌 추상 특성으로 표현되어야 합니다. 이렇게 하면 연관 오브젝트가 변경될 수 있는 연관된 엔티티 오브젝트의 컨텐츠와 무관하게 보존됩니다.

등록 연관은 다음과 같은 경우에 필요합니다.

  • 오브젝트가 다른 오브젝트에서 발생한 상황에 영향을 받은 경우
  • 이벤트 처리를 위해 새 오브젝트를 작성해야 하는 경우(예: 오류가 발생하면 새 창을 열어 사용자에게 알려주는 경우)
  • 다른 오브젝트의 인스턴스화, 변경 또는 파기 시 이를 오브젝트에서 인식해야 하는 경우

'등록되는' 오브젝트는 일반적으로 엔티티 오브젝트입니다. 엔티티 오브젝트는 일반적으로 정보의 수동 스토어로 정보 저장 책임과 연관된 동작이 포함됩니다. 다른 많은 오브젝트는 엔티티 오브젝트가 변경되는 시기를 알아야 합니다. 등록 연관으로 엔티티 오브젝트가 모든 기타 오브젝트를 인식할 필요가 없게 됩니다. 단순히 엔티티 오브젝트에 연관되어 엔티티 오브젝트가 변경되면 알림을 수신하게 됩니다.

지금까지는 단지 '분석 기술'만 다루었으며, 디자인 시 알림 작동 방법을 명확히 정의해야 합니다. 알림 프레임워크를 구매하거나 자체적으로 디자인하고 빌드해야 합니다. 그러나 현재는 알림이 있음을 아는 것만으로도 충분합니다.

연관의 방향은 등록 오브젝트만이 두 오브젝트 사이의 관계를 인식함을 보여줍니다. 등록 설명은 전적으로 등록 오브젝트 내에 있습니다. 연관된 엔티티 오브젝트는 일반적인 방식으로 차례로 정의되며, 기타 오브젝트가 해당 활동에 관심이 있을 수 있음을 고려하지 않아도 됩니다. 이는 또한 등록하는 오브젝트를 변경하지 않고도 등록 오브젝트를 모델에 추가하거나 모델에서 제거할 수 있음을 의미합니다.

분석 유스 케이스 실현(realization) 조정
목적 개별 분석 유스 케이스 실현을 조정하고 일관된 관계의 분석 클래스 세트를 식별. 

특정 유스 케이스 분석 결과 분석 유스 케이스 실현이 개발되었습니다. 이제 개별 분석 유스 케이스 실현을 조정해야 합니다. 분석 클래스 및 분석 유스 케이스 실현 각각에 대해 정의된 지원 연관을 점검하십시오. 불일치를 식별 및 해결하고 모든 중복을 제거하십시오. 예를 들어, 두 개의 다른 분석 유스 케이스 실현이 개념적으로 동일하지만 분석 클래스가 다른 디자이너에 의해 식별되어 다른 이름이 사용되었습니다.  
참고: 소프트웨어 설계자가 초기 아키텍처 정의를 제대로 한 경우 분석 유스 케이스 실현 중복이 매우 적어집니다(타스크: 아키텍처 분석 참조).

모델 요소 조정 시 관계에 주의해야 합니다. 두 개의 클래스가 병합되거나 클래스가 다른 클래스로 대체되는 경우 원본 클래스 관계를 새 클래스로 전파해야 합니다.

분석 유스 케이스 실현 조정 시 비지니스 컨텍스트를 이해하고 소프트웨어 아키텍처 및 디자인을 예상하여 문제점 및 솔루션을 가장 잘 보여주는 분석 클래스를 선택해야 하므로 소프트웨어 설계자가 조정에 참여해야 합니다.

클래스에 대한 자세한 정보는 기법: 분석 클래스를 참조하십시오.

분석 메커니즘 규정
목적 분석 클래스에서 사용되는 분석 메커니즘(있는 경우) 식별. 분석 클래스가 분석 메커니즘에 적용되는 방법에 대한 정보 제공. 

이 단계에서는 식별된 분석 클래스 각각에 적용되는 분석 메커니즘이 점검됩니다.

분석 클래스에서 하나 이상의 분석 메커니즘을 사용하는 경우 캡처된 추가 정보로 소프트웨어 설계자 및 디자이너가 아키텍처 디자인 메커니즘에 필요한 기능을 결정하게 됩니다. 그 중에서도 분석 클래스의 인스턴스 수, 크기, 액세스 빈도, 예상 수명은 디자이너가 알맞은 메커니즘을 선택하는 데 중요하게 작용하는 특성입니다.

분석 클래스에서 사용되는 각 분석 메커니즘에 대해, 적절한 디자인 및 구현 메커니즘 선택 시 고려해야 하는 연관된 특성을 규정하십시오. 이들 특성은 메커니즘 유형에 따라 달라지므로, 적용가능한 경우 또는 불확실한 내용이 많은 경우 범위를 제공하십시오. 다른 아키텍처 메커니즘에는 다른 특성이 포함되므로 해당 정보는 전적으로 설명적이며 정보를 캡처하고 제공하는데 필요한 만큼만 구조화됩니다. 분석 과정에서 정보는 일반적으로 매우 이론적이지만 추가 정보가 드러남에 따라 확정되지 않은 예상이 계속 개정되므로 캡처 시 값이 포함됩니다.

클래스 및 연관된 특성에서 사용되는 분석 메커니즘은 공식적으로 캡처되지 않아도 됩니다. 다이어그램에 첨부된 노트 또는 클래스 설명 확장으로도 충분히 정보를 제공할 수 있습니다. 클래스 전개의 이 시점에서 특성 정보는 매우 유동적이고 이론적이므로 메커니즘 정의 형식보다는 예상 값 캡처에 중점을 두게 됩니다.

예제

Flight 클래스에서 사용되는 지속성 메커니즘 특성은 다음과 같이 규정될 수 있습니다.

세분성: 비행당 2 - 24KB

볼륨: 최대 100,000

액세스 빈도:

  • 작성/삭제: 시간당 100번
  • 갱신: 시간당 3,000번 갱신
  • 읽기: 시간당 9,000번 액세스

예제

Mission 클래스에서 사용되는 지속성 메커니즘 특성은 다음과 같이 규정될 수 있습니다.

세분성: 미션당 2 - 3MB

볼륨: 4

액세스 빈도:

  • 작성/삭제: 매일 1번
  • 갱신: 매일 10번
  • 읽기: 시간당 100번
추적성 설정
목적 분석 모델과 기타 모델의 추적성 관계 유지보수. 

프로젝트의 프로젝트 가이드라인에서 분석 모델 요소에 필요한 추적성을 지정합니다.

예를 들어 사용자 인터페이스의 독립 모델이 있는 경우 해당 모델의 화면 또는 기타 사용자 인터페이스 요소를 분석 모델의 경계 클래스로 추적하는 것이 매우 유용합니다.

결과 검토
목적 분석 오브젝트가 시스템의 기능적 요구사항을 충족하는지 확인.
분석 오브젝트 및 상호작용이 일관되는지 확인. 

타스크: 유스 케이스 분석의 결론 및 동기점으로서 워크샵 마지막에 비공식적인 검토를 수행하십시오.

이 타스크의 중간 산출물 체크리스트로 사용하십시오.



특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보