타스크: 보충 스펙 개발
이 타스크는 특정 유스 케이스에 적용되지 않는 요구사항을 캡처합니다.
원칙: 요구사항
목적
 유스 케이스에서 쉽게 캡처되지 않는 요구사항을 캡처합니다.
관계
기본 설명

요구사항 활동 전반에 걸쳐 수집된 이해 당사자(stakeholder) 요청을 기반으로 특정 유스 케이스에 적용할 수 없는 요구사항은 보충 스펙에 캡처됩니다. 기능적 및 비기능적 요구사항이 모두 보충 스펙에 캡처될 수 있습니다. 

요구사항 분류 및 캡처에 대한 자세한 정보는 개념: 요구사항을 참조하십시오.

이 타스크를 수행하는 동안 모든 요구사항이 디자이너, 테스트 및 문서 작성자에게 넘겨지기 위해 필요한 세부사항 레벨까지 지정되도록 해야 합니다. 요구사항이 추적되거나 그렇지 않으면 공식적으로 관리되는 경우 각 요구사항이 명확하게 식별되고 레이블이 지정되도록 하십시오.

단계
유스 케이스에 특정하지 않은 기능적 요구사항 캡처

기능적 요구사항은 사용자 목적, 타스크 또는 활동 [MAL2001]을 지원하는 시스템의 동작(기능 또는 서비스)을 설명합니다.

많은 기능적 요구사항이 유스 케이스에 문서화되지만 특정 유스 케이스에 적용할 수 없는 기능적 요구사항이 있습니다. 보고, 감사, 인쇄, 보안, 지원/집행 라이센스 부여, 인증 요구사항 등이 예입니다. 그런 기능적 요구사항은 보충 스펙에 문서화되어야 합니다.  

상당한 수의 시스템 전반의 기능적 요구사항이 있는 경우 이 섹션의 조직을 고려해야 합니다. 전형적인 조직은 기능/기능 세트이지만 대체 조직 방법도 가능합니다. 예를 들어 사용자별 조직 또는 서브시스템별 조직도 적합할 수 있습니다.

기능적 요구사항은 "FURPS+"에서 'F'를 표시합니다. "FURPS+"에 대한 자세한 정보는 개념: 요구사항을 참조하십시오.

시스템 품질 캡처

비기능적 요구사항에는 품질과 제한조건이 모두 포함됩니다[MAL2001]. 이 단계에서는 품질에 대해 논의합니다. 제한조건은 별도의 단계에서 다루어집니다.

[시스템] 품질은 이해 당사자(stakeholder)가 걱정하는 시스템의 특성 또는 특징이며 따라서 시스템에 대한 만족도에 영향을 줍니다. [MAL2001]

품질은 "FURPS+"에서 "URPS"를 표시합니다. 요구사항의 이러한 각 카테고리의 관심사는 다음과 같습니다.

  • 책임(Usability):  사용자 인터페이스의 미적 요소 및 일관성.
  • 신뢰성(Reliability): 가용성(시스템 "가동 시간"), 시스템 계산의 정확성 및 시스템의 장애에서 복구하는 능력.
  • 성능(Performance): 처리량, 응답 시간, 복구 시간, 시작 시간 및 시스템 종료 시간.
  • 지원 가능성(Supportability): 테스트 용이성, 적응성, 유지보수성, 호환성, 구성 가능성, 설치 용이성, 확장성 및 현지화 용이성.

"FURPS+" 및 비기능적 요구사항 캡처에 대한 자세한 정보는 개념: 요구사항을 참조하십시오.

시스템에 대해 문서화해야 하는 품질의 수에 따라서 이러한 각 품질 유형에 대한 하위 섹션을 제공할 수 있습니다.

다음 섹션은 이러한 각 품질에 대해 캡처하기 원할 수 있는 정보의 몇 가지 종류 예제를 제공합니다.

사용성

사용성 요구사항을 설명할 때 다음을 지정할 수 있습니다.

  • 일반 사용자 및 고급 사용자가 특정 오퍼레이션에서 생산적이 되기 위한 필수 훈련 시간
  • 일반 타스크에 대한 측정 가능한 타스크 시간
  • 공통 사용성 표준(예: IBM의 CUA 표준 또는 Microsoft의 GUI 표준)을 준수하기 위한 요구사항

신뢰성

신뢰성 요구사항을 설명할 때 다음을 지정할 수 있습니다.

  • 가용성 – 사용 가능한 시간의 백분율( xx.xx%), 사용 시간, 유지보수 액세스, 성능 저하 모드 오퍼레이션 등을 지정하십시오.
  • 평균 실패 시간 간격(MTBF) – 이는 대개 시간 단위로 지정되지만 일, 월 또는 년의 항목으로 지정할 수도 있습니다.
  • 평균 복구 시간(MTTR) – 시스템이 실패한 후 동작하지 않을 수 있도록 허용되는 시간은 얼마입니까?
  • 정확성 - 시스템 산출물에서 요구되는 정밀도(분해능) 및 정확성(몇 가지 알려진 표준에 의한)을 지정하십시오.
  • 최대 버그 또는 결함 비율 - 대개 버그/KLOC(1000행의 코드) 또는 버그/기능 점수의 항목으로 표현됩니다.
  • 버그 또는 결함 비율 - 사소, 중요 및 위험 버그의 항목으로 분류됩니다. 이 요구사항은 "위험" 버그가 의미하는 바를 정의해야 합니다. 예를 들어 데이터의 완전한 유실 또는 시스템 기능의 특정 부분을 완전히 사용할 수 없음 등입니다.

성능

성능 요구사항을 설명할 때 다음을 지정할 수 있습니다.

  • 트랜잭션의 응답 시간(평균, 최대)
  • 처리량(예: 초당 트랜잭션)
  • 용량(예: 고객 수 또는 시스템이 처리하는 트랜잭션 수)
  • 성능 저하 모드(시스템이 어떤 방식으로 성능 저하되는 경우 허용 가능한 오퍼레이션 모드)
  • 자원 사용: 메모리, 디스크, 통신 등

성능 요구사항을 문서화할 때 반드시 특정 응답 시간을 포함하십시오. 해당되는 경우 관련 유스 케이스를 이름으로 참조하십시오.

지원 가능성

지원 가능성 요구사항을 설명할 때 다음을 지정할 수 있습니다.

  • 코딩 표준
  • 이름 지정 규칙
  • 클래스 라이브러리
  • 유지보수 액세스
  • 유지보수 유틸리티
제한조건 캡처

이 단계에서 빌드되는 시스템에 대한 모든 디자인 제한조건을 문서화합니다. 일반 용어로, 제한조건은 솔루션 제공에 있어서 갖고 있는 자유도에 대한 제한입니다([LEF2000]).  디자인 제한조건은 요구되었고 준수되어야 하는 디자인 결정을 표시합니다. 

제한조건은 "FURPS+"에서 '+'를 표시하며 다음과 같이 추가로 분류할 수 있습니다.

  • 디자인 제한조건: 시스템 구조화 및/또는 디자인을 위한 옵션을 지정하거나 제한합니다. 예를 들어 지속성을 위해 관계형 데이터베이스가 사용되도록 요구합니다.
  • 구현 제한조건: 시스템의 코드 또는 구현/구축(Construction)을 지정 또는 제한합니다. 예를 들어 필수 표준, 프로세스, 도구, 구현 언어, 하드웨어 플랫폼, 운영 체제, 써드파티 컴포넌트, 클래스 라이브러리 및 자원 한계(메모리 또는 디스크 공간의 사용)를 지정 또는 제한합니다.
  • 인터페이스 제한조건: 시스템이 상호작용해야 하는 외부 항목을 지정하거나 그런 상호작용 내에서 사용되는 형식 또는 기타 요소를 제한합니다. 메시지 대기열을 통한 외부 시스템과의 상호작용이 예입니다.
  • 실제 제한조건: 시스템을 내장하는 데 사용되는 하드웨어에 부과되는 실제 제한조건(예: 모양, 크기 또는 중량)을 지정합니다.

시스템에 대해 문서화해야 하는 제한조건의 수에 따라서 이러한 각 제한조건 유형에 대한 하위 섹션을 제공할 수 있습니다. 또한,

  • 요구사항이 써드파티 컴포넌트의 구입을 포함하는 경우 반드시 적용 가능한 모든 라이센스 부여 또는 사용 제한 및 연관된 모든 호환성/상호운용성 또는 인터페이스 표준을 문서화하십시오. 구입한 컴포넌트별로 별도의 섹션을 권장합니다.
  • 요구사항이 특정 인터페이스 요구사항을 포함하는 경우 여러 인터페이스의 유형(예: 사용자, 하드웨어, 소프트웨어)에 대해 별도의 섹션을 제공할 것을 권장합니다. 각 인터페이스에 대해 반드시 적절한 세부성, 프로토콜, 포트 및 논리 주소 등을 포함시켜서 인터페이스 요구사항에 대해 소프트웨어를 개발하고 확인할 수 있도록 하십시오. 특히, 다음에 유의하십시오.
    • 사용자 인터페이스의 경우 소프트웨어가 구현할 사용자 인터페이스를 설명하십시오.
    • 하드웨어 인터페이스의 경우 논리 구조, 실제 주소, 예상 동작 등을 포함하십시오.
    • 소프트웨어 인터페이스의 경우 소프트웨어 시스템의 다른 컴포넌트에 대한 인터페이스의 설명을 포함하십시오. 이들은 구매한 컴포넌트, 다른 응용프로그램에서 재사용되는 컴포넌트 또는 이 시스템의 범위 밖에 있는 서브시스템을 위해 개발되지만 이 소프트웨어 응용프로그램이 상호작용해야 하는 컴포넌트일 수 있습니다.

"FURPS+" 및 제한사항 캡처에 대한 자세한 정보는 개념: 요구사항을 참조하십시오.

정부 규제 준수

준수와 관련하여, 표준 준수(규제 표준, 코딩 표준 또는 사용자 인터페이스 스타일 안내서 포함)뿐 아니라 법률적 면책사항, 보증, 저작권 유의사항, 특허 유의사항, 워드마크(wordmark), 상표 및/또는 로고 준수를 포함합니다.

정부 규제 준수는 다른 요구사항(기능, 비기능 및 제한조건)을 통해 실현될 수 있습니다. 그런 경우 해당 요구사항의 세부사항이 이전 단계에서 설명한 대로 보충 스펙의 적용 가능한 섹션에 문서화되어야 합니다. 그러나 시스템이 준수해야 하는 표준과 정책을 요약해야 합니다. 그 결과의 정부 규제 준수가 필요에 따라 적용 가능한 상세한 요구사항을 의미할 수 있습니다.

시스템에 대해 문서화해야 하는 정부 규제 준수의 수에 따라서 시스템에 영향을 주는 준수의 여러 가지 종류에 대한 하위 섹션을 제공할 수 있습니다.

다음 섹션은 여러 가지 종류의 준수에 대해 캡처하기 원할 수 있는 정보의 몇 가지 종류 예제를 제공합니다.

라이센스 부여 요구사항

라이센스 부여 집행 요구사항 또는 소프트웨어가 표시해야 하는 기타 사용량 제한 요구사항을 정의합니다.

법률, 저작권 및 기타 주의사항

소프트웨어에 대한 모든 필요한 법률적 면책사항, 보증, 저작권 유의사항, 특허 유의사항, 워드마크(wordmark), 상표 또는 로고 준수 문제를 설명합니다.

적용되는 표준

모든 적용 가능한 표준 및 설명되는 시스템에 적용되는 해당 표준의 특정 섹션을 (참조에 의해) 설명합니다. 예를 들어 법률, 품질 및 규제 표준, 사용성에 대한 산업 표준, 상호운용성, 국제화 용이성, 운영 체제 준수 등이 포함될 수 있습니다.

문서 요구사항 캡처

이 단계에서는 문서에 대한 요구사항(있는 경우)을 설명합니다. 문서 요구사항은 온라인 도움말에 대한 요구사항뿐 아니라 일반 사용자 문서(예: 설치 안내서, 사용자 안내서, 훈련 자료 등)를 포함할 수 있습니다.  

정부 규제 준수 같이, 문서 요구사항은 다른 요구사항 유형을 가져옵니다. 특히 기능 요구사항(시스템이 온라인 도움말에 대한 지원 기능 액세스를 제공해야 함)뿐 아니라 사용성 요구사항(시스템 사용량 정보에 대한 요구 시 액세스가 시스템의 전체 사용성을 지원함)도 가져옵니다. 

따라서 정부 규제 준수 같이 문서 요구사항을 지원하는 자세한 요구사항이 이전 단계에서 설명한 대로 보충 스펙의 적용 가능한 섹션에 문서화되어야 하지만, 시스템에 대한 전체 문서 요구사항을 문서화하고 요약하는 것도 중요합니다. 결과 요구사항이 적용 가능한 상세 요구사항을 의미할 수 있습니다.

시스템에 대해 문서화해야 하는 문서 요구사항의 수에 따라서 시스템에 대해 제공되어야 하는 문서의 여러 유형에 대한 서브섹션을 제공할 수 있습니다.

핵심 고려사항

유스 케이스 사이에 걸쳐있는 요구사항(예: 시스템 전반의 요구사항)은 시스템 아키텍처의 개발을 추진하는 경향이 있습니다. 사실 일부 프로젝트에서는 그런 요구사항이 보다 도메인에 특정한(또는 유스 케이스에 특정한) 요구사항보다 훨씬 더 중요할 수 있습니다. 예를 들어 의학적 생명 지원 시스템을 개발 중이라면 신뢰성 요구사항이 중요합니다.

불행하게도 그런 요구사항은 보통 수집하기 어렵고 따라서 종종 간과됩니다. 이 타스크는 이러한 요구사항 수집을 위한 전반적인 접근 방식에 대해 설명합니다. 특정 질문지를 사용하여 이러한 요구사항을 수집하기 위한 "조직적" 접근 방식에 대한 자세한 정보는 [EEL2004]를 참조하십시오.

자세한 정보