User stories, use cases, job stories, requirement statements는 소프트웨어가 무엇을 해야 하는지 기록하는 네 가지 방법입니다. 이들은 종종 경쟁 관계로 제시되지만, 서로 다른 수준의 세부 사항에서 다른 질문에 답합니다. User story는 누가 무엇을 왜 원하는지 묻습니다. Use case는 실패하는 경우를 포함하여 상호작용을 단계별로 설명합니다. Job story는 사용자가 처한 상황부터 시작합니다. Requirement는 시스템이 준수해야 하는 규칙을 명시합니다.
이 가이드는 네 가지 방법을 비교하고, 동일한 기능을 각 방식으로 작성한 예시를 보여주며, 언제 어떤 방법을 사용해야 하는지 설명합니다. 스토리 작성의 기본에 대해서는 우리의 허브 가이드를 참조하세요. user stories 작성 방법.
빠른 비교
| User story | Use case | Job story | Requirement statement | |
|---|---|---|---|---|
| 형식 | [사용자]로서, [동작]을/를 원하며, [혜택]을/를 얻고 싶습니다 | 행위자, 목표, 전제 조건, 주요 성공 시나리오, 확장, 사후 조건 | [상황]에서, [동기]를/을 원하며, [기대 결과]를/를 달성할 수 있습니다 | The system shall [behaviour or constraint] |
| 중심 | 사용자 유형과 그들의 목표 | Actor와 시스템 간의 상호작용 | 상황과 동기, 페르소나가 아닌 | 시스템의 행동 또는 품질 |
| 길이 | 한 문장 및 수용 기준 | 반 페이지에서 여러 페이지 | 한 문장 | 요구사항당 한 문장, 문서당 여러 문장 |
| 출처 | Extreme Programming; Connextra(2001)의 형식 | Ivar Jacobson(1980년대 후반); Alistair Cockburn의 목표 기반 스타일(2000) | Intercom의 Paul Adams; Alan Klement가 개발(2013) | 전통적인 요구사항 엔지니어링 (현재 ISO/IEC/IEEE 29148) |
| 적합 대상 | 애자일 백로그 및 스프린트 계획 | 복잡한 플로우, 통합, 규제 또는 계약 기반 작업 | 특히 동일한 상황에 있는 다양한 사용자를 위한 디스커버리와 디자인 | 비기능적 요구사항, 컴플라이언스, 고정 범위 계약 |
| 약점 | 전체 플로우와 엣지 케이스 보여주기 | 속도; 빠른 반복에서 최신 상태를 유지하기 어려움 | 자체적인 계획 수립 및 추정 | 이유 설명; 테스트할 수 없는 목록을 작성하기 쉬움 |
사용자 스토리
사용자 스토리는 기능을 원하는 사람의 관점에서 서술된 기능의 짧은 설명입니다. 일반적인 형식인 “[유형의 사용자]로서, [동작]을/를 하고 싶다. 그 이유는 [혜택]이다”는 2001년 Connextra 팀에서 등장했으며 Mike Cohn의 책 User Stories Applied를 통해 널리 퍼졌습니다. 스토리는 Extreme Programming에서 발전했으며, 고의로 간결하게 작성되었습니다. Ron Jeffries는 각 스토리를 카드, 대화, 확인(3C)으로 설명했습니다. 카드는 사양이 아니며, 대화에서 세부 사항이 합의되고, 인수 기준이 이를 확인합니다.
장점: 스토리는 스프린트 내에서 추정하고 완료하기에 충분히 작고, 비기술적 이해관계자가 읽기 쉬우며, 가치(“so that”)를 항상 시야에 두도록 합니다. Mike Cohn는 요구사항을 위한 사용자 스토리의 장점.
에서 그 근거를 제시합니다. 한계: 개별 스토리로 구성된 백로그는 스토리가 플로우로 어떻게 결합되는지 보여주지 못하며, 이 형식은 에러 케이스를 건너뛰기 쉽게 만듭니다. 팀들은 첫 번째 문제를 사용자 스토리 맵 으로, 두 번째 문제는 잘 작성된 인수 기준(우리의 사용자 스토리 템플릿).
사용 사례
사용 사례는 행위자(사람 또는 다른 시스템)가 목표를 달성하기 위해 시스템을 사용하는 방법을 단계의 시퀀스로 설명하며, 해당 시퀀스가 분기하거나 실패할 수 있는 방법도 함께 다룹니다. Ivar Jacobson은 1980년대 후반에 사용 사례를 도입했으며, Alistair Cockburn의 책 Writing Effective Use Cases (2000)는 오늘날 대부분의 팀이 사용하는 목표 중심의 평문 스타일을 정립했습니다(Cockburn의 사이트).
완전한 사용 사례는 일반적으로 다음을 포함합니다:
- 주요 행위자: 상호작용을 시작하는 주체.
- 목표 및 범위: 행위자가 원하는 것과 설명되는 시스템.
- 전제 조건: 이미 참이어야 하는 것.
- 트리거: 사용 사례를 시작하는 것.
- 주요 성공 시나리오: 모든 것이 순조롭게 진행될 때의 번호 매겨진 단계.
- 확장: 대체 경로와 실패 경로로, 각 경로는 분기되는 단계에 연결됩니다.
- 사후 조건 또는 보장: 성공과 실패 시 끝에 참이 되는 것.
장점: 확장 섹션은 무엇이 잘못될 수 있는지 생각하도록 강제하며, 전체 플로우가 한 곳에서 가시화되어 통합, 결제, 감사 대상 작업에 유용합니다. 한계: 사용 사례는 작성하고 최신 상태로 유지하는 데 시간이 더 걸리며, 하나의 사용 사례는 일반적으로 하나의 스프린트에서 구축하기에는 너무 큽니다.
사용 사례는 애자일 작업에 적응했습니다. Use-Case 2.0에서, Jacobson과 동료들은 각 사용 사례를 계획하고 테스트하기에 충분히 작은 “슬라이스”로 분할했으며, 이는 사용자 스토리와 거의 동일한 역할을 합니다.
잡 스토리 (jobs to be done)
잡 스토리는 페르소나를 상황으로 대체합니다: “[상황]일 때, [동기]를 하고 싶다. 그 이유는 [기대 결과]를 달성하기 위해서다.” 이 아이디어는 Paul Adams가 Intercom 블로그에서 처음 언급했으며, Alan Klement가 2013년 Intercom 게스트 게시물에서 설명하며 발전시켰습니다( 잡 스토리를 활용한 기능 디자인). 이는 Clayton Christensen과 연관된 jobs-to-be-done 사고방식을 기능 디자인에 적용합니다.
잡 스토리를 지지하는 논거는 “바쁜 부모로서”라는 표현은 팀이 테스트할 수 없는 가정을 포함하지만, 상황(“집을 나서려다 장을 보러 주문을 깜빡했다는 사실을 깨달았을 때”)은 긴급성, 제약 조건, 그리고 사용자에게 “완료”가 어떤 느낌인지 설명한다는 것입니다. 동일한 상황에 있는 두 가지 매우 다른 페르소나는 종종 같은 것을 필요로 합니다.
장점: 잡 스토리는 디스커버리와 디자인에 유용하며, 팀이 컨텍스트에 집중하도록 하고, 고객 인터뷰를 위한 더 나은 질문을 생성합니다. 한계: 누가 무엇을 할 수 있는지에 대해서는 거의 언급하지 않으며, 이는 권한과 역할에 중요합니다. 대부분의 팀은 여전히 이를 계획 수립을 위해 사용자 스토리나 태스크로 변환합니다.
요구사항 명세
전통적인 형식은 번호 매겨진 명세입니다: “시스템은 5회 로그인 실패 후 계정을 잠그어야 한다.” 요구사항 명세는 여전히 규제 산업, 정부 입찰, 고정가 계약에서 표준이며, 이를 작성하는 현재 국제 표준은 ISO/IEC/IEEE 29148입니다.
애자일 팀도 요구사항 명세를 사용하지만, 주로 성능, 보안, 가용성, 접근성 등 여러 스토리에 걸쳐 적용되는 비기능 요구사항에 사용합니다. 이러한 요구사항은 보통 완료 정의(Definition of Done)나 짧은 품질 속성 페이지에 한 번 기록하며, 각 스토리에 반복해서 적지 않습니다.
세 가지 방식으로 작성된 동일한 기능
기능: 함께 사는 사람들용 공동 지출 앱에서, 한 사람이 무언가를 결제하고 비용을 다른 사람들과 나눕니다.
사용자 스토리로
공동 구매 비용을 지불한 동거인으로서, 해당 구매에 참여한 사람들과 비용을 나누고자 하며, 이를 통해 모든 사람의 잔액이 나에게 얼마를 갚아야 하는지 보여지기를 바랍니다.
- 비용을 나누는 그룹 구성원을 선택할 수 있으며, 저는 기본적으로 포함됩니다.
- 기본 분할은 균등하며, 정확한 금액이나 백분율로 전환할 수 있습니다.
- 앱은 부분 합계가 전체 금액과 일치하지 않는 분할을 저장하지 않으며, 차이 금액을 알려줍니다.
- 지출이 저장되는 즉시 각자의 잔액이 업데이트되고, 알림을 받습니다.
사용 사례로
사용 사례: 지출 분할. 주요 행위자: 지불자. 전제 조건: 지불자가 로그인되어 있고, 최소 한 명 이상의 다른 구성원이 있는 그룹에 속해 있음. 트리거: 지불자가 “지출 추가”를 선택함.
- 지불자가 금액, 설명 및 날짜를 입력합니다.
- 시스템이 그룹 구성원을 표시하며, 지불자가 선택된 상태로 나타납니다.
- 지불자가 비용을 나누는 구성원을 선택합니다.
- 시스템이 균등 분할을 제안하고 각자의 몫을 표시합니다.
- 지불자가 확인합니다.
- 시스템이 지출을 저장하고, 모든 잔액을 업데이트하며, 선택된 구성원에게 알림을 보냅니다.
- 4a. 지불자가 정확한 금액이나 백분율로 전환하면: 시스템이 각 값이 입력될 때마다 다시 계산합니다.
- 5a. 각자의 몫이 전체 금액과 일치하지 않으면: 시스템이 저장을 차단하고 차이를 표시합니다.
- 6a. 기기가 오프라인 상태이면: 시스템이 지출을 로컬에 저장하고, 대기 상태로 표시한 뒤, 온라인으로 돌아오면 동기화합니다.
- 성공 시 후조건: 지출이 한 번 기록되고, 모든 잔액이 이를 반영합니다. 실패 시: 잔액 변경 없음.
작업 스토리로
계산대에서 동거인들과 함께 쓸 무언가를 막 결제했을 때, 금액을 잊기 전에 기록하고 싶으며, 이를 통해 아무도 추궁하지 않고도 돈을 돌려받을 수 있기를 바랍니다.
요구사항 명세로
- REQ-1: 시스템은 그룹 구성원이 금액, 설명, 날짜, 지불자를 포함하여 지출을 기록할 수 있도록 허용해야 합니다.
- REQ-2: 시스템은 지불자가 지출을 균등하게, 정확한 금액으로, 또는 백분율로 나눌 수 있도록 허용해야 합니다.
- REQ-3: 시스템은 부분 합계가 전체 금액과 일치하지 않는 분할을 거부해야 합니다.
- REQ-4: 시스템은 저장 후 2초 이내에 모든 관련 잔액을 업데이트해야 합니다.
각 버전이 드러낸 내용을 살펴보세요. 사용자 스토리는 추정과 계획이 가장 쉽습니다. 사용 사례는 오프라인 상황을 제기하고 저장 실패 시 반드시 성립해야 할 조건을 명시한 유일한 버전입니다. 작업 스토리는 계산대에서의 속도라는 실제 제약을 드러냈으며, 첫 화면에 금액만 묻고 나머지는 묻지 않아야 함을 시사합니다. 이는 다른 어떤 버전도 제안하지 못했을 것입니다. 요구사항 명세는 스토리가 암시적으로 남긴 측정 가능한 성능 목표를 추가했습니다.
어떤 것을 사용해야 하나요?
| 상황 | 시작하기 | 이유 |
|---|---|---|
| 초기 탐색, 인터뷰, 무엇을 구축할지 결정 | 작업 스토리 | 팀을 사용자의 맥락에 집중시키고 더 나은 인터뷰 질문을 만들어 줍니다 |
| 애자일 제품 백로그, 스프린트 계획 | 수용 기준이 있는 사용자 스토리 | 작고, 추정 가능하며, 누구나 읽을 수 있습니다 |
| 복잡한 흐름, 통합, 자금 이동 | 사용 사례를 작성한 후 스토리로 분할 | 확장 항목은 실패 경로를 버그가 되기 전에 드러냅니다 |
| 규제 대상 제품, 공개 입찰, 고정가 계약 | 사용 사례로 추적되는 경우가 많은 요구사항 명세 | 감사 및 계약에는 번호가 매겨진 검증 가능한 명세가 필요합니다 |
| 성능, 보안, 접근성 목표 | 요구사항 명세 또는 완료 정의(Definition of Done) | 하나의 스토리가 아닌 여러 스토리에 적용됩니다 |
| 소규모 팀으로 진행하는 MVP | 사용자 스토리로 구성된 스토리 맵, 가장 위험한 흐름 하나에 대한 사용 사례 포함 | 빠르게 범위를 설정하고 구축할 수 있는 충분한 구조 |
이들을 조합할 수 있나요?
네, 대부분의 성숙한 팀이 그렇게 합니다. 실행 가능한 순서는 다음과 같습니다:
- 연구 단계에서는 실제 사용자로부터 상황과 동기를 포착하기 위해 잡 스토리를 사용하세요.
- 그 결과로 도출된 기능들을 스토리 맵 에 사용자 스토리로 배치하고 첫 번째 릴리스 슬라이스를 선택하세요.
- 실패 시 비용이 큰 1~2개의 흐름(결제, 가입, 데이터 동기화)에 대해서는 확장성을 찾기 위해 경량 사용 사례를 작성한 후, 각 확장을 별도의 스토리 또는 수용 기준으로 전환하세요.
- 횡단적 요구사항(성능, 보안, 접근성, 컴플라이언스)은 번호가 매겨진 명세나 완료 정의에 한 번만 기록하세요.
기본 원칙: 팀이 올바른 것을 안전하게 구축하는 데 필요한 만큼만 작성하세요. 3인 MVP 팀에는 요구사항 문서가 필요하지 않으며, 은행 연동은 한 문장에 의존해서는 안 됩니다.
자주 하는 실수
- 사용자 인터페이스 스크립트처럼 사용 사례를 작성하는 것(“사용자가 파란 버튼을 클릭합니다”)은 요구사항을 변경될 디자인에 묶어 버립니다.
- “so that”가 없는 사용자 스토리를 작성하는 것은 팀이 더 간단한 해결책을 제안하지 못하게 만듭니다.
- 잡 스토리를 위장한 페르소나처럼 취급하는 것(“바쁜 엄마일 때...”); 상황은 순간이어야 하며 정체성이 아닙니다.
- 긴 요구사항 목록을 백로그에 한 줄당 하나의 스토리로 복사하는 것은 사용자도 가치도 없는 스토리를 생성합니다.
- 같은 백로그에서 서로 다른 포맷을 사용하면서 어느 것이 진실의 원천인지에 대한 합의가 없는 경우
자주 묻는 질문
사용자 스토리와 사용 사례의 주요 차이점은 무엇인가요?
사용자 스토리는 누가 어떤 기능을 왜 원하는지 한 문장으로 설명하며, 작업 계획 및 우선순위 설정에 사용됩니다. 사용 사례는 행위자와 시스템 간의 상호작용을 단계별로 설명하며, 대체 경로와 실패 경로를 포함합니다. 스토리는 더 작고 상세도가 낮으며, 사용 사례는 전체 흐름을 보여줍니다.
사용자 스토리는 요구사항인가요?
이는 요구사항을 경량으로 포착하는 방법이지만 완전한 명세는 아닙니다. 세부 사항은 대화와 수용 기준에 존재합니다. 성능 및 보안과 같은 비기능적 요구사항은 별도로 기록되는 경우가 많습니다.
애자일 팀에서 여전히 사용 사례를 사용하나요?
네, 주로 복잡하거나 고위험 흐름에 사용합니다. Ivar Jacobson 및 동료들이 제안한 Use-Case 2.0은 사용 사례를 사용자 스토리처럼 계획할 수 있는 슬라이스로 분할하여, 두 가지가 같은 백로그에 공존할 수 있게 합니다.
잡 스토리와 사용자 스토리의 차이점은 무엇인가요?
사용자 스토리는 사용자 유형(“~인으로서”)에서 시작합니다. 잡 스토리는 상황(“~할 때”)에서 시작하며, 동기 및 예상 결과에 초점을 맞춥니다. 잡 스토리는 jobs-to-be-done 사고방식에서 유래하며, 발견 및 디자인 단계에서 가장 유용합니다.
하나의 사용 사례가 여러 사용자 스토리가 될 수 있나요?
네. 주요 성공 시나리오는 보통 1~2개의 스토리가 되며, 각 중요한 확장은 별도의 스토리 또는 수용 기준이 됩니다. 이는 엣지 케이스를 잃지 않고 큰 기능을 분할하는 신뢰할 수 있는 방법입니다.
사용 사례와 테스트 케이스의 차이점은 무엇인가요?
사용 사례는 행위자의 목표를 충족하기 위해 시스템이 어떻게 행동해야 하는지 설명합니다. 테스트 케이스는 특정 입력과 예상 결과로 해당 행동의 특정 경로를 확인합니다. 하나의 사용 사례는 보통 여러 테스트 케이스를 생성합니다.
제품에 필요한 명세 수준이 확실하지 않으신가요? 우리는 창업자가 아이디어를 범위가 설정된 백로그로 전환하고 짧은 스프린트로 구축하도록 돕습니다. 보기 월간 개발 플랜.