Use-case 모델링 - 요구사항 식별(개발할 기능을 식별)
Actor 식별
시스템을 사용하는 사람, 프로세스를 가리킨다.
출입관리시스템 -
시스템이 지도를 만드는게 아니라 지도시스템을 사용하는거기때문에 지도시스템이 보조액터(Secondary Actor)
Actor 관계
Use-case 식별
한 액터가 시스템을 사용하여 처리하고자 하는 업무(사용사례)
Use-case 식별 지침서(권고)
- 시스템을 통해 수행하는 업무
- 한 액터가 수행하는 업무
- 한 번에 한 순간에 수행하는 업무 => 카운트가 가능한 업무, 셀수 있는 업무
1주~4주 사이에 개발할 수 있는 규모로 시스템의 기능을 쪼갤 수 있다.
프로젝트 관리가 용이한 규모로 시스템의 기능을 정의할 수 있다.
상품 구매 : 너무 Use-case 가 크다. 쪼개는게 낫다.
1. 상품조회
2. 결제 <--- 사용자
3. 배송 <--- 택배유스케이스란 액터가 시스템을 사용해서 처리하고자하는것을 유스케이스라한다
유스케이스를 식별해야지 기능을 도출할수있다.
식별하고싶으면 업무라는 관점에서 찾아봐라.
예)
게시글 등록하기
게시글 목록 조회하기
게시글 상세 조회하기
게시글 변경 하기
게시글 삭제 하기로그인 로그아웃은 시스템을 사용하기위한 인증을 위한 방법이므로 Use-case가 될 수 없다.
단, 회원가입 이런건 가능
Use-case 실무
어떻게 쪼개야지 개발자에게 어느 개발자에게 업무를 맡기기쉽고 개발영역이 겹치지 않게하기 위해 즉, 관리하기 쉽게 쪼개기 위해서 Use-case모델링이란게 생김
너무 Use-case를 잘게 쪼개면 오히려 관리하기 번거롭다.
단, 합쳤을 때 Use-case의 개발기간이 1~4주 안팎인 것이 좋다.
- 서로 관련된 Use-case인 경우, 한 개의 Use-case로 합칠 수 있다.
예)
[제품 구매하기]
제품 주문하기
제품 배송하기- CRUD Use-case들을 하나의 Use-case로 합칠 수 있다.
[게시글 관리]
게시글 등록하기
게시글 목록 조회하기
게시글 상세 조회하기
게시글 변경 하기
게시글 삭제 하기- 여러 Use-case의 공통 시나리오인경우 별도의 Use-case로 뽑을 수 있다.
[로그인 하기]
게시글 등록하기 ---> 로그인하기
게시글 변경하기 ---> 로그인하기
게시글 삭제하기 ---> 로그인하기로그인 하기는 비록 업무는 아니지만, 여러 Use-case에 포함된 작업이다.
공통기능으로 분리하여 개발할 수 있게 별도의 Use-case로 뽑아낸다.
Use-case 관계
Use-case와 서블릿
프로젝트에 Use-case Modeling 적용
- Actor 식별
- Use-case 식별
- UI Prototype 작성
