사용 사례

시리즈의 일부
소프트웨어 개발
핵심 활동 과정 요구 사항들 설계. 건설 공학 기술 테스트 디버깅 도입 유지
패러다임 및 모델 소프트웨어 엔지니어링 민첩성 클린룸 증분 시제품 제작 나선형 V모델 폭포
방법론 및 프레임워크 Asd. DevOps 아빠. DSDM FDD 아이디 칸반 린 SD 더 적은 MDD MSF PSP RAD RUP 안전한 스크럼 세마토 TSP 열어 보세요. 업. XP
지원 분야 구성 관리 문서 소프트웨어 품질 보증 프로젝트 관리 사용자 경험
프랙티스 ATDD BDD CCO CI CD Ddd. PP SBE 스탠드업 TDD
도구들 컴파일러 디버거 프로파일러 GUI 디자이너 모델링. IDE 자동화 구축 릴리스 자동화 코드로서의 인프라스트럭처 테스트
지식의 표준과 본문 바복 CMMI IEEE 표준 ISO 9001 ISO/IEC 표준 PMBOK 스웨복 IT 인식하다
용어집 인공지능 컴퓨터 공학 전기전자공학
개요 소프트웨어 개발의 개요
v t

소프트웨어 및 시스템 엔지니어링에서 use case라는 용어는 다음 두 가지 의미를 가진 폴리섬입니다.

1. 소프트웨어의 사용 시나리오입니다.소프트웨어가 도움이 될 수 있는 상황을 제안하기 위해 여러 개로 사용되는 경우가 많습니다.
2. 시스템이 외부 요구(사용자 입력 등)를 수신하여 응답하는 시나리오입니다.

이 글은 후자의 의미를 논한다.

유스케이스는 일반적으로 역할(UML(Unified Modeling Language)에서 액터로서 알려진)과 목표를 달성하기 위한 시스템 간의 상호작용을 정의하는 액션 또는 이벤트 단계 목록입니다.배우는 인간일 수도 있고 다른 외부 시스템일 수도 있습니다.시스템 엔지니어링에서 사용 사례는 소프트웨어 엔지니어링 내부보다 더 높은 수준에서 사용되며, 종종 미션 또는 이해관계자의 목표를 나타냅니다.상세한 요건은 Systems Modeling Language(SysML) 또는 계약서에 기재할 수 있습니다.

역사

1987년, Ivar Jacobson은 OOPSLA'87 ^[1]컨퍼런스에서 사용 사례에 대한 첫 번째 기사를 발표했습니다.그는 Ericson에서 이 기술을 사용하여 텍스트, 구조 및 시각적 모델링 기술을 사용하여 객체 지향 분석 및 ^[2]설계를 추진하는 시스템의 요구사항을 포착하고 지정하는 방법에 대해 설명했습니다.원래는 사용 시나리오와 사용 사례라는 용어를 사용했지만(스웨덴어로 anvendingsfall을 직접 번역한 것) 영어에서는 이 두 용어가 모두 자연스럽게 들리지 않는다는 것을 알게 되어 결국 ^[3]사용 사례를 선택했습니다.

1992년에 그는 객체 지향 소프트웨어 엔지니어링 - 사용 사례 ^[4]기반 접근법이라는 책을 공동 집필했습니다. 이 책은 OOS 시스템 엔지니어링 방법의 토대를 마련하고 특히 소프트웨어 개발에서 기능 요건을 포착하기 위한 사용 사례를 널리 알리는 데 도움이 되었습니다.1994년에 그는 비즈니스 모델 및 비즈니스 프로세스 ^[5]리엔지니어링에 적용된 사용 사례와 객체 지향 기술에 대한 책을 출판했습니다.

동시에 Grady Boch와 James Rumbaugh는 각각 객체 지향 분석 및 설계 방법인 Boach 방식과 객체 모델링 기법(OMT)을 통합하는 작업을 수행했습니다.1995년에 Ivar Jacobson은 이 회사에 합류하여 함께 UML(Unified Modeling Language)을 개발하였습니다.Unified Modeling Language에는 사용 사례 모델링이 포함되어 있습니다.UML은 ^[6]OMG(Object Management Group)에 의해 1997년에 표준화되었습니다.Jacobson, Boch 및 Rumbaugh는 Objectory 소프트웨어 개발 프로세스의 개선에도 힘썼습니다.그 결과 1999년에 발표된 유니파이드 프로세스는 활용 사례 중심 ^[7]접근 방식을 촉진했습니다.

Since then, many authors have contributed to the development of the technique, notably: Larry Constantine developed in 1995, in the context of usage-centered design, so called "essential use-cases" that aim to describe user intents rather than sequences of actions or scenarios which might constrain or bias the design of user interface;[8] AlistairCOckburn 2000년에 목표 지향적인 활용 사례 연습 텍스트 담화, 표로 나타낸 사양에 따라;[9]커트 Bittner와 이안'스펜스'2002년 진보한 풍습에 활용 사례와 기능 요건을 분석하기 위한;[10]딘 Leffingwell고 Widrig와 소통 이해 관계자 경영진을 교체하는 경우 적용할 것을 제안했다 개발을 발간했다. activit예를 들어,^[11] Gunnar Overgaard는 2004년에 설계 패턴의 원칙을 사용 ^[12]사례로 확장하도록 제안했다.

2011년 Jacobson은 Ian Spence 및 Kurt Bittner와 함께 전자책 Use Case 2.0을 발행하여 기교를 민첩한 컨텍스트에 맞게 조정하고, 증분 사용 사례 "슬라이스"를 통해 기술을 풍부하게 하며, 연례 IIBA ^[14][15]컨퍼런스에서 새로운 접근 방식을 발표한 후 개발^[13] 라이프사이클 전체에 걸쳐 사용을 촉진했습니다.

일반원칙

사용 사례는 ^[10]시스템의 요구사항을 파악, 모델링 및 지정하는 기술입니다.활용 사례는 시스템이 행위자와 상호작용하여 수행할 수 있는 일련의 행동에 해당하며, 이는 목표 달성에 기여하는 관찰 가능한 결과를 생성합니다.행위자는 인간 사용자 또는 다른 시스템이 상호작용에서 갖는 역할을 나타냅니다.

요건 분석에서는, 그 식별시에, 주된 행위자에 대해서 나타내는 특정의 유저 목표에 근거해 유스케이스가 명명됩니다.사례는 텍스트 설명이나 활동 및 사건의 일반적인 순서와 특수 조건, 예외 또는 오류 상황과 같은 변형에 대해 설명하는 추가 그래픽 모델을 사용하여 더 자세히 설명된다.

Software Engineering Body of Knowledge(SWEBOK)[16]에 따르면 사용 사례는 모델 기반 분석 기술뿐만 아니라 시나리오 기반 요구사항 도출 기술에 속합니다.그러나 이 사용 사례는 서술 기반 요구사항 수집, 증분 요구사항 획득, 시스템 설명서 및 수락 ^[1]테스트도 지원합니다.

바리에이션

기술에는 다음과 같은 다양한 사용 사례와 다양한 종류가 있습니다.

• 시스템 사용 사례는 ^[2]개발할 시스템의 요건을 명시합니다.그들은 상세한 설명에서 행위자와의 상호작용뿐만 아니라 처리에 관여하는 실체도 식별한다.이들은 향후 분석 모델 및 설계 활동의 출발점이 됩니다.
• 비즈니스 활용 사례는 소프트웨어 시스템이 아닌 비즈니스 조직에 초점을 맞춥니다.비즈니스 프로세스 리엔지니어링 ^[5]이니셔티브의 맥락에서 비즈니스 모델 및 비즈니스 프로세스 요구사항을 지정하는 데 사용됩니다.
• 추상적 사용 사례라고도 불리는 필수 사용 사례는 시퀀스를 정의하거나 시나리오를 ^[8]설명하지 않고 행위자의 잠재적 의도 및 시스템이 이러한 문제를 해결하는 방법을 설명합니다.이 프랙티스는 사용자 중심 ^[7]설계를 지원하고 시스템 사양의 초기 단계에서 사용자 인터페이스에 대한 편견을 유발하지 않도록 하기 위해 개발되었습니다.
• Use Case 2.0은 신속한 변화를 위한 개발 ^[1]방법의 맥락에 맞게 기술을 조정합니다.이 기법은 사용자 스토리의 내러티브를 지원함으로써 요건 수집의 실천을 풍부하게 합니다.또한 요구사항의 증분 도출을 촉진하고 증분 구현을 가능하게 하는 사용 사례 "슬라이스"도 제공합니다.

범위

사용 사례의 범위는 주제 및 목표에 따라 정의할 수 있습니다.

• 대상자는 상호작용을 ^[17]제공하는 시스템, 하위 시스템 또는 구성 요소를 식별합니다.
• 목표는 목표에 관심이 있는 조직 수준(예: 회사, 부서, 사용자)과 사용자의 목표를 하위 ^[9]목표로 분해하는 것을 고려하여 계층적으로 구성될 수 있다.목표의 분해는 기존의 기능 ^[10]분해와는 다른 시스템과는 독립적으로 사용자의 관점에서 수행된다.

사용.

사용 사례는 다음 컨텍스트에서 적용되는 것으로 알려져 있습니다.

• 구동 요소로서의 객체 지향 소프트웨어 엔지니어링(OOSE)^[4]
• 행동 모델링 ^[17]도구로서의 통합 모델링 언어(UML)
• Unified Software Development Process(UP) 및 그 선두 주자인 IBM RUP([7]Rational Unified Process)
• 기능 ^[18]요건의 대체 구조로서 소프트웨어 요건 사양(SRS)의 사전 문서화
• 엔티티-컨트롤-프로세서 ^[7]접근방식을 사용하여 요건에서 설계를 도출한다.
• 신속한 개발을 ^[1][19]실현합니다.

템플릿

사용 사례를 텍스트로 작성하는 방법에는 사용 사례 개요, 캐주얼, 아웃라인, 완전 복장 등 다양한 템플릿이 있습니다.다양한 벤더 또는 전문가가 고안한 템플릿으로 사용 사례를 작성하는 것은 고품질의 기능 시스템 요건을 얻기 위한 업계의 일반적인 관행입니다.

콕번 스타일

Alistair Cockburn이 저서 Writing Effective Use Case에서 정의한 템플릿은 가장 널리 사용되는 사용 ^{[citation needed]}사례의 쓰기 스타일 중 하나입니다.

설계 범위

Cockburn은 "Design Scope(설계 범위)"를 표시하는 기호로 각 사용 사례에 주석을 달 것을 제안합니다. 이 기호는 블랙박스(내부 세부 정보가 숨겨져 있음) 또는 화이트박스(내부 세부 정보 표시)일 수 있습니다.다음 5가지 기호를 사용할 ^[20]수 있습니다.

범위	아이콘
조직(블랙박스)	꽉 찬 집
조직(화이트 박스)	채워지지 않은 집
시스템(블랙박스)	채워진 상자
시스템(화이트 박스)	미필 박스
요소	나사 또는 볼트

다른 저자는 조직 차원의 사용 사례를 "비즈니스 사용 사례"^[21]라고 부르기도 합니다.

목표 수준

Cockburn은 "목표 수준"^[22]을 나타내는 기호로 각 사용 사례에 주석을 달 것을 제안합니다. 선호되는 수준은 "사용자 목표"(또는 구어체로 "해수 수준")^{[23]: 101} 입니다.

목표 수준	아이콘	기호.
매우 높은 요약	구름	++
요약	날으는 연	+
사용자 목표	바다의 파도	!
서브 펑션	물고기.	-
너무 낮다	해저조개껍질	--

경우에 따라서는 텍스트 쓰기에서 유스케이스 이름 뒤에 대체 텍스트 기호(!, +, - 등)를 붙이는 것이 레벨을 나타내는 보다 간결하고 편리한 방법이 될 수 있습니다(예: 주문!,

풀드레싱

Cockburn은 사용 사례에 대한 보다 자세한 구조를 설명하지만, 세부 사항이 덜 필요할 때 단순화할 수 있습니다.풀드레스를 한 유스케이스 템플릿에는 다음 ^[24]필드가 나열됩니다.

• 제목 : "주요 ^[25]배우의 목표를 나타내는 능동-동사 목표 문구"
• 프라이머리 액터
• 컨텍스트에서의 목표
• 범위
• 레벨
• 이해관계자와 이해관계자
• 전제 조건
• 최소의 보증
• 성공 정상화
• 트리거
• 메인 성공 시나리오
• 확장
• 기술 &, 데이터 변주곡 목록.

게다가, 코번 각 사용 사례 설계 범위와 목표 수준에 대한 아이콘의 성격을 나타내기 위해 두 기기를 사용할 것을 제안했다.

코쿤은 분명히 그것의 접근법;예를 들어, 알렉산더와 Beus-Dukic 모든 종류의 시스템으로 다음과 같이 필드 코쿤은 분명히 그것과는 다르:[26]을 가진 소프트웨어에서 코쿤은 분명히 그것의"완전하게 사용 사례 옷을 입고"템플릿을 일반화한 다른 저자들은 큰 영향을 주었다.

• 변동 시나리오(아마도 주요 시나리오에서 분기하여 복귀할 수 있음)
• 예외 "예외 이벤트 및 예외 처리 시나리오"

캐주얼

Cockburn은 프로젝트에 항상 상세한 "완전하게 차려입은" 사용 사례가 필요한 것은 아니라고 인식하고 있습니다.다음 ^[24]필드를 사용하여 캐주얼 사용 사례에 대해 설명합니다.

• 제목(목표)
• 프라이머리 액터
• 범위
• 레벨
• (스토리): 사용 사례의 본문은 단순히 텍스트 한두 단락에 불과하며, 어떤 일이 일어나는지 비공식적으로 설명합니다.

파울러 스타일

Martin Fowler는 "사용 사례의 내용을 기술하는 표준적인 방법은 없으며, 다양한 형식으로 다양한 경우에 ^{[23]: 100} 잘 작동합니다."라고 말합니다.그는 "일반적인 사용 스타일"을 ^{[23]: 101} 다음과 같이 설명한다.

• 제목 : "유스케이스가 ^{[23]: 101} 충족시키려는 목표
• 주요 성공 시나리오: 번호부 절차 목록^{[23]: 101}
  • 스텝: "액터 및 시스템 ^{[23]: 101} 간의 상호작용에 대한 간단한 설명"
• 내선번호: 내선번호별로^{[23]: 101} 1개씩 개별번호부 리스트
  • 확장: "와 다른 상호작용을 일으키는 조건.주요 성공 시나리오"입니다.메인 스텝 3으로부터의 내선번호는 3a ^{[23]: 101} 등이다.

파울러 스타일은 Cockburn 템플릿의 단순한 변형으로도 볼 수 있습니다.이 변형은 사용자 스토리라고 불립니다.

Alistair Cockburn은 다음과 같이 말했다.^[27]

2비트의 정밀도로 사용자 사례를 활용 사례로 생각해 보십시오.정밀도의 비트 1은 사용 사례의 목적을 나타내고 비트 2는 주요 시나리오를 추가합니다.비트 3은 장애 조건을 추가하고 비트4는 장애 액션을 추가합니다.비트 5는 입력/출력 데이터의 데이터 설명을 추가합니다.촉매 작용은 메시지 수신자의 모델도 포함되어 있기 때문에 6번째 정밀도로 하겠습니다.Crystal Methodology 패밀리는 프로젝트별로 다른 수준의 정밀도로 활용 사례를 구축했습니다.방법론적으로 가벼운 프로젝트는 User Stories를 사용하고 방법론적으로 무거운 프로젝트는 Use Case를 4비트의 정밀도로 사용하며 촉매 분석에서는 6비트의 정밀도를 사용합니다.

Martin Fowler는 다음과 같이 말했다.^[28]

이것은 사람들이 어떻게 사용 사례를 사용하는지에 대한 것입니다.저는 많은 사람들이 매우 형식적인 방법으로 사용 사례를 사용하는 것을 봐왔습니다.Kent는 UserStories를 훨씬 더 접근하기 쉬운 방식으로 수행합니다.저는 켄트가 사용자 스토리를 하는 것처럼 케이스를 사용합니다.다른 개발자와의 커뮤니케이션을 개선하고 보다 가벼운 접근 방식을 사용하도록 영향을 주기 위해 이러한 사용 사례를 활용 사례라고 합니다.

배우

활용 사례는 목표를 달성하기 위해 외부 행위자와 고려 중인 시스템 간의 상호작용을 정의합니다.배우들은 결정을 내릴 수 있어야 하지만 인간일 필요는 없다: "배우들은 개인, 회사 또는 조직, 컴퓨터 프로그램, 또는 컴퓨터 시스템 – 하드웨어, 소프트웨어 또는 둘 ^[29]다일 수 있다."행위자는 항상 이해관계자이지만, 모든 이해관계자가 행위자는 아니다. 왜냐하면 그들은 "시스템이 어떻게 ^[29]동작하는지 신경쓸 권리가 있음에도 불구하고 시스템과 직접 상호작용하지 않을 수 있기 때문이다."예를 들어, "시스템 소유자, 회사의 이사회 및 국세청, 보험부 등 규제 기관의 소유자"는 모두 이해관계자가 될 수 있지만,^[29] 행위자가 될 가능성은 낮다.

마찬가지로, 시스템을 사용하는 사람은 다른 역할을 하기 때문에 다른 배우로 표현될 수 있다.예를 들어, 사용자 "Joe"는 현금 자동 입출금기를 사용하여 자신의 계좌에서 현금을 인출할 때 고객 역할을 할 수 있으며, 은행 대신 현금 인출기를 재입금할 때 은행 창구 역할을 할 수 있습니다.

배우들은 종종 다른 누군가를 대신해서 일한다.Cockburn은 "요즘은 시스템 사용자가 다른 사람을 위해 행동하고 있다는 것을 포착하기 위해 '고객을 위한 영업 담당자' 또는 '마케팅 부서 직원'을 씁니다."라고 쓰고 있습니다.이를 통해 프로젝트에 대해 "사용자 인터페이스 및 보안 허가"는 영업 담당자 및 점원을 위해 설계되어야 하지만,^[30] 그 결과에 대해 우려하는 역할은 고객 및 마케팅 부서임을 알 수 있습니다.

이해관계자는 능동적 역할과 비활동적 역할을 모두 수행할 수 있습니다. 예를 들어, 컨슈머는 "대중시장 구매자"(시스템과 상호작용하지 않음)와 사용자(구매한 ^[31]제품과 능동적으로 상호작용하는 행위자) 모두입니다.한편, 사용자는 '정상적인 운영자'(시스템을 의도한 목적을 위해 사용하는 행위자)와 '기능적 수익자'(시스템을 ^[31]사용함으로써 이익을 얻는 이해관계자)가 됩니다.예를 들어, 사용자 "Joe"가 자신의 계좌에서 현금을 인출할 때, 그는 현금자동입출금기를 작동시켜 스스로 결과를 얻고 있다.

Cockburn은 시스템의 이해관계자, 사용 사례의 1차 및 지원(2차) 담당자, 설계 중인 시스템(SuD) 자체, 그리고 마지막으로 "내부 행위자", 즉 ^[29]설계 중인 시스템의 구성요소 중에서 행위자를 찾아보라고 조언합니다.

비즈니스 활용 사례

사용자(또는 다른 유형의 행위자)와 시스템 간의 일련의 이벤트와 상호작용을 기술하는 것과 마찬가지로 비즈니스 활용 사례는 비즈니스 시스템과 해당 시스템의 사용자/행위자 간의 보다 일반적인 상호작용을 기술하여 비즈니스 가치를 창출합니다.주된 차이점은 비즈니스 활용 사례 모델에서 검토되는 시스템에는 기술 시스템 외에 사람이 포함될 수 있다는 것입니다.이러한 「시스템내의 사람들」을 비즈니스 워커라고 부릅니다.레스토랑의 예에서는, 각자를 행위자(시스템외)로 취급할지, 비즈니스 워커(시스템내)로 취급할지를 결정해야 한다.아래 예시와 같이 웨이터가 배우로 간주되면 레스토랑 시스템은 웨이터를 포함하지 않으며 모델은 웨이터와 레스토랑 간의 상호작용을 노출시킨다.또 다른 방법은 웨이터를 레스토랑 시스템의 일부(비즈니스 워커)로 간주하고 고객이 시스템 외부에 있는(배우)^[32] 것으로 간주하는 것입니다.

비주얼 모델링

UML 다이어그램 유형
구조 UML 다이어그램
클래스 다이어그램 컴포넌트 다이어그램 복합구조도 도입도 오브젝트 다이어그램 패키지 다이어그램 프로파일 다이어그램
동작 UML 다이어그램
액티비티 다이어그램 커뮤니케이션 다이어그램 상호작용 개요도 시퀀스 다이어그램 상태도 타이밍 다이어그램 사용 사례도
v t

사용 사례는 텍스트뿐만 아니라 필요한 경우 다이어그램도입니다.Unified Modeling Language에서 사용 사례와 행위자 간의 관계는 원래 Ivar Jacobson의 Objectory 표기법에 기반한 사용 사례 다이어그램에 표시됩니다.SysML은 시스템블록레벨에서 같은 표기를 사용합니다.

또한 액티비티 다이어그램, 시퀀스 다이어그램, 통신 다이어그램 및 상태 기계 다이어그램과 같은 다른 행동 UML 다이어그램을 사용하여 사용 사례를 시각화할 수도 있습니다.특히, 시스템 시퀀스 다이어그램(SSD)은 외부 행위자와 설계 중인 시스템(SuD) 간의 상호작용을 보여주는 데 자주 사용되는 시퀀스 다이어그램으로, 일반적으로 사용 사례의 특정 시나리오를 시각화하기 위해 사용됩니다.

활용 사례 분석은 일반적으로 활용 사례 다이어그램을 그리는 것으로 시작됩니다.신속한 개발을 위해 많은 UML 도표와 텍스트 설명, 메모 또는 사용 사례 개요의 요건 모델은 매우 가볍고 소규모 또는 간단한 프로젝트 사용에 충분합니다.사용 사례 텍스트를 보완하기 위해 사용 사례의 시각적 다이어그램 표현은 복잡한 시스템 행동 요건을 보다 잘 이해하고 전달하며 설계하기 위한 효과적인 도구이기도 합니다.

예

다음은 약간 수정된 버전의 Cockburn 스타일 템플릿으로 작성된 사용 사례의 예입니다.기본 사용 사례 설명에는 버튼, 컨트롤, 양식 또는 기타 UI 요소 및 조작은 없으며 기본 흐름 또는 확장의 모든 단계에서 사용자 목표, 하위 목표 또는 의도만 표현됩니다.이 프랙티스에 의해 요건 사양이 명확해지고 설계 및 구현의 유연성이 최대화됩니다.

사용 예: 기사 편집

프라이머리 액터:멤버(등록 사용자)

범위: Wiki 시스템

레벨: ! (사용자 목표 또는 해수면)

개요: (사용자 사례 또는 개요에 상당)

회원은 자신이 읽고 있는 기사의 모든 부분(기사 전체 또는 섹션)을 편집합니다.편집 중에 미리 보기 및 변경 내용을 비교할 수 있습니다.

관계자

...

사후 조건

최소 보증:

성공 보장:

• 문서가 저장되고 업데이트된 보기가 표시됩니다.
• 기사의 편집 레코드는 시스템에 의해 작성되므로 나중에 기사의 시청자에게 업데이트를 알릴 수 있다.

전제 조건:

편집이 활성화된 글은 회원에게 제시됩니다.

트리거:

구성원이 기사에 대한 편집 요청(전체 기사 또는 한 섹션에 대한 편집 요청)을 호출합니다.

기본 흐름:

1. 시스템은 기사의 모든 관련 내용으로 채워진 새로운 에디터 영역/상자를 구성원이 편집할 수 있는 유용한 편집 요약과 함께 제공합니다.구성원이 문서의 섹션만 편집하려는 경우 섹션의 원래 내용만 표시되고 섹션 제목은 편집 요약에 자동으로 입력됩니다.
2. 구성원은 구성원이 만족할 때까지 문서의 내용을 수정합니다.
3. 구성원은 편집 요약을 작성하고 이 문서를 볼 것인지 여부를 시스템에 알린 후 편집을 전송합니다.
4. 시스템은 문서를 저장하고 편집 이벤트를 기록하고 필요한 후 처리를 완료합니다.
5. 시스템은 기사의 최신 보기를 구성원에게 제공합니다.

내선번호:

2–3.

a. 미리보기 표시:

1. 구성원은 수정된 내용을 제출하는 미리보기 표시를 선택합니다.
2. 시스템은 렌더링된 업데이트 내용을 추가하여 1단계를 다시 실행하고 편집 내용이 아직 저장되지 않았음을 구성원에게 알린 후 계속 진행합니다.

b. 변경 내용 표시:

1. 구성원은 변경된 내용을 제출하는 변경 내용 표시를 선택합니다.
2. 시스템은 스텝 1을 재실행하고, 멤버에 의한 현재 편집 내용과 최신 보존 버전의 문서의 차이를 비교한 결과를 표시합니다.

c. 편집을 취소합니다.

1. 멤버가 [Cancel]를 선택합니다.
2. 시스템은 구성원의 변경을 모두 폐기하고 스텝5로 넘어갑니다

4a. 타임아웃:

...

이점

신속한 변화를 위한 움직임이 시작된 이후 Extreme Programming의 사용자 스토리 기법은 매우 인기가 있어 많은 사람들이 이것이 모든 프로젝트의 신속한 변화를 위한 유일한 최선의 솔루션이라고 생각합니다.Alistair Cockburn은 민첩한 ^[33]개발에서 여전히 사용 사례를 작성하는 5가지 이유를 열거합니다.

1. 목표명 리스트는 시스템이 제공하는 서비스의 가장 짧은 요약을 제공합니다(사용자 사례도 마찬가지).또한 초기 우선순위, 견적, 팀 할당 및 시기를 구축하는 데 사용되는 프로젝트 계획의 골격을 제공합니다.
2. 각 사용 사례의 주요 성공 시나리오는 시스템이 기본적으로 무엇을 하고 무엇을 하지 않을지에 대한 합의를 관계자에게 제공합니다.각 특정 라인 항목 요건에 대한 컨텍스트(예: 세분화된 사용자 사례)를 제공합니다. 다른 곳에서는 찾기 매우 어려운 컨텍스트입니다.
3. 각 사용 사례의 확장 조건은 개발 시간과 예산의 80%를 차지하는 사소한 모든 것을 조사하기 위한 프레임워크를 제공합니다.이해관계자가 답을 얻는 데 오랜 시간이 걸릴 것 같은 문제를 발견할 수 있도록 미리 내다보는 메커니즘을 제공합니다.이러한 문제는 일정보다 먼저 처리하여 개발 팀이 작업에 착수할 때 답변을 준비할 수 있도록 해야 합니다.
4. 유스케이스 익스텐션 시나리오의 단편은, 「이 경우는 어떻게 하면 좋습니까」라고 하는, 자주 까다롭고 무시되는 많은 비즈니스 질문에 대한 답을 제공합니다.이것은 프로그래머가 문제를 생각할 수 있도록 도와주는 if...then...else 문장과 일치하는 사고/문서 프레임워크입니다.프로그래밍 시간이 아니라 조사 시간에 이뤄졌다는 것만 빼면요
5. 전체 사용 사례 집합은 조사자들이 모든 사용자의 요구, 시스템 관련 목표 및 관련된 모든 비즈니스 변형을 충분히 고려했음을 보여줍니다.

요약하면, 사용 사례에서 시스템 요구사항을 지정하면 기존 또는 다른 접근 방식에 비해 다음과 같은 명백한 이점이 있습니다.

사용자 중심

사용 사례는 소프트웨어 요건 사양 프로세스를 위한 ^[34]강력하고 사용자 중심적인 도구입니다.유스케이스 모델링은 일반적으로 시스템과 상호작용하는 주요 이해관계자의 역할(행위자)과 시스템이 달성해야 할 목표(외부 관점)를 식별하는 것으로 시작합니다.이러한 사용자 목표는 시스템에서 제공하는 원하는 기능적 기능 또는 서비스를 나타내는 사용 사례의 이름 또는 제목에 이상적인 후보가 됩니다.이 사용자 중심의 접근방식은 개발자나 시스템(내부)의 관점에서 추측된 사소한 기능이 아니라 진정한 비즈니스 가치와 사용자가 진정으로 원하는 것을 개발하도록 보장합니다.

유스케이스 오서링은, 수년간, 유저 중심 설계(UCD)의 분야에서 중요하고 가치 있는 분석 툴이었습니다.

커뮤니케이션의 향상

사용 사례는 구조화된 템플릿을 사용하여 자연어로 작성되는 경우가 많습니다.거의 모든 사람이 이해할 수 있는 이 서술형 텍스트 형식(합법적인 요건 사례)은 시각적인 UML 도표로 보완되어 고객, 최종 사용자, 개발자, 테스터 및 관리자를 포함한 모든 이해관계자 간의 보다 효율적이고 심도 있는 커뮤니케이션을 촉진합니다.커뮤니케이션이 개선되면 품질 요건이 발생하고 품질 시스템이 제공됩니다.

구조 탐사에 의한 품질 요구사항

사용 사례의 가장 강력한 특징 중 하나는 사용 사례 템플릿의 형식, 특히 주요 성공 시나리오(기본 흐름)와 확장 시나리오 조각(확장, 예외 및/또는 대체 흐름)에 있습니다.전제조건에서 사후조건까지 단계적으로 사용사례 플로우의 모든 액션 스텝(기본에서 확장까지)을 조사하고 조사하여 까다롭고 보통 숨겨지고 무시되지만 겉으로 보기에는 사소하지만 현실적으로 비용이 많이 드는 요건(상기 Cockburn에서 설명한 바와 같이)을 특정하는 것은 구조적이고 유익한 방법입니다.명확하고 안정적이며 품질 요건을 체계적으로 파악합니다.

사용자 목표를 달성하기 위해 사용 사례의 작업 단계를 최소화하고 최적화하는 것도 시스템의 상호작용 설계와 사용자 경험을 개선하는 데 도움이 됩니다.

테스트 및 사용자 문서 작성 촉진

액션이나 이벤트 플로우 구조에 근거한 컨텐츠에서는, 잘 작성된 사용 사례의 모델은, 시스템이나 제품의 테스트 케이스나 유저 메뉴얼의 설계에 있어서 뛰어난 기초가 되는 귀중한 가이드 라인이기도 합니다.이것은, 선행 투자에도 도움이 되는 것입니다.사용 사례의 흐름 경로와 테스트 사례 사이에는 분명한 연관성이 있습니다.사용 사례에서 시나리오(사용 사례의 실행 인스턴스)를 통해 기능 테스트 사례를 도출하는 것은 간단합니다.^[35]

제한 사항

사용 사례에는 다음과 같은 제한이 있습니다.

• 사용 사례는 시스템의 비상호작용 기반 요구사항(알고리즘이나 수학적 요구사항 등) 또는 비기능적 요구사항(플랫폼, 성능, 타이밍 또는 안전에 중요한 측면 등)을 파악하는 데 적합하지 않습니다.이것들은 다른 곳에서 선언적으로 더 잘 지정됩니다.
• 사용 사례에 대한 완전한 표준 정의가 없기 때문에 각 프로젝트는 고유한 해석을 형성해야 합니다.
• 확장과 같은 일부 활용 사례 관계는 해석이 모호하여 이해 관계자가 Cockburn에서 지적한 바와 같이 이해하기 어려울 수 있습니다(문제 #6).^{[36][citation needed]}
• 유스케이스 개발자는, 유스케이스에 짜넣는 유스케이스(UI)의 의존성의 레벨을 판별하는 것이 어려운 경우가 많습니다.사용 사례 이론에서는 UI가 사용 사례에 반영되지 않는 것으로 나타나지만, 이러한 설계의 측면을 추상화하는 것은 불편할 수 있습니다. 왜냐하면 이는 사용 사례를 시각화하기가 어렵기 때문입니다.소프트웨어 엔지니어링에서는 트레이서빌리티 매트릭스 등 요건 트레이서빌리티를 적용하여 이 문제를 해결합니다.UI 요소를 사용 사례에 연결하는 또 다른 방법은 사용 사례의 각 단계에 UI 설계를 연결하는 것입니다.이것을 유스케이스 스토리보드라고 부릅니다.
• 활용 사례는 지나치게 강조될 수 있습니다.Bertrand Meyer는 사용 사례에서 너무 문자 그대로 시스템 설계를 유도하고, 사용 사례를 사용하여 잠재적으로 가치 있는 다른 요구사항 분석 ^[37]기술을 배제하는 등의 문제에 대해 설명합니다.
• 사용 사례는 테스트 ^[38]설계의 시작점이지만, 각 테스트에는 자체 성공 기준이 필요하므로 사용 사례를 수정하여 경로별로 ^[39]별도의 사후 조건을 제공해야 할 수 있습니다.
• 사용 사례에는 목표와 맥락이 포함되지만, 목표 뒤에 있는 이러한 목표와 동기(스테크홀더 우려 및 비상호작용을 포함한 평가)가 상충되거나 다른 시스템 목표에 부정/긍정적으로 영향을 미치는지 여부는 목표 지향 요구사항 모델링 기법(BMM, I*, KAOS 및 ArchiMate ARM 등)의 대상이다.

오해

이 섹션은 확장해야 합니다.추가하시면 됩니다. (2015년 7월)

사용 사례에 대한 일반적인 오해는 다음과 같습니다.

사용자 사례는 민첩하지만 활용 사례는 그렇지 않습니다.

Agile과 Scrum은 요구사항 기술에 대해 중립적입니다.Scrum^[40] Primer에 명시된 바와 같이

제품 백로그 항목은 명확하고 지속 가능한 방식으로 명확하게 표현됩니다.일반적인 오해와는 달리 제품 백로그에는 "사용자 사례"가 포함되어 있지 않습니다.단, 아이템이 포함되어 있을 뿐입니다.이러한 항목은 사용자 사례, 사용 사례 또는 그룹이 유용하다고 생각하는 기타 요구사항 접근 방식으로 표현할 수 있습니다.그러나 어떤 접근방식이든 대부분의 항목은 고객에게 가치를 제공하는 데 초점을 맞춰야 합니다.

활용 사례 기술은 활용 사례 슬라이스를 사용하여 활용 사례를 ^[13]점차 강화함으로써 신속한 변화를 위한 접근 방식을 고려하도록 발전되었습니다.

사용 사례는 주로 다이어그램입니다.

Craig Larman은 "사용 사례는 도표가 아니라 ^[41]텍스트"라고 강조합니다.

사용 사례에 UI 관련 콘텐츠가 너무 많습니다.

어떤 사람들은 ^[who?]말하듯이

유스케이스에는, 라벨이나 버튼의 이름등의 상세한 정보가 포함되어 있는 경우가 많기 때문에, 새로운 시스템의 요건을 처음부터 파악하기에는 적합하지 않습니다.

초보자의 오해.잘 작성된 사용 사례의 각 단계는 행위자의 목표 또는 의도(기능 요건의 본질)를 제시해야 하며, 일반적으로 라벨 및 버튼의 이름 지정, UI 조작 등 사용자 인터페이스의 세부사항을 포함해서는 안 됩니다. 이는 잘못된 관행으로 사용 사례 작성을 불필요하게 복잡하게 만들고 구현을 제한합니다.

새로운 시스템에 대한 요건을 처음부터 파악하는 경우, 사용 사례 다이어그램과 사용 사례 요약은 사용자 ^{[citation needed]}사례만큼 가볍고 유용한 도구로 사용되는 경우가 많습니다.

대규모 시스템의 사용 사례를 작성하는 것은 지루하고 시간 낭비입니다.

어떤 사람들은 ^[who?]말하듯이

이 사용 사례의 형식은 수백 페이지 미만으로 대형 시스템(예: CRM 시스템)을 설명하는 것을 어렵게 합니다.시간이 많이 걸리고 불필요한 재작업에 시간을 할애하게 됩니다.

^{[필요한 건]}

가치를 전혀 내지 않고 많은 재작업으로 이어지는 지루한 사용 사례를 작성하는 데 많은 시간을 할애하는 것은 저자들이 능숙하지 못하고 질 높은 사용 사례를 효율적이고 효과적으로 작성하는 방법에 대한 지식이 부족하다는 것을 보여주는 나쁜 냄새입니다.사용 사례는 반복적, 증분적, 진화적(신속적) 방식으로 작성해야 합니다.활용 사례 템플릿을 적용한다고 해서 활용 사례 템플릿의 모든 필드를 처음부터 또는 특별한 전용 단계(종래의 폭포수 개발 모델의 요구사항 단계)에서 포괄적으로 사용하여 작성해야 하는 것은 아닙니다.

실제로 RUP 및 Cockburn(OUM 방법으로도 채택) 등 널리 사용되는 템플릿 스타일에 의해 공식화된 사용 사례 형식은 실제로 대규모 시스템의 복잡한 요건을 캡처, 분석 및 문서화하는 데 유용한 도구로서 입증되었습니다.양호한 사용 사례 문서(모델)의 품질을 크게 또는 크기로만 판단해서는 안 됩니다.또한 대규모 시스템의 품질과 포괄적인 사용 사례 모델이 최종적으로 수백 페이지로 발전하는 것은 주로 ^{[citation needed]}저자의 부족한 쓰기 기술 때문이 아니라 당면한 문제의 본질적인 복잡성 때문이다.

도구들

이 섹션은 어떠한 출처도 인용하지 않습니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 섹션의 개선에 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.(2013년 8월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인)

템플릿이 지원되는 텍스트 에디터 및/또는 워드 프로세서가 사용 사례 작성에 자주 사용됩니다.크고 복잡한 시스템 요구사항에는 전용 사용 사례 도구가 유용합니다.

잘 알려진 사용 사례 도구에는 다음과 같은 것이 있습니다.

• 케이스 컴플리트
• 엔터프라이즈 아키텍트
• 매직 드로우
• Rational Software의 Requisite Pro - 1990년대 초기의 유명한 사용 사례 및 요건 관리 도구 중 하나입니다.
• 소프트웨어 아이디어 모델러
• Wiki 소프트웨어 - 팀이 공동으로 사용 사례를 작성하고 관리하는 데 유용한 도구입니다.

대부분의 UML 도구는 사용 사례의 텍스트 작성과 시각적 모델링을 모두 지원합니다.

「 」를 참조해 주세요.

• 학대 사례
• 비즈니스 케이스
• 엔티티 제어 경계
• 이벤트 파티셔닝
• 특징
• UML 도구 목록
• 오용 사례
• 필요
• 요건의 도출
• 시나리오
• 스토리보드
• 테스트 케이스
• 활용 사례

레퍼런스

추가 정보

• 알렉산더, 이안, 그리고 베우스-두익, 르르카.요건 검출: 제품 및 서비스를 지정하는 방법.Wiley, 2009.
• 알렉산더, 이안 그리고 메이든, 닐시나리오, 스토리, 사용 사례.Wiley 2004.
• 아머, 프랭크, 그리고 그랜빌 밀러.고급 사용 사례 모델링: 소프트웨어 시스템.애디슨 웨슬리, 2000년
• Kurt Bittner, Ian Spence, Use Case Modeling, Addison-Wesley Professional, 2002년 8월 20일
• 콕번, 알리스테어효과적인 사용 사례 작성.애디슨 웨슬리, 2001년
• Larry Constantine, Lucy Lockwood, Software for Use: A Practical Guide to the Essential Models and Methods of Usage-Centric Design, Adison-Wesley, 1999.
• 데니, 리처드사용 사례 성공: 스마트하게 작업하여 품질을 실현합니다.애디슨 웨슬리, 2005년
• 파울러, 마틴UML 증류판(제3판).애디슨 웨슬리, 2004년
• Jacobson Ivar, Christerson M., Jonson P., Overgaard G., 객체 지향 소프트웨어 엔지니어링 - A Use Case Drivening, Addison-Wesley, 1992.
• 제이콥슨 아이바, 스펜스 1세, 비트너 K사용 사례 2.0: 사용 사례 성공 가이드, IJI SA, 2011.
• Dean Leffingwell, Don Widrig, 소프트웨어 요건 관리: A Use Case Approach, Addison-Wesley Professional, 2012년 12월 7일
• 쿨락, 데릴, 에몬 기니.사용 사례: 컨텍스트에 맞는 요구사항.애디슨 웨슬리, 2012년
• 마이어, 베르트랑객체 지향 소프트웨어 구축. (제2판). 프렌티스 홀, 2000년
• 슈나이더, 게리와 윈터스, 제이슨 P.활용 사례 적용 제2판: 실용적인 가이드.애디슨 웨슬리, 2001년
• Wazlawick, Raul S.정보 시스템의 객체 지향 분석 및 설계: UML, OCL 및 IFML을 사용한 모델링. Morgan Kaufmann, 2014.

외부 링크

• Alistair Cockburn의 사용 사례 열 및 기본 사용 사례 템플릿
• GSA의 Usability.gov에 있는 사용 사례
• Academia.edu에서 이해관계자 분석 '프로젝트 이카루스' 활용 사례 적용
• IBM Developer에서 "사용 사례" 검색