시스템의 기능적 요구 사항을 설명하는 최신 방법. 알리스테어 코번. 책 검토 및 추가 사항

이 책에서는 문제 설명의 일부를 작성하는 한 가지 방법, 즉 유스 케이스 방법을 설명합니다.

그것은 무엇입니까? 이는 시스템(또는 비즈니스)과의 사용자 상호 작용 시나리오에 대한 설명입니다. 이 경우 시스템은 블랙박스 역할을 합니다. 이를 통해 복잡한 설계 작업을 설계 상호 작용과 이러한 상호 작용 보장으로 나눌 수 있습니다. 동시에, 비참가자도 쉽게 읽을 수 있도록 보장하고 이해관계자의 목표에 대한 완전성과 준수 여부를 확인할 수 있는 표기 표준이 도입되었습니다.

사용 사례 예

이메일을 통한 사이트 인증의 예를 사용하여 시나리오는 다음과 같습니다.

(시스템) 개인 계정에 접속하려면 웹사이트에 로그인하세요. ~~ (해수면)

문맥: 승인되지 않은 클라이언트가 사이트에 로그인하면 사이트에서 그를 인식하고 이메일을 로그인으로 사용하여 검색 기록, 구매 내역, 현재 보너스 포인트 수 등의 개인 정보를 표시합니다. 
레벨 : 사용자 목표
주인공: 고객 (온라인 상점 방문자)
범위: 온라인 상점 웹사이트와 고객 상호 작용
이해관계자 및 이해관계:

• 마케팅 담당자는 개인 메일링의 범위를 확대하기 위해 사이트 방문자의 최대 수를 식별하기를 원합니다.
• 보안 전문가는 한 계정의 비밀번호를 추측하거나 비밀번호가 취약한 계정을 검색하려는 시도를 포함하여 방문자의 개인 데이터에 대한 무단 접근 사례가 없는지 확인하고자 합니다.
• 공격자는 피해자의 보너스에 접근하기를 원합니다.
• 경쟁업체는 제품에 대해 부정적인 리뷰를 남기고 싶어합니다.
• 봇넷은 매장의 고객 기반을 확보하고 공격을 통해 사이트를 작동 불가능하게 만들려고 합니다.

전제 조건: 방문자는 승인을 받아서는 안 됩니다.
최소 보증: 방문자는 인증 시도가 성공했는지 실패했는지 알 수 있습니다.
성공 보장: 방문자가 승인되었습니다.

주요 시나리오:

1. 클라이언트가 인증을 시작합니다.
2. 시스템은 "보안 규칙 No. 23"에 따라 클라이언트가 승인되지 않았으며 특정 세션(여러 계정에 대한 취약한 비밀번호 검색)에서 실패한 승인 시도 횟수를 초과하지 않음을 확인합니다.
3. 시스템은 인증 시도 횟수에 대한 카운터를 늘립니다.
4. 시스템은 클라이언트에게 인증 양식을 표시합니다.
5. 클라이언트는 자신의 이메일과 비밀번호를 입력합니다.
6. 시스템은 시스템에 해당 이메일이 있는 클라이언트의 존재를 확인하고 비밀번호가 일치하며 "보안 규칙 24번"에 따라 이 계정에 대한 로그인 시도 횟수를 초과하지 않는지 확인합니다.
7. 시스템은 클라이언트를 승인하고 이 클라이언트 계정의 마지막 세션에 이 세션의 검색 기록과 장바구니를 추가합니다.
8. 시스템은 인증 성공 메시지를 표시하고 인증을 위해 클라이언트가 중단된 스크립트 단계로 이동합니다. 이 경우 개인 계정 데이터를 고려하여 페이지의 데이터가 다시 로드됩니다.

확장:
2.a. 클라이언트가 이미 승인되었습니다.
 2.a.1. 시스템은 클라이언트에게 이전에 수행된 인증 사실을 알리고 스크립트를 중단하거나 4단계로 이동하도록 제안합니다. 6단계가 성공적으로 완료되면 설명과 함께 7단계가 수행됩니다.
 2.a.7. 시스템은 이전 계정에서 클라이언트를 비활성화하고 새 계정에서 클라이언트를 승인하는 반면, 이 상호 작용 세션의 검색 기록 및 장바구니는 이전 계정에 남아 있으며 새 계정으로 이전되지 않습니다. 다음으로 8단계로 이동합니다.
2.b 인증 시도 횟수가 "보안 규칙 No. 23"에 따른 임계값을 초과했습니다.
 2.b.1 4단계로 이동하면 인증 양식에 보안문자가 추가로 표시됩니다.
 2.b.6 시스템은 보안문자 입력이 올바른지 확인합니다.
    2.b.6.1 보안 문자가 잘못 입력되었습니다:
      2.b.6.1.1. 시스템에서는 이 계정에 대한 승인 시도 실패 횟수도 증가합니다.
      2.b.6.1.2. 시스템에 실패 메시지가 표시되고 2단계로 돌아갑니다.
6.a. 이 이메일을 사용하는 계정을 찾을 수 없습니다:
 6.a.1 시스템은 실패에 대한 메시지를 표시하고 2단계로 이동하거나 "사용자 등록" 시나리오로 이동하여 입력된 이메일을 저장할 수 있는 선택권을 제공합니다.
6.b. 이 이메일 계정의 비밀번호가 입력한 비밀번호와 일치하지 않습니다.
 6.b.1 시스템은 이 계정에 대한 실패한 로그인 시도 횟수를 늘립니다.
 6.b.2 시스템은 실패에 대한 메시지를 표시하고 "비밀번호 복구" 시나리오로 이동할지 아니면 2단계로 이동할지 선택할 수 있는 옵션을 제공합니다.
6.c: 이 계정의 로그인 시도 카운터가 "보안 규칙 24번"의 임계값을 초과했습니다.
 6.c.1 X분 동안 계정 로그인 차단에 대한 메시지가 표시되고 2단계로 진행됩니다.

뭐가 대단해?

완전성과 목표 준수 여부를 확인합니다. 즉, 검증을 위해 다른 분석가에게 요구 사항을 제공할 수 있으므로 문제 공식화 단계에서 실수를 줄일 수 있습니다.

블랙박스 시스템을 사용하면 구현 방법에서 자동화할 내용에 대한 개발 및 고객과의 조정을 분리할 수 있습니다.

이는 유용성의 주요 부분 중 하나인 분석가 경로의 일부입니다. 사용자의 시나리오는 사용자의 주요 이동 경로를 정의하므로 디자이너와 고객의 선택 자유가 크게 줄어들고 디자인 개발 속도를 높이는 데 도움이 됩니다.

설명에 각 상호 작용 단계의 예외 사항이 식별되어 있는 부분이 매우 만족스럽습니다. 완전한 IT 시스템은 일종의 예외 처리를 제공해야 하며 일부는 수동으로, 일부는 자동으로(위의 예에서처럼) 제공해야 합니다.

경험에 따르면 무심코 예외 처리를 하면 시스템이 매우 불편한 시스템으로 쉽게 바뀔 수 있습니다. 나는 소련 시대에 결정을 내리기 위해 여러 서비스로부터 여러 승인을 받아야 했고 마지막 서비스에서 말할 때 얼마나 고통스러웠는지 이야기를 기억합니다. 그러나 귀하의 신청서에 잘못된 이름이 있거나 다른 실수가 있습니다. 구두점을 수정하고 모든 것을 다시 실행하고 모든 것을 다시 조정하세요.

나는 예외를 고려하지 않은 시스템의 운영 논리로 인해 시스템의 상당한 재작업이 필요한 상황을 자주 접합니다. 이 때문에 분석가 작업 중 가장 많은 부분이 예외 처리에 사용됩니다.

다이어그램과 달리 텍스트 표기법을 사용하면 더 많은 예외를 식별하고 다룰 수 있습니다.

연습 방법에 추가

유스 케이스는 사용자 스토리와는 달리 설명문에서 독립적으로 우선순위가 부여되는 부분이 아닙니다.

위의 시나리오에서는 예외 “6.a. 이 이메일을 사용하는 계정을 찾을 수 없습니다.” 그리고 다음 단계 “6.a.1 시스템이 실패 메시지를 표시하고 2단계로 진행합니다.” 그 뒤에는 어떤 부정적인 것들이 남아 있었나요? 고객의 경우 모든 반환은 그가 데이터를 입력한 모든 작업이 매립지에 던져진다는 사실과 같습니다. (스크립트에는 보이지 않을 뿐입니다!) 무엇을 할 수 있나요? 이런 일이 발생하지 않도록 스크립트를 다시 빌드하세요. 이것이 가능합니까? 예를 들어 Google 인증 스크립트를 살펴보세요.

시나리오 최적화

이 책에서는 형식화에 대해 설명하지만 그러한 시나리오를 최적화하는 방법에 대해서는 거의 언급하지 않습니다.

하지만 시나리오를 최적화하여 방법을 강화하는 것이 가능하며, 유스케이스 형식화 방법을 사용하면 이것이 가능합니다. 특히, 발생하는 각 예외에 대해 생각하고, 원인을 파악하고, 예외를 제거하거나 고객 여정을 최소화하기 위해 스크립트를 다시 작성해야 합니다.

온라인 매장에서 주문 시 배송 도시를 입력해야 합니다. 고객이 선택한 도시에 매장이 배송되지 않거나, 크기 제한으로 인해 또는 해당 창고에 상품이 부족하여 매장에서 상품을 배송하지 못하는 경우가 발생할 수 있습니다.

등록 단계에서의 상호 작용 시나리오를 간단히 설명하면 "고객에게 배송이 불가능함을 알리고 도시 또는 카트 내용을 변경할 것을 제안합니다"라고 쓸 수 있습니다(그리고 많은 초보 분석가는 거기에서 멈춥니다). 하지만 그러한 경우가 많으면 시나리오를 최적화할 수 있습니다.

가장 먼저 해야 할 일은 배송 가능한 도시만 선택하도록 하는 것입니다. 언제 해야 할까요? 웹사이트에서 제품을 선택하기 전(설명과 함께 IP를 통해 도시 자동 감지)

둘째, 고객에게 전달할 수 있는 상품에 대해서만 선택권을 주어야 합니다. 언제 해야 할까요? 선택 시점 - 제품 타일 및 제품 카드에 표시됩니다.

이 두 가지 변경 사항은 이 예외를 제거하는 데 큰 도움이 됩니다.

측정 및 지표 요구 사항

예외 처리 최소화 작업을 고려할 때 보고 작업을 설정할 수 있습니다(사용 사례는 설명되지 않음). 예외가 몇 개 있었는지, 어떤 경우에 발생했는지, 그리고 성공적으로 통과한 수신 시나리오 수를 추가합니다.

하지만 아쉽게도. 경험에 따르면 이 형식의 시나리오에 대한 보고 요구 사항은 충분하지 않으며 주로 유스 케이스 형식으로 설명되지 않는 프로세스에 대한 보고 요구 사항을 고려해야 합니다.

유용성에 대한 접근

실제로 우리는 클라이언트가 결정을 내릴 수 있도록 엔터티 및 데이터의 특정 속성에 대한 설명으로 사용 사례 설명 양식을 확장하여 후속 유용성을 향상시켰습니다.

사용성 디자인을 위해 입력 섹션(표시 데이터)을 추가했습니다.

권한 부여 시나리오에서는 클라이언트가 시스템에서 권한을 부여받았다는 사실입니다. 클라이언트가 사전 승인된 경우 승인 성공 후 탐색 기록과 장바구니를 새 계정으로 전환하라는 경고를 표시합니다.

일반적으로 이는 고객이 시나리오에 따라 추가 조치에 대한 결정을 내릴 수 있도록 고객에게 필요한 정보를 표시합니다(이 데이터가 고객에게 충분한지, 그 밖에 무엇이 필요한지, 어떤 정보가 필요한지 물어볼 수 있음) 클라이언트가 결정을 내려야 함).  
입력된 정보가 별도로 처리되고 다양한 예외가 형성되는 경우 입력 필드로 나누는 것도 가치가 있습니다.

클라이언트 인증의 예에서 입력한 정보를 로그인과 비밀번호로 분리하는 경우 별도의 로그인과 별도의 비밀번호를 입력하는 단계를 강조 표시하기 위해 인증 스크립트를 변경하는 것이 좋습니다. 이는 Yandex, Google에서 수행되지만 대부분의 온라인 상점에서는 수행되지 않습니다).

필요한 데이터 변환 달성

스크립트에서 데이터 변환 알고리즘에 대한 요구 사항을 추출할 수도 있습니다.

예 :

• 온라인 상점에서 제품 구매를 결정하려면 고객은 제품 카드에서 이 제품의 가능성, 비용, 해당 도시까지의 배송 시간(제품 가용성을 기반으로 한 알고리즘에 의해 계산됨)을 알아야 합니다. 창고 및 공급망 매개변수).
• 검색 줄에 문구를 입력하면 알고리즘에 따라 클라이언트에 검색 제안이 표시됩니다(알고리즘에 의해 생성됨...).

전체로

일반적으로 책을 읽은 후에는 불행히도 분석가에서 비즈니스 문제, 개발자를 위한 공식화된 기술 사양에 이르기까지 어떻게 진행해야 하는지 명확하지 않습니다. 이 책은 입력 단계가 불분명하고 다음 단계가 불분명한 프로세스의 일부만 설명합니다. 사용 사례 자체는 개발자에게 완전한 설명이 아닌 경우가 많습니다.

그럼에도 불구하고 이는 상호작용이 주체의 무언가에 변화를 가져올 때 객체와 주체 간의 상호작용 시나리오를 형식화하고 처리하는 매우 좋은 방법입니다. 이는 명시적인 예외 검색 지점을 통해 검증 가능한 요구 사항을 허용하는 몇 가지 작성 방법 중 하나입니다.

이 책은 분석가들이 테스트 가능한 희곡을 쓰기 시작하기 위해 반드시 읽어야 할 책입니다.

출처 : habr.com