Software Requirement Specification

SRS

Software Requirement Specification

 

소프트웨어&서비스 개발을 위한 SRS(표준기획서)

-서비스 요구분석서(요구사항 명세서)

 

          문서제목

              작성자
              관련 부서
              주소
              날짜
              문서 버전 통제 정보

 

1.도입

   1.1 문서의 목적
   이 문서의 목적, 이 문서를 읽을 타겟 오디언스가 누구인지를 적는다.

   1.2 문서의 범위
   이 SRS 문서의 범위를 설명한다. 이 소프트웨어(서비스)의 사용자와 타겟 고객, 시스템 엔지니어, 개발자들을 포함한 소프트웨어(서비스) 개발 요구 도출 팀을 소개한다.
  

스케쥴과 비용, 개발 환경 등 개발 요구사항 도출 과정에 있어서 제한사항들을 모두 기술한다.

   1.3 제품(서비스) 개요
   개발될 서비스나 소프트웨어 등 제품의 간단한 개요를 적는다.

   1.4 사업 소개
   이번 제품(서비스) 개발을 지원하는 부서 혹은 조직이 누구인지, 이번 개발 프로젝트의 비즈니스적 목표는 무엇인지, 이 일을 맡은 조직의 비즈니스 목표는 무엇인지를 분명하게 적는다.

 

 2. 총설

   2.1 제품 기능
  제품(서비스)의 일반적인 기능을 적는다. 디테일한 설명은 아래 별도 항목에 적는다.

   2.2 유사 시스템 정보
  다른 제품들과 본 제품의 관계를 적는다. 이 제품(서비스)이 스탠드얼론으로 사용되는 것인지, 아니면 다른 제품(서비스)의 일부 요소로 사용될 것인지 구체화한다. 만일, 후자라면 이 섹션에서 본 제품(서비스)과 함께 쓰일 제품(서비스)과의 관계를 설명한다.

   2.3 사용자 캐릭터
  사용자 집단의 특징을 적는다. 사용자 집단이 이 제품(서비스)과 관련하여 어느 정도의 전문적인 기술적 이해도를 갖추고 있을지도 적는다.

   2.4 사용자 문제(니즈) 기술
  사용자 집단이 현재 안고 있는 핵심적인 문제점들을 정리하여 적는다.

   2.5 사용자 목표
  사용자의 관점에서 이 제품(서비스)이 갖추어야 할 목표와 요구사항들을 기술한다. 사용자들이 기대하고 있는 제품(서비스)의 특징을 기술한 사용자들의 '희망 목록(wish list)'을 적고, 비즈니스 목적에 맞으며 실행가능한 해법을 적는다.

   2.6 일반적 제한사항
  하드웨어 사양, 요구되는 프로토콜, 속도 등을 포함하여, 개발팀에서 제기된 일반적인 제한사항을 목록화한다.

 

3. 기능 요건

이 부분은 기능 요구사항들을 중요한 순서대로 열거한다. 기능 요건들은 소프트웨어(서비스) 시스템이 내놓을 예상 가능한 결과들, 즉 시스템이 반드시 충족해야 하는 기능 목표를 서술한다. 다른 종류의 요구사항들(인터페이스 요구사항, 퍼포먼스 요구사항, 신뢰도 요구사항 등)은 시스템이 ‘어떻게’ 이러한 기능요구사항을 충족시키는지를 적는 것이다. 각각의 기능 요구사항들은 다음과 같은 포맷으로 구체적으로 적어야 한다.

 

1.      가장 중요도가 높은 기능 요건부터 짧고, 직관적인 문장으로 적는다.

 

1.서술
스팩 전체를 세밀하고 꼼꼼하게 적는다.

2.중요도
이 기능이 전체 제품(서비스)에 얼마나 필수적인지 적는다.

          3.기술적인 이슈
이 기능을 구현하는 데 있어 어떤 디자인이나 개발 이슈가 연관되어 있는지 적는다.

          4.비용과 일정
이 건과 연관된 간접적이고 직접적인 비용을 모두 적는다.

          5.위험요소

이 기능이 충족되지 못할 수도 있는 상황들을 적고, 이런 위험 요소를 줄이기 위해 어떤 조치들이 취해져야 하는지 적는다.

          6.다른 요건들과의 의존성
다른 기능과의 상관관계를 적는다.

 

          7.필요한 기타 사항

 

2 . <그 다음 순위 요구 사항들>
기타 등등...

 

4. 인터페이스 요건들
소프트웨어(서비스) 인터페이스가 인풋 아웃풋(입출력)에 있어 다른 소프트웨어 제품들이나 사용자들과 어떻게 상호작용하는지를 서술한다. 이 같은 인터페이스 사례로는 도서관 루틴, 토큰 스트림, 공유 메모리, 데이터 스트림 등이 있다.

 

4.1 유저 인터페이스(UI)I
이 제품이 사용자들과 어떻게 상호작용하는지(interface)를 기술한다.

 

4.1.1 그래픽화된 유저 인터페이스(GUI)
GUI가 존재한다면, 그것을 정리하여 적는다. 이 부분은 UI 특징들을 묘사하기 위한 일련의 스크린 캡쳐나 모형(mockup)을 포함해야 한다. 만약 시스템이 메뉴에 따라 동작하는 구조라면, 모든 메뉴와 그들의 요소에 대한 서술을 포함해야 한다.

 

4.1.2 명령계통 인터페이스(CLI)
CLI(Command-line 인터페이스)가 존재한다면 그것을 서술. 각각의 명령에 대해, 모든 변수와 예시 값 지시문 등을 서술해야 한다.

 

4.1.3 응용 프로그래밍 인터페이스(API)
응용 프로그래밍 인터페이스 구조를 서술. 각각의 공용 인터페이스 기능, 이름, 변수, 리턴값, 지시문의 예, 다른 기능들과의 상호작용 등에 대해 서술한다.

 

4.1.4 진단 또는 ROM
디버깅 정보 또는 다른 진단 데이터를 어떻게 얻을 수 있는지 적는다.

 

4.2 하드웨어 인터페이스
하드웨어 장비들과의 인터페이스를 적는다.

 

4.3 커뮤니케이션 인터페이스
네트워크 인터페이스를 적는다.

 

4.4 소프트웨어 인터페이스
위에 포함되지 않은 나머지 소프트웨어 인터페이스를 적는다.

 

5. 성능 (퍼포먼스) 요구사항

속도,  메모리 요구사항들을 구체적으로 적는다.

 

6. 디자인 제약사항

  이 표준문서를 사용할 개발팀에 대한 제약사항들을 적는다.

  6-1 표준규격 적합성

 

  6.2 하드웨어 사양

 

  6.3 이외의 사항들은 적절한 범위에서 기술.

 

 7. 다른 비 기능적 속성 

시스템에 필요한 기타 특별한 비 기능적 속성을 기술한다

보기는 아래와 같다

 

7.1 안전성

 

7.2 호환성

 

7.3 신뢰도

 

7.4 유지보수

 

7.5 휴대성

 

7.6 연장성

 

7.7 재사용성

 

7.8 적용 친숙도/호환성

 

7.9 자원 활용성

 

7.10 유용성, 편리성

 

7.11 기타

 

8. 초기의 목표 분석

이 부분에서는 요구사항을 충족하기 위해 시스템 내에서 모델링해야 할 근본적인 목표들이 무엇인지를 구체적으로 적는다. 이렇게 하는 이유는 위에서 정리한 요구사항들을 구조적으로 정리해보고, 이 요건들이 시스템안에서 어떻게 충족될 것인지 여러가지 대안을 확인하기 위한 것이다.

 

8.1 승계 관계

이 섹션에서는 목표 시스템의 여러 요소들간의 얼개와 계층구조를 묘사하는 그래프를 반드시 그려넣어야 한다.

보기:                    운송수단

            승용차                       트럭

도요타               혼다     GMC                 볼보

 

8.2 각 단계 설명

각 계층 단계를 세부적으로 상세하게 설명한다.

 

각 단계에 대한 설명은 아래 구조와 같이 되어야 한다.

    1.  8.2.1  <단계 명>

       1.  8.2.1.1 추상적이거나 구체적 :

           해당 단계가 추상적인지 또는 구제적인지 가리킨다.

       2.  8.2.1.2  상위 목록 리스트 :

     직접적인 모든 상위 목록들의 이름을 적는다

       3.  8.2.1.3  하위 목록 리스트 :

     직접적인 모든 하위 목록들의 이름을 적는다

       4.  8.2.1.4 목적:

           각 단계의 기본적인 목적을 진술한다.

       5.  8.2.1.5 연관성:

목적 달성을 위해 이 단계가 상호 연관성을 가지고 있어야 할 각 단계들의

 이름을 나열한다

6.  8.2.1.6 속성 :

각 단계의 instance와 연계된 attributes(state variables)를 일일이 나열하고,

가능한 값(또는 범위)의 사례들을 보여준다 .

      7.  8.2.1.7 운영 :

이 단계의 각각의 instance로부터 나타날 수 있는 각각의 operation을 나열한다. 각 오퍼레이션에 대해 arguments와 type, return value와 type 그리고 혹시 있을지도 모를 오퍼레이션의 side effects를 반드시 구체적으로 적어야 한다.

8.  8.2.1.8 제한 사항

          이 단계의 각각의 instance의 general state 혹은 behavior에 따른 제한 사항을 나열한다.

9. 운영 시나리오

이 부분에서는 다양한 상황에서 시스템을 사용했을 때 사용자가 경험하게 될 사항들을 사용자 관점에서 정리한 일련의 시나리오들을 적는다. 조사에 기초한 요구사항 분석에 따르면 시나리오는 다음과 같이 정의된다

포괄적인 개념으로, 시나리오는 특정 시스템의 사용법을 간단하게 명시한 것이다. 보다 구체적으로 말하면, 시나리오는 필수 시스템과 그 환경을 포함한 하나 또는 그 이상의 연관된 처리 과정에 대한 설명서이다. 시나리오는 레벨별로 필요한 세부사항에 따라 여러가지 다른 방법으로 문서화 할 수 있다. 가장 간단한 형태는 사용목적의 경우로 단순하게 번호를 붙인 간단한 설명들로 구성된다.
 좀 더 세분화된 형태는 스크립트라고 불린다. 스크립트는 일반적으로 테이블이나 다이아그램 형태로 나타나며 행동과 행동의 주체를 규정하는 것과 관련이 있다. 이 때문에 스크립트는 액션 테이블이라고도 불린다.

시나리오는 개발 요구사항(요건)들을 습득하고 확인하는데는 유용하지만, 그 자체가 요건은 아니다. 왜나하면 시나리오는 특정 환경에서의 시스템의 동작을 기술하고 있기 때문이다. 다시 말하면, 일반적으로 시스템이 어떤 일을 하는지를 기술한 설명서일 뿐이다.

10. 초기 일정

여기서는 주요 달성 과제와 상호 연관된 작업의 예정 시작일과 완료일을 포함한 프로젝트 플랜의 초안을 설명한다. 또 하드웨어와 소프트웨어 그리고 소프트웨어를 만들고 하드웨어를 조작하기 위해 필요한 인적 자원에 대한 정보를 포함한다.

프로젝트 플랜은 하나 또는 그 이상의 퍼트(PERT:계획 평가검토기법)나 GANTT 차트를 포함해야 한다.

11. 초기 예산

    여기서는 비용 요소에 따른 항목을 적고, 프로젝트를 위한 초기 예산을 잡는다.

 

12. 부록

요구사항들을 이해할 수 있도록 유용한 정보를 나열한다. 모든 SRS 문서에는 적어도 아래 두가지 이상의 항목을 포함해야 한다.

 

 12.1 정의, 약어(첫 대문자만 따는 형태), 단축어

    잘 모르는 분야의 정의, 전문용어, 약어에 대한 명확한 의미를 전달할 것

 

 12.2 참조

    문서 작성에 참조하거나 이용한 모든 문서나 회의에 대한 완벽한 인용사항을 적는다.