"사용 사례", "사용자 사례"및 "사용 시나리오"의 차이점에 대한 정확하지만 간단하고 이해하기 쉬운 정의가 있습니까?

꽤 많은 설명이 있지만 지금은 한 문장 또는 두 문장의 차이점을 설명하는 사람이 없습니다 ...

(예 : http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison 매우 길고 찾기 어려우며 토론으로 가득 함)

사용자 스토리 (A)의 약식, 친근하고 작은 버전입니다 사용 사례 뺀 UML 다이어그램; 일반적으로 반복 시나리오에서 사용됩니다.

사용 시나리오는 때때로 플로우 차트와 함께 단계별 절차, 속으로 그려진 사용 사례입니다.

나에게 사용자 스토리와 사용 사례의 가장 큰 차이점은 다음과 같습니다.

• 사용자 스토리는 A는 경량 (A로, 내가 원하는,하기 위해서) 카드에 기록 할 수있는 문서. 사용자 스토리는 모든 세부 사항을 캡처하지는 않으며 토론에 대한 비공식적 인 지원입니다.
• 사용 사례 입니다 헤비급 워드 문서를 필요로 문서. 단계 및 / 또는 조치의 "정상 플로우"및 자세한 "대체 플로우"에 대해 설명합니다. 유스 케이스는 모든 세부 사항을 캡처하며 공식 스펙입니다.

사용 시나리오의 Scott W. Ambler에 따르면 이러한 아티팩트는 유스 케이스 플로우처럼 보입니다.

사용 시나리오 짧게, 또는 시나리오의 실제 예를 들어 설명하는 방법을 하나 또는 그 이상의 사람이나 조직 시스템과 상호 작용합니다. 상호 작용 중에 발생하는 단계, 이벤트 및 / 또는 조치를 설명합니다. 사용 시나리오는 매우 상세하여 누군가가 사용자 인터페이스를 사용하는 방식을 정확하게 나타내거나 중요한 비즈니스 작업을 설명하는 수준이 높지만 수행 방식을 나타내는 것은 아닙니다.

솔직히 유스 케이스 플로우와의 차이점은이 단락을 읽은 후에도 명확하지 않습니다 (마지막 문장이 가장 중요 할 수 있음).

상상할 수 있듯이 사용 사례와 시나리오에는 몇 가지 차이점이 있습니다. 먼저, 유스 케이스는 일반적으로 고객과 같은 일반 행위자를 참조하고 시나리오는 일반적으로 John Smith 및 Sally Jones와 같은 행위자의 예를 참조합니다. 일반적인 시나리오를 작성하는 데 방해가되지는 않지만 일반적으로 이해를 돕기 위해 시나리오를 개인화하는 것이 좋습니다. 둘째, 사용 시나리오는 단일 논리 경로를 설명하지만 유스 케이스는 일반적으로 여러 경로 (기본 코스와 적절한 대체 경로)를 설명합니다. 셋째, UP 기반 프로세스에서 유스 케이스는 종종 공식 문서로 유지되는 반면 시나리오는 더 이상 필요하지 않은 경우 종종 폐기됩니다.

틀릴 수도 있지만 사용 시나리오는 실제로 사용 사례 흐름과 비슷하지만 애자일 터치로 브랜드가 변경되었습니다.

이 것들에 대한 정확한 정의는 없습니다. 회사마다 그리고 시스템마다 조금씩 다릅니다.

가장 좋은 방법은 현재 프로젝트에 대한 예제를 찾아서 따르는 것입니다.

새 시스템을 만드는 경우 원하는 시스템에 따라 다양한 유형의 사용 사례에 대한 정의를 찾을 수 있습니다. 의도를 가장 잘 전달하는 것으로 보이는 패턴 만 선택하십시오.

이름에 매달리지 마십시오.

사용자 스토리는 항상 비공식적이며 사용자의 요구를 설명합니다. 유스 케이스는 공식적이거나 비공식적 일 수 있으며 시스템 동작을 설명합니다.

"기술"사용자 스토리를 가질 수 있지만 사용 사례와 동일하지 않습니다.

완료되면 사용자 스토리는 일반적으로 삭제됩니다. 제품 수명주기 동안 사용 사례가 유지 될 수 있습니다.

범위도 다릅니다. 사용자 스토리는 일반적으로 범위가 더 작기 때문에 유스 케이스는 여러 사용자 스토리로 구성됩니다. 기존 시스템에 대한 변경된 요구 사항은 새로운 사용자 사례 또는 업데이트 된 사용 사례 버전에 설명되어 있습니다.

사용자 사례와 사용 사례의 유사점은 둘 다 계획 및 예약에 사용된다는 것입니다.

개발자에게 개별적으로 할당 할 수있는 작업으로 분해 될 때 사용자 사례는 사용 사례 시나리오보다 범위가 더 세분화되고 제한되지 않을 수 있습니다. 사용자 스토리는 사용자의 요구, 즉 시스템 사용의 목표 또는 결과에 관한 것입니다.

사용자 사례의 예는 다음과 같습니다.

1. 저는 고객이며 계정 잔액을 온라인으로 지불하고 싶습니다.
2. 저는 고객이며 저장된 신용 정보에 대해 만료 연도를 업데이트하려고합니다.

최고 수준의 추상화에서 유스 케이스는 고객 업데이트 카드 만료 연도와 매우 유사하게 들리지만 목표보다는 기능에 대한 진술입니다.

유스 케이스 시나리오의 세분성이 정의됨에 따라 기능 및 절차에 대한 정보가 더 많아집니다.

유스 케이스 기본 시나리오의 사후 조건은 사용자 스토리 (고객의 신용 카드 만료 연도가 업데이트 됨)에 명시된 것과 동일한 결과 여야합니다.

유스 케이스 시나리오는 텍스트 또는 프로세스 플로우 차트에 단계별로 설명되어 있습니다 (UML 또는 BPM 일 필요는 없음)-표준 교차 기능 플로우 다이어그램을 사용하여 유스 케이스의 교육받지 않은 소비자가 명확하고 사용하기 쉽도록합니다.

결론은 사용자 사례는 요구와 결과 (시스템이 제공해야하는 것)를 설명하는 반면 유스 케이스는 목표를 달성하는 데 필요한 액터 간의 상호 작용을 설명하고 잘못 될 수있는 것 (확장, 대체 또는 오류 시나리오) (사용자와의 상호 작용 방식)을 설명합니다. 시스템은 그 결과를 달성합니다)

이 주제에 대한 자세한 내용 은 Alistair Cockburn 웹 사이트에서 http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison 을 참조 하십시오 . 그는 사용자 스토리를 만들었고 지난 수십 년 동안 유스 케이스 전문가로 간주 된 Agile Manifesto의 서명자이므로 더 많은 정보를 얻을 수있는 훌륭한 출처라고 생각합니다.

_{빠른 임시 참고 사항 :이 게시물은 1) 추가 세부 정보가 참조에 포함되어야합니다 .2) 일부 인용이있을 수 있습니다 .3) 영어의 전반적인 정확성 4) 전반적인 이야기의 질 5) 등과 같은 질문에 대한 답변을 개선하기 위해 개선이 필요합니다. 다시 직접 개선하십시오.}

템플릿을 살펴보면 이러한 용어의 차이점에 대한 귀중한 통찰력을 얻을 수 있습니다.

사용 사례

사용 사례를위한 여러 템플릿이 있습니다. 빠른 검색 후 3을 찾았습니다 : 1 , 2 , 3 . 그들이 모호하게 공유하는 몇 가지 요점은 다음과 같습니다.

1. 유스 케이스 이름 / 제목
2. 설명 -범위를 설명하는 짧은 텍스트입니다.
3. 액터 / 일차 액터 -이 특정 사용 사례와 상호 작용하는 사람.
4. 전제 조건 -이 사용 사례가 수명주기를 시작하기 전에 참이라고 가정 할 수있는 모든 것
5. 성공 시나리오 -발생하는 올바른 이벤트 흐름을 설명하는 일련의 단계입니다.

6. 확장 -성공 시나리오의 흐름에서 벗어날 때 응용 프로그램의 흐름 :

   1. 대체 흐름 -올바른 흐름의 다른 옵션
   2. 예외 흐름 -상황이 잘못되었을 때의 이벤트 흐름

7. 성공 보장 (일명 사후 조건)-모든 작업이 완료된 후의 애플리케이션 상태

포함 할 수있는 몇 가지 추가 포인트는 레벨 , 최소 보증 , 트리거 등입니다.

위는 완전 옷을 입은 유스 케이스 입니다. 다음과 같이 가장 중요한 포인트 만 사용하여 일반적인 사용 사례 를 사용 하여 사용 사례 작성을 단순화 할 수 있습니다 .

1. 표제
2. 배우
3. 사건의 연속

사용 사례는 80 년대 후반 90 년대 초 Ivar Jacobson에 의해 만들어지고 대중화되었습니다. 나중에 다른 사람들도 그의 작업에 기여했습니다 (이러한 사람들 중 하나는 Writing Effective Use Cases의 저자 인 Alistair Cockburn입니다 ). 하려면 마틴 파울러의 의역 그것의 텍스트에 텍스트와 UML 다이어그램, 그러나 그들의 가장 큰 가치 거짓말을 이용하실 수 있습니다 사용 사례를. 그들은 크지 않고 읽기 쉽지 않을 때 가장 좋습니다.

사용자 스토리 _{(일명 기능)}

사용자 이야기-특정 기능을 설명하는 작은 이야기. 사용자 스토리를 작성하는 일반적인 패턴이 있습니다.

A와 사용자의 특정 유형
내가 원하는 일을 할
수 있도록 몇 가지 이유 .

또한 사용자 스토리에는 승인 기준 이있을 수 있습니다 .

보시다시피이 템플릿은 사용 사례보다 훨씬 작습니다. 사용자 스토리는 일반적으로 소프트웨어 개발의 scrum / agile / xp 영역과 관련이 있습니다. 그것들은 포스트잇 노트와 같은 작은 표면 영역 및 / 또는 스크럼 보드에 쓰여 져야합니다. 그곳에서 그들은 (보통) 해당 사용자 스토리에 투자 할 얼마나 많은 노력이 필요 대략 소수점 값 주어진다 ^심판 .

Bill Wake 는 좋은 사용자 스토리의 특성을 설명하기 위해 INVEST 니모닉 을 개발했으며 Martin Fowler의 짧은 요약을 그의 웹 사이트에서 빌릴 것입니다 .

독립성 : 스토리는 어떤 순서로든 전달 될 수 있습니다.
협상 가능 : 스토리에있는 내용의 세부 사항은 개발 중에 프로그래머와 고객이 공동 작성합니다.
귀중한 : 기능은 소프트웨어의 고객 또는 사용자에게 귀중한 것으로 간주됩니다.
추정 가능 : 프로그래머는 스토리를 구축하기위한 합리적인 견적을 제시 할 수 있습니다.
스몰 : 스토리는 적은 시간, 일반적으로 사람의 일로 구축해야합니다. 확실히 한 번의 반복으로 여러 스토리를 만들 수 있어야합니다.
테스트 가능 :이 스토리의 소프트웨어가 올바르게 작동하는지 테스트하기 위해 테스트를 작성할 수 있어야합니다.

사용 시나리오

사용 시나리오는 다음과 같이 Given-When-Then을 나타내는 GWT 패턴을 따릅니다.

시나리오 : 제목
제공된 : 특정 사실
및 : 다른 특정 사실 (선택적 일 수 있음)
시기 : 일부 이벤트가 발생한 경우
다음 : 일부 다른 이벤트가 발생

사용 시나리오는 행동 주도 개발과 관련이 있습니다. 테스트와 매우 유사합니다. 블로그 포스트의 Martin Fowler는 사용 시나리오에 대한 몇 가지 역사와 추론을 제공합니다. 중요한 부분은 다음과 같습니다.

주어진 당신은이 시나리오에서 지정하고있는 동작을 시작하기 전에 부분은 세계의 상태를 설명합니다. 테스트의 전제 조건으로 생각할 수 있습니다. 때 섹션을 지정하고 있다는 그 동작입니다. 마지막으로 then 섹션은 지정된 동작으로 인한 변경 사항을 설명합니다.

사용 시나리오는 응용 프로그램에 대한 테스트 작성에 사용될 수 있습니다. Martin의 게시물의 마지막 단락을 인용하려면 다음을 수행하십시오.

Given-When-Then 스타일은 BDD에 증상이 있지만 기본 아이디어는 테스트 또는 스펙을 예제로 작성할 때 매우 일반적입니다. Meszaros는 패턴을 4 상 테스트로 설명합니다. 그의 4 단계는 설정 (Given), 연습 (When), 확인 (Then) 및 Teardown입니다. Bill Wake는 Arrange, Act, Assert로 공식화했습니다.

더 많은 연구를위한 참고 자료 :

에 대한 위키 백과 페이지 를 사용하는 경우 , 사용자 스토리 , 사용 시나리오
에 마틴 파울러의 블로그를 사용하는 경우 , 사용자 스토리 , 사용 시나리오

User Story에 익숙하지 않지만 몇 년 전에 이것을 살펴봤을 때 :

유스 케이스는 중요한 작업입니다.
사용자 시나리오는 작업을 수행 할 수있는 다양한 방법입니다. 따라서 모든 유스 케이스에는 하나 이상의 시나리오가 있습니다. 유스 케이스는 초록이며, 사용자 시나리오는 해당 초록 태스크의 가능한 모든 인스턴스의 카탈로그입니다.

따라서 :
사용 사례 A : 사용자는 ID와 비밀번호로 인증합니다.

시나리오 :
1. ID가 인식되고 암호가 정확합니다. ( "화창한 날"시나리오)
2. ID가 인식되고 암호가 올바르지 않습니다.
3. 아이디가 인식되고 비밀번호가 세 번째 잘못되었습니다.
4. 아이디가 인식되지 않습니다.

나는 항상 사용 사례를 고객의 관점에서 요구 사항을 서술 방식으로 정의하는 방법으로 생각했습니다. 클라이언트가 "하지만 시스템이 다운 될 때 자정과 로그인 사이에 로그인하려고하면 어떻게됩니까?"라고 표시되면 인증 작업에 대한 다른 시나리오와 몇 가지 추가 요구 사항이 발견되었습니다.

사용자 스토리는 고객의 관점에서 비롯된 것이며 때로는 부정확하거나 불완전합니다. 성능, 오류 처리 또는 백엔드에 대한 고려 사항이 없을 수 있습니다.

유스 케이스는 개발자의 관점에서입니다. 정확하고 완전합니다. 고객의 모든 요구 사항에 답변해야합니다.

"사용 사례"와 "사용자 사례"는 고객의 "요구 사항"을 의미한다는 점에서 동일합니다.

유스 케이스는 시스템이 각 경우에 사용되는 방식으로, 일반적으로 액터와 시스템 또는 시스템 간의 상호 작용으로 표시됩니다.

사용자 사례는 최종 사용자가 무언가를 수행 할 수있게 해주는 컴퓨터 지원 도구를 만드는 여정의 출발점입니다. 일반적으로 누가, 무엇을, 왜 ( "사용자가 응용 프로그램을 닫을 때, 나는 원합니다. 유용한 작업을 보존하고 잘못된 작업을 버릴 수 있도록 마지막 저장 이후 변경된 내용을 저장하라는 메시지가 표시됩니다. "). 그런 다음이 사용자 스토리는 개발자가 애플리케이션을 빌드하기 위해 사용하는 테스트 사례와 테스터가 테스트를 수행하는 사례로 발전시켜야합니다.

QA 테스터의 관점에서 볼 때 "사용자 사례"를 테스트하는 것이 아니라 "사용 사례"를 테스트하는 것입니다. 이는 소프트웨어 기능을 테스트하는 것을 의미합니다.

사용 시나리오의 목적은 시스템 작업의 세부 사항이나 실제 디자인에 대해 자세히 살펴 보지 않고 목표를 달성하기위한 시스템과의 사용자 상호 작용의 본질을 포착하는 것입니다. 초점은 시스템이 아니라 사용자에 있습니다.

... 사용 사례에는 시스템이 수행 할 작업에 대한 설명도 포함되어 있지만 사용 시나리오에서는이 논의를 피합니다.

구현 방법을 아직 결정하지 않았습니다.

로부터 제품 예술 사이트.