요구사항명세서(SRS,Software Request Specification)

IEEE 830

---

I. 사용자, 시스템의 요구사항 명세화, 요구사항 명세서의 개요

가. 요구사항 명세서(Software Request Specification)의 정의

   - 시스템에서 구현되어야 할 것에 대한 공식적인 문장으로 사용자, 시스템 요구 사항을 명세화한 산출물

---

II. 요구사항 명세서의 표준 및 구성요소

가. 요구사항 명세서의 표준 (IEEE 830-1993)

구분	구성
1. 서론	1-1. 요구사항 문서의 목적 1-2. 제품의 영역 1-3. 정의, 약어, 생략어 1-4. 참고문헌 1-5. 문서의 나머지에 대한 요약
2. 일반적인 기술	2-1. 제품에 대한 전망 2-2. 제품의 기능 2-3. 사용자 특징 2-4. 일반적인 제약 2-5. 가정과 의존성
3. 특수 요구사항	기능적 요구사항, 비기능적 요구사항, 인터페이스 요구사항 작성 요구사항 - 외부 인터페이스, 시스템기능, 성능, 논리적 DB 요구사항, 설계제약, 창발성과 품질 특성 등
4. 부록
5. 색인

나. 요구사항 명세서의 구성요소

구분	구성
서문	- 예상되는 문서의 독자와 버전 이력. 새로운 버전을 만든 동기를 요약
개요	- 기능와 다른 시스템과의 연계 방법 등을 설명
용어	- 문서에 사용되는 기술 용어집
사용자 요구사항 정의	- 제공되는 서비스와 비기능적 요구 사항의 기술
시스템 아키텍처	- 시스템 모듈에 있는 기능의 분포를 보여주는 예상 시스템 구조에 대해 개괄적으로 표현하고 재사용된 컴포넌트 강조
시스템 사용자 명세	- 기능적, 비기능적 요구사항을 좀 더 상세하게 기술
시스템 모델	- 시스템 컴포넌트와 시스템 환경 간의 관계를 나타내는 하나 또는 그 이상의 시스템 모델 기술
부록	- 개발된 응용에 관계된 상세하고 구체적인 정보 제공
색인	- 여러 종류의 색인 표현

---

 III. 요구사항 명세서의 평가(원리)

평가 기준	설명
무결성과 완벽성	- 사용자의 요구를 오류 없이 빠짐없이 완벽하게 반영
일관성	- 요구사항 명세서 안에 서로 모순되는 부분 없어야 함
명확성	- 요구 분석의 모호한 점이 없도록 간결하고 명확하게 작성
기능적	- “어떻게”보다 “무엇을”에 관점을 두고 기술
검증 가능성	- 요구 분석이 사용자 요구를 만족시키고 있는지 검증
추적 가능성	- 각 요구사항 근거에 대한 추적과 상호 참조가 가능하여야 함
변경 용이성	- 요구사항 변경 시 쉽게 수정할 수 있어야 함

- 프로젝트 진행을 측정하고 관리하기 위해 요구사항 명세서 평가 활동 수행