효과적인 사용 사례를 작성하는 방법

게시 됨: 2015-08-21

효과적인 사용 사례를 작성하는 방법

사용 사례는 비즈니스 로직과 시스템 프로세스를 문서화하는 데 널리 사용됩니다. 그러나 유용한지, 어떻게 구성해야 하는지에 대해 많은 의견이 있습니다. 일부 프로젝트에서 개발자는 사용 사례가 장황하거나 실제로 많은 것을 이해하지 못한다는 유스 케이스를 보지 않습니다. 비즈니스 분석가는 사용 사례를 실제로 효과적으로 만들기 위해 무엇을 할 수 있습니까?

우리 대부분은 사용 사례가 비즈니스 프로세스를 설명하고 특정 목표에 대한 시스템과 행위자 간의 상호 작용에 대한 사양이라는 것을 알고 있습니다. 사용 사례 문서는 요구 사항 문서와 다르며 설계 문서와 동일하지 않습니다.

요구 사항에 대한 사용 사례의 두 가지 예를 살펴보겠습니다. 그 중 어느 것이 더 낫다고 생각하십니까?

예 – 1

사용 사례 세부정보 코멘트

사용 사례 이름 – 티켓 주문

이름이 좋다. 사용 사례가 무엇인지 명확하게 나타냅니다.

목표 – 고객이 웹사이트에서 축구 경기 티켓을 성공적으로 예약

설명 - 배우가 웹사이트를 방문하여 조회합니다.
일정, 경기 선택
그리고 좌석, 책
티켓을 구매하고 축구 경기에 대한 지불을 합니다.

목표와 설명 이 명확하게 언급되어 있습니다.
이것은 디자이너에게 도움이 될 것입니다
개발자는
설계 문서 및 코드의 목표

행위자 – 고객, 고객 서비스 담당자
전제 조건 – 시스템이 가동되어 실행 중입니다.
트리거 – 행위자가 티켓을 예약하기 위해 시스템에 액세스했습니다.
사후 조건 – 배우는 티켓을 예약할 수 있습니다. 시스템이 정보를 업데이트합니다.

Actor ,
전제 조건, 사후 조건 및
도움이 될 트리거가 언급되었습니다.
응용 프로그램의 설계 및 개발이 더 쉬워집니다.

주요 흐름 – 단계

  1. 배우가 웹사이트에 액세스하여 티켓 예약을 선택합니다.
  2. 시스템이 예약 정보를 표시합니다.
  3. 액터가 경기 내용을 확인합니다(자세한 내용은 UI 사양 참조).
  4. 배우가 좌석 세부 정보를 확인합니다(자세한 내용은 UI 사양 참조).
  5. 시스템에서 가용성 확인
  6. 시스템은 사용자 정보를 얻기 위한 양식을 제공합니다.
  7. 액터는 사용자 정보를 제공합니다(다른 사용 사례의 세부정보).
  8. 시스템은 지불 정보 양식을 제시합니다.
  9. 행위자는 지불 정보를 제공합니다(다른 사용 사례의 세부 정보)
  10. 시스템이 세부 정보를 확인하고 예약 ID를 제공합니다.
  11. 배우가 티켓을 저장합니다.
  12. 액터가 시스템을 종료합니다.

포함된 사용 사례

– 결제하기

– 예약 ID 생성

확장된 사용 사례

– 결제 실패 메모 생성

– 티켓 인쇄

주요 흐름의 단계는 명확하지만
UI 세부 정보 는 생략됩니다. 사용 사례의 UI 세부정보
좌석 선택 및 매치에 대해
선택은 사용 사례를 다루기 어렵게 만들 수 있습니다.
사용 사례 는 액터가 수행해야 하는 작업과 시스템이 수행할 작업을 명확하게 보여줍니다.
지불 절차는
작업을 수행할 수 있도록 다양한 사용 사례
다른 디자인 구성 요소로 쉽게 나뉩니다.
포함확장 사용 사례의 이름이 지정됨
할 수 있도록
자세한 내용은 참조하십시오.

대체 흐름

-티켓 취소

  1. 행위자가 거래를 취소함
  2. 시스템이 거래를 취소함

예외 흐름

-일부 경기/일부 좌석은 티켓 사용 불가

1. 시스템에 오류 메시지가 표시됩니다.

대체 및 예외 흐름 이 자세히 설명되어 있습니다.

* 사용 사례는 참조 및 대체 및 예외 흐름 측면에서 더 자세히 설명할 수 있습니다. 이 예는 잘 작성된 사용 사례에 포함되어야 하는 내용을 강조하기 위한 것입니다.

예 – 2

사용 사례 세부정보 코멘트

사용 사례 이름 – 티켓 주문

이름은 사용자 관점이 아니며 비즈니스 프로세스 정의처럼 보입니다.

설명 – 배우가 웹사이트를 방문하여 일정을 보고 경기와 좌석을 선택하고 티켓을 예약하고 축구 경기에 대한 지불을 합니다.

사용 사례의 목표가 누락되었습니다. 디자이너, 테스트 분석가 및 개발자는 이 기능을 개발해야 하는 이유를 이해하지 못할 것입니다.

행위자 – 고객, 고객 서비스 담당자
트리거 – 행위자가 티켓을 예약하기 위해 시스템에 액세스했습니다.
사후 조건 – 배우는 티켓을 예약할 수 있습니다. 시스템이 정보를 업데이트합니다.

전제 조건이 누락되었습니다.

주요 흐름 단계

  1. 고객은 웹사이트에 접속하여 '티켓 예약' 옵션을 선택하여 '티켓을 예약합니다.
  2. 시스템이 드롭다운에 일치 목록을 표시합니다.
  3. 고객 서비스 담당자가 드롭다운에서 선택합니다.
  4. 시스템은 좌석 지도에 좌석 세부 정보를 표시합니다.
  5. 배우가 좌석을 선택합니다. 좌석이 없을 경우 오류 메시지가 표시됩니다.
  6. 배우가 지불 세부 정보를 제공합니다.
  7. 배우는 티켓을 예약하고 그렇지 않으면 티켓을 취소합니다.
  8. 시스템은 고객의 이름과 무작위로 생성된 4자리 숫자를 사용하여 예약 ID를 생성합니다.

포함된 사용 사례
– 결제하기

사용 사례 단계에서 독자를 혼란스럽게 할 수 있는 실제 UI 요소에 대한 몇 가지 참조가 있습니다. 대체 플로우는 메인 플로우 내에 작성되어 전체 프로세스를 이해하기 어렵습니다.
행위자는 '고객, 행위자 및 고객 서비스 담당자'라는 많은 이름으로 언급되어 혼란스럽습니다.
예약 ID 생성은 티켓 주문과 관련된 행위자에게 관심이 없지만 여기에 설명되어 있습니다.
대체 흐름, 예외 흐름 및 모든 관련 사용 사례에 대한 언급이 없습니다.

이 사용 사례는 명확성과 세부 사항이 부족하고 팀이 기능을 적절하게 개발하는 데 도움이 되지 않습니다.

유스 케이스에 있어야 할 것 사용 사례에 있어서는 안 되는 것
  1. 이름
  2. 설명/목표
  3. 전제 조건
  4. 방아쇠
  5. 기본 흐름 및 대체 흐름
  6. 예외 시나리오
  7. 포스트 조건
  8. 특별 요구 사항이 있는 경우
  9. UI 세부 정보 및 기타 관련 모델/다이어그램에 대한 링크
  1. 구현 세부 정보
  2. 내부 처리
  3. 비기능적 요구사항
  4. 사용자 인터페이스 세부 정보는 사용 사례와 동시에 수행해야 하지만 별도의 문서에서 수행해야 합니다.

.

유용한 사용 사례를 작성하기 위해 따라야 할 몇 가지 팁:

  1. 액터의 관점에서 사용 사례 단계를 작성하십시오.
  2. 사용 사례에는 디자인 및 아키텍처 세부 정보가 없어야 합니다. 비즈니스 프로세스에 집중해야 합니다.
  3. 사용 사례의 단계를 시간 순서대로 작성하는 것이 좋습니다.
  4. 요구 사항과 복잡성에 따라 CRUD(생성, 읽기, 업데이트 및 삭제) 작업을 별도의 사용 사례에 보관해야 하는지 아니면 하나로 결합할 수 있는지 결정합니다.
  5. 비즈니스 설계가 완료되도록 대체 흐름, 예외 흐름, 포함된 사용 사례 및 확장된 사용 사례에 대한 참조를 제공하는 것이 중요합니다.
  6. 템플릿(프로젝트 정의, 회사 정의 또는 세부 정의)을 선택하고 모든 사용 사례의 구조를 따르십시오.
  7. 사용 사례 다이어그램을 갖는 것이 중요합니다.
  8. Agile에는 요구 사항을 캡처하는 사용자 스토리가 있습니다. 반복적인 방식으로 린 사용 사례를 사용하여 사용자 스토리를 자세히 설명할 수 있습니다.
  9. 유효성 검사를 자세히 설명해야 합니다.

사용 사례를 작성한 후 다음 질문을 하고 모든 질문에 대한 대답이 "예"인 경우 효과적인 사용 사례입니다.

  1. 사용자는 사용 사례에 있는 비즈니스 흐름이 언제 실행되는지 알 수 있습니까?
  2. 사용 사례의 어떤 단계를 누가 수행할 것인지 명확합니까?
  3. 분석, 설계, 개발 및 테스트를 위한 정보가 충분하도록 비즈니스 로직에 대한 설명이 되어 있습니까?
  4. 기본 흐름에서 대체 및 예외 흐름으로의 적절한 참조가 있습니까?
  5. 사용 사례 다이어그램이 있습니까?

사용 사례는 요구 사항을 캡처하고 제대로 작성된 비즈니스 프로세스를 공식적으로 문서화하는 효과적인 방법입니다. 전체 팀은 사용 사례를 사용하여 작업을 수행하도록 지도해야 합니다. 사용 사례 및 사용 사례 다이어그램은 고객과 비즈니스 프로세스를 논의하는 좋은 방법입니다. 사용 사례 작성에 대한 지침이 있는 표준 사용 사례 템플릿을 갖는 것이 좋습니다. 이러한 방식으로 작성된 사용 사례는 모든 프로젝트 팀 구성원과 이해 관계자가 평가할 것입니다.