추가 적립 안내

효과적인 유스케이스 작성법을 보여준다!

『WRITING EFFECTIVE USE CASES(앨리스터 코오번의 유스케이스)』는 유스케이스를 작성하거나 남을 지도할 때 사용하는 지침을 담고 있다. 또한 더 나은 유스케이스와 유스케이스 집합을 얻기 위해 생각할 것과 준수할 것을 담고 있다. 독학 지침서 형태로 구성된 이 책은 소개에서부터 고급 수준의 내용까지 포괄하고 있고, 개념, 예제, 주의사항, 연습문제를 수록하였다. 유스케이스에 대한 일반적인 소개, 다음으로 유스케에스 본문에 대한 상세한 설명, 그리고 자주 묻고 답하는 것들, 바쁜 사람들을 위한 주의사항, 그리고 부록으로 구성되어 있다.

유스케이스 기본 개념부터 고급 예제까지
유스케이스의 모든 것

유스케이스는 다이어그램이다? 저자는 ‘원래 유스케이스란 텍스트 기반의 서술이다.’라고 말한다. 유스케이스 작성은 기본적으로 산문체 수필을 연습하는 것이다. 그 과정에서 일반적인 산문체의 좋은 표현을 생각해 낼 때 겪는 어려움에 맞닥뜨린다. 훌륭한 유스케이스가 어떠하다고 말하는 것으로는 턱없이 부족하다. 우리가 진정 알고자 하는 것은 그보다 어려운 ‘무언가’이다. 즉, 유스케이스를 작성하는 방법을 알고, 이 방법을 적용하여 훌륭한 유스케이스를 만드는 것이다.

시스템 사용법은 간단하게 작성할 수 있다고 생각하는 사람이 많다. 하지만 실제로 유스케이스를 작성해야 할 상황이 되면 ‘정확히 무엇을 작성해야 하는가?’ 또는 ‘얼마나 상세하게 작성해야 하는가?’라는 질문에 부딪힌다. 이 책의 목표는 효과적인 유스케이스 작성법을 보여주는 것이다. 과연 명확하게 요구사항을 전달할 수 있는 유스케이스는 어떻게 작성해야 할까? 이런 고민에 빠져있는 독자라면 이 책에서 그 답을 찾을 수 있을 것이다.

옮긴이의 글
지은이의 글
감사의 글

1장 소개
1.1 유스케이스는 어떻게 생겼나(개략적으로)?
1.2 상황에 따라 사용하는 유스케이스가 다르다
1.3 요구사항과 유스케이스
1.4 유스케이스가 가치를 발하는 시점
1.5 에너지 관리
1.6 사용 이야기와 준비운동
1.7 연습문제

제1부 유스케이스 내용들

2장 행위에 대한 계약, 유스케이스
2.1 목표를 가진 액터 간의 상호작용
2.2 이해관계를 가진 당사자 간의 계약
2.3 그래픽 모델

3장 범위
3.1 기능 범위
3.2 설계 범위
3.3 가장 바깥쪽 유스케이스
3.4 범위-정의 작업 산출물 사용
3.5 연습문제

4장 이해관계자와 액터
4.1 이해관계자
4.2 일차 액터
4.3 지원 액터
4.4 목표 시스템
4.5 내부 액터와 화이트-박스 유스케이스
4.6 연습문제

5장 세 가지 목표 수준
5.1 사용자 목표
5.2 요약 수준
5.3 하위 기능
5.4 그림 아이콘으로 목표-수준 강조하기
5.5 올바른 목표 수준 찾기
5.6 긴 예제: 여러 수준의 ‘보험금 청구 처리’
5.7 연습문제

6장 선조건, 트리거, 보증
6.1 선조건
6.2 최소 보증
6.3 성공 보증
6.4 트리거
6.5 연습문제

7장 시나리오와 단계
7.1 주요 성공 시나리오
7.2 행동 단계
7.3 연습문제

8장 확장(Extension)
8.1 확장의 기초
8.2 확장 조건
8.3 확장 처리
8.4 연습문제

9장 기술과 데이터 변동

10장 유스케이스 연결
10.1 하위 유스케이스
10.2 확장 유스케이스
10.3 연습문제

11장 유스케이스 양식
11.1 선택 가능한 양식
11.2 유스케이스 작성 형식에 영향을 주는 요인
11.3 다섯 가지 프로젝트 표준 유형
11.4 결론
11.5 연습문제

제2부 자주 논의되는 주제

12장 유스케이스 완료 시점

13장 대량 유스케이스 다루기

14장 CRUD와 매개변수화 유스케이스
14.1 CRUD 유스케이스
14.2 매개변수화 유스케이스


15장 비즈니스 프로세스 모델링
15.1 모델링 대 설계
15.2 비즈니스와 시스템 유스케이스 연결

16장 누락 요구사항
16.1 데이터 요구사항 정밀도
16.2 유스케이스로부터 타 요구사항 교차-연결

17장 개발 프로세스에서 유스케이스
17.1 프로젝트 조직에서 유스케이스
17.2 작업이나 특성 목록을 위한 유스케이스
17.3 설계를 위한 유스케이스
17.4 UI 디자인을 위한 유스케이스
17.5 테스트를 위한 유스케이스
17.6 실제 유스케이스 작성

18장 유스케이스 요약서와 익스트림 프로그래밍

19장 실수 바로잡기
19.1 시스템이 없음
19.2 일차 액터가 없음
19.3 사용자 인터페이스 세부사항이 지나치게 많다
19.4 매우 낮은 목표 수준
19.5 목적과 내용이 서로 다름
19.6 UI가 지나치게 많은 고급 예제

제3부 바쁜 사람들을 위한 주의사항
20장 각 유스케이스를 작성할 때 주의할 사항
주의사항 1. 유스케이스는 산문체 수필이다
주의사항 2. 유스케이스를 읽기 쉽게 만든다
주의사항 3. 한 문장 형식
주의사항 4. 하위 유스케이스를 ‘포함’한다
주의사항 5. 누가 공을 가졌는가?
주의사항 6. 올바른 목표 수준을 가진다
주의사항 7. GUI는 제외시킨다
주의사항 8. 두 가지 결말
주의사항 9. 이해관계자는 보증을 필요로 한다
주의사항 10. 선조건
주의사항 11. 유스케이스 통과/실패 테스트

21장 유스케이스 집합을 다룰 때 주의할 사항들
주의사항 12. 끊임없이 전개되는 이야기
주의사항 13. 회사 범위와 시스템 범위
주의사항 14. 핵심 가치와 변형
주의사항 15. 유스케이스 집합에 대한 품질 관련 질문

22장 유스케이스로 작업할 때 주의할 사항들
주의사항 16. 유스케이스는 단지 제3장일 뿐이다
주의사항 17. 작업 폭이 우선이다
주의사항 18. 12단계 비결
주의사항 19. 실수 비용을 파악한다
주의사항 20. 청바지가 더 낫다
주의사항 21. 실패 처리
주의사항 22. 초기에 직책을 활용한다
주의사항 23. 액터는 역할을 수행한다
주의사항 24. 위대한 그림 속임수
주의사항 25. 위대한 도구 논쟁
주의사항 26. 제목과 요약서를 이용한 프로젝트 계획 작성

부록 A UML에서 유스케이스
A.1 타원과 막대기 모양
A.2 UML의 포함 관계
A.3 UML의 확장 관계
A.4 UML의 일반화 관계
A.5 예속 대 하위 유스케이스
A.6 유스케이스 다이어그램 작성
A.7 텍스트 기반으로 유스케이스 작성

부록 A UML에서 유스케이스
부록 B 유스케이스 통과/실패 테스트
부록 C 연습문제(일부에 대한) 해답
부록 D 용어집
부록 E 참고자료

옮긴이의 글

3년 동안 진행해온 프로젝트에서 애자일(Agile) 개발방법인 스크럼을 적용해왔습니다. 제품 백로그, 스프린트 백로그로 요구사항 목록을 만들고 스프린트 계획회의, 일일 회의를 통해 사용자 스토리를 작성한 다음 스토리 점수 추정으로 일정을 계획하고 관리했습니다. 거의 대부분의 경우 사용자 스토리 그리고 고객과의 대화로 요구사항을 파악할 수 있었고, 개발 범위에 대한 합의를 할 수 있었습니다. 그러나 그것만으로는 해결할 수 없는 문제가 있었습니다. 첫 번째는 개발자나 담당고객이 교체되거나, 신규 개발자를 투입해야 하거나, 원격지 개발을 해야 하는 경우 등에서 개발자 간에 고객과 합의된 요구사항 내역과 예외상황에서의 처리 방법을 공유할 수 있는 수단이 없다는 문제였습니다. 두 번째로 주요 이해관계자 식별이나 관심사항 분리, 트리거, 전반적인 시스템 규모 등을 파악하는 수단도 필요했습니다. 대부분의 고객은 시스템의 기능목록과 언제 프로젝트가 종료되는지를 알고 싶어 하기 때문입니다.

유스케이스는 이런 문제를 아주 훌륭하게 해결해 주었습니다. 유스케이스는 소프트웨어 공학적인 접근방법으로 적용할 땐 작성하기 어렵고 유지하는 비용도 만만치 않습니다. 하지만 실용적인 애자일 방법으로 접근한다면 살아있는 유스케이스를 만들어 이해관계자와 개발자가 하나의 목표를 바라보고 달려갈 수 있게 합니다.

그렇다면 유스케이스가 어떤 특장점을 갖고 있기에 이런 문제를 해결할 수 있을까요? 저자인 앨리스터 코오번(Alistair Cockburn)은 유스케이스를 다음과 같이 소개하고 있습니다.

“유스케이스는 이해관계자와 시스템 간의 행위와 관련된 계약 내용을 담고 있다. 유스케이스는 일차 액터라 불리는 이해관계자의 요청에 응답을 하는 시스템을 서술하는데, 요청과 응답 행위는 다양한 조건 아래서 이루어진다. 일차 액터는 어떤 목표를 달성하기 위해 시스템과 상호작용을 시작한다. 시스템은 응답하되, 모든 이해관계자의 입장을 고려한다. 서로 다른 일련의 행위, 또는 시나리오는 특정 요청이나 그 요청을 둘러싼 조건에 따라 전개할 수 있다. 유스케이스는 서로 다른 여러 시나리오의 묶음이다.”
“유스케이스가 가치를 발하는 첫 번째 순간은 시스템이 지원할 사용자 목표에 유스케이스 이름을 붙이고 목록으로 작성할 때다. 이 목록은 시스템이 해야 할 일과 시스템의 범위와 목적을 나타낸다. 이 목록은 프로젝트 이해관계자 간의 의사교환 수단이다.
두 번째로 유스케이스가 가치를 발하는 순간은 유스케이스 작성자가 성공 시나리오에서 잘못될 수 있는 모든 경우에 대해 브레인스토밍 하며, 그 결과를 나열하고, 시스템 응답을 문서로 작성할 때다. 그 순간, 수행 측 팀 구성원이나 사용자 측 요구사항 담당자들이 미처 생각하지 못했던 놀라운 것들을 발견하고는 한다.”