7-1. Usecase Modeling Usecase Specification
개요
유스케이스 명세서 작성
중요한 것은 유스케이스 다이어그램만으로는 알 수 없고 각 유스케이스에 대한 명세서라는 문서가 나와야 한다.
유스케이스 명세서 : 양식
설명을 간략하게 쓰고 관련된 엑터를 쓰고 중요한 것은 우선순위(유스케이스가 엄청 나오기 때문에 개발하려는 유스케이스를 처음부터 동시에 개발할 수 없기 때문에 우선순위를 정하여 높은 애 먼저 개발)
유스케이스가 실행되기 전에 해야하는 조건과 후에 만족되는 조건을 써주고 중요한 것은 이벤트 흐름!
이 유스케이스 다이어그램에는 유스케이스는 이름밖에 안보이는데 그래서 명세서로 세부적인 내용 작성. 주로 보는게 이벤트 흐름(일이 어떤 식으로 흘러가는지), 시나리오를 묶어서 추상화시켜서 흐름 하나씩 만드는 것
이 유스케이스와 관계되어 있는 비기능적 요구사항
유스케이스는 기능적 요구를 찾는 개념이지만 이를 위한 비성능을 써준다
유스케이스 명세서 : 항목
- 유스케이스 이름: 유스케이스에 대한 가장 간결한 명세로서 유스케이스를 통하여 제공되는 시스템의 기능을 명확한 동사구 형태로 표현해야 한다.
- 개요: 모든 이해관계자는 가장 먼저 유스케이스 명세서의 개요 항목을 통해서 유스케이스를 이해한다.
- 관련액터항목:해당유스케이스가동작할때필요한주변액터를이해할수가있다.주액터와보조 액터를 구분하여 기록 한다.
- 우선순위:기능의중요도와개발난이도를바탕으로결정된다.개발순서,자원투입등과같이프로젝 트 관리 측면에서 활용된다.
- 선행조건: 유스케이스의 시작 시 만족되어야 할 조건으로서 만족되지 않으면 유스케이스는 시작되지 않는다.
- 후행조건:유스케이스의종료시만족해야하는조건으로유스케이스의정상동작여부에대한최소 한의판단기준으로사용될수있다.
- 이벤트흐름: 유스케이스의 관련 액터와 시스템 간의 상호작용에 대한 구체적인 정의를 담고 있다. 하 나의 유스케이스에는 기본 흐름과 대안 흐름으로 구분하여 기술한다.
- 비기능적 요구사항: 성능, 신뢰도, 보안 등 이 유스케이스와 관련된 비기능적 요구사항을 기술한다.
기본 개념
개요
- 유스케이스가 뜻하는 시스템의 기능을 간결하고 명확하게 기술한다
관련 액터
- 유스케이스와 상호작용하는 액터를 기술한다.
- 주엑터는 시작하는애, 보조엑터는 사용하는 애, 나가는 애
- 유스케이스를 개발하기 위하여 필요한 외부 인터페이스를 파악하는데 도움을 준다.
엑터를 알면 유스케이스와 인터렉션 있어야 하니까 사람과의 소통에는 유저 인터페이스가 필요할 것이고 시스템은 시스템 인터페이스가 있어야 하고 장치가 있으면 디바이스 인터페이스가 있어야 한다.
우선 순위
- 유스케이스의 중요성을 우선순위로서 기술한다
- 기능의 중요도와 개발의 난이도를 고려
- 유스케이스에 대한 프로젝트 관리 시 활용
- 유스케이스 명세서의 우선순위는 개발 순서를 결정할 때 활용될 수 있다
전체를 동시다발적으로 구현하는 것이 아니라 우선순위가 높은 애들부터 구현
새로운 기술을 사용해야 한다면 빨리 개발해야하고 주요기능도 빨리 개발해야 한다.
우선순위에 따라서 프로젝트를 진행해야 한다.
→ 우선순위 정하는 것은 매우 중요
선행조건
- 유스케이스의 수행이 시작되기 위하여 필요한 조건을 뜻한다
- 선행조건이 만족하지 않으면 유스케이스 동작이 시작되지 않음을 의미
선행조건에 성적 조회기간에만 할 수 있다!라는게 있어서 구현되어서 시스템상으로 비활성화시킨다, 반영되어야 한다.
후행조건
- 유스케이스 수행이 완료된 후 만족되어야 하는 조건을 뜻한다
- 해당 유스케이스의 정상 동작에 대한 최소한의 판단 기준이 될 수 있다
- 만약 이 조건이 만족되지 않으면 시스템이 정상적으로 동작했다고 판단하기 어렵다
- 그러나 후행조건이 충족되었다고 유스케이스가 올바르게 수행되었다고 판단할 수는 없다
이벤트 흐름
- 기본흐름과 대안흐름 으로 구성된다
1. 기본흐름
유스케이스에 내포되어있는 다양한 상황 중에서 가장 일반적이고 정상적인 상황
Ex) 출금- atm에 10만원이 충분히 있고 비번도 안틀리고 등등…
2. 대안흐름
기본흐름이 아닌 다른 모든 흐름을 의미, 일반적이지 않은 특수한 상황, 비정상적인 상황을 의미
ex)오류가 난다던지 5만원짜리, 수표로 할것인지 등등 다 대안흐름
- 유스케이스 명세서에 흐름을 쓸거고 이걸로 분석, 설계, 테스트까지 함
→ 이벤트 흐름을 쓸 때 사용자와 잘 대화해서 써야 함
- 기본흐름으로부터 분기
-
대안 흐름은 분기된 후 종료되는 경우도 있고 다시 기본흐름으로 분기되는 경우도 존재
Ex) 중간에 카드 판독이 실패했다던가 암호가 불일치한다면? 중간에 취소한다면? Atm기에 돈이 없을 때? 시간이 초과되었을 때
2-1. 선택흐름
엑터의 선택하는 곳, 옵션이 있는 것이 선택 흐름, 시스템에 돈이 존재하느냐
- 액터의 능동적인 옵션 선택 흐름
- 시스템의 상태에 따른 선택 흐름
- 데이터 유형에 따른 선택 흐름
2-2. 예외흐름
잘못 비밀번호를 입력하거나 등등
- 부적절한 입력 형식 예외 흐름
- 입력 시간 경과 예외 흐름의 예
- 시스템 처리 예외 흐름
흐름의 유형
- 기능을 하기 위해 어떤 일의 순서가 나는지 순서대로 쓰고 기본흐름은 정상적인 흐름 나머지는 대안흐름
- 기본흐름에서 분기들이 나올 것
- 대안흐름 찾는게 중요~~~! 정상적인 시스템은 거의 없음 이런 흐름들을 가지고 분석하고 설계하고 구현하고 테스트할 것
- 기본흐름이 아닌 대안흐름까지 고려해야 함
이벤트 흐름
- 흐름은 액터와 시스템간의 구체적인 상호작용을 명시적으로 정의해야 한다
Uml에 기본 양식은 없지만 번호를 매겨서 하는 것을 추천하는 편
EX) 출금 유스케이스 흐름 명세
액터와 기능 간의 일이 흘러가는 순서, 인터렉션을 작성, 구현과 관계된 내용은 없음. 사용자와 합의봐야 한다
자연어로 쓰기도 하고 시퀀스 다이어그램으로 표시하기도 한다. 자연어로 쓸 때에는 왼쪽에는 엑터가 하는 일 오른쪽에는 시스템이 하는 일 이렇게 나눠 써서 오른쪽만 구현. 액터가 요청하면 시스템이 대답하는 형식, 메소드가 아니라 메세지가 왔다갔다하는 거를 보여주는 거임(버튼이라고 쓰면 안된다) → ui가 나오게 된다
- 흐름 명세는 대안 흐름을 포함해야 한다.
do while으로 표현할 수도 있고 명세서에서 대안흐름을 표현할 수도 있고 더 많이 쓰는 거는 오른쪽처럼 사용( 보통 아키텍터가 용어를 알려줄 것)
결국은 사용자가 시스템을 어떻게 사용하고 시스템은 어떻게 반응하고 인터렉션만 잘 나타내면 된다.
비기능적 요구사항
- 유스케이스와 관련된 비기능적 요구사항이 있다면 기술한다.
기본 원칙
개요
- 유스케이스가 나타내는 전체적인 기능이 명확히 기술되어야 한다
- 유스케이스에 내포된 기능이 일부분 만이 개요에 기술되어서는 안된다
- 유스케이스와 관련된 액터들이 모두 사용된다.
- 기본 흐름과 주요 대안 흐름의 기능이 포함된다.
- 액터와 시스템 간의 구쳊거인 상호작용은 흐름에서 기술하므로 개요에서 액터의 입출력 데이터, 입출력 순서를 기술하지는 않는다.
관련 액터
- 유스케이스 다이어그램에서 이 유스케이스와 연관관계를 맺고 있는 액터는 모두 관련 액터 부분에 나열되어야 한다
우선순위
- 해당 기능의 중요도와 개발의 난이도를 고려하여 결정
선행조건/ 후행조건
- 유스케이스의 수행 시작을 위하여 항상 만족이 되어야 하는 조건이다
- 엑터와 시스템 상태에 대한 제약으로 표현
- 임베디드의 경우 주변장치의 정상동작이 선행조건에 기술
- 해당 유스케이스와 관련된 장치의 정상 동작만 점검하면 된다 또한 핵심 장치에 대한 점검이 충분할 수 있다
- 유스케이스의 선행조건은 사용자 인터페이스에 반영된다
- 유스케이스 수행완료 후에 만족되어야 하는 조건
흐름
- 유스케이스와 관련된 모든 액터와의 모든 상호작용을 기술해야 한다.
- 테스트단계에서 이 흐름에 따라 테스트를 하는데 이벤트 흐름이 테스트 케이스까지 가기 떄문에 흐름을 찾는것과. 합의를 보는 것이 중요
- 중요한 것은 유스케이스 흐름은 사용자에게 요구사항을 찾는 거이기 떄문에 개발자의 기술적인 용어를 사용하지 않고 도메인의 용어를 사용한다
- 각 스텝의 주어는 시스템 또는 액터를 주어로는 능동태의 문장으로 기술
엑터는 머한다. 시스템은 머한다. 이렇게 적어야 함
- 한 스템에는 시스템 또는 하나의 액터에 의한 기능/ 행위를 기술
- 각 스템은 시스템과 액터와의 입출력이 명확하게 기술되어야 한다
어떤 데이터가 왔다갔다하는지 정확하게
- 기본흐름과 주요 대안 흐름 모두 기술해야 한다(대안흐름을 많이 찾는 것이 가장 중요)
- 명확한 표현과 이해를 위해 if,while, for 등을 활용할 수 있다
- CRUD는 대안으흐름으로서 기술한다
비기능적 요구사항
- 검증이 가능하도록 명확하고 구체적으로 기술
유스케이스 명세서를 작성하는 이유는 요구사항을 찾아서 합의를 보기 위함
회원가입에 드어가는 내용이 다 명세서에 들어가 있어야 한다.
이걸 가지고 분석하고 구현할 것.
여기서 list 박스는 안된다. 카드 정보라고도 쓰면 안되고 써야 한다. 우리가 모르는 도메인 정보이므로 이것도 명세서에 써놔야 한다.
유스케이스 다이어그램 작성 -> 각각 명세서 작성하는데 기본흐름과 대안흐름을 쓰는게 주목적이고 여기서 엑터와 시스템 사이의 인터렉션을 도메인 언어로 써야 하고 버튼, 리스트박스 등등을 쓰면 안된다.
- 개별 유스케이스 또는 유스케이스 패키지 별로 유스케이스 명세서 문서를 작성한다