다음을 통해 공유

개발 요구 사항

  • 아티클

요구 사항은 관련자가 제품에서 기대하는 사항을 기술합니다. 비즈니스 관련자와의 논의를 쉽게 해 줄 수 있는 용어로, 즉 해당 비즈니스 도메인의 용어와 개념을 사용하여 요구 사항을 표현해야 합니다. 요구 사항에서는 구현에 대해 논의하지 않으며 구현에 좌우되지도 않습니다. 요구 사항에는 사용자가 기대하는 동작 및 서비스 품질뿐만 아니라 법적 규제와 상업적 표준도 포함됩니다.

Visual Studio Team Foundation Server에서 요구 사항 작업 항목을 사용하여 요구 사항을 기록하면 다음과 같은 이점이 있습니다.

  • 요구 사항을 테스트 사례에 연결하여 요구 사항이 충족되었는지 확인할 수 있습니다.

  • 요구 사항을 작업(task) 작업 항목에 연결하여 요구 사항의 구현 진행률을 모니터링할 수 있습니다.

  • 요구 사항을 보다 쉽게 관리하고 진행률 보고서에서 해당 정보를 요약할 수 있도록 요구 사항을 전반적이고 보다 세부적인 요구 사항으로 구조화할 수 있습니다.

  • Visual Studio Ultimate에서 모델 요소를 Team Foundation Server의 요구 사항에 연결하여 요구 사항을 모델링할 수 있습니다.

이 항목에서는 요구 사항 결정과 관련하여 사용할 수 있는 광범위한 자료와 중복되는 내용은 다루지 않습니다. 대신 CMMI에 맞는 방식으로 Visual Studio 도구를 사용하는 데 있어 중요한 사항을 중점적으로 설명합니다. CMMI에 대한 자세한 내용은 CMMI의 배경을 참조하십시오.

이 항목에서 설명하는 활동은 다른 개발 활동과 마찬가지로 엄격한 순서로 수행되어야 합니다. 한 활동을 통해 다른 활동이 개선될 수 있으므로 시나리오를 작성하는 동안 도메인 모델을 개발해야 합니다. 시나리오를 코딩할 때가 되어갈 때 시나리오를 개발하십시오. 또한 작성 및 시연된 코드를 포함하는 환경을 앞으로 구현할 시나리오에 다시 적용하십시오.

항목 내용

요구 사항을 개발하는 시기

비전 설명서 작성

시나리오 작성

비즈니스 도메인 모델링

서비스 품질 요구 사항 개발

요구 사항 검토

유효성 검사

요구 사항 검사 및 편집

요구 사항을 개발하는 시기

Team Foundation Server에서는 반복적 작업을 지원하며, 이 방법은 초기 반복을 통해 예상 사용자 및 기타 관련자로부터 피드백을 얻을 경우에 가장 효과적입니다. 이 피드백을 활용하여 이후 반복에 대해 명시된 요구 사항을 개선할 수 있습니다. 또한 같은 기간 동안 사용자 시험 없이 개발된 제품보다는 최종 설치 시에 훨씬 더 효과적인 제품을 개발할 수 있습니다. 프로젝트가 보다 큰 프로그램에 속하는 많은 프로젝트 중의 한 구성 요소인 경우 초기에 이를 다른 구성 요소와 통합하면 프로그램 설계자가 전체 제품을 향상시킬 수 있습니다.

고객이나 함께 진행되는 프로젝트의 파트너에게 확실한 약속을 제공해야 하는 필요성과 이러한 융통성을 잘 고려하여 균형을 맞춰야 합니다.

따라서 요구 사항은 프로젝트 전체 기간에 걸쳐 제어된 범위에 따라 개발되고 조정됩니다. 세부적인 요구 사항은 프로젝트 도중 변경되기 쉬우므로 구현이 적절하게 이루어지기 전에 요구 사항을 전체적으로 결정하면 불필요한 수고를 초래할 수 있습니다.

  • 반복 0에서는 주요 기능을 기술하는 요구 사항 집합을 제품 계획을 세우는 데 필요한 정도로만 세부적으로 개발하십시오. 제품 계획에서는 요구 사항을 반복에 할당하고 각 반복이 종료될 때 달성될 요구 사항을 명시합니다. 주요 개념 및 활동의 도메인 모델을 만들고, 사용자와 논의할 때나 구현할 때 해당 개념에 사용할 용어를 정의합니다. 보안 및 기타 서비스 품질 요구 사항과 같은 모든 기능을 망라하는 광범위한 요구 사항을 결정해야 합니다.

  • 각 반복이 시작될 때 또는 그 직전에 해당 기능에 대한 요구 사항을 보다 세부적으로 개발하십시오. 사용자가 따를 단계를 결정하고 이를 동작 또는 시퀀스 다이어그램을 사용하여 정의합니다. 또한 예외의 경우에 발생할 수 있는 사항을 정의합니다.

  • 구현된 모든 요구 사항을 가능한 한 자주 확인하십시오. 보안과 같이 광범위하게 적용되는 요구 사항은 기능이 새로 추가될 때마다 그에 맞게 확장된 테스트를 통해 확인해야 합니다. 자동 테스트는 지속적으로 수행할 수 있으므로 가능하면 테스트를 자동화합니다.

요구 사항 변경 내용 관리

다음 지침을 따르면 증분식 프로세스를 CMMI 요구 사항에 맞도록 모니터링하면서 진행할 수 있습니다.

  • 반복에 대해 설정된 요구 사항은 변경하지 마십시오. 드물기는 하지만 상황이 뜻하지 않게 변화할 경우에는 반복을 취소하고 제품 계획을 검토한 다음 새 반복을 시작해야 할 수 있습니다.

  • 요구 사항에 불명확성이 있는지 찾으십시오. 초기 반복 결과를 사용자가 경험해 보고 이를 통해 불명확성을 줄일 정보를 얻을 수 있도록 계획을 세웁니다.

  • 변경 요청 작업 항목을 사용하여 이미 구현된 동작에 대한 변경 요청을 기록하십시오. 단, 요청된 개선 사항이 이미 계획에 포함된 경우는 제외됩니다. 각 변경 요청을 적절한 요구 사항 작업 항목에 연결합니다. 자세한 내용은 변경 요청(CMMI)을 참조하십시오.

  • 각 반복 전 제품을 검토할 때 변경 요청을 검토하십시오. 요청된 사항이 종속 프로젝트 및 사용자에게 미칠 영향을 조사하고, 코드 변경에 따르는 비용을 예측합니다. 변경 요청이 승인되면 요구 사항을 업데이트합니다.

  • 모든 요구 사항 변경 내용에 맞게 테스트를 업데이트하십시오.

  • 요구 사항을 변경할 수 있는 기한 날짜(예: 반복 2 또는 반복 3 후)를 지정하십시오. 이 날짜 이후에는 매우 정당한 사유가 있을 때만 요구 사항을 변경해야 합니다. 프로젝트가 지불 고객을 위한 프로젝트인 경우에는 고객이 기본 요구 사항 집합을 승인하고 시간당 지불 조건에서 고정 대금으로 전환하는 날짜가 이 기한 날짜가 됩니다.

  • 버그 작업 항목을 사용하여 구현된 동작 중 명시적 또는 암시적 요구 사항에 따라 수행되지 않는 동작을 기록하십시오. 실제로 도움이 될 경우 해당 버그를 포착할 수 있는 새 테스트를 만듭니다.

비전 설명서 작성

팀과 비전 설명서에 대해 논의하고, 이를 프로젝트의 Team Foundation Server용 웹 포털에 표시합니다.

비전 설명서는 제품이 가져다 줄 이점을 짧게 요약한 문서입니다. 해당 제품을 통해 사용자가 이전에는 가능하지 않았던 어떤 이점을 누릴 수 있을지를 요약합니다. 비전 설명서는 제품의 범위를 명확히 하는 데 유용합니다.

제품이 기존에 있던 제품일 경우 새 버전에 대한 비전 설명서를 작성합니다. 해당 버전을 통해 제품 사용자가 이전에는 가능하지 않았던 어떤 이점을 누릴 수 있을지를 요약합니다.

시나리오 작성

고객 및 기타 관련자와 협력하여 시나리오를 만들고, 이를 요구 사항 작업 항목으로 입력합니다. 이때 요구 사항 유형 필드는 시나리오로 설정합니다.

시나리오나 사용 사례는 이벤트 시퀀스를 기술하고, 특정 목표를 달성할 방법을 보여 주며, 일반적으로 사람 또는 조직과 컴퓨터 간의 상호 작용을 포함하는 서술입니다.

목록에 표시될 때 다른 시나리오와 분명하게 구별되도록 이해하기 쉬운 시나리오 제목을 사용합니다. 주요 행위자가 명시되어 있고 행위자의 목표가 분명한지 확인해야 합니다. 예를 들어 다음과 같은 제목이 좋은 제목입니다.

고객이 식사를 구입합니다.

시나리오는 다음과 같은 형태로 작성할 수 있습니다. 때로는 둘 이상의 형태를 사용하는 것이 유용합니다.

  • 작업 항목 설명에 포함되는 한두 문장

    고객이 웹 사이트에서 식사를 주문하고 신용 카드로 지불합니다. 주문이 식당에 전달되면 식당에서는 식사를 준비하여 배송합니다.

  • 작업 항목 설명에 포함되는 번호가 매겨진 단계

    1. 고객이 웹 사이트를 방문하여 식사를 주문합니다.

    2. 웹 사이트에서 지불을 위해 고객을 지불 사이트로 리디렉션합니다.

    3. 주문이 식당의 작업 목록에 추가됩니다.

    4. 식당에서 식사를 준비하여 배송합니다.

  • 스토리보드. 스토리보드는 기본적으로 스토리가 있는 만화입니다. PowerPoint에서 스토리보드를 그릴 수 있습니다. 스토리보드 파일을 요구 사항 작업 항목에 첨부하거나, 파일을 팀 포털에 업로드하고, 해당 작업 항목에 대한 하이퍼링크를 추가합니다.

    스토리보드는 사용자 상호 작용을 보여 주는 데 특히 유용합니다. 그러나 비즈니스 시나리오의 경우에는 해당 디자인이 사용자 인터페이스의 최종 디자인이 아님을 명확히 할 수 있도록 스케치 스타일을 사용하는 것이 좋습니다.

  • 요구 사항 문서. 요구 사항 문서에서는 각 요구 사항의 세부적인 내용을 적절한 수준으로 자유롭게 기술할 수 있습니다. 문서를 사용하기로 결정한 경우 각 요구 사항마다 하나씩의 Word 문서를 만들고, 문서를 요구 사항 작업 항목에 첨부하거나 파일을 팀 포털에 업로드한 다음, 해당 작업 항목에 대한 하이퍼링크를 추가합니다.

  • UML(Unified Markup Language) 시퀀스 다이어그램. 시퀀스 다이어그램은 여러 주체가 상호 작용하는 경우에 특히 유용합니다. 예를 들어 식사 주문 과정에서는 고객, DinnerNow 웹 사이트, 지불 시스템 및 식당이 특정 시퀀스에 따라 상호 작용해야 합니다. UML 모델에서 시퀀스 다이어그램을 그리고, 이를 Team Foundation Server에 체크 인한 다음, 요구 사항 작업 항목에 링크를 입력합니다. 자세한 내용은 UML 시퀀스 다이어그램: 지침을 참조하십시오.

구체적 시나리오

가장 먼저 특정 시퀀스를 통해 특정 행위자 집합을 따르는 구체적 시나리오를 작성합니다. 예를 들어 "Carlos가 DinnerNow 웹 사이트에서 피자와 마늘빵을 주문합니다. 웹 사이트에서는 Carlos를 Woodgrove 은행의 지불 서비스로 리디렉션합니다. Fourth Coffee는 피자를 준비하여 배송합니다."와 같은 형태입니다.

구체적인 시나리오는 사용되는 시스템을 파악하는 데 도움이 되며 기능을 처음으로 탐색할 경우에 가장 유용합니다.

구체적인 시나리오는 사람 및 조직의 배경과 기타 활동을 기술하는 명명된 가상 사용자를 만드는 데도 유용할 수 있습니다. Carlos는 노숙자로 인터넷 카페를 사용하고, Wendy는 외부인 출입 통제 단지에 거주하고, Sanjay는 직장에 있는 부인을 위해 식사를 주문하고, Contoso는 전 세계에 2,000개 이상의 식당이 있는 체인을 운영하고, Fourth Coffee는 자전거로 배송하는 부부에 의해 운영됩니다.

"고객"이나 "메뉴 항목"과 같은 용어로 작성되는 보다 일반적인 시나리오는 더 편리할 수는 있지만 유용한 기능을 발견할 수 있는 가능성은 적습니다.

세부 수준

반복 0에서는 몇 가지 중요한 시나리오를 어느 정도 세부적으로 작성하지만 대부분의 시나리오는 개략적인 수준으로만 작성합니다. 특정 시나리오가 완전히 또는 부분적으로 구현될 반복을 시작할 때가 되면 시나리오에 보다 세부적인 내용을 추가합니다.

시나리오를 처음 고려할 때는 제품과 관련이 없는 사항일지라도 비즈니스 상황을 기술하는 것이 유용할 수 있습니다. 예를 들어 DinnerNow의 배송 방법을 기술합니다. 즉, 각 식당에서 자체의 배송 서비스를 두고 있는지 DinnerNow에서 배송 서비스를 운영하는지를 기술합니다. 이러한 사항을 확인함으로써 개발 팀에 유용한 상황을 제공할 수 있습니다.

반복 초기에 개발하는 시나리오가 세부적이면 사용자 인터페이스 상호 작용을 기술할 수 있으며 스토리보드를 통해 사용자 인터페이스 레이아웃을 보여 줄 수 있습니다.

시나리오 구성

다음 방법을 사용하여 시나리오를 구성할 수 있습니다.

  • 각 시나리오를 사용 사례로 보여 주는 사용 사례 다이어그램을 그립니다. 이 방법을 사용하면 시나리오를 매우 쉽게 제시하고 논의할 수 있으므로 이 방법을 사용하는 것이 좋습니다. 자세한 내용은 UML 사용 사례 다이어그램: 지침을 참조하십시오.

    • 각 사용 사례를 시나리오를 정의하는 작업 항목에 연결합니다. 자세한 내용은 방법: 모델 요소에서 작업 항목으로 연결을 참조하십시오.

    • 한 시나리오가 다른 시나리오의 변형임을 표시하려면 확장 관계를 그립니다. 예를 들어 "고객이 지불 주소와 배송 주소를 따로 지정합니다."는 기본 사용 사례인 "고객이 주문을 합니다."의 확장입니다. 확장은 이후의 반복에서 구현될 시나리오를 분리하는 데 특히 유용합니다.

    • 몇 개의 사용 사례에 공통적인 "고객이 로그온합니다."와 같은 절차를 분리하려면 포함 관계를 그립니다.

    • "고객이 지불합니다." 같은 일반적인 시나리오와 "고객이 카드로 지불합니다." 같은 구체적인 변형 사이에는 일반화 관계를 그립니다.

  • Team Foundation Server에서 시나리오 작업 항목 간에 부모-자식 링크를 만듭니다. 팀 탐색기에서 이 계층 구조를 볼 수 있습니다. 자세한 내용은 제품 계획에 따라 요구 사항 설정을 참조하십시오.

비즈니스 도메인 모델링

제품을 사용하는 데 관련된 주요 동작 및 개념을 기술하는 UML 모델을 만듭니다. 이 모델에 정의된 용어를 시나리오, 관련자와의 토론, 사용자 인터페이스 및 사용자 설명서, 코드 자체 등 "어디에서나 통용되는 언어"로 사용합니다.

고객이 제시하는 많은 요구 사항은 명시적이지 않고 암시적이며 이러한 요구 사항을 제대로 이해하려면 비즈니스 도메인, 즉 해당 제품이 사용될 상황을 이해하고 있어야 합니다. 따라서 익숙하지 않은 도메인에서 요구 사항을 수집하기 위해서는 해당 상황에 대한 지식이 있어야 합니다. 필요한 지식을 얻은 후에는 둘 이상의 프로젝트에서 이 지식을 사용할 수 있습니다.

모델을 버전 제어에 저장합니다.

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

동작 모델링

시나리오를 요약하려면 동작 다이어그램을 그립니다. 스윔 레인을 사용하여 서로 다른 행위자가 수행하는 작업을 그룹화합니다. 자세한 내용은 UML 동작 다이어그램: 지침을 참조하십시오.

시나리오에서는 대개 구체적인 이벤트 시퀀스를 기술하지만 동작 다이어그램에서는 모든 가능성을 보여 줍니다. 동작 다이어그램을 그리면 대체 시퀀스를 고려하고 비즈니스 클라이언트에게 해당 사례에서 발생할 사항을 질문하는 데 유용합니다.

다음 그림에서는 동작 다이어그램의 간단한 예를 보여 줍니다.

동작 세 개와 루프 하나가 포함된 작업입니다.

메시지 교환이 중요한 경우 각 행위자의 수명선과 주요 제품 구성 요소를 포함하는 시퀀스 다이어그램을 사용하면 보다 효과적일 수 있습니다.

사용 사례 다이어그램을 사용하면 제품이 지원하는 여러 가지 동작 흐름을 요약할 수 있습니다. 다이어그램의 각 노드는 특정 사용자 목표를 달성하기 위해 사용자와 응용 프로그램 간에 이루어지는 일련의 상호 작용을 나타냅니다. 일반적 시퀀스와 선택적 확장을 별개의 사용 사례 노드로 나눌 수도 있습니다. 자세한 내용은 UML 사용 사례 다이어그램: 지침을 참조하십시오.

다음 그림에서는 사용 사례 다이어그램의 간단한 예를 보여 줍니다.

이전 동작에 대한 사용 사례

개념 모델링

시나리오에 언급된 중요한 엔터티와 해당 엔터티의 관계를 나타내려면 도메인 클래스 다이어그램을 그립니다. 예를 들어 DinnerNow 모델에서는 식당, 메뉴, 주문, 메뉴 항목 등을 보여 줍니다. 자세한 내용은 UML 클래스 다이어그램: 지침을 참조하십시오.

이름과 카디널리티를 사용하여 관계의 역할(종단)에 레이블을 지정합니다.

도메인 클래스 다이어그램에서는 일반적으로 작업을 클래스에 연결하지 않습니다. 도메인 모델에서 동작 다이어그램은 동작을 나타냅니다. 프로그램 클래스에 책임을 할당하는 것은 개발 작업의 일부입니다.

다음 그림에서는 클래스 다이어그램의 간단한 예를 보여 줍니다.

Order 클래스에 연결된 주석의 규칙

정적 제약 조건

클래스 다이어그램에는 특성 및 관계를 제어하는 제약 조건을 추가합니다. 예를 들어 한 주문의 품목은 모두 동일한 식당의 품목이어야 합니다. 이러한 유형의 규칙은 제품 디자인에 중요합니다.

모델 일관성

모델과 시나리오는 일관되어야 합니다. 모델의 가장 강력한 용도 중 하나는 모호성을 해결하는 것입니다.

  • 시나리오 설명에서는 모델에 정의된 용어를 사용하며 모델이 정의하는 관계와 일관된 관계를 따릅니다. 모델이 메뉴 항목을 정의하는 경우 시나리오에서 제품과 동일한 항목을 참조해서는 안 됩니다. 클래스 다이어그램에서 메뉴 항목이 정확히 하나의 메뉴에만 속하는 것으로 나타날 경우 시나리오에서 메뉴 간의 항목 공유를 언급해서는 안 됩니다.

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

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

서비스 품질 요구 사항 개발

서비스 품질 요구 사항을 지정하는 작업 항목을 만듭니다. 이때 요구 사항 유형 필드는 서비스 품질로 설정합니다.

서비스 품질이나 비기능적 요구 사항으로는 성능, 유용성, 안정성, 가용성, 데이터 무결성, 보안, 제공 가능성, 서비스 가능성, 업그레이드 가능성, 전달 가능성, 유지 관리 용이성, 디자인, 형태 및 마감 등이 포함됩니다.

각 시나리오에 대해 이러한 각 범주를 고려합니다.

각 서비스 품질 요구 사항의 제목에서는 상황, 작업 및 측정 값을 표시하여 요구 사항의 정의를 알 수 있도록 해야 합니다. 예를 들어 "카탈로그 검색 시 검색 결과를 반환하는 데 걸리는 시간은 3초 미만이어야 합니다."라는 요구 사항을 만들 수 있습니다.

또한 해당 요구 사항이 필요한 이유를 자세히 나타내면 유용합니다. 가상 사용자가 해당 요구 사항을 왜 중요하게 생각하는지와 이러한 서비스 수준이 필요한 이유를 기술합니다. 또한 상황과 정당한 사유를 제공합니다. 이 설명에는 시장 조사, 대상 고객 그룹 또는 유용성 연구에서 얻은 데이터, 지원 센터 보고서/티켓 또는 그 밖의 일화적인 증명 정보 같은 유용한 위험 관리 정보가 포함될 수 있습니다.

서비스 품질 요구 사항은 서비스 품질의 영향을 받는 모든 시나리오(요구 사항 작업 항목)에 연결합니다. 관련 작업 항목을 연결하면 Team Foundation Server의 사용자가 종속된 요구 사항을 추적할 수 있습니다. 쿼리와 보고서에서는 서비스 품질 요구 사항이 시나리오로 파악한 기능적 요구 사항에 어떤 영향을 주는지를 보여 줄 수 있습니다.

요구 사항 검토

요구 사항이 작성되거나 업데이트된 후에는 해당 관련자가 요구 사항을 검토하여 제품과의 모든 사용자 상호 작용이 적절하게 기술되었는지를 확인해야 합니다. 일반적인 관련자로는 실무 전문가, 비즈니스 분석가 및 사용자 경험 설계자가 포함될 수 있습니다. 또한 시나리오를 검토하여 프로젝트에서 혼란이나 문제를 발생시키지 않고 해당 시나리오를 구현할 수 있는지 확인합니다. 문제가 발견되면 이 활동의 최종 단계에서 시나리오를 올바르게 수정해야 합니다.

검토 작업 항목을 만들어 검토를 추적합니다. 이 항목은 SCAMPI(Standard CMMI Appraisal Method for Process Improvement) 평가를 위한 중요한 증명 정보를 제공하며, 이후에 근본 원인을 분석하는 데 유용한 기초 자료로 활용할 수도 있습니다.

각 시나리오의 다음 특징을 검토합니다.

  • 시나리오는 사용자가 수행해야 하는 작업, 사용자가 이미 알고 있는 사항, 사용자가 기대하는 제품과의 상호 작용 방법을 고려하여 작성해야 합니다.

  • 시나리오는 문제를 간략히 설명하며, 문제에 대한 해결 방법이 제안되더라도 해당 시나리오는 공개되어야 합니다.

  • 제품과의 모든 관련 사용자 상호 작용을 식별해야 합니다.

  • 실무 전문가, 비즈니스 분석가 및 사용자 경험 설계자가 프로젝트의 컨텍스트에서 각 시나리오를 검토하여 모든 시나리오가 성공적으로 구현될 수 있는지 확인해야 합니다. 시나리오가 유효하지 않으면 유효하게 수정해야 합니다.

  • 정해진 예산 및 일정 내에서 사용 가능한 기술, 도구 및 리소스로 시나리오를 구현할 수 있어야 합니다.

  • 시나리오는 한 가지로만 해석되고 이를 쉽게 이해할 수 있어야 합니다.

  • 시나리오가 다른 시나리오와 충돌하면 안 됩니다.

  • 시나리오는 테스트 가능해야 합니다.

유효성 검사

최종 릴리스 전에 베타 버전의 제품을 작업 환경에 배포하도록 계획합니다. 이 배포에서 얻은 관련자 피드백에 따라 요구 사항을 업데이트하도록 계획합니다.

유효성 검사란 제품이 작동 환경에서 의도한 용도를 달성하는지 확인하는 것을 의미합니다. MSF for CMMI에서는 프로젝트 전체 기간 동안 각 반복이 끝날 때마다 관련자에게 작동하는 소프트웨어를 시연함으로써 유효성 검사를 수행합니다. 초기 시연에서 개발자가 피드백을 통해 얻은 주요 문제를 남은 반복에 대한 계획에서 처리할 수 있도록 일정을 조정합니다.

진정한 유효성 검사를 위해서는 제품을 데모 환경이나 시뮬레이션된 환경에서만 실행해서는 안 되고, 가급적이면 실제 상황에서 제품을 테스트하는 것이 좋습니다.

요구 사항 검사 및 편집

고객 요구 사항 쿼리를 사용하여 개발 작업이 많이 필요한 시나리오와 서비스 품질 요구 사항을 검사할 수 있습니다. 모든 요구 사항을 표시하려는 경우 요구 사항 작업 항목 형식의 모든 작업 항목을 반환하는 쿼리를 작성할 수 있습니다. 이때 결과 열에는 반복 경로가 표시되도록 설정합니다. 자세한 내용은 팀 쿼리(CMMI)를 참조하십시오.

팀 탐색기 또는 Team Web Access에서 직접 쿼리를 볼 수 있을 뿐 아니라 Office Excel 또는 Office Project에서 쿼리를 열 수도 있습니다. 이러한 도구는 작업 항목을 일괄 처리로 편집하고 추가하는 데 보다 편리합니다. 자세한 내용은 Team Foundation Server에 연결된 Microsoft Excel 및 Microsoft Project에서 작업 및 Excel에서 작업 항목의 트리 목록을 사용하여 하향식 계획 수행을 참조하십시오.

팀은 대부분의 요구 사항을 프로젝트의 초기 반복에서 만들어야 합니다. 초기 버전에서 피드백을 얻으면 그에 따라 새 요구 사항을 추가하거나 다른 요구 사항을 조정합니다.

추가 리소스

자세한 내용은 다음 웹 리소스를 참조하십시오.