2. 유즈케이스 모델링 (Use case Modeling) 2 2010-09-15 Intelligent Systems Research Lab.
3. 유즈케이스 모델 시스템의 행위 기술 시스템의 기능적 측면을 사용자 관점에서 설명하는 명시적 모델 시스템에서 제공되어야 할 기능을 기술 3 2010-09-15 Intelligent Systems Research Lab.
4. 유즈케이스 모델 특성 사용자의 기능적 요구사항을 정의하는 직관적인 방법 개발하고자 하는 시스템과 시스템 사용자와의 관계를 정립하는 도구 사용자가 원하지 않는 시스템의 기능을 식별하는 것도 중요 개발자와 사용자간 상호 의사소통의 수단 Use Case Model은 시스템 개발 전 단계에 걸쳐서 영향을 미침 구현 문제는 생각하지 않음 4 2010-09-15 Intelligent Systems Research Lab.
5. 유즈케이스 모델 구성 요소 액터:시스템과 상호작용하는 주체 유즈케이스: 시스템의 기능 행위를 표현 유즈케이스 명세서 :각가의유즈케이스의 처리 흐름을 기술한 문서 유즈케이스 다이어그램 :시스템 영역내의 유즈케이스와액터간의 관계를 도식화 5 2010-09-15 Intelligent Systems Research Lab.
6. 유즈케이스 모델 Use-Case Model 유즈케이스의 관점에서 시스템의 기능적 요구사항을 묘사하는 모델 시스템의 의도된 기능성(유즈케이스) 및 그와 관련된 환경(액터) Actors Use Cases ... Use-Case Specifications 6 2010-09-15 Intelligent Systems Research Lab.
7. 액터(Actor) 액터는 클래스의 스테레오타입 액터는식별자; 사용자는 하나의 인스턴스 액터는유즈 케이스를 발견하는 기준 시스템 외부에서 시스템과 직접적으로 상호작용 하는 어떤 것 시스템으로부터 입력을 제공하거나 출력을 획득 액터 7 2010-09-15 Intelligent Systems Research Lab.
8. 유즈케이스 유즈케이스의 정의 특정 액터를 위해 측정 가능한 결과치를 제공하기 위해 시스템에 의해 수행되는 일련의 트랜잭션 하나의 유즈케이스는 반드시 액터에게 어떤 가치를 제공 시스템이 사용될 때 어떻게 행동할 것인가에 대한 응집된 이야기 각각의 액터가 시스템을 사용하는 목적을 달성하도록 하기 위해서 시스템이 제공해야 하는 기능. 어떠한 기능들이 시스템에 의해서 액터에게 제공될 것인가를 정의 시스템의 유즈 케이스를 모아 놓은 것은 시스템이 사용되어지는 모든 방법들을 구성 사용자 관점 특정 액터가 시스템을 통해 수행하는 일련의 행위들(sequence of actions)을 모아놓은 것 액터의 요구에 의해 시스템이 어떻게 사용될 것인가를 표현 시스템이 액터에게 어떤 서비스를 제공하는지를 표현 고객의 입장에서 본 기능적인 요구사항 유즈케이스는 그 자체로 완전하고 하나의 의미를 갖는 업무 처리 단위 8 2010-09-15 Intelligent Systems Research Lab.
9. 유즈케이스 유즈케이스는 요구사항에 대한 문서화 목적이 아니라, 요구사항 파악을 목적으로 한다 유즈케이스는 그 자체로 요구사항이다 별도의 요구사항 목록으로 재정의 할 필요 없음 유즈케이스가 요구사항의 전부는 아니다. 유즈케이스는 시스템 행위의 기능적 측면만 표현 성능(Performance), 신뢰성(Relaibility), 사용성(Availability)등 비기능적 요구사항을 표현하지는 못함 비기능적 요구사항은 별도의 요구사항 목록으로 작성 필요 9 2010-09-15 Intelligent Systems Research Lab.
10. 유즈케이스 유즈케이스 식별을 위한 질문 리스트 각 액터들이 해야 하는 일은 무엇인가? 시스템에서 정보를 생성, 저장, 변경, 삭제 또는 조회하는 액터가 있는가? 어떠한 유즈 케이스가 이러한 정보를 생성, 저장, 변경, 삭제 또는 조회하는가? 갑작스러운 외부의 변경사항을 시스템에 통지하는 액터가 있는가? 시스템에서 발생하는 어떤 상황들을 보고 받아야 하는 액터가 있는가? 어떠한 유즈 케이스들이 시스템의 지원과 관리를 수행하는가? 이 유즈 케이스들에 의해 시스템의 모든 기능적인 요구 사항들이 수행될 수 있는가? 10 2010-09-15 Intelligent Systems Research Lab.
11. 유즈케이스 다이어그램 Usecase Diagram 시스템의 기능적 요구사항을 표현, 시스템의 사용자(액터)와 시스템 간 정형적인 상호작용 기술 사용자 관점에서 시스템 행동을 조직화하고 Modeling 11 2010-09-15 Intelligent Systems Research Lab.
12. 유즈케이스 명세서 유즈케이스 그 자체는 “WHAT”에 관한 문제 유즈케이스 명세서는 “HOW”에 관한 문제 “어떻게 구현할 것인가”가 아니라 “내부 업무 흐름이 어떠한가?”임 구현에 대한 How가 아니라 업무에 대한 How 2010-09-15 12 Intelligent Systems Research Lab. <Use Case 이름> 개요 관련 액터 사전조건 Flow of Event 사후조건 특별요구사항 <Use Case 이름> 개요 관련 액터 사전조건 Flow of Event 사후조건 특별요구사항 고객정보관리 구매성향분석
13. 유즈케이스 명세서 Flow of event 유즈케이스의 작업이 완료되기 위한 여러 비즈니스 이벤트의 흐름(Scenario) 시스템외부 발생 상황은 기술하지 않는다. 액터와유즈케이스간 정보 교류 기술. UI에 관한 내용은 언급하지 않는다. 가능한 쉬운 용어 사용 해당 유즈케이스에 관한 것만 기술. 자세하게 기술하기 보다는 정확하게 기술 Basic Flow(기본흐름) 일반적인 흐름을 기술. 잘못된 경우는 기술하지 않음 Alternative Flow(대체흐름) 선택사항 예외사항(Error) 유즈케이스size가 큰 경우 13 2010-09-15 Intelligent Systems Research Lab.
14. 유즈케이스 명세서 유즈케이스 명세서 작성 지침 액터의 관점에서 작성 너무 세부적이지 않지만 정확하게 작성 요구사항을 수집하고 정의하기 위해서 작성하는 것이지, 세부적인 분석, 설계를 하는 것은 아니다. 완벽한 유즈케이스를만들수도 없고, 만들려고 노력할 필요는 없다. 유즈케이스 명세서는 액터와유즈케이스간 상호작용을 설명한다. 고객은 현금 인출카드를 넣고 비밀번호를 입력한다. 시스템은 잔고에서 일정액을 차감한다. 2010-09-15 14 Intelligent Systems Research Lab.
15. 유즈케이스 명세서 액터의 움직임이 아닌 의도를 보여준다 사용자 인터페이스에서 사용자의 움직임을 서술할 필요 없음(인터페이스 상세 서술) 문서가 길수로 읽기 어렵고, 유지보수 비용도 높아진다. 서술된 대화(Dialogue)는 요구사항이기 보다는 그 순간에 작성자가 사용자 인터페이스를 상상하는 것에 가깝다. 대화(Dialogue)는 시스템이 조금만 변경되어도 작성된 부분을 무효로 할 수 있다는 점에서 불안정 사용자 인터페이스의 의도를 파악 일반적으로 한쪽 방향으로 전달되는 모든 데이터는 한 개의 행동 단계로 표현한다. 2010-09-15 15 Intelligent Systems Research Lab. 1.시스템이 이름을 묻는다. 2.사용자가 이름을 입력한다. 3.시스템이 주소를 묻는다. 4.사용자가 주소를 입력한다. 5.사용자가 ‘확인’을 클릭한다. 6.시스템은 사용자 정보를 보여준다. 1.사용자가 이름과 주소를 입력한다. 2.시스템은 사용자 정보를 보여준다.
16. 유즈케이스 명세서 작성 서식 유즈케이스 명 개요 짤막한 문장으로 해당 유즈케이스의 목적과 역할에 대해 기술 관련 액터 해당 유즈케이스와 상호작용하는 액터 사전조건(Pre-Condition) 유즈케이스가시작되기전에 반드시 만족해야 하는 조건 예) 주문 상품 변경을 위해서는 해당 주문이 결제가 미완료 상태이여야 함. 이벤트 흐름(Flows of Events) 해당 유즈케이스에서 시스템에 해야 하는 행위에 대한 서술(textual description) 복수의 이벤트 흐름이 존재(기본흐름, 대체흐름, 예외흐름) 사후조건(Post-Condition) 유즈케이스가 종료되면서 반드시 만족해야 하는 조건 특별 요구사항 2010-09-15 16 Intelligent Systems Research Lab.
17. 유즈케이스 명세서 2010-09-15 17 Intelligent Systems Research Lab. 상품구입 I.관련액터 고객액터 II.기본흐름 1. 고객이 상품목록을 찾아보고, 구매할 상품을 선택한다. 2. 고객이 계산을 시작한다. 3. 고객이 배송정보를 입력한다.(주소, 익일배송인지 일반배송인지) 4. 시스템에서는 배송비를 포함한 총 금액을 보여준다. 5. 고객이 신용카드 정보를 입력한다. 6. 시스템이 구매를 승인한다. 7. 시스템이 판매가 완료되었음을 즉시 확인한다. 8. 시스템이 확인메일을 고객에게 발송한다. III.대체흐름 3A.고객이 단골고객인 경우 1. 시스템이 현재의 배송비, 가격, 지불정보를 표시한다. 2. 고객이 기본사항을 그대로 이용하거나, 정보를 갱신한 후, 6번으로 간다. 6A.시스템이 신용카드 승인에 실패한다. 1.고객이 신용카드 정보를 다시 입력하거나, 취소한다.
18. 실습 과제 Thinkwise로 작성한 요구사항을 기능적 요구사항, 비기능적 요구사항으로 구분 기능적 요구사항을 유즈케이스 다이어그램으로 나타냄 유즈케이스 명세서를 작성 유즈케이스 명세서 템플릿은 홈페이지에 업로드 2010-09-15 18 Intelligent Systems Research Lab.
19.
20. 슬라이드 마스터 메인페이지, 제목페이지 두 장만 업로드레포트 2010-09-15 19 Intelligent Systems Research Lab. 추석특집 숙제!!
21. 참고자료 Usecase사이의 관계 Include 관계 하나의 유즈케이스가유즈케이스 내의 작업 흐름의 과정 안에 다른 유즈케이스의 작업 흐름을 포함하는 관계 여러 유즈케이스들 간에 비슷한 작업이 공통으로 발생하는 경우 특정 부분을 하나의 유즈케이스로 따로 분리하고 정의 A A <<include>> 구조화 C B B <<include>> 20 2010-09-15 Intelligent Systems Research Lab.
22. 참고자료 Usecase사이의 관계 Extend 관계 하나의 유스케이스의 흐름이 다른 유스케이스 내의 작업 흐름의 과정에 추가되어 작업 흐름을 확장하는 관계 <<extend >> A A 구조화 <<extend>> <<extend >> 21 2010-09-15 Intelligent Systems Research Lab.
23. 참고자료 Usecase사이의 관계 Generalization 관계 객체 지향 개념에서의 상속 관계와 유사해서 자식 유스케이스가 부모 유스케이스가 가지는 속성, 작업 흐름, 확장 지점, 다른 유스케이스와의 관계 등을 모두 가진다는 의미 현금결제 결제 카드결제 22 2010-09-15 Intelligent Systems Research Lab.
24. 유스케이스 작성에 대한 10가지 잘못 다른 형태의 요구사항 문서는 만들 필요가 없다. [유스케이스]면 요구사항을 충분히 반영할 수 있다. 아니다. 요구사항 문서는 요구사항을 가장 잘 반영할 수 있는 형태의 문서로 만들어야 한다. 데이터베이스 설계에 대한 요구사항은 ER모델이 적합하고, 화면 구조에 대한 요구사항은 그래픽이 가미된 문서가 더 적합하다. 읽는 사람이 [유스케이스]의 목적에 대해 이해하기 힘들게 한다. [유스케이스]의 이름을 지을 때 ‘작업하다’, ‘처리하다’와 같은 말을 사용하여 혼란스럽게 한다. 만약 읽는 사람을 혼란스럽게 하는 데 성공했다면 [유스케이스]를 실제로 구현할 때 어떻게 해도 상관없을 것이다.[유스케이스]를 이용해서 효과적으로 소프트웨어 시스템을 구현하기 위해서는 명확하게 [유스케이스]를 작성할 필요가 있다. 간혹 어떻게 [유스케이스]를 작성해야 하는지 모르는 경우에 이렇게 처리하는 경우가 있는데 좋지 않은 모습이다. [유스케이스]의 범위에 대해 혼란스럽게 한다. 범위는 어차피 점점 퍼져나갈 것이고 나중에 리펙토링을 하면 된다. 사용자는 어차피 생각을 계속 바꿀 것인데 왜 성가시게 범위를 미리 확정하겠는가?[유스케이스]는 만들려고 하는 시스템이 어떠한 범위를 다루는지를 표현하는 것에도 사용된다. 시스템의 범위를 명확히 하고 그것을 여러 관여자가 충분히 이해할 수 있도록 [유스케이스]를 작성해야 한다. 23 2010-09-15 Intelligent Systems Research Lab.
25. 유스케이스 작성에 대한 10가지 잘못 [유스케이스] 기술서에 비기능적 요구사항과 사용자 인터페이스 디테일을 포함시킨다.유스케이스의 작업 흐름에 사용자 인터페이스에 대한 세부 내용을 포함시키면 작업 흐름이 늘어나게 된다. 사용자 인터페이스를 요약한 내용을 추가하면 되지 상세한 내용까지는 포함시킬 필요가 없다. 초기 [유스케이스] 다이어그램에 포함 관계와 확장 관계를 많이 사용한다. 그러면 유스케이스를 작은 단위의 것으로 나눌 수가 있다.초기 버전의 유스케이스는 상위레벨의 유스케이스를 작성하고 반복을 거치면서 보다 상세화한 유스케이스를 작성하는 것이 좋다. CRUD를 처리하는 유스케이스가 대표적인데, 초기에는 ‘관리하다’라는 유스케이스로 하나로 만들고 이후에 반복을 통해 ‘생성’, ‘조회’, ‘수정’, ‘삭제’ 유스케이스로 세분화한다. 비즈니스 룰을 정의하는 것에는 관여하지 말라.비즈니스 룰을 만들고 사용하는 것은 사용자이지만 그것을 산출물로 표현하도록 하는 것은 매우 중요하다. 룰 자체를 만드는 것에는 관여할 필요가 없지만 그것을 [유스케이스]를 통해 표현하도록 독려해야 한다. 24 2010-09-15 Intelligent Systems Research Lab.
26. 유스케이스 작성에 대한 10가지 잘못 [유스케이스]의 작성에 도메인 전문가를 관여시키지 말라. 그들은 질문이나 해댈 뿐이다.[유스케이스]는 요구사항에 대한 표준 표기법인데, 소프트웨어 시스템에 대한 요구사항을 가장 잘 알고 있는 것은 도메인 전문가이다. 물론 이들이 작업을 성가시게 할 수도 있지만 좋은 결과를 내기 위한 고통이라 생각해야 한다. 만약 사용자를 [유스케이스] 정의에 관여시킨다면 그냥 그래라. 왜 사용자와의 미팅을 준비하는 데 골머리를 썩힐 것인가? 많은 양의 문서나 만들게 되고, 어쨌든 그들은 계속 마음을 바꾸게 될 것이다.될대로 되라는 식의 태도는 좋지 않다. 사용자에게 [유스케이스]를 충분히 이해시키고 [유스케이스]를 통해 효과를 볼 수 있도록 노력해야 한다. [유스케이스]를 한 번에 아주 상세하게 만들어라.반복적으로 점증적으로 [유스케이스]를 작성하는 것이 좋다. [유스케이스]를 검증하거나 평가하지 말라. 재작업이나 만들어 낼 뿐이다.반복적으로 점증적으로 작성하고 중간중간 계속 사용자나 도메인 전문가의 피드백을 받아야 한다. 25 2010-09-15 Intelligent Systems Research Lab.
30. 유즈케이스 유즈케이스 식별을 위한 질문 리스트 각 액터들이 해야 하는 일은 무엇인가? 시스템에서 정보를 생성, 저장, 변경, 삭제 또는 조회하는 액터가 있는가? 어떠한 유즈 케이스가 이러한 정보를 생성, 저장, 변경, 삭제 또는 조회하는가? 갑작스러운 외부의 변경사항을 시스템에 통지하는 액터가 있는가? 시스템에서 발생하는 어떤 상황들을 보고 받아야 하는 액터가 있는가? 어떠한 유즈 케이스들이 시스템의 지원과 관리를 수행하는가? 이 유즈 케이스들에 의해 시스템의 모든 기능적인 요구 사항들이 수행될 수 있는가? 2010-09-15 27 Intelligent Systems Research Lab.
31. 액터(Actor) 액터 도출 가이드 어떠한 요구사항에 관심을 가지는 사람은 누구인가 ? 조직 안에서 시스템이 사용되는 곳이 어디인가 ? 누가이 시스템을 사용함으로 이익을 얻는가 ? 누가 시스템에 이 정보 (예.학생정보)를 제공하고 사용하고 제거시키는가 ? 누가 시스템을 관리하고 지원할 것인가 ? 시스템은 외부 자원을 사용하는가? 한사람이 여러 역할을 하는가 ? 여러 사람이 같은 역할을 하는가 ? 액터는 시스템을 사용하는 역할이기 때문에 한 사람이 여러 역할을 한다면 여러 액터가 되는 것이고 여러 사람이 같은 역할을 하고 있다면 하나의 액터가 되는 것이다 시스템이 기존 시스템과 상호 작용하는가 28 2010-09-15 Intelligent Systems Research Lab.
