소프트웨어 요구 명세

이 주제에 대한 더 자세한 내용은 소프트웨어 요구사항 문서를 참고하십시오.

소프트웨어 요구 명세서(software requirements specification, SRS)는 개발될 소프트웨어 시스템에 대한 설명이다. 이는 비즈니스 요구사항 명세서 ((CONOPS))를 모델로 한다. 소프트웨어 요구 명세서는 기능 요구사항 및 비기능 요구사항을 제시하며, 완벽한 상호작용을 위해 소프트웨어가 사용자에게 제공해야 하는 사용자 상호작용을 설명하는 유스 케이스 세트를 포함할 수 있다.

소프트웨어 요구 명세서는 소프트웨어 제품이 어떻게 기능해야 하는지에 대해 고객과 계약자 또는 공급업체 간의 합의를 위한 기반을 구축한다(시장 주도 프로젝트에서는 마케팅 및 개발 부서가 이러한 역할을 수행할 수 있다). 소프트웨어 요구 명세는 보다 구체적인 시스템 설계 단계 이전에 요구사항을 엄격하게 평가하는 것으로, 목표는 나중에 재설계를 줄이는 것이다. 또한 제품 비용, 위험 및 일정을 추정하기 위한 현실적인 기반을 제공해야 한다.^[1] 적절하게 사용될 경우, 소프트웨어 요구 명세는 소프트웨어 프로젝트 실패를 예방하는 데 도움이 될 수 있다. 소프트웨어 요구 명세 문서에는 프로젝트 개발에 필요한 충분하고 필수적인 요구사항이 나열되어 있다.^[2] 요구사항을 도출하기 위해 개발자는 개발 중인 제품에 대해 명확하고 철저한 이해를 가져야 한다. 이는 소프트웨어 개발 프로세스 전반에 걸쳐 프로젝트 팀 및 고객과의 상세하고 지속적인 커뮤니케이션을 통해 달성된다.

SRS는 계약의 인도물 데이터 항목 설명 중 하나이거나^[3] 조직에서 의무화하는 다른 형태의 내용을 가질 수 있다.

일반적으로 SRS는 테크니컬 라이터, 시스템즈 아키텍트 또는 소프트웨어 프로그래머가 작성한다.^[4]

역사

소프트웨어 요구사항 명세서는 이미 1975년부터 소프트웨어 개발 프로세스에 사용되고 있다.^[5]

소프트웨어 요구사항 명세서의 목적과 내용은 1983년 IEEE에 의해 공식화되었다. 이 표준은 1984년에 IEEE-830-1984로 발행되었고 ANSI의 승인을 받았다.^[6] 국제 표준으로 대체되기 전인 1993년과 1998년에 개정되었다.^[7][8] 이 표준은 좋은 SRS에 대한 기준과 그 내용에 대한 권고 사항을 제공하는 것을 목표로 했다. 이는 요구공학을 위한 프로토타이핑의 이점을 인정했다. 구조의 예시와 여러 변형을 제안한다.

ISO/IEC/IEEE 29148 표준 "시스템 및 소프트웨어 공학 —수명 주기 프로세스 — 요구공학"은 2011년에 IEEE 830을 대체했다.^[8] 현재 개정판은 2018년이다. 이 표준은 요구사항 품질 기준, 요구사항 관리 프로세스, 비즈니스 요구사항 명세서(BRS)는 물론 이해관계자 요구사항 명세서(StRS)까지 포괄하여 더욱 광범위하다.^[9] 약간 변경된 예시 구조를 제안한다.

구조

SRS의 예시 구성은 다음과 같다.^[10]

1. 목적
   1. 정의
   2. 배경
   3. 시스템 개요
   4. 참고 자료
2. 전반적인 설명
   1. 제품 관점
      1. 시스템 인터페이스
      2. 사용자 인터페이스
      3. 하드웨어 인터페이스
      4. 소프트웨어 인터페이스
      5. 통신 인터페이스
      6. 메모리 제약
   2. 설계 제약
      1. 운영
      2. 사이트 적응 요구사항
   3. 제품 기능
   4. 사용자 특성
   5. 제약, 가정 및 종속성
3. 특정 요구사항
   1. 외부 인터페이스 요구사항
   2. 성능 요구사항
   3. 논리적 데이터베이스 요구사항
   4. 소프트웨어 시스템 속성
      1. 신뢰성
      2. 가용성
      3. 보안
      4. 유지보수성
      5. 이식성
   5. 기능 요구사항
      1. 기능적 분할
      2. 기능 설명
      3. 제어 설명
   6. 환경 특성
      1. 하드웨어
      2. 주변기기
      3. 사용자
   7. 기타

예를 들어 특정 요구사항 섹션을 반영하는 구조를 가진 특정 섹션과 같이 소프트웨어의 요구사항을 충족시키기 위해 계획된 검증 접근법을 다루는 것이 권장된다.^[9]

요구사항 품질

요구사항은 시스템 설계와는 독립적으로 필요한 것에 대해 엄격해야 하며, 소프트웨어가 이를 어떻게 수행해야 하는지에 대해서는 다루지 않아야 한다.^[9] 따라서 개별 요구사항은 필수적이고, 적절하며, 명확해야 한다. 또한 요구사항 세트는 완전하고, 일관되며, 실현 가능하고, 이해하기 쉬워야 한다.

코드 스멜의 아이디어를 따라, 요구사항이 반드시 틀린 것은 아니지만 문제가 될 수 있는 요구사항 명세의 문제를 설명하기 위해 요구사항 스멜이라는 개념이 제안되었다.^[11] 요구사항 스멜의 예로는 주관적인 언어, 모호한 부사 및 형용사, 최상급 표현 및 부정문이 있다.^[11] 비교 표현, 검증 불가능한 용어 또는 전체를 의미하는 용어도 피해야 한다.^[9]

같이 보기

• 시스템 요구사항 명세서
• 콘셉트 오브 오퍼레이션스
• 요구공학
• 소프트웨어 공학 지식 체계 (SWEBOK)
• 설계 명세서
• 시방서
• 정형 명세
• 추상형