RUP 는 헤비급 소프트웨어 관리 프로세스로 간주되지만 점점 더 많은 소프트웨어 개발자들이 변화하는 요구에 민첩하게 대응하기 시작했습니다. 그러나 요구 사항을 설명하는 방법으로 사용 사례의 개념과 방법론은 여전히 요구 사항을 분석하는 데 도움이 됩니다.
표현의 경우 사용 사례는 순서도, 순서도 등의 수요 표현보다 객체 지향적이고 디자인 지향적입니다. 일반적으로 용례는 전문적인 훈련을 받지 않은 사람들이 더 쉽게 받아들일 수 있다. 사용 사례는 사용자 또는 외부 사람에게 요구 사항을 설명하는 한 가지 방법으로 사용될 수 있습니다.
유스 케이스는 요구 사항을 설명하는 방법입니다. 사용 사례는 다양한 조건에서 참가자 요청에 대한 시스템 응답을 설명합니다. 유스 케이스는 일반적으로 참가자 (누구? ) 시스템에 요청을 하면 시스템은 참가자의 요청에 따라 (무엇을 합니까? ), 다양한 조건에서 특정 동작 시퀀스 실행 (시스템이 어떻게 충족됩니까? ) 을 참조하십시오. 각 동작 시퀀스를 하나의 장면이라고 할 수 있으며 하나의 사용 사례에는 여러 장면이 포함되어 있습니다. 장면은 유스 케이스의 인스턴스라고도합니다.
공식 사용 사례에는 사용 사례명, 개요, 범위, 수준, 주요 참가자, 프로젝트 관계자와 이익, 전제 조건, 최소 보증, 성공 보장, 트리거 이벤트, 주요 성공 시나리오, 확장 시나리오 및 관련 정보 등이 포함되어야 합니다.
각 구성 요소의 의미는 다음과 같습니다.
유스 케이스는 다음과 같은 다양한 목적으로 사용할 수 있습니다.
작성 목적에 따라 사용 사례 작성 과정에서 초점이 달라집니다.
팀마다 상황이 다를 수도 있습니다. 예를 들어, 대규모 개발 프로젝트 팀에서는 사용 사례 인스턴스에 따라 엄격하게 설명해야 하는 반면, 의사 소통이 잦은 소규모 프로젝트 팀에서는 비교적 간단한 설명 방법을 사용할 수 있습니다.
위에서 언급한 구성 요소가 더 일반적입니다. 실제로 사용 사례의 형식은 정적이 아니므로 필요한 경우 정보를 늘리거나 줄일 수 있습니다. 특정 사용 사례에는 어떤 정보가 포함되어야 합니까? 다른 학교가 있다. 관심 있는 사람은 관련 자료를 확인해 볼 수 있으니 여기서는 말하지 않겠습니다.
한마디로: 너의 용례는 나의 용례가 아니라 적당한 용례만이 가장 좋다.
이 논문의 주요 관점은 모두 아리스텔 콕본의' 효과적인 용례 작성' 에서 나온 것이다. 흥미가 있는 사람은 원문을 볼 수 있다.
유스 케이스는 요구 사항을 표현하는 데 사용되지만 주의해야 할 두 가지 사항이 있습니다.
사용 사례 이름은 요약 및 읽기가 쉬운 사용 사례를 식별하는 데 사용됩니다.
규칙: 활성 음성의 동적 빈 구로 설명됩니다.
일반적으로 활성 음성의 동빈구를 사용하여 사용 사례의 목적을 설명하는 것이 좋습니다. 예: "상품 찾기", "장바구니에 담기". 경우에 따라 사용 사례를 더 정확하게 표현해야 하는 경우 "사용자가 카트를 비우다" 및 "관리자가 카트를 비우다" 와 같은 속성을 추가하여 수정할 수 있습니다.
규칙: 주도자를 설명합니다.
사용 사례에 대한 설명은 주요 참가자를 설명해야 합니다. 예를 들어, "주문 요금 청구" (시스템의 경우) 대신 "지불 주문" (주요 참가자의 경우) 을 사용할 수 있습니다.
사용 사례의 범위는 우리에게 시스템 경계와 논의 요구에 대한 기본적인 배경을 줄 수 있다. 설계 범위가 다르면 논의해야 할 참가자와 장면이 달라질 수 있습니다. 간단히 말해서, 우리가 토론하는 체계에 대한 범위를 정의하고 우리가 토론하는 경계를 결정하는 것이다.
예를 들어, 한 사용자의 주문 행동에 대해 살펴보겠습니다. 범위가 기업 전체인 경우 프로젝트 관련자는 사용자와 제 3 자 서비스 제공 업체 (예: 택배 등) 입니다. ). 단, 시스템이 범위인 경우 프로젝트 관련자에게는 시스템 관리자 및 기업 내 고객 서비스 직원도 포함되어야 합니다.
그래서 사용 사례를 쓸 때, 사용 사례에서 논의된 문제에 대해 * * * 를 인식할 수 있도록 사용 사례의 범위가 무엇인지 알아야 합니다.
사용 사례의 설계 범위를 논의할 때 먼저 시스템의 기능 범위를 결정해야 합니다. 콕번은 효과적인 사용 사례를 작성하는 기능 범위를 결정하기 위해 내부/외부 목록을 추천했습니다.
기능 범위를 결정하는 이점은 분명합니다. 예를 들어, 시스템 외부에 이미 인쇄 주문 시스템이 있습니다. 시스템의 기능 범위를 명확하게 구분하지 않을 경우 일부 개발자는 인쇄 주문 기능을 설계하고 구현할 수 있습니다. 사실, 이러한 기능 중 어느 것도 디자인이 필요하지 않습니다.
기능 범위를 정의한 후 시스템 수행자도 확인할 수 있습니다. 위의 예에서 인쇄 주문 시스템은 "주문 인쇄" 사용 사례의 보조 수행자가 됩니다.
기능 범위가 결정되면 설계 범위가 완료됩니다. 디자인 범위는 우리가 사용 사례를 쓸 때 논의한 경계와 대상을 가리킨다. 유스 케이스에서 언급 한 범위는 달리 명시되지 않는 한 설계 범위 (기능 범위 아님) 를 의미합니다.
예를 하나 들어보죠. ECom 은 ESubSys 와 같은 여러 하위 시스템을 포함한 ESys 시스템을 만들 계획입니다.
ECom 을 설계 범위로 사용하여 사용 사례를 논의한다면 사용자가 회사에서 원하는 것과 회사가 사용자의 요구 사항을 충족하는 방식에 대해 우려하고 있습니다. 만약 외부 회사가 있다면, 너도 외부 회사 간의 업무가 무엇인지 고려해야 한다.
ESys 를 설계 범위로 사용하여 사용 사례를 논의하는 경우 시스템에 대한 사용자의 요청과 요청에 대한 시스템 응답에 더 많은 관심을 기울이고 있습니다. 또한 ESys 를 범위로 하면 기업 내 직원도 사용 사례의 수행자가 되므로 시스템에 대한 직원의 요청도 고려해야 합니다.
사용 사례의 범위를 결정하면 우리가 논의해야 할 문제가 무엇인지 알고, 토론의 범위를 정의하고, 사용 사례에 로켈을 제공하는 데 도움이 될 수 있다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 사용 사례명언)
규칙: 설계 범위는 간단한 고유 이름입니다.
사용 사례의 범위는 간단한 전용 명사여야 하며 사용 사례 토론의 범위 경계를 간략하게 설명해야 합니다. 예를 들어 위의 예에서 범위는 "ECom", "ESys", "ESubSys" 로 직접 나타낼 수 있습니다.
주 집행자는 시스템 관계자 중 시스템 응답을 요청하는 사람 또는 일이다. 마스터 수행자는 시스템 요청의 개시자이지만 마스터 수행자는 직접 운영 체제의 관련자가 아닐 수 있습니다.
한 가지 경우 주 수행자는 다른 시스템 운영자 운영 체제를 통과합니다. 예를 들어 고객이 고객 서비스 부서에 전화하여 비정상적인 주문을 문의합니다. 고객이 시스템 쿼리를 직접 통과하지 못했습니다.
또 다른 경우는 고정 시간에 작업을 트리거하는 것입니다. 고객이 시스템이 정기적으로 작업을 수행하기를 원하는 경우 시스템을 최종 실행하는 관련자는 시스템 자체입니다.
주 집행인을 확정하는 것이 중요하지만, 때때로 주 집행인은 그렇게 중요하지 않다.
용례를 쓸 때, 주 집행자를 확정하면 집행인의 관점에서 시스템 수요를 충분히 빗질할 수 있다. 또한 주요 수행자의 특성에 따라 시스템 상호 작용을 설계할 수 있습니다. 다음 표, 마스터 요약 테이블:
대부분의 경우, 우리가 사용 사례를 쓰기 시작한 후, 주 수행자는 그다지 중요하지 않게 되었다. 예를 들어, 관리자, 매니저, 고객 서비스, 심지어 다른 회사 직위에서도 주문을 질의하는 용례에는 특별한 차이가 없습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 이때 주집행인이 누구인지는 중요하지 않다.
규칙: 사용 사례의 주요 수행자는 수행자 또는 수행자 역할일 수 있습니다.
이 경우 몇 가지 주요 수행자를 요약하고 역할-수행자 매핑 테이블을 작성하겠습니다. 위의 용례에서 우리는 관리자, 매니저 등을 요약했다. 운영 역할-주문 관리자가 됩니다. 우리가 용례를 묘사할 때, 우리는 역할을 주요 수행자로 삼을 수 있다.
개요는 주로 사용 사례의 목표, 즉 사용자가 완료해야 하는 목표를 설명하는 데 사용됩니다.
규칙: 자연어 설명을 사용합니다.
가능한 자연어로 사용자가 목표를 달성하려고 할 때 어떻게 하는지 설명하세요.
규칙: 시스템 단계가 아닌 사용 사례가 달성한 것을 설명합니다.
용례가 무엇을 완성해야 하는지 명확하게 밝히기만 하면 되며, 시스템 단계나 사용자의 구체적인 운영 절차를 설명할 필요가 없다.
예를 들어, "사용자가 구매할 제품을 선택하면 해당 제품을 카트에 추가한 다음 카트에 주문을 제출할 수 있습니다. 사용자는 장바구니에 가입하지 않고 선택한 상품을 직접 구매할 수도 있다. " 개요는 구체적인 시스템 작동을 설명할 필요가 없으며, "장바구니에 가입하기 위해 버튼을 클릭하는 것" 과 같은 시스템 운영 세부 사항에 대한 설명도 없습니다.
프로젝트 관련자는 시스템에 특정 이해 관계가 있는 참여자입니다. 관련자는 반드시 사람이 아닐 수도 있고, 외부 시스템, 조직 등이 될 수도 있다.
따라서 프로젝트 관련자가 될 수 있습니다.
수석 집행자
주요 수행자는 실행 사례를 시작한 관계자입니다.
보조 수행자
보조 실행기는 설계된 시스템을 위해 서비스를 수행하는 외부 실행기입니다. 보조 수행자는 다른 시스템, 개인 또는 조직이 될 수 있습니다. 예를 들어 프린터는 시스템에 대한 다양한 청구서를 인쇄합니다. 예를 들어 택배회사는 시스템에 택배 서비스를 제공하고 물류 정보를 제공한다.
내부 수행자
내부 집행자는 체제 내에서 체제 이익에 관심을 갖는 관계자이다.
디자인 시스템
설계된 시스템 자체는 때때로 자신에게 특정한 이점이 있다.
관계자에게 설명해야 할 몇 가지 사항이 있습니다.
규칙: 관계자와 이익은 해당 목록으로 기록됩니다.
":< 이익 >" 을 사용하여 관계자와 해당 이익을 설명합니다.
사용 사례를 작성하는 과정에서 사용자 요구 사항 (예: 사용자 구매 상품), 시스템의 특정 기능 (예: 사용자 로그인), 프로세스 (예: 상품 구매 및 상품 획득 프로세스) 를 설명하는 경우가 있습니다. 용례를 쓸 때 용례의 위치를 아는 것은 우리가 용례를 쓰고 이해하는 데 도움이 된다.
전체 계층에서 하위 계층까지 샘플 계층을 요약, 사용자 목표 및 하위 기능의 세 가지 계층으로 나눕니다.
사용자 목표는 주요 수행자가 시스템을 사용할 때 기대하는 목표입니다. 사용자 목표는 유스 케이스 작성의 초점입니다. 사용자 목표는 주요 수행자가 시스템을 통해 "수행" 하는 것과 사용자가 수행 한 후 얻을 수있는 이점을 설명합니다.
사용자의 목표는 주 수행자가 시스템에서 이익을 얻는 프로세스를 한 번 수행하는 것입니다. 따라서 한 번의 실행으로 달성할 수 있는 목표나 사용자가 이익을 얻을 수 없는 수요는 사용자 목표라고 할 수 없습니다.
예를 들어, 주문부터 택배까지 며칠이 걸리는 상품을 구매하는 것을 사용자 목표라고 부를 수 없습니다. 또 다른 예로, 사용자가 로그인한 후에는 아무런 이익도 얻지 못하므로 사용자 목표라고 부를 수 없습니다. 사용자가 주문한 작업은 사용자 대상이 될 수 있습니다.
요약 계층에는 여러 사용자 목표가 포함될 수 있으며, 요약 대상은 사용자 대상보다 실행 주기가 길어 며칠, 몇 달 또는 더 긴 프로세스가 될 수 있습니다. 요약 목표는 다음과 같은 세 가지 목적을 가지고 있습니다.
하위 기능 계층은 실행 중 사용자의 목표가 달성될 목표입니다. 예를 들어, 한 번 로그인, 한 번 주문 인쇄 등이 있습니다. 여러 사용자 목표 * * * 가 상품 찾기, 주문 찾기 등과 같은 하위 기능을 사용할 수도 있습니다.
하위 기능 사용 사례는 사용자 대상 사용 사례의 가독성을 높이기 위해 존재합니다. 실제 작성 과정에서 부득이한 경우를 제외하고는 하위 기능 사용 사례를 설계하지 마십시오.
규칙: 계층에는 요약, 사용자 목표 및 하위 기능의 세 가지 옵션만 있습니다.
사용 사례의 레벨은 요약, 사용자 대상 및 하위 기능의 세 가지 레벨 중 하나일 수 있습니다.
전제조건은 사용 사례가 실행되기 전에 우리가 성공을 기대하는 조건이다. 사용 사례를 작성하는 과정에서 이 조건을 검사하고 토론하지 않을 수 있습니다. 예를 들어 "주문" 은 "사용자가 로그인했습니다" 라는 전제 조건에 의존해야 합니다.
규칙: 전제 조건은 사용 사례가 실행되기 전에 성공을 기대하는 조건이어야 합니다.
그 불필요한 조건들이 선행 조건에 기록되는 것을 방지해야 한다. 예를 들어 주문 취소는 사용자 주문의 성공 여부에 따라 달라지지 않습니다. 실제로 사용자는 실패한 주문을 취소할 수 있습니다 (예: 지불 실패). 사용 사례에서 주문이 성공했는지 여부를 확인하고 실패한 조치를 취해야 합니다.
최소 보증은 사용 사례 집행이 성공 여부와 상관없이 집행될 것을 보장하는 것이다. 비록 용례 집행의 성공 여부에 관계없이 최소 보증은 항상 집행된다. 최소보장은 유스 케이스 실행이 실패할 경우 유스 케이스 관계자에게 제공되는 이익 보장이다. 여러 개의 최소 보장이 있을 수 있다.
최소 보증의 일반적인 예는 "시스템이 사용자의 실행을 기록한다" 는 것입니다. 즉, 사용 사례 실행에 실패하면 사용자의 작업도 로그에 기록됩니다.
성공 보장은 사용 사례가 성공적으로 실행된 후 사용자가 얻을 수 있는 이익 보장을 말합니다. 관련자의 이익을 보장할 수 있는지 여부는 용례 집행 성공의 판단 조건이다. 여러 개의 성공 보장이 있을 수 있다.
예를 들어, 주문 사용 사례에서 사용자는 "주문이 생성되어 처리를 위해 백그라운드로 제출되었습니다." 라고 확인해야 합니다.
트리거 이벤트는 이벤트를 트리거하여 단계별로 실행되는 유스 케이스가 시작하는 이벤트입니다.
규칙: 트리거 이벤트는 시스템과 상호 작용하는 첫 번째 작업입니다.
사용자가 주문한 사용 사례를 예로 들어 보겠습니다. 사용자는 상품을 구매하기로 결정한 후 시스템에서 상품을 찾아 주문을 합니다. 그러면' 사용자가 상품 구매를 결정하다' 는 사용 사례의 트리거 이벤트가 될 수 없다. 실제로 사용자의 보다 체계적인 상호 작용은 "찾기" 로 시작되므로 "사용자 찾기" 는 사용 사례의 트리거 이벤트입니다.
사용자와 시스템 간의 상호 작용에 대해 논의할 때, 우리는 또한 우리가 논의하고 있는 시스템의 범위에도 주의를 기울여야 한다. 특히 주 집행자가 직접 소프트웨어 시스템을 조작하지 않는 경우 시스템 범위를 명확히 해야 합니다. 예를 들어, "사용자가 계정 관리자에게 전화를 걸어 주문하다" 는 시나리오는 소프트웨어 시스템 범위, 시스템 범위 또는 회사로 제한될 수 없습니다. 따라서 "사용자 호출 계정 관리자" 는 우리 시스템과 상호 작용하는 첫 번째 단계이므로 "트리거 이벤트" 가 될 수 있습니다.
주요 성공 시나리오는 사용 사례가 트리거 이벤트로 시작하여 한 번에 한 단계씩 실행되고 마지막으로 사용 사례의 흥미를 만족시키는 일련의 단계입니다.
주요 성공 시나리오에는 다음 정보가 포함되어야 합니다.
이러한 단계를 구현하는 데는 몇 가지 간단한 규칙이 있어야 합니다.
규칙: 간단한 구문을 사용합니다.
간단한 구문 구조 사용:
예를 들면 다음과 같습니다.
규칙: 연기자 간의 전환을 정확하게 설명합니다.
단계를 수행하려면 단계 실행 중 수행자 간 전환을 정확하게 설명해야 합니다. 예를 들어, "사용자가 고객 담당자에게 전화" 하면 단계가 사용자에서 고객 담당자로 전환되었음을 알 수 있습니다.
그러나 집행인이 명확한 상황에서는 문장에 나타나지 않을 수도 있다. 예를 들어, "사용자가 비밀번호를 입력하다" 와 같이, 이 단계의 수행자가 사용자에서 시스템으로 전환되었다는 것을 알 수 있습니다. 우리는 "사용자가 시스템에 비밀번호를 입력하다" 라는 불필요한 설명을 사용할 필요가 없다.
규칙: 시스템 외부에서 단계를 설명합니다.
시스템 내부에서 또는 모두 시스템 관점에서 생각해서는 안 됩니다. 대신 시스템 외부에서 이러한 단계를 설명해야 합니다.
시스템 내부에서 단계를 설명하면 다음과 같이 쓸 수 있습니다.
이러한 단계가 시스템 외부에서 설명되는 경우 다음과 같이 표시됩니다.
규칙: 프로세스가 앞으로 진행됨을 나타냅니다.
일부 작은 단계는 몇 가지 작업만 수행할 수 있으며, 때로는 이러한 작업이 진행 과정을 잘 설명하지 못할 수도 있습니다. 예를 들어, "사용자가 확인 버튼을 클릭했습니다." 이 단계는 앞으로 나아가는 과정을 잘 묘사할 수 없다. 사용자의 진정한 목적은 시스템에 로그인하는 것입니다. 사용자가 시스템에 로그인할 때 사용 사례 단계를 계속할 수 있습니다.
규칙: 동작이 아니라 연기자의 의도를 표현합니다.
수행자는 일반적으로 운영 체제를 통해 작업을 수행하므로 사용 사례를 설명할 때 사용자의 작업을 수행자의 의도와 쉽게 혼동할 수 있습니다.
예를 들면 다음과 같습니다.
1. 신원 정보를 입력해야 합니다.
2. 사용자 이름과 비밀번호를 입력합니다.
3. 사용자가 확인 버튼을 클릭합니다
시스템에서 사용자 id 정보를 확인합니다.
......
너무 많은 사용 사례는 시스템의 운영 인터페이스와 사용자의 동작을 설명합니다 (예: "사용자 ID 정보 입력 필요"). 이는 상호 작용일 뿐만 아니라 수행자의 의도이기도 합니다.
사용자 동작을 설명하는 단계를 줄이고 예제를 다음과 같이 변경할 수 있습니다.
규칙: 합리적인 활동 세트를 포함합니다.
단계를 설명할 때 각 단계에 하나의 활동을 포함할 필요는 없습니다. 필요에 따라 일부 활동을 하나의 단계로 결합할 수 있습니다.
예를 들면 다음과 같습니다.
이 단계는 두 단계로 설명할 수도 있습니다.
용례에 대한 묘사는 간단하고 효과적이며, 때로는 특정 방식에만 국한되지 않는다. 사실, 많은 개발팀이 이미 자신의 용례 작성 규범을 형성했다.
규칙: 단계는 가능한 실패가 아닌 성공적인 장면을 설명합니다.
주 성공 장면의 단계는 성공 단계를 설명합니다. 예를 들면 다음과 같습니다.
이렇게 단계를 쓰면, 우리는 "판단이 정확하다면 ..." 과 "판단이 실패하면 ..." 를 계속 고려할 것이다. 그러나 주 성공 장면의 단계에서는 실패한 단계가 반영되지 않습니다. 따라서 단계를 다음과 같이 변경해야 합니다
시스템 검증에 실패하면 어떻게 합니까? 이 정보는 확장에 설명되어 있습니다. 다음은 자세히 설명하겠습니다. 여기서는 펼쳐지지 않습니다.
규칙: 단계가 연속적으로 실행되지 않을 때 시간 제한을 추가할 수 있습니다.
대부분의 경우 이러한 단계는 점진적으로 진행됩니다. 어느 정도까지 다음과 같이 설명 할 수 있습니다.
규칙: 한 단계에 여러 관련자가 포함될 수 있습니다.
우리는 때때로 한 시스템에서 다른 시스템으로의 실행 동작을 시작해야 하는데, 다음과 같이 쓸 수 있다.
규칙: 하나 이상의 단계를 반복할 수 있습니다.
사용자가 하나 이상의 단계를 반복하는 경우가 있으므로 이러한 단계에 대한 설명이 필요합니다. 예를 들면 다음과 같습니다.
확장은 주 성공 장면의 분기로, 주 성공 장면이 몇 가지 다른 조건에서 수행할 다양한 동작을 나타냅니다. "예외" 또는 "오류" 대신 "확장" 을 사용하면 실제로 확장에는 성공과 실패라는 두 가지 가능한 상황이 포함됩니다. 기본 논리는 시스템이 ... (사고가 감지됨) 주요 성공 장면을 실행한 다음 ... (무언가를 하다).
확장할 수 있는 일반적인 시나리오는 다음과 같습니다.
이러한 장면이 나타나면 이러한 장면이 확장에서 어떻게 처리되는지 설명한 다음 주 성공 장면으로 돌아가거나 사용 사례를 종료해야 합니다.
확장은 주요 성공 시나리오에 대한 것이므로 확장을 작성할 때 확장 대응 관계를 숫자로 표현해야 합니다.
주요 성공 시나리오는 다음과 같습니다.
다음과 같이 확장합니다.
각 단계에서 트리거될 수 있는 확장인 경우 "*" 로 표시할 수 있습니다. 예를 들면 다음과 같습니다.
또는 특정 단계가 * * * 조건을 트리거하는 경우 다음과 같이 표시할 단계를 추가할 수 있습니다.
규칙: 시스템 탐지의 관점에서 확장 조건을 설명합니다.
확장 조건은 시스템에서 감지할 수 있는 조건이어야 하며, 무슨 일이 일어났는지 알 수 있어야 합니다. 예를 들어, 사용자가 비밀번호를 잊어버린다면, 시스템은 사용자가 비밀번호를 가지고 있는지 아니면 다른 원인을 감지할 수 없습니다. 시스템 감지의 관점에서 볼 때, 시스템은 사용자가 잘못된 비밀번호를 입력했거나 사용자 입력 시간 초과만 감지할 수 있습니다.
규칙: 합리화 합병의 확장 조건.
실제로 확장 조건의 가능한 모든 시나리오를 열거할 필요는 없습니다. 합리적인 범위 내에서 일부 확장 조건을 동등한 항목으로 결합할 수 있습니다. 판단에는 두 가지 기준이 있습니다.
예를 들어, 암호 입력 단계에서는 사용자가 암호 입력 오류를 잊거나 수동으로 오류나 기타 가능성을 입력할 수 있습니다. 이는 시스템에서 감지할 수 없는 상황입니다. 먼저 이러한 조건을 시스템이 테스트할 수 있는 조건으로 변환합니다. 비밀번호를 잘못 입력했습니다. 변환 후 모든 조건을 하나로 결합할 수 있습니다.
비밀번호 입력 오류, 사용자 이름 오류, 사용자 이름이 존재하지 않는 등 시스템이 완료할 수 있는 조건을 살펴보겠습니다. 우리 시스템의 처리는 "사용자 이름 또는 비밀번호가 잘못되었거나 존재하지 않음을 묻는 것" 입니다. 이때 조건을 "시스템에서 사용자 이름 또는 암호 입력 오류를 감지했습니다." 라고 결합할 수 있습니다.
또 다른 경우에는 확장이 하위 기능 수준과 같은 하위 레벨 사용 사례에서 충분히 설명된 경우 사용자 대상 레벨과 같은 고급 사용 사례에서 중복 설명을 반복하지 않을 수 있습니다. 예를 들어, 하위 기능 레벨 사용 사례인 "데이터 저장" 에서는 저장 중 발생할 수 있는 다양한 확장 조건에 대한 전체 설명이 있으므로 상위 사용 사례에서 설명할 필요가 없습니다.
--
유스 케이스는 유스 케이스 다이어그램으로도 표현할 수 있습니다. 이 글은 주로 용례 중점과 용례 구성을 통해 요구 사항에 대한 설명을 토론하기 때문에 용례도를 소개하지 않겠습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 용례명언) 관심 있는 독자는 다른 자료를 참고하여 자신의 이해를 할 수 있다.
애자일 개발에 대한 인식이 높아지는 오늘날, 상대적으로' 무거운' 수요 분석과 표현 모델은 점점 더 적게 사용되고 있다. 우리가 사용 사례의 초점과 분석 방법을 연구할 때, 그들의 많은 사상은 우리의 일상적인 수요 분석에서 여전히 참고할 수 있다.