저는 유용성 사례를 발견한 이후부터 열심히 지지자였습니다. 유용성 사례는 요구사항 파악의 중요한 도구임을 깨달을 때부터 그 가치를 알게 되었습니다. 유용성 사례는 제품과 그 기능보다는 사용자가 제품을 통해 해야 하는 작업을 탐구하도록 요구사항 파악 참여자들의 초점을 옮깁니다. 이러한 사용 중심적 중요성은 솔루션의 필수 능력과 특성을 이해하게끔 이끕니다.

유용성 사례는 특정 사용자가 시스템과 상호 작용을 통해 이루고자 하는 목표를 설명합니다. 유용성 사례 설명의 중심 요소는 주 사용자, 시스템, 그리고 추가 사용자, 시스템 또는 구성 요소 간에 발생하는 단계별 대화입니다. 이러한 유용성 사례 구조 덕분에 특정 목표를 달성하기 위해 사용자가 세션을 시작하는 대화형 시스템을 이해하는 데 효과적인 도구입니다.

유용성 사례가 가치 있는 도구임에도 불구하고 모든 제품 유형에 이상적인 도구는 아닙니다. 보완적인 요구사항 파악 전략은 시스템이나 제품이 경험할 수 있는 다양한 사건 및 각각에 대응해야 하는 방법을 탐색하는 것입니다. 시스템이 이벤트를 감지할 때 그 상태에 따라 다르게 응답해야 합니다. 이벤트 분석은 소프트웨어와 하드웨어 구성 요소 모두를 포함하는 미들웨어 제품 및 실시간 시스템에 특히 적합합니다.

자주 혐오받는 셀프 계산대

이벤트 분석이 사용 사례 분석의 통찰을 보충하는 방법의 한 예로서, 자주 사용하더라도 모든 것이 원할하게 진행되는 드문 경우 외에는 사용하기 꺼려지는 상점 셀프 계산대 기계를 고려해보겠습니다. 상점 셀프 계산대의 능력을 결정하기 위해 다양한 이해 관계자와 협력하고 있는 비즈니스 분석가(BA)가 되었다고 상상해보세요.

요구사항 수집을 시작하기 좋은 곳은 제품을 위한 다양한 사용자 클래스를 식별하는 것입니다. 셀프 계산대의 주요 사용자 클래스는 상점 고객입니다. 다른 사용자 클래스에는 고객이 직면한 문제를 해결하는 데 도움이 필요한 상점 직원, 기계를 설치, 구성, 사용자 정의 및 테스트할 사람들이 포함됩니다. 이제 고객 사용자 클래스에 집중해봅시다.

고객을 위한 유일한 사용 사례는 "제품 구매"입니다. 그것이 고객의 유일한 목표입니다. 제품을 구매하기 위한 사용자의 목표를 달성하는 과정에서 스캔하거나 신용 카드로 결제하는 등 사용자가 세션 동안 마주칠 수 있는 개별 조치, 기능 또는 문제는 사용 사례가 아닙니다. 이것들은 셀프 계산대를 사용하여 한 개 이상의 제품을 구매하는 사용자의 목표를 달성하기 위한 과정일 뿐입니다. 사용 사례는 완료 시 사용자에게 일정한 가치를 제공하는 독립적인 작업입니다.

앞으로 BA는 구매 제품 유스케이스를 탐구하기 위해 일부 고객 대표와 함께 함께할 수 있습니다. 고객이 장치와 상호 작용하여 하나 이상의 제품을 구매하는 방법을 상상하는 방식을 배우기 위해서죠. 이는 거대하고 매우 복잡한 유스케이스가 될 것입니다! 사용자가 만날 수 있는 많은 선택적인 경로인 대안 흐름이 있습니다. 또한, 사용자로서 장치를 사용해 본 모든 이들이 잘 알고 있는 것처럼, 문제가 발생하여 목표를 달성하지 못하게 하는 많은 가능한 예외 사항이 있습니다. 뿐만 아니라, 고객이 제품을 구매하는 방법에 대해 탐구하는 것만으로는 셀프체크아웃의 모든 기능을 명시하는 데 충분한 정보가 제공되지 않습니다. 이는 고객에게 보이는 기능만을 다루는 것이지요. 이러한 제품을 위한 요구 사항을 이해하기 위한 더 나은 방법이 있을까요?

셀프체크아웃 이벤트

이벤트 분석은 셀프체크아웃과 같은 실시간 제품에 적합한 대안 요구사항 수집 기술입니다. 이벤트는 응용 프로그램 환경에서 발생하는 변화이며 특정 반응을 유도합니다. 다음과 같은 몇 가지 이벤트 클래스가 있습니다.

• 비즈니스 이벤트: 비즈니스 도메인 외부의 누군가나 무언가(사용자는 반드시 인간이어야 할 필요가 없음)가 도메인으로부터 서비스를 요청합니다. 이 요청은 종종 유스 케이스의 실행을 트리거합니다. 셀프체크아웃으로 일부 제품을 구매하기로 결정하는 고객이 비즈니스 이벤트를 시작하는 것입니다.

시그널 이벤트: 시스템이 비즈니스 도메인 외부에서 입력을 받는 경우입니다. 예를 들어, 자기 계산기의 카드 리더가 신용 카드나 휴대폰과 같은 근접한 무선 결제 장치를 감지할 때, 그것이 시그널 이벤트입니다.

시간 이벤트: 미리 설정된 시간이 도달하거나 이전 이벤트 이후 또는 시스템이 특정 상태에 들어간 이후 지정된 시간 간격이 경과한 경우입니다. 가방에 스캔되지 않은 물품을 넣으면 자기 계산기가 먼저 스캔하라는 메시지를 보여줍니다. X초 내로 물품을 제거하지 않으면 장치는 계산 프로세스를 중지하고 도움을 요청하거나 다른 조치를 취합니다.

기계가 감지하고 처리해야하는 다양한 이벤트를 고려하면 요구 사항을 더 잘 이해할 수 있습니다. 이곳에 일부 자기 계산기 이벤트 목록이 있습니다.

• 시스템이 근처 고객을 감지함
• 고객이 자신의 할인 카드를 스캔함
• 고객이 자신의 가방을 사용 중임을 표시함
• 고객이 물품의 UPC를 스캔함
• 고객이 계량 가능한 물품을 스캔함
• 시스템이 가방에서 무게 불일치를 감지함
• 고객이 쿠폰을 스캔함
• 고객이 현금 결제를 요청함
• X초 동안 고객 활동이 없음

간단한 목록을 만드는 것은 이벤트 분석의 첫 번째 단계입니다. 이벤트 목록은 시스템의 필요한 기능과 구성 요소에 대한 통찰을 제공합니다. 예를 들어, 고객이 가까이 있을 때 장치가 감지해야 한다면 어떤 종류의 카메라나 모션 감지기가 필요합니다.

이벤트 지식 표현

다음 수준의 세부 정보는 이벤트 목록을 이벤트-응답 테이블로 확장하는 것입니다. 이 테이블은 각 이벤트를 감지할 때 시스템이 있는 상태를 식별하고 예상 시스템 응답을 설명합니다. 아래의 그림은 이벤트-응답 테이블 일부를 보여줍니다:

[2024-07-14-WhenUseCasesArentEnough_1.png]

각 이벤트를 잠재적인 예외 상황에 대해 분석하세요. 고객이 제품의 UPC를 스캔하지만 시스템 데이터베이스에서 제품을 찾을 수 없는 경우는 어떻게 해야 할까요? 저도 이런 경우가 있었습니다. 또한, 고객이 스캔 후 표시된 가격이 선반에 붙은 가격표나 주간 광고에 표시된 가격과 일치하지 않는 경우는 어떨까요? 가능한 많은 예외 상황을 예상하고 시스템이 감지하고 응답하며 복구를 시도하는 방법을 명시하는 견고한 요구 사항 집합이 필요합니다.

이 예시들은 단순화되고 불완전하지만, 다음 단계의 이벤트 세부 사항으로 진입하면 필요한 시스템 기능이 드러나며 더 나아가 시스템 기능을 시사합니다. 예를 들어, 기기가 청각 메시지를 제공해야 한다면, 음성 합성기와 스피커가 필요합니다. 볼륨, 음성의 성격 및 기타 특성에 대한 세부 정보는 나중 요구 사항 논의에서 명시되거나 개발자가 디자인 선택으로 유도되며, 제안된 디자인을 검증하기 위해 프로토타입 평가를 사용하는 것이 좋습니다.

시스템 이벤트에 대한 이러한 텍스트 표현 이외에도, 시스템 상태 전이 다이어그램을 그려서 가능한 시스템 상태와 이벤트 및 조건 조합을 보여주는 것은 종종 가치가 있습니다. 유사한 시각적 모델의 이름은 상태, 상태차트 및 상태 머신 다이어그램이 있습니다.

저는 소프트웨어 개발 경력 초기에 학습했던 것이 하나의 요구 사항 표현만으로 모든 이해관계자에게 필요한 모든 것을 보여주진 못한다는 것입니다. 다이어그램은 이벤트-응답 테이블, 기능 요구 사항 집합 또는 사용자 스토리의 세부 사항에서 멀어져서 보다 높은 수준의 추상화에서 큰 그림을 볼 수 있도록 도와줍니다. 텍스트와 시각적 표현의 혼합이 지식을 가장 효과적으로 전달합니다.

사용자들은 모든 것을 알지 못합니다

알려진 사용자 클래스의 적절한 대표자들과 효과적으로 협력하는 비즈니스 애널리스트라도 제품을 완전히 명시하기 위해 필요한 모든 요구 사항 정보를 얻지 못할 것입니다. 고객은 아마도 비즈니스 애널리스트에게 "셀프 체크아웃이 내 가방에 스캔되지 않은 물품이 있다는 것을 감지하면 문제를 보고해야 한다"고 말하지 않을 것입니다. 마찬가지로 고객은 "기기에 99센트 미만의 동전이 있으면 거스름돈을 줘야 할 경우 현금 결제 옵션을 제공해서는 안 된다"고 말하지 않을 것입니다. 비즈니스 애널리스트는 이러한 갭을 메워 가치를 추가합니다.

예를 들어, "X분 동안 고객 활동이 없을 때"와 같은 타임아웃을 고려해보세요. 타임아웃은 본질적으로 부정적인 시간적 이벤트입니다. 시스템은 특정 기간 동안 아무 일도 일어나지 않았거나 이전 이벤트 이후에도 아무 일도 일어나지 않았음을 확인하고 결과적으로 어떤 조치를 취해야 합니다. 정보 도출 토론에서 대표 고객은 "잠시 동안 아무것도 안 하면 시스템이 제자리에 있는지 확인해달라"고 말하지 않을 것입니다.

(추가로, 내 지역 슈퍼마켓의 셀프 체크아웃의 타임아웃은 너무 짧다고 생각합니다. 다양한 대표 고객 집합을 사용한 보다 철저한 프로토타이핑은 고객에게 빈번한 불편을 느끼지 않는 더 나은 디자인 선택으로 이어질 수 있었을 것입니다.)

현재 고객이 알거나 관심을 갖지 않을 수많은 작업이 뒷면에서 진행 중일 것입니다. 재고 관리, 고객이 물품을 구매할 때 데이터베이스 업데이트 등이 그 예시에 해당합니다. 보안 담당자는 자가계산레지를 사용하여 지불하지 않고 떠나는 고객을 찾거나 방지하기 위해 비디오 카메라를 포함시키길 원할 수도 있습니다. 비즈니스 분석가는 이러한 명백하지 않은 기능들을 직접 사용자가 아닌 다른 이해자 및 주제 전문가로부터 학습해야 합니다. 요구 사항 도출 중에 중요한 정보를 놓치지 않도록 비즈니스 분석가는 넓은 범위로 타진해야 합니다.

보완 기법

복잡한 시스템이 겪을 수 있는 이벤트를 분석하고 각 이벤트에 대해 시스템이 어떻게 대응해야 하는지 검토하는 것은 경우에 따라 사용 사례만 탐구하는 것보다 더 유익할 수 있습니다. 이벤트 대응 테이블과 상태 전이 다이어그램의 구조화된 기법은 사용 사례의 흐름 지향적 성격보다 특정 유형의 정보를 효율적으로 조직화합니다.

그렇다면 성실한 비즈니스 분석가는 사용 사례를 활용해야 할까요, 아니면 이벤트 분석을 적용해야 할까요? 당신의 제품의 성격을 심사해보세요. 해결책과 상호 작용하며 다양한 목표를 달성하길 원하는 여러 사용자 클래스를 식별할 수 있나요? 그렇다면 사용 사례 분석부터 시작해보세요. 제품이 하드웨어 구성 요소가 포함되며 사용자가 직접 볼 수 없는 여러 복잡한 상호 작용이 일어나는 경우는? 이벤트 분석이 더 나은 선택일 것입니다. 두 가지 방법은 상호 배타적이 아닙니다. 사용 사례를 탐구하기 시작한 다음 별개의 단순한 이벤트 목록을 작성할 수 있습니다. 비교하고 빠뜨린 부분이 있는지 확인해보세요.

개발자들은 사용 사례, 사용자 이야기 또는 이벤트 목록을 구현하지 않습니다. 그들은 해결책이 특정 사건이 발생할 때 어떻게 동작해야 하는지를 결정하는 기능 조각을 구현합니다. 사용 사례와 이벤트 분석 모두 비즈니스 분석가가 올바른 시기에 더 깊은 수준의 세부사항으로 더 자세히 들어가야 합니다. 개발자가 구현할 구체적인 기능을 식별해야 합니다.

예를 들어, Figure 1의 마지막 행은 시스템이 세션을 종료한다고 합니다. 세션을 종료하는 데는 무엇이 포함되는 것일까요? 그 세부사항을 파악해야 합니다. 해당 정보가 요구 사항에 최종적으로 포함되지 않으면 개발팀이 무엇을 제공할지 놀라지 마세요.

여기 자기 레지스터의 시스템 응답 중 하나도 "고객의 시간 낭비"를 언급하지 않는다는 점을 주목해주세요. 그것은 무료입니다.

칼 위거스는 Process Impact의 주요 컨설턴트입니다. 그는 Joy Beatty와 함께 공동 저술한 Software Requirements, More About Software Requirements, Software Development Pearls, The Thoughtless Design of Everyday Things를 포함한 다수의 책의 저자입니다. 칼의 최근 책은 Candase Hokanson과 함께 공동 저술한 Software Requirements Essentials입니다.