SRS(Software Requirements Specification) 이란? + 템플릿 공유

소프트웨어 프로젝트에서 문서를 딱 하나만 만들어야된다면, 시간이 없다면?
당장 SRS부터 작성해야 한다.

 

 

요구사항 분석 문서의 종류는 수도 없이 많다. 개발방법론에 따라 제시하는 요구사항 문서가 다르고, 그 개수도 다르다. 하지만 그 많은 순서 중 가장 중요한 문서는 SRS이다.

 

■ SRS = Software Requirements Specification

 

소프트웨어 프로젝트 나무 (출처 : 지어소프트)

요구사항 문서는 프로젝트에서 작성하는 산출물 중 가장 중요하다. 위 그림, 소프트웨어 프로젝트 나무에서 보는 바와 같이 요구사항 문서인 SRS는 소프트웨어 프로젝트의 기둥이다.

 

 

 

개발 단계별 요구사항 오류 수정 비용 (출처 : https://softwaredev.tistory.com/entry/SRS%EC%9D%98%EC%A4%91%EC%9A%94%EC%84%B1)

잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 요구사항 오류는 개발 단계가 지나가면 지나갈 수록 그 수정 비용이 기하급수적으로 증가한다. 초반부터 충분히 검토해서 오류가 없는 요구사항을 만드는 것이 ... 효율적이다.

 

 

 

■ SRS의 역할

SRS는 프로젝트에 관련된 다양한 계층이 모두 사용하는 문서, 즉 프로젝트의 가장 중심이 되는 문서이다. 프로젝트의 거의 모든 관련자가 보는 문서이며 다른 여러 문서들의 출발점이기도 하다.

 

• 고객, 마케팅, 영업은 SRS를 통해 어떤 제품이 만들어지는지 알 수 있고, 제품 카탈로그도 만든다.
• 프로젝트 관리자에게는 SRS가 프로젝트 관리의 기본이 된다. 일정을 짜고, 인력을 배분하며, 리스크 분석도 한다.
• 개발팀은 SRS을 통해 본인이 개발해야 하는 제품이 무엇인지 정확하게 알 수 있고 자세한 기능도 알 수 있다.
• 테스트팀은 SRS를 통해 평가 계획 및 테스트 케이스 (T/C)도 짤 수 있다.
• 기술문서팀은 SRS를 통해 매뉴얼과 도움말을 만든다. 제품이 완성되어야만 매뉴얼을 작성할 수 있는 것은 아니다.
• 유지보수 및 기술지원(서비스)팀은 SRS를 통해 유지보수할 제품에 대해 자세히 할 수 있으며, 제품이 어떻게 동작하는지 알 수 있고, 고객 지원 방법을 미리 준비할 수 있다.
• 외주업체는 SRS를 통해 외주 업무를 정확하게 파악하고 이를 기준으로 계약할 수 있다.

 

주요 산출물 관계도 예 (출처 : https://www.allofsoftware.net/search/label/SRS)

 

 

■ SRS는 누가 쓰지

누가 적을지에 대한 이슈는 꽤 오래된 문제이나, 결론은 간단하다. 부서에 상관하지 않고 제일 잘 쓸 수 있는 사람이 적으면 된다.

고참 개발자인 프로젝트 리더가 주로 쓰는데, 때에 따라서 프로젝트 관리자가 적기도 한다.

 

SRS를 적는 사람을 분석가라고 부르는데, 분석가는 다음과 같은 일을 수행할 줄 알아야 한다.

• 토론을 잘해야 함 : 대부분의 요구사항은 토론을 통해서 나오기 때문에 토론 및 인터뷰를 잘 할 수 있어야 한다.
• 요구사항 분석을 잘 해야 함 : 요구사항에 대한 토론 하다보면 분쟁이 있고 충돌이 있기 때문에 잘 중재해서 합리적인 결론에 이르도록 유도해야 한다.
• 글을 잘써야 함 : 어떤 SRS은 1,000페이지가 넘는다. 많은 내용을 잘 조직화 하고 체계적으로 작성해야 한다. 또한 모든 사람이 이해할 수 있게 쉽게 문장을 잘 작성해야 한다.

 

 

 

■ SRS 템플릿 (IEEE)

SRS는 IEEE에서 만든 가이드와 표준 템플릿이 있지만 회사마다 사용하는 템플릿이 약간씩 다르며, 여기에서 문서 이름과 목적, 취지는 전세계적으로 표준이라고 보면 된다.

https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc

위 링크는 구글에 "IEEE SRS 템플릿"이라고 검색했을 시 가장 먼저 나오는 링크이다. 그리고 아래는 그 목록을 캡처한 것이다.