1. SW 개발과정
	1.1 요구사항 정의 ★ Our Focus
			: 기능적(사용자 요구사항) + 비기능적(성능 = 품질속성. 아키텍트가 비기능 명세를 정의한다.)

	1.2 유스케이스 : 기능적인 요구사항 획득 및 서술 

2. 유스케이스
	2.1 모델과 명세(명세에 집중) 모두 필요하다.
	2.2 시나리오 집합 : 스텝을 반드시 넣어야 한다.(추후 대안 흐름 때문)
	2.3 (사용자)목표의 집합.
	2.4 액터 : 사용자 혹은 타 시스템이 현 시스템에서 수행하는 역할(!=권한)
	2.5 내용(!=다이어그램)
	2.6 애자일 진영에서 비판을 많이 받는다.(요구사항에 대한 빠른 피드백을 방해를 하기 때문)
	2.7 강점 : 초기 커뮤니케이션에 도움을 많이 주기 때문에 초기에 분석 및 설계된 부분이 추후 요구사항 변경시에도 위력을 발휘한다.
	2.8 기능적 요구사항을 주로 획득된다.
	2.9 내용
		2.9.1 주 성공시나리오 :	심플. 분기나 대안 조차 없다.
													액터(주체) 반드시 표기
													UI 서술금지
													액터의 의도를 표시.
		2.9.2 확장 :	대안흐름(major 대안, minor 예외 or 오류)
								스텝을 기록하는 이유.
								#* or *# : 트리거. 언제든지 수행가능.(애스터리스크 위치가 언제든지 가능하단 뜻)
		2.9.3 액터 :	시스템과 상호작용하므로, 처리의 핵심.
			2.9.3.1 일차액터 :	요구사항을 내는 액터. 이해관계자 ex) 고객
			2.9.3.2 지원액터 :	시스템과 통신하는 액터. 실제 시스템 사용. ★인터페이스간 프로토콜 식별에 도움이 됨 ex) 전화교환원
			
			2.9.3.3 액터찾기 : 질문들 확인
			2.9.3.4 추가항목 :	사전조건	- ex) log-in
											보증			- 종료시 보장되어야 하는 사항. 유스케이스 자체가 보증을 말하는 것이므로 별도 기입하는 경우가 적다. 성공보증 or 최소보증
											트리거		- 시작되도록 하는 이벤트
											간략하게	- 가독성을 위해

3. 유스케이스 다이어그램
	3.1 표기법 : 최대한 적게. 유스케이스와 연관관계만 써라. 간단하게 해야 명세도 간단하게 나온다. 단방향 관계를 최대한 많이 써라.
	3.2 다이어그램은 최대한 간단하게, 명세에 집중할 것. 명세를 써봐야지 다이어그램의정 확성을 알 수 있다.
	3.3 일반적인 형태 : 일차액터 - 바운더리 - 이차액터


4. 유스케이스 수준
	4.1 수준개요
		4.1.1 요약목표
		4.1.2 사용자 목표
		4.1.3 하위 기능

	4.2 요소 비즈니스 프로세스 : 5~10스텝 사이. 비즈니스 적 가치가 있어야 한다. 비즈니스 적으로 자료의 소스(DB등)는 비즈니스에 중요치 않다. 대부분 블랙박스로 할 것.(화이트 박스의 최소화)

	4.3 목표수준
		4.3.1 높이기(왜) / 낮추기(어떻게). 
		4.3.2 이후 명세서 작성시 5~10단계 안에 끝나면 적당한 수준으로 판단해도 된다. 최상(3~8단계), 최고(11단계). 단, UI 등 낮은 수준의 명세는 제외. 총 2페이지.
	
	4.4 크기
		4.4.1 가장 바깥쪽			: 레이아웃. 
		4.4.2 사용자 목표수준	: 가이드라인 : 20개를 대규모로 볼 수 있을까 의문이 든다. 숫자에 얽매이지 않는게 맞을 것 같다.

	4.5 분리
		4.5.1 대안흐름이 중요한 이유. 확장(extend)하여 복잡성을 줄인다.
		4.5.2 고려사항 :	유스케이스가 많아지면 관리비용이 많아진다고 한다.
										팁) 언더바(데이터), 볼드(유스케이스) 등등

	4.6 특이 유스케이스
		4.6.1 Startup	: 유스케이스 간엔 일반적으로 선후 관계는 없으나 이 유스케이스는 시작관계가 존재한다.
		4.6.2 CRUD	: 하나로 표현할 것. 노트 사용 추천.

	4.7 작성양식
		4.7.1 후조건 : 되도록 사용하지 말자. 오용의 위험이 큼. 대신 보증을 쓰자.
		4.7.1 기본흐름 자체가 의미를 가지므로, 기본흐름과 외부의 넘버링으로 연관시킬 필요없다. 기본흐름은 그냥 1,2,3으로 써도된다.

	!!. 인클루드 : A -> B. 절대적. 반드시 수행.			A -> B -> A로 돌아온다.
		익스텐드 : A <- B. 선택적. 특정지점에서 확장.	A의 확장점일 때 B가 A에 들어온다고 보면된다.