3.1 요구 모델링 Date : Create by kim wan yi

Presentation on theme: "3.1 요구 모델링 Date : Create by kim wan yi"— Presentation transcript:

1 3.1 요구 모델링 Date : 2010. 05.28 Create by kim wan yi
UML 이해와 실제 3.1 요구 모델링 Date : Create by kim wan yi

2 학습 목표 요구 모델링을 위한 요구사항 중요성을 인지하고 효과적인 요구사항 수집 및 명세기법을 이해한다
요구 모델링의 주요 모델링 기법인 유스케이스 모델링 기법을 알아본다. 특히 유스케이스 모델링 절차와 액터 및 유스케이스 식별, 명세방법을 이해한다. UML 표기법을 토대로 유스케이스 모델의 해석 방법과 실례를 통한 모델링 기술 및 가이드라인을 숙지하여 유스케이스 모델링 능력과 작성된 모델의 가독 능력을 배양한다.

3 3.1 요구 모델링 3.1.1 개요 1. 요구사항 중요성 2. 요구사항 유형
- 요구 사항은 구축하여야 할 시스템이 어떤 기능을 제공해야 하는지를 표현하고 있으므로 프로젝트 전 단계에서 참조해야 할 절대적 인 이정표 - 요구사항을 명확히 이해하지도 않고 분석, 설계, 개발단계를 진행하여 얻은 결과물은 부정확하고 완성도가 떨어져 사용자의 불신을 얻을 가능성이 많고 나중에 정확히 요구사항을 이해하여 해당 영역을 정정하더라도, 발생한 에러를 수정하는데 따른 부담은 프로젝트에 치명적 영향을 끼침 - 요구사항 정의 단계에서는 사용자와 합의 하여 요구사항을 작성하는 것이 좋고, 합의된 요구사항 명세서를 사용자가 확인하고 승인하는 절차를 통해 사용자의 프로젝트 참여도를 높일 수 있음은 물론, 개발 후반부에 발생할 수 있는 요구사항의 추가, 변경에 따른 분규의 소지를 어느 정도 완화 2. 요구사항 유형 1. 기능 요구사항 (Functional Requirements) - 시스템이 수행해야 하는 행위를 구체화한 것으로 향후 유스케이스 모델을 통해 분석됨 - 소프트웨어 개발주기의 분석단계 수행의 기준 2. 비 기능 요구사항 (Non- Functional Requirements) - 행위와 관련된 제약사항으로써 시스템이 가져야 하는 기능 이외의 요구사항(성능, 신뢰성, 편의성, 유지보수성, 보안 및 인증체계, 외부 인터페이스, 설계제약사항, 시스템 특성 ) - 아키텍쳐 정립과 설계단계에서 주로 고려됨

4 3. 요구사항 범위 IEEE에서 정의 한 소프트웨어 요구사항 범위는 요구공학 프로세스, 추출, 분석, 명세, 검증, 유지보수를 포함 4. 요구 사항 프로세스 - 요구사항 추출, 분석, 명세, 검증, 유지보수의 5단계 요구사항 추출 (Elicitation) 요구사항 분석 (Analysis 요구사항 명세 (Specification) 요구사항 검증 (Validation) 요구사항 유지보수 (Maintenance)

5 다양한 기법을 적기에 활용하여 사용자의 요구사항을 효과적으로 추출 할 수 있어야 함
1.) 요구사항 추출 고객, 시스템사용자, 그리고 시스템 개발에 관련된 이해당사자들과 서로 의견을 교환함으로써 실제로 개발하고자 하는 시스템에 대한 요구들을 찾아내는 공정, 다른 단계들보다 선행되는 단계이므로 가장 중요한 과정 사용자가 원하는 것이 무엇인지를 알아내며, 조직과 응용분야의 주의 깊은 분석과 개발될 시스템이 어떻게 사용되어야 하는가에 관한 내용들을 포함 다양한 기법을 적기에 활용하여 사용자의 요구사항을 효과적으로 추출 할 수 있어야 함 2) 요구사항 분석 사용자가 필요한 것을 알아내고 여러 제약사항들을 정리하는 공정, 어떻게 시스템을 만들 것인가 보다는 어떤 시스템을 만들 것인가를 분석하는 단계 분석 방법 : 1) 객체지향 중심분석 방법 OOA (Object-Oriented Analysis) 반복, 점진적으로 수행 2) 자료와 프로세스 관계를 중심으로 분석하는 방법 FOA (function –Oriented Analysis) 계층이 트리 구조로 형성되는데 상위 계층은 시스템과 입, 출력 관계를 추상적으로 나타내며, 하위 계층으로 가면 갈수록 더욱 세분하여 구체적으로 나타내게 됨 3) 요구사항 명세 - 분석된 요구사항을 명확하고, 정확하게 기록하여 문서화하는 공정 - 명세 방법 1) 자연어에 의한 방법 : 산업체에서 많이 사용하는 방법, 사용자와 개발자 모두 이해할 수 있다는 장점이 있으나 명확성 및 검증에 문제점이 있음 2) 정형화 기법: 명확성 및 검증에 대한 문제점을 해결할 수 있으나, 기법에 대한 사전지식이 없으면 일반 사용자들은 그 의미를 명확하게 이해할 수 없고 대형과제에 응용 사례가 적다는 문제점을 가지고 있음

6 4) 요구사항 검증 5. 요구 사항 관리 방안 2가지 작업을 통해서 검증
- 사용자들의 요구사항에 맞게 정확하고, 완벽하게 그리고 추적 가능하게 명세화 되었는지를 점검하는 단계 2가지 작업을 통해서 검증 1) 요구명세서가 내부적으로 일관성을 유지하고 있는지 와 형식에 맞게 작성 되었는지, 그리고 품질 기준에 적합한지를 확인하기 위하여 요구사항에서의 생략, 충돌, 그리고 모호성 등을 검사하는 것 2) 외부적으로 사용자나 고객이 명세서를 검증하는 것으로 검증의 어려움이 예상될 경우, 요구사항을 미리 확인해 보기 위해 프로토타입 기법을 사용 5) 요구사항 유지보수 - 새로운 요구사항 출현과 빈번한 변경이 발생함에 따라 이를 체계적으로 관리하는 활동 요구사항 변화관리, 요구사항 간의 추적성 관리, 관련양식의 표준화 준수 여부 등이 주요 관리대상 영역 5. 요구 사항 관리 방안 - 요구사항 관리의 목적은 프로젝트 요구사항을 소프트웨어 개발 생명주기 전 과정에 걸쳐 관리하여 사용자가 원하는 품질의 제품을 정해진 기한 내에 인도하기 위함, 관리의 핵심은 전 단계를 통해 추적성을 보장하는 것 - 요구사항 추적 관리는 프로젝트 진행 동안 고객의 요구사항이 반영되고 시스템화 되는 과정을 효과적으로 관리할 수 있는 중요한 활동

7 기법 적용 상황 단계 3.1.2 요구사항 수집 및 명세 1) 요구사항 수집기법
요구사항 수집은 요구사항 정의에 앞서, 시스템이 제공해야 하는 기능들이 무엇인지를 도출하는 과정 요구사항 수집 작업은 사용자의 적극적인 참여와 협조가 전제 요구사항 수집활동의 효과를 높이기 위해 치밀한 계획과 철저한 일정관리가 요구 프로젝트 관리자는 요구사항 수집 작업일정이 계획대로 완료될 수 있도록 지속적인 관심과 노력이 요구됨 1) 요구사항 수집기법 기법 적용 상황 단계 InterView 상위 요구사항을 도출할 때 사용자 필요를 파악하고자 할 때 사용자 문제를 효과적으로 이해하고자 할 때 의사 결정자들의 프로젝트에 대한 관심과 신임을 고조시키고자 할 때 추출 Questionnaire 시스템에 대한 전체 의사가 필요한 경우 현 시스템의 문제점을 파악하고자 할 때 사용자가 원격지에 있을 때 Role Playing - 사용자의 문제를 효과적으로 이해하고자 할 때 Workshop 요구사항 추출을 촉진시켜 요구사항 범위를 확정 하고자 할 때 단기간에 집중적인 노력을 들여 요구사항을 추출, 피드백을 받아 확정 하고자 할 때 실 사용자의 개선된 의사결정 및 책임의식을 기대할때 Brainstorming 짧은 시간 내에 많은 양의 아이디어를 획득하고자 할 때 판단과 비판을 유보하여 창의성을 극대화 할 때

8 기법 적용상황 단계 유스케이스 모델링 사용자 참여도를 높이고자 할 때 사용자와 효과적인 의사소통이 필요할 때 분석 데이터 모델링 - DBMS를 중심으로 업무를 파악하고자 할 때 프로토타이핑 사용자의 정확한 피드백을 얻고자 할 때 기술 검증이 필요할 때 위험 관리가 중요할 때 고객의 이해 증진과 공유를 위해 정확한 개발계획 수립이 필요할 때 Review - 고객과 함께 검토하고자 할 때 검증 Inspection 사용자 요구사항이 정확히, 완벽하게 그리고 추적성 있게 정의 되었는지 점검 할 때 Walk - Through - 객관성을 확보하기 위해 제3가 점검할 때 2) 요구사항 명세방법 - 요구사항 명세서는 분석 및 설계자에게 충분하고 자세한 수준의 정보를 제공할 수 있고, 시스템 테스트에 필요한 정보를 줄 수 있는 소프트웨어 요구사항의 모든 것으로, 각 요구사항은 유일한 ID와 함께 기술하여 향후 요구사항 관리를 위한 추적성을 보장할 수 있도록 작성 되어야 함 - 요구사항 명세는 사용자와 개발자가 함께 만드는 것이 가장 좋은 방법

9 명세 속성 내 용 정확성 (Correctness)
3) 요구사항 명세화 절차 현행 시스템 사용자 지침서나 인터뷰 결과와 같은 요구사항 관련 문서를 수집하여, 이를 토대로 기술서 개요를 작성하되, 프로젝트 목적과 기능 및 비 기능 요구사항을 파악하여 기술하고, 가정과 위험요소, 용어와 데이터 정의 및 사용자 인터페이스 식별등의 절차를 거쳐 명세화 4) 요구사항 명세 속성 명세 속성 내 용 정확성 (Correctness) 명세화 된 요구사항이 실제 시스템 구현 시 필요한 것인지 알 수 있도록 정확해야 한다 명확성 ( Clarity) 혼돈스럽지 않게 단 한가지로 해석되어야 한다. 완전성 ( Completeness) 시스템이 구현될 때 필요하고 요구 되어진 모든 것이 표현 되어야 한다 일관성 ( Consistency) 요구사항들 간에 충돌이 없어야 한다. 수정용이성 (Modification) 구조와 스타일의 일관성이 유지되면서 요구사항 변경이 용이하여야 한다. 추적성 (Traceability) 각각의 요구사항들이 그들간에 관련 있는 다른 요구사항과 유기적으로 연결되어 있어야 한다. 이것은 요구사항 변경이나 유지 보수에 매우 중요한 속성이다.

10 대구분 소구분 포함 항목 요구사항 명세서 포함 항목 : 기능 요구사항과 비 기능 요구사항을 중심으로 작성 개요
프로젝트 목표, 범위, 용어 및 정의, 약어, 참고 문헌등 일반사항 사용자 특성, 제약사항, 가정, 위험요소등 기능요구사항 업무 기능 각 업무별 제공기능을 온라인, 배치, 보고서 유형별로 분류하여 기술 비기능요구사항 시스템 기본 요건 성능: 시스템이 만족시켜야 할 처리 응답시간 수준(Local 및 Remote로 분류하여 정의) 신뢰성 : 오류가 발생하지 않으면서 시스템이 동작할 확률 편의성: 조작의 편리성과 사용의 편리성 유지보수성: 이식 및 추가, 변경용이성 및 효율성 보안 및 인증체계 : 사내 외 보안 및 인증정책 가용성: 사용자가 시스템을 사용할 수 있는 가용시간 및 기간 복구성: 시스템 장애발생시 업무재계를 위해 요청되는 시스템 기능 및 데이터 복구 방법 마이그레이션 : 유형 및 범위(대상, 데이터량) 사용자 인터페이스: 방식, 표준화 요건 산출물 : 산출물 종류 및 각 산출물별 갖추어야 할 요건 기술 요구사항 하드웨어: 플랫폼,서버, 클라이언트, 주변기기 소프트웨어 : O/S, 미들웨어, DBMS, 지원도구 네트워크: 네트워크 구성방식, 프로토콜, 장비 인터페이스 요구사항 인터페이스 기능: 디바이스, 연동해야 할 내부 및 외부 시스템 인터페이스 시점 전달하는 데이터 유형 및 포맷 전달받는 데이터 유형 및 포맷 < 요구사항 명세서 포함 항목 >

11 요구사항 관련 산출물 3.1.3 유스케이스 모델링 유스케이스 모델링 이란?
- 프로젝트에 참여하는 모든 이해당사자들에게 , 구축해야 할 시스템이 어떤 기능을 제공해야 하는지에 대한 동일한 목표를 제시 요구사항 관련 산출물 종류 : 비전 기술서, 요구사항 기술서, 소프트웨어 요구사항 명세서, 시스템 특성명세서 등이 있다. 비전 기술서 : 기존 시스템 문제점과 해결 방안을 기록하고, 프로젝트 목적을 각 이해당사자들의 시각으로 기술한 문서 3.1.3 유스케이스 모델링 - 소프트웨어 개발의 성공 여부는 요구사항을 정확히 파악할 수 있는지에 달려있음, 소프트웨어 프로젝트가 실패하는 주된 원인을 찾아보아도 대부분이 사용자 요구사항을 정확히 파악하지 못하는데 있음 유스케이스 다이어그램의 두 가지 목적 1) 사용자 요구사항이 제대로 도출 되었는지를 검증하기 위한 용도로 사용 2) 개발하고자 하는 시스템의 기능들을 제대로 이해하여 식별하였는지를 파악하기 위한 용도로 사용 - 유스케이스 다이어그램은 객체 지향 개념에 기반 보다는 기능 중심에 초점을 둔 다이어그램 유스케이스 모델링 이란? 이벤트 및 반응 방식 시스템 개발에 효율적인 모델링 방법 시스템 기능을 사용하는 사용자와 시스템간의 교류를 표현한 것 프로젝트 목표를 달성하기 위한 시스템의 사용 줄거리 사용자 관점에서 시스템의 요구사항(행동)을 설계하는 것 초기 요구사항 분석부터 마지막 시험, 배치 등 전 공정에서 사용할 수 있는 수단 시스템이 해야 할 일(Use Case) 과 시스템 주변(Actor)을 함께 표현한 모델 액터 와 유스케이스 관계로 구성

12 << include>>
UML 표기법 및 유스케이스 모델링 절차 대구분 소구분 표기법 구성 요소 (Elements) 액터(Actor) 유스케이스(use case) 시스템 바운더리 (system boundary) 관계 (Relationships) 일반화 (Generalization) 연관관계 (Association) 포함 (Include) << include>> 확장 (Extend) << extend >> Use case name 유스케이스 관련 UML 표기법

13 주요 단계 세부 절차 1. 액터 식별 - 액터를 먼저 도출하고 그 역할을 정의 2. 유스케이스 식별
- 사용자가 시스템을 통해 얻으려고 하는 기능을 유스케이스 단위로 식별 3. 유스케이스 다이어그램 작성 액터와 유스케이스간 관계를 설정 유스케이스들 간 관계를 설정 유스케이스 다이어그램을 검토 4. 유스케이스 명세서 작성 유스케이스명, 액터명 및 개요를 기술 사전 및 사후 조건과 제약사항들을 식별 작업(정상, 대치, 예외) 흐름과 시나리오를 도출 유스케이스 흐름에서 포함(include)이나 확장(extend)유스케이스로 구조화 5. 사용자 승인 - 사용자 리뷰를 통해 확인하고 승인을 득함 6. 추적성 보장 - 변경사항을 관리하고 그 이력을 관리 7.유스케이스 실체화 - 유스케이스를 인터렉션 모델로 실체화 유스케이스 모델링 절차

14 액터 식별 - 액터의 명칭은 특정 사람의 이름을 사용해서는 안되며, 사람의 역할명 이나 외부 시스템명 으로 기술
- 액터는 시스템 외부에 존재하는 사람 또는 사물로써, 시스템을 접근하는 사용자 및 사물의 역할명을 액터로 표현하고, 시스템 외부에 존재하는 타 시스템이나 데이터베이스 서버 등을 표현하기도 함 - 액터의 명칭은 특정 사람의 이름을 사용해서는 안되며, 사람의 역할명 이나 외부 시스템명 으로 기술 - 액터는 요구사항 명세서에서 시스템에 이벤트를 주거나 시스템으로부터 정보를 받게 되는 외부 개체에 해당하는 사람 또는 사물로 식별 실습: 예제: 인터넷 쇼핑몰 시스템 우리는 인터넷을 통해 물품을 판매하는 시스템을 구축하고자 한다. 고객은 회원등록을 통해 본인 정보를 등록하고, ID, Password를 입력함으로써 시스템에 접속할 수 있으며, 물품을 구입할 수 있다. 고객이 회원 로그인 을 할 때 및 물품을 구입할 때에는 별도 암호화 된 모듈을 통해 본인확인 절차를 거쳐야 한다. 물품을 구매하여 결재할 때에는 일반 포인트를 결재할 수 있으며, 신용카드를 통해 결재할 수도 있다. 신용카드를 통해 결재하고자 하는 경우에는 협약을 맺은 카드 승인회사에게 카드승인을 요청하여야 한다. 고객은 구매한 물품의 배송상황을 조회할 수 있으며, 직원도 고객 물품에 대해 배송추적을 할 수 있다. 고객 직원 카드승인 시스템 액터 식별 예

15 유스케이스 식별 - 유스케이스는 사용자 입장에서의 기능 요구사항이며, 액터가 특정 목표를 달성하기 위하여 해당 시스템에서 수행해야 하는 일련의 행동으로써 시스템에서 제공해야 하는 독립적인 기능군을 의미 - 외부시스템과 상호작용하는 행위들의 집합, 시스템 또는 서브시스템의 필수 행동 및 범위를 표현하여 최종 사용자 또는 고객과의 의사소통 수단을 제공 대상 행동 자체만을 명세하는 것 실습 : 인터넷 쇼핑몰에서 제공하여야 할 주요 기능인 “회원등록”, “ 회원로그인”, “ 물품구매”, “ 배송조회”, “ 본인확인”, “ 신용카드지불” 등의 유스케이스 추출 본인확인 유스케이스의 경우 다른 유스케이스에서 공통적으로 사용할 수 있는 기능군임을 고려하여 별도의 유스케이스 도출 신용카드 지불 유스케이스의 경우에도 카드승인시스템에서 처리하는 일련의 기능을 제공하기 위해 유스케이스로 도출 회원 등록 회원 로그인 물품 구매 배송 조회 본인확인 신용카드 지불 유스케이스 식별 예

16 유스케이스 다이어그램 작성 1) 액터와 유스케이스간 관계 설정
액터와 유스케이스와의 관계를 설정하기 위해서는 해당 액터와 이벤트를 보내거나 받는 유스케이스를 찾아 액터와 유스케이스간의 연관 관계를 맺도록 도식 2) 유스케이스들 간 관계 설정 유스케이스 다이어그램에서 유스케이스 간의 관계는 의존성(Dependency)으로 표현되며, 스테레오타입으로 그 관계를 명확하게 표현한다. 유스케이스 간의 관계는 <<include>>와 <<extend>>로 표현, 이는 각 유스케이스 간에 포함(include)관계 및 확장(extend)관계로 이루어짐 - include 관계 실습 include관계는 여러 유스케이스들에서 중복적으로 나타나는 기능들에 대해서 이러한 기능들을 별도의 유스케이스로 추출한 뒤, 관련된 유스케이스와 연결을 맺어줄 때 사용하는 관계 include 관계를 맺는 유스케이스는 여러 유스케이스들에서 중복적으로 사용되며, 반드시 include하는 유스케이스를 포함하는 형태로 상위 유스케이스가 실행됨 회원등록 액터와 유스케이스간 관계 설정 예 회원로그인 물품구매 본인확인 <<include>>

17 특정 한 유스케이스 내에서 유스케이스 내의 흐름이 특정 시점의 특정조건에서 여러가지 형태로 분류될 경우에 사용하는 관계
- extend 관계 실습 특정 한 유스케이스 내에서 유스케이스 내의 흐름이 특정 시점의 특정조건에서 여러가지 형태로 분류될 경우에 사용하는 관계 중복적으로 사용되지 않고 특정 조건에서 한 유스케이스로만 파생되어 표현되며, 확장(extend)하는 유스케이스는 상위 유스케이스로 부터 어떠한 특정 조건에 의해 수행됨을 의미 유스케이스 다이어 그램 검토 신용카드지불 물품구매 <<extend>> 회원등록 회원로그인 물품구매 본인확인 배송조회 신용카드지불 고객 직원 카드승인시스템 <<include>> <<extend>> 인터넷 쇼핑몰 시스템의 유스케이스 다이어그램 예

18 유스케이스 명세서 작성 - 유스케이스 다이어그램에서 유스케이스는 시스템이 수행해야 할 기능이 무엇인지 만을 표현한다. - 유스케이스 명세서는 각각의 유스케이스에 대해서 해당 유스케이스가 어떻게 수행되는지를 표현하는 수단 실습 다음은 회원등록 유스케이스 명세서 예이다 유스케이스명: 회원등록 액터: 고객(비회원) 설명: 비회원이 인터넷 쇼핑몰 시스템을 사용하기 위해 회원 가입을 하는 유스케이스이다. 사전 조건: 회원에 가입 되어 있지 않은 상태여야 한다. 정상 흐름 액터 시스템 1. 회원등록을 요청한다. 3. 회원약관에 동의(E-1) 한다 5. 회원정보 항목(비밀번호, 비밀번호 재입력, 이름, 주민등록번호, 등)을 입력하고 등록요청을 한다 2. 회원약관을 보여준다. 4. 회원정보 입력항목을 보여준다. 6. 입력된 정보를 확인 (E-2)한다 7. 기존 가입 회원인지를 주민등록번호를 검색하여 확인(E-3)한다 8. 회원정보를 저장, 등록을 완료한다.

19 E-1a. 회원약관에 동의 하지 않을 경우 ‘약관 동의하에 회원가입 가능’ 오류 메시지를 보여주고 동의를 요청한다.
- 대치 흐름 : 해당사항 없음 - 예외 흐름 E-1a. 회원약관에 동의 하지 않을 경우 ‘약관 동의하에 회원가입 가능’ 오류 메시지를 보여주고 동의를 요청한다. E-2a. 회원 정보입력항목 중 입력하지 않은 항목이 있을 경우 오류 메시지를 띄우고 재입력을 요청한다. E-2b. 비밀번호가 4~8자리에 해당하지 않을 경우나 특수문자가 입력되었을 경우 오류 메시지를 보여주고 재입력을 요청한다. E-3a. 기존에 가입 되어 있는 회원인 경우 ‘ 이미 가입된 회원입니다.’ 라는 메시지를 보여준다. 시나리오 물품구매를 위해 홍길동은, 1234(비밀번호), 1234(비밀번호 재입력), 홍길동(이름), (주민등록번호), 내용으로 회원등록을 완료하였다. 유스케이스 실체화(Realization) 도출된 기능중심의 유스케이스를 구현시스템의 구성요소로 구체화 시키는 형태로 진행되며, 명세서 중심의 유스케이스를 유스케이스 실체화 과정을 통해 구현 시스템의 논리적 구성요소인 클래스를 식별하고 이의 협력(collaboration) 관계를 파악하는데 중점을 두는 과정이다. 유스케이스 모델링 관련 FAQ(Frequently Asked Question) - 유스케이스 크기에 관한 문제 유스케이스 크기에 대한 기준이 모호하여, 개발자간 식별된 유스케이스 크기 차이가 많은 문제점이 종종 발생 크기 결정에 대한 대안을 사전에 검토하여야 하며 검토된 각 방안을 충분히 이해한 후 프로젝트와 업무 특성을 고려하여 적절한 방안을 선택함으로써 크기의 일관성을 확보하여야 함

20 - CRUD(create/Read/Update/Delete) 기능의 유스케이스 추출 문제

21 Thank You