5장 - 유스케이스

유스케이스는 훌륭한 아이디어로 시작했지만 나중에 괜히 엄청나게 복잡해진 경우다.

유스케이스를 단순하게 유지하는 것이 유스케이스를 사용하는 진짜 비결이다.

정해진 형식을 맞춰야 하나 걱정하지 말고 그냥 빈 종이에 쓰거나, 단순한 워드프로세서로 빈페이지에 작성하거나, 텅빈 인덱스 카드에 적어라

모든 세부사항을 채워야 하는지 걱정할 필요도 없다.

세부사항은 나중에 중요해진다.

모든 유스케이스를 포착할 수 있는지 걱정하지도 마라. 애초에 불가능한 일이다.

기억해야 할 점은 이것이다. "내일이면 다 바뀐다." 내일이면 다 변한다.

유스케이스를 그때그때 작성하는 요구사항이라고 생각하라

유스케이스 적기

• 특정한 관점에서 보는 시스템의 동작을 글로 기술 한 것이다.

• 유스케이스 다이어그램은 유스케이스의 내용은 하나도 말해주지 않는다.

• 유스케이스 다이어그램들에는 유스케이스가 포착해야 하는 동작상의 요구사항에 관련된 정보는 하나도 없다.
  

유스케이스란 무엇인가?

• 유스케이스는 시스템의 동작 하나를 기술

• 사용자가 보낸 자극 하나에 대한 반응로 시스템이 진행하는 눈에 보이는 이벤트들의 흐름을 포착
  

기본흐름

• 유스케이스를 구성하는 항목의 첫 째 항목은 "흐름"이다.

• 세부사항을 기록하지 않을 것이다.

• 만약 세부사항을 하나도 기록하지 않는다면 어떻게  유스케이스를 추정해볼 수 있을까? 그것은 skateholder와 이야기해보면 추정할 수 있다.

• 세부사항을 너무 일찍 기록하는 작업은 비용 대비 효율이 너무 낮다

• 무엇을 기록할까?

• 유스케이스 이름을 기록하라

• 구현할 때가 가까워지면 세부사항을 채워 넣는다.
  

대체흐름

• 대화할 때 여러분은 실패 시나리오를 이야기해봐야 한다. ("프로젝트 실패가 아닌 not condition을 말하는 것 같다.")
  

나머지는?

• 액터, 2차 액터, 선행조건, 후행조건 등등은 알 필요가 없고

• 더 자세히 알고 싶으면 Alistair Cockburn - Writing Effective Use Cases 를 읽으면 된다.

유스케이스 다이어그램

• 유스케이스 다이어그램은 UML의 많은 다이어그램에서 가장 혼란스럽고 쓸모없다.
  

시스템 경계 다이어그램

• 유스케이스 다이어그램은 프로젝트 이해당사자에게 프리젠테이션할 때 멋진 표지로 사용하기에는 좋다.
  

유스케이스 관계

결론