Use Cases 컴포넌트비젼(주) 이경원 email: kwlee@componentvision.com

소프트웨어 개발 과정 요구사항 수집(Requirements gathering) 분석(Analysis) 설계(Design) 구현(Construction) 검사(Testing) 배포(Deployment) 유지보수(Maintenance)

소프트웨어 개발 과정 요구사항 수집(Requirements gathering)  우리의 관심사!! 분석(Analysis) 설계(Design) 구현(Construction) 검사(Testing) 배포(Deployment) 유지보수(Maintenance)

전통적으로 요구사항 수집은… 오래 걸리는 잘못된 것을 기록하는 발생하지 않을 일을 추측하는 시간에 맞춰 끝나기는 하지만 급변하는 비즈니스 환경 덕에 재작업이 필요하게 되는 경향이 있다

요구사항이 어쨌는데?

요구사항이란 무엇인가? 컴퓨터 어플리케이션이 사용자에게 제공해야 하는 어떤 것 요구사항들이 소프트웨어 개발 프로젝트의 범위(Scope)가 된다. 시스템이 사용자에게 어떤 응답을 해야 하는가를 제시한다. 요구사항은 ‘어떻게’가 아니라 ‘무엇을’에 관한 사항이다. 요구사항은 대게 추상적이거나 불분명하다. 개발자의 두뇌 안에 요구사항과 디자인이 늘어 붙는 경향이 있다. 요구사항과 디자인을 분리시키는 것이 매우 중요하다.

요구사항 구성요소 기능적 요구사항 비 기능적 요구사항 시스템이 사용자를 위해 해 줬으면 하는 일들에 대한 요구사항. 사용자에게 중요하지만 일반적으로 감춰져서 잘 깨닫지 못하는 요구사항.

비 기능적 요구사항 정의 Availability Rate of hardware and software component failure (mean time between failures) Cost of ownership Overall operating costs to the organization after the system is in production Maintainability Ability of the support programming staff to keep the system in a steady running state, including enhancements Data integrity Tolerance for loss, corruption, or duplication of data Development cost Overall cost of development Extensibility Ability to accommodate increased functionality Flexibility Ability to handle requirement changes Functionality Number, variety, and breadth of user-oriented features Installability Ease of system installation on all necessary platforms Leverageability/Reuse Ability to leverage common components across multiple products Operability Ease of everyday operation; level of support requirements Performance Ability to meet real-time constraints in batch and online Porability Ability to move the application to different platforms or operating systems Quality Reduced number of severe defects Robustness Ability to handle error and boundary conditions while running Scalability Ability to handle a wide variety of system configuration sizes

요구사항 정의 견본 요구사항 리스트 Requirement Definition 6.7.1.4.2 The system must provide the capability to capture all of the customer transactions for the fiscal year. 6.7.1.4.3 The system will provide restricted remote inquiry access(via dial-in) to view images and data separately or simultaneously. 6.7.1.4.4 The system will barcode documents automatically prior to distribution. At a minimum, the codes will be used to identify to which work queue the documents should be routed within the organization when they are returned. 6.7.1.4.5 When a workflow is initiated, the system must be able to prefetch the documents that are in electronic image format by document type or grouping of documents by process. 6.7.1.4.6 The system must create an entry in the journal file whenever a letter is created. … 이런게 100페이지 이상 …

요구사항 정의가 산으로 가네?… 요구사항 수집 활동이 비 생산적인 경로를 거치기 때문. 요구사항 수집이 무시되는 경향이 있다. 개발팀은 시스템이 어떻게 작동해야 하는지에 대한 가정을 기반으로 해서 곧바로 솔루션 작성에 들어간다. 요구사항 수집에만 매달리는 수도 있다. 수백 장에 달하는 ‘요구사항’들이 수집되고, 문서화 되고, 상호참조 되고, 뿌려져서 결국 ‘Analysis Paralysis’가 되고 프로젝트는 취소된다. 요구사항을 한 사람이 결정한다. 시스템 오너나 고위급 경영자만을 위한 시스템이 만들어 진다. 전산인들이 요구사항에 대해 헛 짚는 전형적인 사례 디자인에 대한 생각이 개입 애매 모호 한 듯 하면서 분명치 않은 것 같은 전산인들만의 은어 사용

기능 요구사항을 표현하는 전통적인 방법 Requirements specifications “시스템은 ~~해야 한다”식의 나열. 요구사항이 중복되거나 상충되기 쉽다. 좀더 구조화된 먼가가 필요 Data-flow diagrams (DFDs) 시스템 내부 동작에 초점을 둠. 사용자와 별 연관 없는 자료 흐름이 상세화 된다. 요구사항에는 부적절 Entity-relationship diagrams (ERDs) 데이터의 논리적인 모델과 데이터베이스의 구조를 보여줌. 동적인 상호작용을 보여주지 못한다. 자료 모델링에 적합 Prototypes 시스템의 기능을 보여주는 시제품. 사용자 인터페이스가 강조되는 경향이 있다.

유스케이스 등장~ 1960년대 후반 Ivar jacobson 박사에 의해 개념이 만들어짐 1980년대 후반 요구사항 정립의 수단으로 OOP 커뮤니티에서 각광을 받음 1990년대 중반 Ivar jacobson 박사가 Rational에 합류하면서 유스케이스가 UML에 편입 현재 UML1.4와 RUP의 핵심적인 개념으로 사랑 받고 있음.

유스케이스가 어쨌는데?

유스케이스란 무엇인가? 요구사항을 뽑아내는 수단. 기능적 요구사항을 정의하는 것의 기반. 어플리케이션을 가늠해 보는 것을 수월하게 한다. 시스템의 범위를 정하는 것을 돕는다. 최종사용자 혹은 고객과의 의사소통 수단. 시스템의 동적인 black-box view를 제공한다. 객체 도출의 기반 요구사항의 흔적을 찾을 수 있는 수단. 사용자 인터페이스나 경험 설계의 기반. 기능적 요구사항에서 객체/컴포넌트 구조로 되는 것을 수월하게 한다. 기능을 객체/컴포넌트에 할당하는 것의 기반. 객체의 인터페이스와 상호작용을 정의하는 메커니즘 데이터베이스에 접근하는 패턴을 정의한다. 프로세서 용량을 재는 것을 도와준다. 통합 테스팅의 기반. 테스트 케이스를 정의한다. 점증적 개발의 기반. 프로젝트 규모와 필요한 자원의 예측하는 것을 돕는다. 사용자 문서와 매뉴얼의 기반을 제공한다. 프로젝트 관리의 도구. 개발 과정을 조정한다. 비즈니스 프로세스를 표현하는 표준 방법. 리엔지니어링 과정에서 레가시 시스템을 설명하는데 사용됨. e-비즈니스 기업이 되기 위해 리엔지니어링을 할 때 사용됨. … 대신에 Snake oil이나 Silver bullet은 아니다.

그래서 유스케이스란 무엇인가? 요구사항을 뽑아내는 수단. 시스템의 범위를 정하는 것을 돕는다. 최종사용자 혹은 고객과의 의사소통 수단. 유스케이스 다이어그램과 유스케이스 기술서로 구성되어 있다.

유스케이스 다이어그램

액터 (Actor) 특정 작업을 완수할 목적으로 시스템과 상호 작용하는 사람이나 사물의 역할. 액터 사례 사람 - 텔레마케터 외부시스템 - 청구시스템 장치 - 열 감지 센서 외부조직 - 금융감독원 이벤트 발생시점 - 매일 밤 2시 Primary 액터, Secondary 액터 - [Ivar Jacobson]

액터 (Actor) 액터의 성격에 따른 분류 Initiator – 유스케이스를 시작시킨다. External server – 유스케이스 내에서 시스템에 서비스를 제공한다. Receiver – 유스케이스로부터 정보를 전달 받는다 Facilitator (proxy) – 다른 액터와 시스템간의 상호작용을 돕는다. initiator Facilitator

유스케이스 (Use Case) 시스템이 액터에게 주목할 만한 결과를 내놓기 위해 수행하는 여러 작업들의 집합 – [Booch 1999] 유스케이스는 하나의 목표와 사용자가 목표에 달성하기 위해 수행하는 시도에 따라 발생하는 모든 가능한 사항을 기술한다. 유스케이스 사례 대출을 신청한다. 대출 현황을 점검한다. 유스케이스의 분화 비즈니스 유스케이스 (business use case) 시스템 유스케이스 (system use case) 체인지 케이스 (change case) 테스트 케이스 (test case) 비즈니스 케이스 (business case)

포함 (include) 관계 유스케이스의 이벤트 흐름 안에 다른 유스케이스의 행동을 포함하는 것. 유스케이스 간에 공통 발생 부분을 뽑아내서 참조하게 한다. Including유스케이스는 included유스케이스 없이는 제구실을 못한다.

확장 (extend) 관계 한 유스케이스의 인스턴스가 다른 유스케이스의 기능에 의해 확장되는 것. 확장시키는 유스케이스를 별도로 해서 관리를 용이하게 한다. 확장되는 유스케이스의 수정 없이 기능 추가를 할 수 있다. Extended유스케이스는 extending유스케이스 없이도 제구실을 한다. Extension point~!

유스케이스 기술서 유스케이스는 시스템의 기능에 대한 서술 표현 이름과 서술부분으로 구성되어 있다. 다양한 종류의 유스케이스 서술법이 존재한다. 워드 파일 노츠 위키위키

유스케이스 기술서의 구성요소 이름 (Name) 반복 (Iteration) 액터 (Actor) 범위 (Scope) 수준 (Level) 요약 (Summary, Brief Description) 주 사건 흐름 (Main flow of event) 대안 흐름 (Alternative flow) 예외 흐름 (Exception flow) 사전조건 (Pre-condition) 사후조건 (Post-condition) 비즈니스 룰 (Business Rule) 사용자 화면 (User Interface) 작성자 (Author) 작성일 (Date) …

유스케이스 기술서 양식 <the name should be the goal as a short active verb phrase> Context of Use: <a longer statement of the goal, if needed, its normal occurrence conditions> Scope:<design scope, what system is being considered black-box under design> Level:<one of: summary, user-goal, subfunction> Primary Actor:<a role name for the primary actor or description> Stakeholders and Interests: <list of stakeholders and key interests in the use case> Precondition:<what we expect is already the state of the world> Minimal Guarantees:<how the interests are protected under all exits> Success Guarantees:<the state of the world if goal succeeds> Trigger:<what starts the use case, may be time event> Main Success Scenario: <put here the steps of the scenario from trigger to goal delivery and any cleanup after> <step #> < action description> Extensions: <put here there extensions, one at a time, each referring to the step of the main scenario> <step altered><condition>:<action or sub use case> Technology & Data Variations List: <put here the variations that will cause eventual bifurcation in the scenario> <step or variation #><list of variations> Related Information: <whatever your project needs for additional information>

유스케이스 기술서 양식 Use Case 25 Actually Login Primary Actor: User Scope: Application Level: Subfunction Upon presenting themselves, the user is asked to enter a username and password. The system verifies that a submitter exists for that username and that the password corresponds to that submitter. The user is then given access to all the other submitter commands. If the username corresponds to a submitter that is marked as an administrator, then the user is given access to all the submitter and administrator commands. If the username does not exist, or if the password does not match the username, then the user is rejected

유스케이스 기술서 양식 Use Case # <the name is the goal as a short active verb phrase> Context of use <a longer statement of the context of use if needed> Scope <what system is being considered black box under design> Level <one of summary, primary task, subfunction> Primary actor <a role name for the primary actor, or a description> Stakeholder and interests stakeholder Interest <stakeholder name> <put here the interest of the stakeholder> Preconditions <what we expect is already the state of the world> Minimal guarantees <the interests as protected on any exit> Success guarantees <the interests as satisfied on a successful ending> Trigger <the action upon the system that starts the use case> Description step Action 1 <put here the steps of the scenario from trigger to goal delivery and any cleanup after> 2 <…> 3 Extensions Step Branching Action 1a <condition causing branching>:<action or name of sub use case> Technology and data variations <list of variations>

유스케이스 기술서 양식 Customer System Enters order number Detects that the order number matches the winning number of the month. Registers the user and order number as this month’s winner. Sends an e-mail to the sales manager. Congratulates the customer and gives her instructions on how to collect the prize. Exits the system

유스케이스 기술서 양식 1. Use Case Name 1.1. Brief Description …text… 1.2. Actors 1.3. triggers 2. Flow of events 2.1. Basic flow 2.2. Alternative flows 2.2.1. Condition 1 2.2.2. Condition 2 2.2.3. … 3. Special Requirements 3.1. platform 3.2. … 4. Preconditions 5. Postconditions 6. Extension Points

유스케이스 어떻게 만드나?

코번의 12단계 시스템의 범위와 경계 설정 시스템에 관계된 모든 액터 찾기 사용자가 시스템을 통해 얻으려고 하는 것(use case)들 찾기 각 액터에 대한 최 외각 유스케이스(summary use case) 설정. 최 외각 유스케이스들에 대한 정제 작업(시스템 범위의 재확인) 상세 작업을 할 유스케이스 선택 이해 관계자와 그들의 이(利), 선행조건, 후행조건 등을 뽑아냄 주 성공 흐름 작성 대안 흐름과 예외 흐름 찾기. 대안 흐름과 예외 흐름 작성. 복잡한 스텝을 하위 유스케이스로, 자잘한 스텝들은 모아서 하나로 유스케이스 조절작업(읽기는 쉬운지, 구색은 갖췄는지, 이해관계자는 만족하는지)

Advanced Use Case Modeling Framework 스테이크 홀더 분석 수행 유스케이스 프레임웍 선택과 맞춤작업 개발 툴, 템플릿, 개발 표준 선택 교육과 컨설팅 필요성에 대한 결정 컨텍스트 다이어그램 작성 주요 액터를 찾는 작업 개념적 시스템 유스케이스를 찾는 작업 초기 유스케이스 다이어그램 작성 개념적 비즈니스 객체 결정 테스트 전략 작성 테스트 계획 작성 테스트 케이스 작성 사용자 도큐먼트 작성 기본 유스케이스 설명 작성 기본 유스케이스 설명 갈고 다듬기 작업 유스케이스간의 관계 작성 유스케이스와 객체 모델간의 연관관계 작성 유스케이스 시나리오 작성 비즈니스 기능적 패키지 작성 유스케이스 의존 관계 찾는 작업 스테이크 홀더의 입장에서 유스케이스 조직화 유스케이스 모델 리팩토링 Prepare for use case modeling Perform initial use case modeling Expand on the use case model Create test cases and documentation Organize the use cases Ongoing use case management *Advanced use case modeling 발췌

좀 추려서 정리하면… 시스템의 범위를 결정하고 액터를 찾고 유스케이스의 이름 정도를 찾고 유스케이스의 주 성공 흐름을 작성하고 유스케이스의 대안/예외 흐름을 작성하고 적절히 패키징 해서 정리한다.

반복을 통해 상세함을 더한다 Initial Base Elaborated 이름 : 이름 : 이름 : 액터 : 액터 : 액터 : 요약 : 이름 : 액터 : 요약 : 선행조건 : 사건 흐름 : 사후조건 : 이름 : 액터 : 요약 : 선행조건 : 사건 흐름 : 사후조건 : 대안흐름 : 예외흐름 :

자주 논의되는 사항들

적절한 Use-Case의 크기는?

Use Case Level Summary Goals User Goals Subfunction Overall Project Advertise Order Invoice User Goals Set Up Promotion Reference Promotion Monitor Promotion Place Order Create Invoice Send Invoice Identify Promotion Register User Identify Product Identify Customer Subfunction

왜? 어떻게? Summary Goals Why? User Goals How? Subfunction

적절한 레벨을 찾아라 유스케이스에 적절한 골 레벨을 표시 : summary, user, subfunction 내 ‘goal’들 중에서 user goal레벨이 어디인지를 점검 한사람이 한자리에 앉아서 한번(2분~20분)에 끝낼 수 있는 정도 종료되었을 때 액터가 자리를 뜨는데 어려움이 없는 정도 대부분의 유스케이스는 주요 이번트 흐름이 3~9단계. 만약 9단계가 넘는다면 다음과 같은 스텝들을 하나로 합쳐라. 같은 액터가 여러 스텝을 점유 액터가 사용자 인터페이스를 사용하는 부분에 대한 상세한 스텝들 두 액터들간의 간단한 주고 받는 스텝들 “왜 액터가 이 스텝을 밟고 있나?” 에 대한 대답이 바로 다음 상위 레벨이 된다. Subordinate use case vs. Sub use case

Use Case 는 Functional decompositon이다!

대가들의 대답 기능 분할이 문제 해결 구조의 밑바탕으로 사용되지 않는 한 문제 영역을 기능분할 하는 것에 문제될 것은 없다. – Robert C. Martin 시스템의 내부 구조가 외부 구조(Use cases)처럼 보여야 할 필요는 없다. – Martin Fowler

CRUD는 어떻게 처리하나?

CRUD use case Create, Retrieve, Update, Delete VS. Manage 코번 초반에는 유스케이스의 숫자를 적게 하기 위해 manage로 처리한다. 유스케이스가 점점 복잡해지면 새로운 하위 레벨로 유스케이스를 뽑아낸다. Summary 레벨의 Manage와 서브 레벨의 CRUD를 모두 보유.

어떤게 잘 못된 유스케이스인가?

전통적인 실수들 액터가 없는 유스케이스, 시스템이 없는 유스케이스 사용자 인터페이스의 내용을 너무 상세히 담고 있는 유스케이스 너무 낮은 레벨의 유스케이스 전산인의 언어를 사용한 유스케이스 어플리케이션 관점의 유스케이스 스타일을 변환한다. 스타일을 적용한다. 다른 문서의 스타일을 가져온다. 문서내의 양식을 일정하게 한다. 문서가 다른 문서와 비슷하게 보이게 한다. …

Reference Writing Effective Use Cases – Alistair Cockburn Advanced Use Case Modeling software systems – Frank Armour, Granville Miller Use Cases requirements in context – Daryl Kulak, Eamonn Guiney Applying Use Cases, Second Edition a practical guide – Geri Schneider, Jason P. Winters Etc …

Happy Modeling !! 감사합니다.