요구명세 - SRS (Software Requirement Specipication) 의 중요성과 SW진흥법 전면 개정

요구명세(SRS)의 중요성 뛰우기

Software를 개발할려면 우선 무엇을 개발할것이며, 어떤 기능, 어떤 화면을 개발할 것인가에 대해서
사용자의 요구사항을 정리하게 되는데. 이러한 문서를 보통 요구사항정의서 또는
요구명세(SRS; Software Requirement Specification) 라고 한다. 
그리고 이러한 요구명세에 의해서 과업, 비용, 개발기간을 정량화 한 후 합의를 해서 이후 분석,설계
, 구현, 시험, 인수 의 전과정에서 의사결정의 판단 기준이 되는 중요한 문서이다 
그러나 실제 국내 SI 프로젝트를 보면 요구명세(SRS)의 활용도가 아주 떨어진다.
왜냐하면 요구명세(SRS)의 바탕이 되는 제안요청서(RFP)부터 애매하게 정의가 되기 때문에
일단 프로젝트를 시작한 후에 그 때부터 산출물 기준으로 요구명세를 꺼꾸로 정의해 나가는
상황이 벌어지고 있다. 
그래서 2018년 3월 22일 과학기술정보통신부가 입법예고한 소프트웨어진흥법 전부개정안에 따르면 
이러한 주먹구구식 개발관행은 민간기업에게 강제할 수는 없지만 적어도 공공SI에서만큼은 제대로 된
요구명세(SRS)를 시작으로 프로젝트 전과정에 사용할 수 있도록  발주자는 예비입찰자가 FP(Function Point)
를 가늠할 수 있도록 과업범위를 상세하게 적은 제안요청서(RFP)를 공고해야 하고, SW기업과 계약 직후
착수회의 까지 과업내용을 합의해 오면, 제3자인 과업심의위원회가 그 과업내용을 계약금액과 대비하여 "
심사한다. 또한 프로젝트 수행 중 불가피한 과업변경 요구가 있는 경우, SW기업이 변경 영향도 분석을 
거쳐 과업심의위원회 개최를 요청하면 공공기관은 이에 응하도록 법안에 명시했다. 
최종 검수 단계에서는 애초에 작성한 SRS를 기준으로 검수하여 불명확한 기준으로 인한 검수지연 
및 지체상금 부과가 최소화 되도록 하위법령 또한 마련해야 한다.

요구명세(SRS) 가 없는 SI사업의 문제점

문제점	내용
과업내용 모호	제안요청서의 96%가 과업규모 산정이 불가능하여 사업위험을 예측할 수 없는 수준인데, 이를 기준으로 계약을 체결함
과업확정 지연	설계산출물을 상세설계와 구현 단계에 확정한다는 발주기관 비율이 75%에 달하는 등 발주자와 개발자가 합의없이 설계하고, 산출물을 보면서 과업을 확정해 나가는 주먹구구식 개발관행이 일반화
변경관리 불가	애초부터 과업내용이 불명확하여 사업수행 도중 발주기관이  추가로 요구하더라도 과업변경인지 판단이 어려워 결과적으로 과업변경 심의위원회 등 과도한 과업변경에 대한 SW기업 보호제도마저 유명무실
대가없는 과업변경	미 발생한 과업변경에 대하여 발주기관이 계약금액을 조정할 수 있는 근거가 부족하므로 SW기업에게 추가대가를 지급하는 사례를 찾아보기 어려움
분쟁 시 판단기준 부재	민관합동 SW불공정행위 모니터링단 사례집 (KOSA 2017) 중 공공부문 분쟁의 약 30%가 과업추가와 검수지연으로서 발주자와 수주자 간 과업정의와 검수에 대한 기준이 다른 것에서 기인함

                            
SW진흥법 전부개정안의 공공SW사업 이행방안 요구명세(SRS) 중심의 사업관리

계약 전 SRS를 위한 토대를 구축하고, 계약과 착수회의를 거치면서 2단계로 SRS를 확정하며, 이후 수행과 
검수과정에서 SRS를 의사결정 기준으로 설정
즉 계약단계에서 요구명세(SRS)를 확정을 하기에는 어려움이 있다.  이를 감안해서 계약후 착수회의 때 
SRS에 대해서 다시한번 검토 및 확정을 할 수 있게 했다.

단계	SRS 역할
1. 사업계획	사업예산을 확보하면서 SRS의 이전단계인 요구사항을 개념화
2. 사업공고	RFP의 요구사항을 정량적으로 분석하여 SRS의 토대 수립
3. 계약	RFP를 반영한 SRS 초안으로 계약금액과 총 과업규모를 협상,조정
4. 착수	SRS를 리뷰하고 착수보고를 통해 구체적인 과업내용까지 합의,확정
5. 변경	SRS를 기준으로 과업변경을 심의한 후, 변경내역을 SRS에 반영
6. 검수	SRS대로 개발되었는지 테스트하고, 사업수행 결과를 검수

SW진흥법 전부개정안의 요구명세(SRS) 활용방안 요약

항목	현황/개선	설명
1. 제안요청서와 SRS	현황	상세한 요구사항은 공공SW사업 예산편성부터 검수까지 전 과정에서 사업  성공의 기초인데, 현행 공공SW사업의 제안요청서 중 사업규모를 산정할 수 있는 B등급* 이상의 비율은 4% 미만에 불과함
	개선	과업규모를 산정할 수 있는 B등급 이상의 요구사항을 적은 제안요청서를 공고하도록 의무화
2. SRS와 계약	현황	과업내용을 확정한 후 이를 근거로 계약을 체결하는 것이 바람직  하나, 계약 체결 전(제안요청→입찰→제안평가→기술협상)에 과업내용을  합의하는 것은 현실적으로 어려움
	개선	과업규모와 금액으로 계약*을 체결하고, SW사업자는 일정기간 내에 착수계획서를 작성하여 보고하는 과정에서 발주자와 SW사업자 쌍방이 구체적인 과업내용 까지 적은 SRS에 합의하도록 함
3. SRS에 근거한 과업변경	현황	과업변경심의위원회가 거의 개최되지 않고* 과업변경을 인정받기 어려워 계약금액의 조정이 이루어지지 않음 * SW계약 4951건 중 0.4%인 23건만이 과업변경심의위원회를 개최
	개선	국가기관별로 과업심의위원회를 의무적으로 설치하고 SW 사업자가 과업심의회의 개최를 요청하면 발주기관은 이에 응하도록 규정 ㅇ (과업변경 절차) 과업심의위원회에서 계약시점에 작성한 SRS·산출내역서와 과업내용 변경 요청서를 비교하고 과업변경에 대한 영향도(기간, 금액)를 검토하여 과업 증감량과 이에 따른 계약 금액의 조정을 심의
4. SRS와 사업검수	현황	SW사업의 인수테스트와 검수의 기준이 명확하지 않아 발주자의 재량과 사업기간 등 외부상황에 따라 검수가 이루어짐
	개선	SRS가 인수테스트와 검수의 기준 문서가 됨
5. SRS와 사업비	현황	SRS를 작성하는 것이 SW구현비용을 산정하는 기초가 되는데, SRS작성에 전체 사업비의 약 20% 정도가 소요됨   -> SW구현비용은 FP(Function Point) 또는 MM(Man Month)로 산정하는       데 이는 국가계약법 상거래실례가, 실적공사비, 원가계산, 견적가 중       원가계산 방식에 해당하며, SW사업은 이러한 원가계산에만 많은 비용       이 소요되는 딜레마 상황임 ㅇ (대가기준) 소프트웨어산업협회의 SW사업대가(KOSA) 산정 가이드는     요구분석 단계에 19%의 가중치를 할당함 ㅇ (실태조사) 요구분석 단계 까지의 인건비 비중은 10%~25%로 조사
	개선	충실한 SRS를 위해 지출한 20%의 비용이 나머지 80% 사업비의 낭비를 방지하므로, SRS를 기준으로 SW구현을 계속할지 의사결정하고 적절 하지 않는 경우 구현을 중단4) 하거나 계획 자체를 변경할 수 있는 체계가 필요함   -> 즉 요구사항 분석을 시작하면 반드시 구현까지 해야 하는 일괄발주       사업의 제약을 벗어나기 위해, 사업을 분리하여 시행하는 방안이 필요       함 (SRS에 의해 사업의 진행여부를 판단함)
6. SRS와 선행사업 분리	현황	현행 일괄발주 체계 내에서 SRS의 품질과 명확성을 일정 수준 이상 보장할 수 있는 예산과 기간을 확보하기 어려움
	개선	SRS 작성에 상당한 예산과 기간이 소요됨에 따라 별도의 사업으로 분리하여 발주하는 체계가 필요 ㅇ (SRS 수준) 선행 사업의 결과물인 SRS는 소요비용과 역량을 고려할 때 B등급(간이법 FP) 이상의 산출물을 도출할 수 있음

< 출처 : 인사이트리포트 2018-001 요구명세의 중요성과 제도화 방향 >