3. 요구사항 변경

요구사항 변경

1. 고객이 요구사항을 변경 요청
2. 요구 사항에 대해 유스케이스 변경
3. 유스케이스 정리(주 경로, 대체 경로, 서브 경로 등)
4. 유스케이스를 가지고 시나리오 추출
5. 변경된 유스케이스를 가지고 요구사항을 확인(빠진 부분이 있나 체크)

 

OOA&D 도구 상자

요구사항

• 좋은 요구 사항은 시스템이 고객이 기대한 대로 동작하도록 합니다.
• 여러분의 요구 사항이 시스템의 유스케이스의 모든 단계들을 담고 있는지 확인하세요.
• 유스케이스를 사용해서 고객이 잊고 얘기하지 않았던 것들을 찾아내세요.
• 유스케이스는 시스템에 추가되어야 할 불완전하거나 빠진 요구 사항들을 분명하게 합니다.
• 요구 사항은 항상 끊임없이 변화합니다.(그리고 성장합니다.).

 

객체 지향 원리

• 변화하는 것을 캡슐화 하세요.

 

핵심 정리

• 요구 사항은 프로젝트를 진행하는 내내 계속 바뀝니다.
• 요구 사항이 변하면, 시스템은 그 새로운 요구 사항을 해결하기 위해서 변경되어야 합니다.
• 시스템이 새롭게 또는 다른 방식으로 동작해야 할 때, 여러분의 유스케이스를 고치는 것부터 시작하세요.
• 여러분의 유스케이스를 바꿀 때마다, 요구 사항으로 다시 돌아가서 확인해야 합니다. 좋은 유스케이스를 만드는 이유는 좋은 요구 사항을 얻기 위해서라는 것을 기억하세요.
• 시나리오는 유스케이스를 처음부터 끝까지 진행하는 하나의 경로 입니다.
• 각 시나리오가 고객을 위해 같은 목표를 가지고 있기만 하면, 하나의 유스케이스에는 여러 개의 시나리오가 있을 수 있습니다.
• 대체 경로들은 가끔만 일어나는 단계들일 수 있고, 또는 유스케이스에서 부분적으로 완전히 다른 경로를 제공할 수도 있습니다.
• 어떤 단계가 시스템의 동작 방식에서 선택적이거나 또는 시스템을 사용하는 대체 경로를 제공하면, 3.1, 4.1 그리고 5.1이나 2.1.1, 2.2.1 그리고 2.3.1처럼 번호로 매겨진 부 단계를 사용하세요.
• 거의 대부분 중복 코드는 피해야 합니다. 중복 코드는 유지보수 할 때의 골칫거리이며, 보통은 시스템의 설계에 문제가 있다는 의미 입니다.