문제의 역사:
복잡한 요구 사항은 종종 높은 수준의 추상화로 형성되거나 여러 개의 숨겨진 조건과 예외를 포함합니다. 이러한 요구 사항을 분해하고 구체화하지 않으면 고객, 개발자 및 테스터 간에 다양한 해석이 발생할 수 있습니다.
문제:
모호하거나 충분히 분해되지 않은 요구 사항은 팀이 세부 사항을 스스로 추론하게 만듭니다. 결과적으로 비즈니스 가치는 실현되지 않거나 왜곡되며, 이를 수정하는 것은 훨씬 더 복잡하고 비용이 많이 듭니다.
해결책:
시스템 분석가는 분해 기술(Use Case Diagram, Activity Diagram, User Stories by INVEST, Event Storming, decomposition tree)을 사용하여 요구 사항에 대한 상세 분석을 수행합니다. 시나리오(basic/alternative/exceptional flows)를 만들고, 결정 표를 작성하며, 전환 행렬을 구축하는 것이 중요하며, 마지막으로 예외 사례를 통해 각 "노드"를 고객과 함께 검증합니다. 분해 후 분석가는 통합 포인트를 분석하고 일관성을 보장하면서 모든 부분을 수집합니다.
주요 특징:
User Story 시나리오에 대한 텍스트 설명 하나로 충분한가요?
아니요, 단순한 user story로는 부족합니다: 복잡한 비즈니스 논리를 위한 시퀀스 다이어그램, 예외 사례, UI 목업 및 결정 표가 필요합니다.
분해가 요구 사항 간의 모순을 자동으로 방지합니까?
아니요, 분해는 충돌하는 요구 사항의 통합, 정기적인 리뷰 세션 및 의존성 분석과 함께 수행되어야 합니다.
분해 작업을 오로지 개발자나 테스터에게 맡길 수 있나요?
아니요, 분석가는 세부화의 완전성을 책임집니다. 이를 다른 역할에 맡길 경우 해석의 다양성과 불일치가 발생합니다.
부정적인 사례:
비즈니스 고객이 "시스템은 각 고객에 대해 개별적으로 할인율을 계산해야 한다" 라고 입력했습니다. 개발은 경직된 할인 구조로 진행되었습니다. 테스트에서 숨겨진 매개변수가 10개 이상이라는 사실이 밝혀졌고, 이는 형식화 단계에서 드러나지 않았습니다.
장점:
단점:
긍정적인 사례:
분석가는 Event Storming 워크샵을 실시하여 모든 매개변수와 조건을 밝혀냈습니다. 결정 표 및 시퀀스 다이어그램을 구축하고, 비즈니스와 예외 사례를 협의하여 요구 사항을 명확하고 검증 가능하게 만들었습니다. 개발 시작 전에 오류를 발견했습니다.
장점:
단점: