사용자 스토리 모델링

팀에서 예측하거나 개발하려고 하는 사용자 스토리를 이해하는 데 도움이 되는 모델을 만들 수 있으며, 질문이 적절히 복잡한 경우 개발 중에 제품 소유자와 진행 중인 논의에서 모델을 사용할 수도 있습니다.

예를 들어 팀에 새로운 개념 집합이 프로젝트에 포함될 수 있습니다. 팀에서는 제품 소유자와 작업하여 이러한 개념과 개념 간의 관계를 포착하기 위해 도메인 클래스 다이어그램을 개발할 수 있습니다. 팀에서 사용자 동작의 주요 시퀀스를 이해해야 하는 경우 동작 다이어그램을 만들 수 있습니다.

자세한 내용은 사용자 요구 사항 모델링을 참조하십시오.

도메인 모델: 사용자의 언어

도메인 클래스 다이어그램

도메인 클래스 다이어그램은 응용 프로그램과 관련된 개념과 관계를 보여 줍니다. 응용 프로그램과 관련된 모든 사용자는 이러한 개념을 사용하여 보다 일관성 있게 이해할 수 있습니다.

위의 그림에 있는 예제는 몇 가지 다른 방식으로 이러한 관계를 나타낼 수 있는 소프트웨어 솔루션의 클래스 다이어그램은 아니지만 사용자 스토리를 작성하는 데 사용할 수 있는 용어를 제시합니다.

고객은 Order를 만들기 위해 Menu를 선택한 다음, Menu에서 Menu Items를 선택하여 Order에서 Order Items를 만듭니다.

이 다이어그램은 프로그램의 개체가 아니라 개념의 모델이기 때문에 이 용도로 사용되는 경우에는 일반적으로 클래스에 작업을 할당하지 않습니다. 대신 동작 다이어그램을 사용하여 사용자가 수행하는 작업에 대해 설명할 수 있습니다.

자세한 내용은 UML 클래스 다이어그램: 지침를 참조하십시오.

동작 다이어그램

팀에서 동작 다이어그램을 사용하여 사용자가 수행할 수 있는 동작의 흐름에 대해 설명하고 각 지점에서 동작의 대체 경로를 보여 줄 수 있습니다.

팀에서 테스트를 만드는 경우 동작 다이어그램을 참조하고 동작 다이어그램을 통해 각 경로에 대한 테스트를 만들 수 있습니다.

사용자 스토리에서 기존 동작 다이어그램에 경로를 도입할 수도 있습니다. 예를 들어 사용자 스토리가 "고객으로서 나는 지금 지불하는 대신 이후에 처리하기 위해 주문을 저장하도록 선택할 수 있습니다."일 수 있습니다. 개발을 위해 이 스토리를 스프린트로 가져오는 경우 동작 다이어그램을 업데이트하여 새 기능을 표현할 수 있습니다.

팀에서 구현한 모든 사용자 스토리를 반영하기 위해 다이어그램을 업데이트하는 경우 동작 다이어그램은 응용 프로그램의 특정 릴리스를 사용하여 사용자가 따라갈 수 있는 경로의 전체 집합에 대해 설명할 수 있습니다.

자세한 내용은 UML 동작 다이어그램: 지침을 참조하십시오.

모델을 사용하여 간격 드러내기

팀에서 다이어그램이 지원하지 않는 대화에서 발생하는 오해를 방지하여 사용자의 요구 사항을 보다 효과적으로 이해할 수 있습니다. 예를 들어 다이어그램은 주문의 항목과 메뉴의 항목을 명확하게 구분합니다.

모델을 만들면 팀에서 개발이 많이 진행될 때까지 묻지 않을 수도 있는 질문을 하는 데 도움이 됩니다. 몇 가지 방법은 다음과 같습니다.

• 클래스 다이어그램에서 카디널리티에 대해 묻기(예: "메뉴 항목이 둘 이상의 메뉴에 나타날 수 있습니까?")

• 클래스 다이어그램에서 루프에 대해 묻기(예: "어떠한 주문에서든 모든 항목이 동일한 메뉴에서 제공됩니까?")

이러한 유형의 질문에 대한 대답은 다이어그램에서 주석으로 추가될 수 있습니다.

모델 일관성

팀에서 모델과 사용자 스토리가 일치하는지 확인하여 모호성을 해결할 수 있습니다.

• 사용자 스토리는 모델에 정의되고 모델이 정의하는 관계와 일치하는 용어를 사용합니다. 모델이 메뉴 항목을 정의하는 경우 스토리에서는 동일한 항목을 나타내기 위해 "제품"이라는 용어를 사용해서는 안 됩니다. 클래스 다이어그램에서 메뉴 항목이 정확히 하나의 메뉴에만 속하는 것으로 나타날 경우 스토리에서는 메뉴 간의 항목 공유를 언급해서는 안 됩니다.

• 모든 사용자 스토리에서는 동작 다이어그램이 허용하는 일련의 단계를 기술합니다.

• 사용자 스토리 또는 동작은 클래스 다이어그램의 각 클래스 및 관계가 만들어지고 삭제되는 방식을 기술합니다. 예를 들어 메뉴 항목을 만드는 사용자 스토리가 무엇인지, 주문이 삭제되는 때는 언제인지 등을 기술합니다.

모델 및 제품 백로그

팀에서는 모델과 스토리보드를 표시하여 각 사용자 스토리에서 변경할 부분을 보여 줄 수 있으며 개발 계획에 도움이 되도록 모델에서 색을 지정하거나 주석을 추가할 수 있습니다. 예를 들어 팀에서는 동작 다이어그램의 작업에 색을 지정하여 완료된 작업과 다음 스프린트에 완료될 작업을 나타낼 수 있습니다.

자세한 내용은 사용자 요구 사항 모델링을 참조하십시오.

모델 및 테스트

팀에서는 도메인 모델을 시스템 테스트의 기초로 사용하여 테스트와 사용자 요구 사항의 관계를 명확히 할 수 있습니다. 이 관계는 팀에서 테스트를 신속하고 정확하게 업데이트하는 데 도움이 되고 제품이 새로운 요구 사항을 충족하도록 하는 데 유용합니다.

팀에서는 UML(Unified Modeling Language) 모델의 요소를 테스트 등의 어떠한 작업 항목에도 연결할 수 있습니다. 모델의 특정 부분이 변경되면 모델은 팀에서 해당 부분과 관련된 테스트를 찾는 데 도움이 됩니다.

도메인 모델을 사용하여 테스트를 쉽게 만들 수 있습니다.

• 메뉴 항목 또는 주문 항목과 같은 각 형식 또는 연결의 생성과 관련된 테스트를 하나 이상 만들고 각 형식 또는 연결의 소멸과 관련된 테스트를 하나 이상 만듭니다.

• 동작 다이어그램에서 설명하는 모든 경로가 테스트되었는지 확인합니다.

  참고

  테스트에서는 일반적으로 동작 다이어그램에서 나타내지 않을 예외적인 경로도 다뤄야 합니다.

• 도메인 모델의 용어를 사용하여 테스트를 정의합니다. 예를 들어 테스트에는 Select Menu Item 작업의 테스트가 포함되어 이 작업이 Order에 새로운 Order Item이 포함되게 하는지 확인합니다. 자동화된 테스트를 작성하려면 다이어그램을 직접 기반으로 하는 클래스와 관계를 사용할 수 있습니다.

자세한 내용은 모델에서 테스트 개발을 참조하십시오.