[도분설] 인셉션(Inception) 단계

[Inception 인셉션]

인셉션이란 무엇인가?

딱 듣고 생각하는 디카프리오 주연의 인셉션이 아닙니다 ㅋㅋㅋㅋ

도메인 분석 설계에서 말하는 Inception의 정의는 다음과 같아요.

Inception 요약

---

- 제품의 범위, 비전, 비즈니스 케이스를 시각화 한것.

- 제품의 비전에 대해 이해관계자들의 기본적인 동의를 얻는 것

- 프로젝트에 들어가는 비용을 추청하는 것

인셉션 단계의 산출물 **시험문제 : Inception 단계에 해당하는 업무가 아닌 것은?

---

1) 비전과 비즈니스 케이스

2) 유즈케이스 모델

- 모든 유즈케이스의 이름들이 정의 되어야함.

- 10%의 유즈케이스들이 분석 되어야함. 

3) Supplement Specification(보충 사항)

4) Glossary(용어 정리)

5) Risk list(리스크 목록)

- Risk list는 인셉션 단계에서 필수적이다. 변경 가능성이 있는 것이 리스크 목록이 될 수 있다.

- 비즈니스 리스크, 기술적인 리스크, 자원 리스크, 스케쥴 리스크

6) Prototype(데모 버전)

- 프로토 타입을 만들어서 컨셉을 증명하고, 기술 적용이 가능한지 확인한다.

7) Development case

- 프로젝트에 대한 커스터마이징 된 Unified Process와 산출물

8)  Phase plan

- 낮은 수준의 Elaboration 계획 세우기

9) Iteration plan

- 첫 번째 iteration의 Elaboration 플랜 세우기

Inception 요약 : 

프로젝트에 대한 일반적인 비전 및 기본 범위를 설정하기 위한 프로젝트 초기의 짧은 단계. 이 단계에 이어지는 Elaboration 단계에서 프로그래밍을 시작할 수 있도록 약 10% 정도의 유즈케이스 분석, 중요한 비기능적 요구사항의 분석, 비즈니스 케이스의 생성, 개발 환경의 구축 등을 수행.

Inception 단계의 특징

---

- 요구사항들은 시스템이 준수해야 하는 기능 및 조건을 갖추어야 한다.

- 10~20%의 중요하고 리스크가 높은 요구사항들은 인셉션 단계에서 분석이 되어서 다음 단계에서 개발될 수 있도록 하여야 한다.

- UP 요구사항 관리법 : 시스템의 변화하는 요구 사항을 찾고, 문서화하고, 조직하고, 추적하는 체계적인 접근법

요구사항 찾기(FURPS)

---

- Functionality : 특징, 기능

- Usability : 인간적인 요소, 문서화

- Reliability : 실패 빈도, 회복력, 예측성

- Performance : 응답시간, 정확성, 자원 사용률

- Supportability : 적용가능성, 유지성

Use-case Modeling

1. 유즈 케이스란? 시스템을 이용하는 사용자가 목적을 달성하기 위한 텍스트로 기술된 기능

2. 유즈케이스 모델? 모든 유즈케이스들을 나열한 것. 시스템의 기능과 환경에 대해 보여준다.

                                        [유즈케이스 모델 예시 이미지]

3. 유즈케이스 모델을 사용하는 목적

- 시스템의 기능적 요구사항을 결정하고 서술하기 위해 사용.

- Use case는 시스템 테스트를 가능하게 한다.

1) 단위 테스트 : JUnit 단위 테스트

2) 통합 테스트 : 단위테스트 이후에 조합을 하여 통합테스트를 한다.

3) 시스템 테스트 : 요구사항 명세서를 바탕으로 전체적인 시스템을 테스트

- ※ 유즈케이스와 요구사항 명세서의 차이 : 유즈케이스는 사용자 관점의 모델링, 요구사항 명세서는 회사 관점에서의 모델링

4. 시나리오(Scenarios) : 사용자와 시스템 사이에 발생하는 순차적인 상호작용.

5. 사용자(Actors) : Use case를 사용하는 주체

- Actor는 사람이 될 수 도 있고, 시스템의 인터페이스가 될 수도 있다.

- Primary Actor : 유즈케이스를 수행시키는 사용자의 목적을 알기 위해서 식별

- Supporting Actor : 외부인터페이스와 프로토콜을 명확히 하기 위해서 식별

- Offstage actor : 모든 필수적인 이해관계를 식별하고 만족시키기 위해 식별. 숨겨져 있는 Actor

---

Use case를 작성하는 포맷

- Fully-Dressed Format : 모든 단계와 변경사항들에 대해 자세하게 기술

예시 사진

1) Stakeholders and Interests : 유즈케이스는 이해관계자들의 관심사를 끄는 행동(behavior), 요소를 바탕으로 작성되어야 한다.

2) Precondition and Postconditions(사전조건, 사후 조건) :  

- 사전 조건 : 시나리오가 시작되기 전에 반드시 충족되어야 하는 조건. EX) 로그인, 회원가입 절차 etc

- 사후 조건 : 유즈케이스가 성공적으로 수행되기 위해서 필요한 조건.

3) Main Success Scenario(Basic flows)

- 이해관계자들의 요구사항을 만족시키는 시나리오 흐름

- 이 단계는 다음 3개 중 1개에 해당한다 :

1. 액터간 상호작용

2. 시스템에 의한 검증

3. 시스템에 의한 상태변화

4) Extensions(or Alternative Flows)

- Main Success 시나리오에서 대체, 확장되는 시나리오이다.

- Condition(조건), Handling(해결방안) 2가지 요소로 구성된다.

- 조건은 시스템 혹은 사용자에 의해 발견된 것으로 작성한다.

- 유즈케이스에서 <<extends>> 관계에 해당.

5) Special Requirements(비기능)

- 비기능적 요소 : 품질 특성, 제약 조건 등과 같이 기능과 직접적 관련이 없는 요소.

- 이러한 비기능적 요소들은 Supplementary Specification에서 다루어져야 한다.

6) Write in an essential style(UI 고려 하지 말기)

- 설계, 디자인에 대해서는 작성 X

- 오직 What, 무엇을 구현할 지에 대해서만 작성

7) Take an actor and actor-goal perspective(액터와 액터 골에 관점에서 작성)

- 요구사항을 사용자의 관점에 집중하여 작성

- 사용자가 얻게될 결과를 생각하며 작성

8) Black Box 스타일로 작성(시스템 내부작동, 구성요소, 설계는 기술 X)

- 구현을 어떻게 할지에 대해서는 작성하지 말기. EX) SQL문이 어쩌구, 파일업로드 코드는 multipart 파일로

- 오직 기능적 요구사항, 행위가 무엇인지를 명세하기. 그 안에 어떻게 구현될지는 black box로 놔두기.

9) Basic Procedure

1단계 : 시스템의 경계(System Boundary)를 정한다.

2단계 : 주요 액터 설정(Identify Primary Actor)

3단계 : 액터의 목적, 골에 대해 설정

4단계 : 액터골당 1개 유즈케이스 정의.(CRUD는 작성X)