엘스테어 코번의 'Writing Effective Use Cases'
주 행위자: 채용 담당자
수준: 행위자의 목적
전제조건: 채용 정보가 입력되었지만 아직 볼 수는 없는 상태다.
최소한의 보장: 없음
성공 보장: 채용 공고가 등록되었음. 채용 담당자의 신용카드로 결제 되었음.
주 성공시나리오:
1. 채용 담당자는 신용카드 번호, 날짜, 인증 정보 등을 입력한다.
2. 시스템은 신용카드를 검증한다.
3. 시스템은 신용카드 결제를 수행한다.
4. 등록한 채용 공고를 구직자들이 조회할 수 있다.
5. 채용 담당자는 고유한 등록 확인 번호를 부여 받는다.
확장:
2a: 시스템이 처리할 수 없는 카드종류다.
2a1: 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.
2b: 카드의 ID번호가 잘못되었다.
2b1: 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.
2c: 카드의 유효기간이 지났다.
2c1: 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.
3a: 카드의 신용한도가 부족하다.
3a1: 시스템은 결제할 수 있는 만큼 결제한다.
3a2: 사용자는 이에 대해 통지받고, 잔액 결제를 위해 두 번째 카드 정보를 입력하다는 요청을 받는다. 단계 2에서 계속된다.
유스케이스는 성공적인 실행경로외에도 다른 부차적인 경로들을 같이 기록한다. 이 점이 나에게 상당한 매력이었다. 이 때까지 개발된 요구사항 명세서는 주 성공 시나리오에 대해서만 다루고 예외상황이나 특별한 상황에서의 시나리오는 명세화되지 않았다. 그리고, 이런 요구사항들은 QA팀의 테스트 케이스에 빼곡히 차 있었다. SQA에 참가했을 때 불과 몇 개되지 않던 요구사항이 3~4배로 늘어나는 상황을 겪은 적이 있었다. 우리팀은 추가된 요구사항으로 인해 거의 월화수목금금금 형태로 일하지 않으면 일정을 맞출 수 없었다. 만약, 이런 요구사항들을 미리 발견하여 포함했다면 어땠을까? 적어도 불완전한 소프트웨어를 QA팀에 인도하지 않았을 것이고, 개발단계에서 품질에 대해 더 신경썼을 것이다.
