• 다음과 같은 기본 문제점이 해결되어야 합니다.
    • 기능성: 소프트웨어가 수행할 일은 무엇입니까?
    • 외부 인터페이스: 소프트웨어가 사람, 시스템 하드웨어, 기타 하드웨어 및 기타 소프트웨어와 어떤 방법으로 상호작용합니까?
    • 성능: 여러 소프트웨어 기능의 속도, 사용 가능성, 응답 시간, 복구 시간은 어떻습니까?
    • 속성: 이식성, 정확성, 유지보수성, 보안과 같은 고려사항은 무엇입니까?
    • 구현에 적용되는 설계 제한조건: 실제로 필요한 표준, 구현 언어, 데이터베이스 무결성에 대한 정책, 자원 한계, 운영 환경 등이 있습니까?
  • SRS 경계 외부에 있는 요구사항이 지정되어 있습니까? 이는 SRS가 다음과 같아야 함을 의미합니다.
    • 모든 소프트웨어 요구사항을 올바르게 정의해야 합니다.
    • 어떠한 설계 또는 구현 세부사항도 기술해서는 안됩니다.
    • 소프트웨어에 추가 제한조건을 적용해서는 안됩니다.
  • SRS가 특정 설계를 지정하지 않고 올바른 설계 범위를 제대로 제한합니까?
  • SRS에 다음과 같은 특징이 있습니까?
    • 정확: SRS에 소프트웨어가 만족해야 하는 모든 요구사항이 기술되어 있습니까?
    • 명백함
      • 각 요구사항이 단 한 가지로 해석됩니까?
      • 고객의 언어를 사용했습니까?
      • 자연 언어 설명을 보강하기 위해 다이어그램을 사용했습니까?
    • 완료
      • SRS가 모든 중요한 요구사항, 기능성과의 관련 여부, 성능 설계 제한조건, 속성 또는 외부 인터페이스를 포함합니까?  
      • 모든 가능한 시나리오의 입력 값으로 예상했던 범위가 식별되어 해결되었습니까?  
      • 응답이 올바른 값과 올바르지 않은 값 모두에 포함되었습니까?
      • 모든 그림, 테이블 및 다이어그램에 전체 레이블, 참조, 모든 용어 및 특정 단위의 정의가 포함되어 있습니까?  
      • 모든 TBD가 해결되거나 분석되었습니까?
    • 일치
      • 이 SRS가 비전 문서, 유스 케이스 모델 및 추가 스펙과 일치합니까?
      • 다른 고급 레벨의 스펙과 일치합니까?
      • 충돌시 스펙 내에 기술된 개별적인 요구사항 서브세트가 없으면 내부적으로 일치합니까?
    • 요구사항 순위 결정
      • 각 요구사항에 해당 특정 요구사항의 중요도 또는 안정성을 나타내는 ID가 붙어 있습니까?
      • 우선순위를 적절히 결정하는 데 필요한 중요한 속성이 식별되었습니까?
    • 확인 가능
      • SRS에 기술된 모든 요구사항이 확인 가능합니까?
      • 사람 또는 시스템이 소프트웨어 제품이 요구사항을 만족하는지를 판별하기 위해 사용할 수 있는 제한된 비용 효율적 프로세스가 있습니까?
    • 수정 가능
      • SRS에는 SRS의 중요한 재작업을 하는 데 필요한 변경사항이 포함된 구조 및 스타일을 가지고 있습니까?
      • 중복성을 식별하여 최소화한 다음 상호 참조했습니까?
    • 추적 가능
      • 각 요구사항이 명확한 ID를 갖고 있습니까?
      • 각 요구사항의 발단이 명확합니까?
      • 이전 결과물을 명시적으로 참조하여 역추적성이 유지보수됩니까?
      • SRS에 의해 생성된 결과물에 대해 적당한 양의 정방향 추적성이 유지보수됩니까?

참조: [IE830]



Rational Unified Process   2003.06.15