개념: 요구사항 유형
요구사항 유형은 단순히 팀이 광범위한 요구사항을 의미 있고 보다 관리 가능한 그룹으로 구성할 수 있게 하는 요구사항 클래스입니다. 서로 다른 요구사항 유형을 한 프로젝트에 설정하여 팀 구성원이 요구사항을 분류하고 보다 분명하게 커뮤니케이션하는 데 도움이 됩니다.
관계
기본 설명

일반적으로 요구사항은 개념: 요구사항에 언급된 범주 중 하나에 맞는 텍스트 명령문으로 간주됩니다. 각 요구사항은 "시스템이 따라야 하는 조건 또는 기능"을 설명합니다.

효과적인 요구사항 관리를 수행하기 위해 요구사항으로 관리하는 대상을 단순히 자세한 "소프트웨어 요구사항" 이상으로 확장하는 것이 도움이 된다는 점을 배웠습니다. 요구사항 유형 개념을 도입하여 서로 다른 레벨의 요구사항 추상 및 목적을 분리합니다.  

소프트웨어 요구사항 스펙 테스트 스위트 디자인 모델 보충 스펙 유스 케이스 모델 이해 당사자(stakeholder) 요청 비전 개념: 요구사항

모호한 "필요" 및 이해 당사자(stakeholder)의 정규 요청을 계속 추적하여 관리하는 방법을 알고 있는지 확인할 수 있습니다. 비전 문서를 사용하여 시스템의 "사용자 요구" 및 "기능"을 계속 추적할 수 있습니다. 유스 케이스 모델은 자세한 기능적"소프트웨어 요구사항"을 표현하는 효과적인 방법이므로, 유스 케이스를 요구사항 뿐만 아니라 "시스템이 따라야 하는 조건 또는 기능"을 설명하는 유스 케이스 특성 내의 개별 명령문으로도 추적하고 관리해야 할 수 있습니다. 보충 스펙은 시스템의 디자인 제한조건 또는 규정 요구사항과 같은 다른 "소프트웨어 요구사항"을 포함할 수 있습니다. 소프트웨어 요구사항의 전체 정의의 경우 유스 케이스보충 스펙은 함께 패키지되어 특정 "기능" 또는 기타 서브시스템 그룹화에 대한 소프트웨어 요구사항 스펙(SRS)을 정의합니다.

시스템이 보다 크고 복잡해질수록 더 많은 표현식 또는 요구사항 유형이 나타나고 요구사항 볼륨이 더 커집니다. 프로젝트의 "비즈니스 규칙" 및 "비전" 명령문은 "사용자 요구", "기능" 또는 기타 "제품 요구사항"까지 추적됩니다. 유스 케이스 또는 기타 모델 형식 및 보충 스펙은 디자인 요구사항을 구동하며, 디자인 요구사항은 분석 및 디자인 모델 및 다이어그램에 표시된 기능적 및 비기능적 "소프트웨어 요구사항"으로 추가 분해될 수 있습니다.

자세한 정보

이 주제에 대한 자세한 정보는 다음을 참조하십시오.

개념: 요구사항
개념: 요구사항 관리
개념: 추적성
백서: 유스 케이스로 요구사항 관리 적용