소프트웨어 설계자가 분석되고 디자인될 특정한 수의 시나리오와 유스 케이스를 선택하여 연속적인 반복의 기술적 내용과 순서를 제안합니다. 이 기술 제안서는 개인적 가용 시간, 인도물로 표시되는 고객
요구사항, 도구 및 COTS 제품의 가용성 및 기타 프로젝트의 요구를 기반으로 다양한 개발 팀에 의해 완료되고 정제됩니다.
"구조적으로 중요한"(예: 아키텍처의 유스 케이스 보기 구성) 것으로 간주되는 시나리오 및 유스 케이스의 선택은 아래에 요약되는 몇 가지 핵심 구동 요소에 의해 구동됩니다.
-
이해 당사자(stakeholder)에 대한 시나리오의 이점: 중대한, 중요한, 유용한.
-
시나리오의 아키텍처 영향은 없음, 확장, 수정입니다. 아키텍처에 대한 영향이 없거나 아주 미약한 핵심 유스 케이스 및 큰 영향을 미치지만 적은 이점을 갖는 유스 케이스가 있을 수 있습니다. 아키텍처 영향은
크고 이점은 낮은 유스 케이스는 프로젝트 관리자가 검토하여 가능하면 배제시켜야 합니다.
-
완화될 위험성(성능, 제품 가용성 및 컴포넌트의 적합성).
-
아키텍처 적용 범위의 완료(정제(Elaboration) 단계의 종료 시에, 개발되어야 하는 소프트웨어의 모든 부분이 구현 보기에서 홈을 발견했는지 확인).
-
기타 전술적 목표 또는 제한조건: 사용자에게 시연 등.
동일한 컴포넌트를 대상으로 하고 비슷한 위험성을 다루는 두 시나리오가 있을 수 있습니다. A를 먼저 구현하는 경우 B는 구조적으로 중요하지 않습니다. B를 먼저 구현하는 경우 A가 구조적으로 중요하지 않습니다.
따라서 이러한 속성은 반복 순서에 의존할 수 있으며, 요구사항 자체가 변경될 때뿐 아니라 순서가 변경될 때도 재평가되어야 합니다.
잘 이해하지 못하거나 변경될 수 있는 구조적으로 중요한 유스 케이스는 분류 및 안정화를 위해 우선순위가 결정되어야 합니다. 일부 경우에 이는 요구사항을 구현하기 전에 추가 요구사항 분석이 수행되어야 함을
의미합니다. 다른 경우에는 프로토타입 생성 양식이 가장 좋을 수 있습니다.
|