요구명세(SRS; Software Requirement Specification)는 SW프로젝트의 과업, 비용, 기간을 정량화한 후 합의하여 향후 분석․설계․구현․개량 전 과정에서 의사결정의 주요 판단기준이 된다. 하지만, 그 중요성에 비해 국내 SI 프로젝트에서 많이 활용되지 못했다. 애초부터 애매한 요구사항으로 RFP를 공고한 후 계약체결까지 명세(Spec.) 수준으로 구체화되지 못한 상태에서 프로젝트를 일단 시작한 후, 구현산출물을 보면서 명세를 거꾸로 확정해 나가는 주먹구구식 개발관행이 일반적이었기 때문이다.
지난 2018년 3월22일 과학기술정보통신부가 입법예고한 소프트웨어진흥법 전부개정안에 따르면 이러한 주먹구구식 개발관행은 적어도 공공SI에서만큼은 퇴출대상이다. 발주자는 예비입찰자가 FP(Function Point)를 가늠할 수 있도록 과업범위를 상세하게 적은 제안요청서를 공고해야 하고, SW기업과 계약 직후 착수회의까지 과업내용을 합의해 오면, 제3자인 과업심의위원회가 그 과업내용을 계약금액과 대비하여 심사한다.
또한 프로젝트 수행 중 불가피한 과업변경 요구가 있는 경우, SW기업이 변경영향도 분석을 거쳐 과업심의위원회 개최를 요청하면 공공기관은 이에 응하도록 법안에 명시했다. 최종 검수 단계에서는 애초에 작성한 SRS를 기준으로 검수하여 불명확한 기준으로 인한 검수지연 및 지체상금 부과가 최소화 되도록 하위법령 또한 마련해야 한다.
민간 SI프로젝트에서는 공정계약의 원칙하에 표준계약서를 사용하도록 보급하며 이 계약서에 상기(上記)한 과업확정의 기준, 과업변경과 계약금액의 조정기준을 명시한다. 또한 공공과 민간 양쪽에서 발생하는 분쟁의 조정창구로서 분쟁조정위원회를 설치한다.
이상의 제도가 잘 작동하기 위해서는 SW기업은 SRS를 꼼꼼하게 작성하여 발주자에게 제시해야 하며, 발주자는 이에 대해 진지하게 검토하고 합의에 응해야 한다. 다만 SRS를 작성하는 것에 생각보다 많은 시간과 비용이 소요되므로 발주자는 선행-후속사업 분리와 예산이월 규정을 적극 활용할 필요가 있다.
이처럼 요구명세의 개념이 포함된 SW진흥법 개정에 따라 공공과 민간이 그 동안 취약했던 요구명세 작성․활용이 확산되어, 그 결과 SW산업구조가 고도화 되고 SW개발자의 처우가 개선되는 효과를 기대한다.
Executive Summary
The Software Requirement Specification (SRS) is a key criterion for decision-making in the analysis, design, implementation, and improvement process of a software project based on a mutual agreement to quantified tasks, costs, and duration. However, compared to its importance, system integrators used to not write and make an agreement based on the SRS in the Republic of Korea. This is because it was common practice to start a project with a specification that was not clearly specified at the feasible software requirement specification level based on the ambiguous Request for Proposal(RFP) from the beginning and then to contract with the unfinished specification. Rather, after starting the project, it was common to fix the incomplete specifications with reference to the implementation artifacts.
According to the bill of software promotion law which promised legislation by the Ministry of Science and ICT on March 22, 2018, these unreasonable development practices are subject to exclusion at least from the public sector. Public clients must announce a RFP detailing the scope of the work so that the preliminary tenderer can measure the function point(FP), and if the successful bidder and the client agree on the contents of the work until the kick off of the contract, The task evaluation committee reviews whether the contents of the work are appropriate for the contract amount as a third party.
Also, according to the bill, if there is a demand for an unavoidable change during the project, a company performing the task may request the holding of a task evaluation committee after an impact analysis of change, and the client in the public sector should accept the request. Further, in the final inspection stage, the inspection should be based on the original and changed SRS. Accordingly, a subordinate statute should be prepared so as to minimize inspection delay and an imposition of delayed prizes due to unclear criteria for the inspection.
Government will spread standard contract form to private sector under the principle of fair contract. In this contract, the criteria for the determination of the task, the adjustment of the task change and the adjustment of the contract amount accordingly shall be specified as mentioned above. In addition, a dispute settlement committee shall be established as a coordinating desk for disputes arising from both the public and private sectors.
In order for the above system to work well, a software company should carefully prepare the SRS and present it to the client. The client should seriously review it and agree to the agreement. However, since it takes more time and expense to write the SRS, the client can consider splitting another project for software requirement specification and can leverage the law clause of budget carry over for making another project.
This bill of the Software Promotion Law, which includes the concept of software requirements specification, is expected to lead to the improvement of the structure of the industry and further improvement of the welfare of software developers.
