체크포인트: 유스 케이스
- 각 구체적인 유스 케이스가 최소 하나의 액터에 관련되었습니까?
그렇지 않다면 무엇인가 잘못된 것입니다. 액터와 대화하지 않는 유스 케이스는 불필요한 것으므로 제거해야 합니다.
자세한 정보는 가이드라인: 유스 케이스를 참조하십시오.
- 각 유스 케이스가 서로 독립적입니까? 두 유스 케이스가 항상 동일한 순서로 활성화되면 하나의 유스 케이스로 병합해야 합니다.
- 포함된 유스 케이스의 경우, 이를 포함하는 유스 케이스에 대해 가정합니까?
포함할 유스 케이스를 변경해도 포함된 유스 케이스가 영향을 받지 않도록 이러한 가정을 하지 마십시오.
- 유스 케이스에 매우 유사한 이벤트 플로우 또는 작동이 있습니까?
있을 경우, 나중에 해당 작동을 유사하게 만들려면 이를 하나의 유스 케이스로 병합해야 합니다.
그러면 나중에 변경사항을 쉽게 적용할 수 있습니다.
참고: 유스 케이스를 병합할 경우, 새로운 병합된 유스 케이스와 대화하는 사용자에게 영향을 미치기 때문에 사용자를 포함시켜야 합니다.
- 이벤트 플로우의 일부가 다른 유스 케이스로서 모델화되었습니까?
그렇다면, 새 유스 케이스가 기존의 유스 케이스를 사용하게 할 수 있습니다.
- 이벤트 플로우의 일부가 이미 다른 유스 케이스의 일부입니까?
그렇다면, 이 서브플로우를 추출하여 질문된 유스 케이스에서 사용하게 해야 합니다.
참고: 서브플로우를 "재사용"하기로 결정한 경우, 기존 유스 케이스의 사용자에게도 영향을 미치기 때문에 사용자를 포함시켜야 합니다.
- 한 유스 케이스의 이벤트 플로우를 다른 이벤트 플로우에 삽입해야 합니까?
그렇다면, 다른 유스 케이스에 대한 확장 관계를 사용하여 이를 모델화해야 합니다.
- 다음 단계에서 혼동되지 않도록 유스 케이스가 고유하고 직관적이며 설명적인 이름을 갖고 있습니까?
그렇지 않으면 이름을 변경하십시오.
- 고객 및 사용자가 유스 케이스의 이름 및 설명을 똑같이 이해합니까?
각 유스 케이스 이름은 유스 케이스가 지원하는 작동을 기술해야 합니다.
- 유스 케이스가 명확하게 성능을 관리하는 모든 요구사항을 만족시킵니까?
특수 요구사항 유스 케이스의 객체 모델에서 처리할 모든 (비기능적) 요구사항을 포함해야 합니다.
- 액터 및 유스 케이스 간의 통신 순서가 사용자가 예상대로 작동합니까?
- 유스 케이스의 이벤트 플로우가 시작 및 종료하는 방법과 시기가 명확합니까?
- 특정 조건을 만나지 않았을 때에만 활성화되는 작동이 있을 수 있습니다.
주어진 조건을 만족하지 못할 때 발생할 작동에 대한 설명이 있습니까?
- 너무 복잡한 유스 케이스가 있습니까?
유스 케이스를 이해하기 쉽게 만들려면 복잡한 유스 케이스를 나누어야 합니다.
- 유스 케이스에 공통점이 없는 플로우가 있습니까?
그렇다면, 두 개 이상의 유스 케이스로 나누는 것이 좋습니다.
불필요한 이벤트 플로우를 포함하는 유스 케이스는 이해하기가 어렵고 유지보수하기도 어렵습니다.
- 유스 케이스 내의 서브플로우가 정확히 모델화되었습니까?
- 유스 케이스를 수행할 사람이 명확합니까? 유스 케이스의 목적도 명확합니까?
- 액터 대화 및 교환된 정보가 명확합니까?
- 간략한 설명이 유스 케이스에 대한 정확한 설명을 제공합니까?
| |
|