-
Inception Phase
시작 단계에서 나타날 의문
What is the vision and business case for this project?
Feasible?
Buy and/or build?
Rough estimate of cost: Is it $10K-100K or in the millions?
Should we proceed or stop? -
Inception을 한 문장으로 하자면
제품 범위, 비전 및 비즈니스 사례 구상 이다.해결할 주요 문제
이해 관계자가 프로젝트의 비전에 합의 했는지
진지한 조사에 투자할 가치가 있는지
-
시작 단계에서 산출물
Vision and Business Case :
높은 수준의 목표와 제약 조건, 비즈니스를 설명합니다.
사례 및 요약 정보를 제공합니다.Use-Case Model :
기능 요구사항 및 관련 비기능 요구사항을 설명합니다.Supplementary Specification(추가 설명서) :
다른 요구사항 설명Glossary(용어 사전) :
주요 도메인 용어 설명Risk List & Risk Management Plan :
완화 또는 대응에 대한 비즈니스, 기술, 리소스, 일정 리스크 및 아이디어를 설명합니다.Prototypes and proof-ofconcepts :
비전을 명확히 하고 기술 아이디어를 검증합니다.Phase Plan & Software Development Plan :
정교화 단계 기간 및 노력, 도구, 인력, 교육 및 기타 리소스에 대한 대략적인 추측.Development Case :
이 프로젝트의 사용자 지정된 UP 단계 및 아티팩트에 대한 설명입니다. UP에서는 항상 프로젝트에 맞게 커스터마이징합니다.
- Development case는 프로젝트에 특화된 프로세스로 customized process라고도 함
-
유용한 분류
기능적 요구사항 vs 비기능적 요구사항
비기능적 요구사항의 대부분은 집합적으로 불린다. 품질 속성 또는 품질 요구 사항으로
기능 요구사항을 찾고 Use case model에 기록한다.
다른 요구사항은 관련 use cases나 추가 설명 산출물에 기록합니다.
Vision 산출물은 높은 수준의 요구사항을 기록합니다.
용어집에는 유효성 검사 규칙, 허용 가능한 값 등과 같은 데이터와 관련된 요구 사항을 기록하는 데이터 사전의 개념이 포함되어 있습니다. -
Use case를 쓰는 이유
기능 요구사항을 분석, 기록 및 개선하기 위한 툴이 필요
=> 요구사항의 의미가 뭔소린지개발자는 무엇을 구현할 것인지 정확히 알아야 함
=> 기능 요구사항을 수집하고 분석할 수 있는 툴 필요
=> 시스템의 기능을 가능한 한 빨리 모델링할 수 있는 도구 필요고객은 구현될 내용을 이해해야 합니다.
=> 시스템이 개발된 후에 검증과정이 필요함답은 유스케이스다.
-
목표 & 이야기
고객 및 최종 사용자와 같은 이해 당사자는 목표(일명 요구)를 가지고 있으며 시스템이 이를 충족시킨다.
이해관계자: SuD(System under Design)의 행동에 대한 기득권을 가진 사람 또는 사물
(SuD란 시스템을 의미)유스케이스란 목표를 달성하기 위한 시스템 사용에 대한 이야기이다.
목표와 시스템의 기능 요구사항을 파악하는 가장 효과적인 방법은 유스케이스를 작성하는 것이다.
유스케이스는 간단하고 친숙하기 때문에 클라이언트와 최종 사용자가 정의 또는 평가에 기여할 수 있습니다.
-
Actors
기본 정의:
배우란 SuD와 상호작용하는 SuD 이외의 모든 것을 말한다.
예를 들어 사람, 하드웨어 장치, 조직 또는 다른 시스템.확장 정의
배우는 행동을 가진 모든 것이다, 다른 배우들의 서비스에 대한 요청을 할 때 SuD 조차도
(행위자와 목표 모델 관점에서 사용 사례를 볼 때만) 사람 액터의 경우, 유스케이스 내에서 그 사람이 연기하는 역할을 나타낸다.
-
액터 타입 분류
Primary actors
Primary 액터는 자기의 목적 달성을 위해 시스템을 사용하는 주체
유스케이스를 시작(triger)하는 역할을 함. (근데 100%는 아님)왜 사용하는가 => 사용자의 목표(Goals)를 파악할려면 누가 우리 시스템을 사용하는지 알아야함
Supporting actors
Supporting 액터는 SuD에게 서비스를 제공해줄 목적으로 시스템 외부에서 시스템과 교류하는 대상
왜 사용하는가? => 외적인 인터페이스와 프로토콜을 명료하게 하기 위해서
Offstage actors
Offstage 액터는 무대 밖에 있는 actor로 직접적인 이해관계는 아니지만 유스케이스의 행동에 간접적으로 이해관계가 있음 ex 금융감독원
왜 사용하는가? => 유스케이스를 작성하는 단계별에서 Offstage의 이해관계를 만족하는 과정이 필요함
-
시나리오
시나리오(유스케이스 인스턴스)는 행위자와 SuD가 공통의 목표를 달성하기 위해 수행하는 행동과 상호작용의 특정 순서이다.
시스템 사용에 대한 하나의 특정 스토리 또는 사용 사례를 통한 하나의 경로입니다.
-
Use Cases
일반적으로 유스케이스를 다음과 같이 정의한다.
목적 달성을 위해서 액터가 시스템을 사용하며 성공하거나 실패하는 이야기를 묶어놓은 것이다.유니파이프로세스에서는 유스케이스를 다음과 같이 정의한다.
각각의 인스턴스는 관측할 수 있는 값의 결과를 생산하는 액션의 시퀀스(스토리)이다.사용자의 입장에서 시스템의 행위가 유스케이스이다.
-
유스케이스의 제목을 보면 유스케이스의 목적을 알 수 있다.
목표는 시스템 기능을 이해하기 쉽고 검증 가능한 사용 용어로 요약합니다. -
유스케이스는 목표를 달성하기 위한 성공 시나리오 세트를 가지고 있다.
유스케이스라는 것은 하나의 같은 목적을 위해 펼쳐지는 것이고
적당한 수준의 목적을 달성하기 위해서는 액션이 너무 간단해서는 안됨
시작과 끝이 있어야 한다.모든 상호작용은 동일한 primary actor의 동일한 목표와 관련이 있다.
유스케이스는 트리거링 이벤트에서 시작하여 목표를 이루거나 실패할 때까지 계속되며, 시스템은 상호 작용에 따라 책임을 완수한다.
-
유스케이스는 목표와 시나리오를 함께 제공하며, 각 시나리오에서는 하나의 조건이 어떻게 전개되는지 설명합니다.
유스케이스 이름은 유스케이스의 목표가 잘나타날 수 있도록 지어야함
능동형을 활용함 active verb -
유스케이스의 목표는 동일하고 서브 목표에 따라 경우의 수는 여러가지가 나온다. 시나리오 결과 성공버전과 실패 버전으로 따로 묶는다.
-
개발자 사용자 전문가에게 주는 이점
이렇게 작성된 유스케이스는
사용자에게 글로 쓰여져서 이해가 쉽고
전문가에게는 비즈니스 룰이 제대로 지켜지고 있는지 알 수 있다.
개발자 입장에서는 어떤 상황(Context)에서 구체적으로 무엇을 해야 하는지 알 수 있다. -
유스케이스 종류
유스케이스의 종류에는
비즈니스 유스케이스와 시스템 유스케이스로 나뉜다.비즈니스 업무를 그대로 표현하고 있는 유스케이스 => 신입사원 교육용
시스템의 행위를 설명하는 유스케이스
-
블랙박스 vs 화이트 박스
시스템 내부가 보이느냐 안보이느냐골 달성을 위해서 어떤 식으로 되는지 표현할 수 없는 시스템 유스케이스 => 블랙박스
시스템이 수행 방법을 결정하지 않고 수행해야 하는 작업(기능 요구 사항)을 설명함(설계에서)조직안에 어떤 사람이 참여해야하는지 절차를 표현할 수 있는 비즈니스 유스케이스는 => 화이트 박스
이미 설계가 다 끝난 시스템의 다큐먼트 용도 => 화이트박스
기술 개발 팀은 설계하려는 SuD의 운영 컨텍스트를 문서화하기 위해 동일한 내용을 작성할 수 있으며, 화이트박스 시스템 사용 사례를 작성하여 설계한 시스템의 작동을 문서화할 수 있다. -
유스케이스 포멧
제목 쓰고
한 단락으로 요약하거나 간단하게 쓰는거 일반적으로 성공 시나리오임 => 브리프 포멧
중요하다고 생각되는 (성공 or 실패 시나리오) 몇가지 단락의 다양한 시나리오 => 캐주얼 포멧
채울 수 있는 건 다 채우는 중요하다고 생각하는 시나리오
열에 따라 1, 2, 3 포멧으로 나눠짐 속성은 액터, 시스템, 서포팅 액터 등으로 나눠짐
=> fully dressed 포멧 (이때 액션의 주체가 누구인지 명확해야 함) -
정의 확장
유스케이스란 두 액터가 목표를 위해 상호작용 하는 것
유스케이스란 이해관계를 가지고 있는 당사간의 이해관계 보호를 위해 내부적으로 시스템이 하는 것
확장 :
액터는 다른 액터들의 서비스를 요청할 때 Sud 그 자체를 포함하여 행동을 가진 모든 것이다.
-
유스케이스의 기본 모델은 Actors interact to achieve their goals
프라이머리 액터는 시스템을 위해 궁극적으로 달성하고 싶은 목표를 위해 시스템 시작
액션스텝 하나를 밟으면서 goal을 달성함
어떤 goal은 혼자 하는 것도 있지만
어떤 goal은 서비스를 요청해야만 가능한 게 있음
그 요청을 만족 시키기 위한 책임이 있고 <- 이게 시스템의 goal임
서로 goal을 가지고 있는 액터들 사이에 액션을 그대로 기술한게 유스케이스 이다. -
유스케이스는 이해관계가 있는 이해관계자 간의 행동 계약으로 볼 수 있다.
The Actors and Goals model은 유스케이스에서 문장을 작성하는 방법을 설명하지만, 논의 중인 시스템의 내부 동작을 설명할 필요성은 다루지 않는다.
따라서 Actors and Goals model을 Stakeholders and Interests model로 확장해야 한다.
Stakeholders and Interests model에 관점으로도 봐야하는데 이 모델은 유스케이스에 포함할 항목을 식별한다.다음은 포함할 항목이다.
1 -두 액터 사이의 상호작용 (목표 달성을 위한)
2 -validation (이해관계자들의 이해관계 보호를 위해)
3 -An internal stage change (이해관계자를 대신하여 또한 이해관계자의 이익을 보호하거나 나아가기 위해)
-
유스케이스란 일반적인 goal 밑에 성공 실패 시나리오를 모두 묶은 거고 이론적으로는 무한대이다.
