요구사항명세서

왜 배우는가: 요구사항명세서는 개발 계약, 인수 시험, 변경 관리의 기준 문서이므로 실무에서 분쟁의 출발점이 된다. 시험에서는 1교시 용어 문제와 2교시 공공 소프트웨어 사업 논술 문제로 반복해 출제되었다.

출제 이력: 제130회 1교시 3번, 제119회 2교시 2번

1. 한 줄 정의와 핵심 키워드

요구사항명세서(SRS)는 시스템이 제공해야 할 기능·성능·제약을 발주자와 개발자가 같은 뜻으로 읽도록 기술한 산출물이다.

핵심 키워드

• 요구사항명세서(SRS): 요구사항을 문서로 확정한 개발 산출물이다.
• 기능 요구사항: 입력에 대해 시스템이 수행할 동작을 기술한다.
• 비기능 요구사항: 성능, 보안, 신뢰성 같은 품질 조건을 기술한다.
• 완전성·일관성: 빠진 요구나 서로 충돌하는 요구가 없어야 한다.
• 추적성: 요구사항과 설계, 코드, 시험 항목이 서로 연결되어야 한다.
• 검증 가능성: 시험으로 충족 여부를 판정할 수 있어야 한다.
• 인수 기준: 발주자가 산출물을 받아들이는 판단 조건이다.

2. 개념 풀이

쉬운 말로 하면 SRS는 발주자가 무엇을 원하는지 개발자가 빠짐없이, 틀리지 않게 알아듣도록 적어 둔 약속서다. 이 문서가 없으면 개발자는 추측으로 설계하고, 발주자는 완성본을 보고 원한 것과 다르다고 말하게 된다.

정식 정의는 이해관계자의 필요를 시스템이 충족해야 할 요구로 옮겨 체계적으로 기술한 문서다. 국제 표준인 ISO/IEC/IEEE 29148 계열은 이 문서를 요구공학(Requirements Engineering) 프로세스의 산출물로 다룬다.

작성 형식은 흔히 시스템은 ~해야 한다 라는 문장으로 통일한다. 한 문장에는 하나의 요구만 담고, 모호한 표현 대신 단위와 조건이 드러난 값을 쓴다. 예를 들어 응답 시간 같은 항목은 측정 가능한 수치와 측정 조건을 함께 적어야 시험 기준이 된다.

SRS의 위치도 분명히 해야 한다. 설계 명세서는 검증(verification)의 대상이지만, SRS는 시스템이 발주자 요구를 충족하는지 확인(validation)하는 기준으로 쓰인다. 그래서 SRS의 품질은 이후 모든 단계의 품질을 결정한다.

핵심 용어 풀이는 다음과 같다.

• 기능 요구사항(functional requirement): 시스템이 무엇을 수행해야 하는지 정의한다. 입력, 처리, 출력, 예외 처리 조건을 함께 적는다.
• 비기능 요구사항(non-functional requirement): 성능, 가용성, 보안, 확장성처럼 기능의 품질 수준을 정한다. 정량 값으로 쓰지 않으면 검증이 어렵다.
• 추적성(traceability): 요구사항 한 건이 설계, 코드, 시험 케이스까지 이어지는 연결 관계다. 변경이 생기면 영향 범위를 찾는 근거가 된다.
• 인수 기준(acceptance criteria): 산출물을 인수할지 판단하는 조건이다. 계약 분쟁에서 완성 여부를 가르는 기준이 된다.

3. 등장 배경과 필요성

소프트웨어 규모가 커지고 발주자와 개발자가 분리되면서 요구를 말로만 주고받는 방식은 한계를 드러냈다. 요구 오류는 후반 단계에서 발견될수록 수정 비용이 커지므로, 요구를 문서로 고정하고 검토하는 절차가 필요해졌다.

표준 측면에서는 IEEE 830이 오랫동안 SRS의 기준 역할을 했다. 이후 ISO/IEC/IEEE 29148이 2011년에 IEEE 830을 대체했고, 현재 개정판은 2018년 개정판이다. 이 표준은 요구사항 품질 기준, 요구사항 관리 프로세스, 비즈니스 요구사항 명세서(BRS), 이해관계자 요구사항 명세서(StRS)까지 포괄하도록 범위를 넓혔다.

공공 소프트웨어 사업에서는 SRS의 필요성이 법령으로도 드러난다. 소프트웨어 진흥법 제50조는 과업내용의 확정과 과업내용 변경의 확정을 과업심의위원회의 심의 사항으로 정한다. 과업내용이 문서로 확정되어 있어야 변경 요청의 기준선을 정할 수 있다.

계약 측면에서도 같은 흐름이 보인다. 소프트웨어 진흥법 제38조 제2항은 계약의 목적과 범위, 계약기간을 계약서에 분명하게 적도록 한다. 계약서의 과업 범위는 SRS의 요구 목록과 연결되어야 분쟁을 줄일 수 있다.

변경 절차에서도 기간이 정해져 있다. 시행령 제47조 제5항은 과업심의위원회 개최 요청을 받은 날부터 14일 이내에 심의·의결 결과와 조치계획을 개최를 요청한 소프트웨어사업자에게 통보하도록 한다. 불가피한 경우에는 협의하여 한 차례에 한정해 14일 이내의 범위에서 통보기한을 연기할 수 있다.

개정안이 기획과 설계 단계를 강화하는 방향이므로, SRS가 계약과 변경 관리의 기준 문서로서 맡는 역할은 더 커진다고 볼 수 있다. 따라서 요구사항명세서는 개발팀만의 문서가 아니라 발주자와 수급인이 함께 확인하는 공식 문서로 다뤄야 한다.

4. 구성요소·원리·절차

요구사항명세서는 여러 구성요소로 이루어진다. 한 항목이라도 빠지면 계약 범위와 인수 기준이 흐려진다.

표의 구성요소는 계약 문서와 시험 문서가 공통으로 참조하는 항목이다. 각 항목은 설계와 시험으로 이어져야 한다.

요구사항은 '시스템은 ~해야 한다' 형태로 쓴다. 한 요구사항에는 하나의 조건만 담는다. 명세서는 완전성, 일관성, 추적성, 검증 가능성, 명확성을 갖춰야 한다. 명세서는 계약, 인수 시험, 변경 관리의 공통 기준선이다. 각 요구사항에 고유 번호를 부여하면 설계·구현·시험 항목과 연결하는 추적성 행렬을 만들 수 있다.

요구사항 명세 절차는 다음과 같다.

• 이해관계자 요구를 도출한다.
• 요구를 분석하고 충돌하는 요구를 조정한다.
• 구성요소 체계에 맞춰 명세서를 작성한다.
• 검토와 승인을 받아 기준선(baseline)으로 확정한다.
• 변경이 생기면 영향을 분석하고 명세서를 갱신한다.

그림의 되먹임 경로는 검토나 변경 단계에서 결함이 나오면 분석 단계로 돌아가는 것을 뜻한다. 반복이 있어야 불일치가 줄어든다.

명세서의 구성 체계는 다음 블록으로 그린다.

5. 관련 법령·기준·표준

요구사항명세서는 두 축의 기준과 연결된다. 하나는 계약과 과업 변경을 규율하는 「소프트웨어 진흥법」이고, 다른 하나는 요구공학 절차를 규정한 국제표준이다.

표의 값은 요구사항 변경이 계약금액과 기간에 미치는 경로를 보여준다. 요구사항명세서가 변경 근거로 쓰이려면 이 기한 안에 심의 근거를 제시할 수 있어야 한다.

계약 관련 공정계약은 법 제38조가 기본 원칙으로 정한다. 과업내용 과업심의위원회는 법 제50조가 설치 근거를 둔다. 하도급 제한은 법 제51조가 정한다. 법 제50조 제4항과 제5항, 제2항 개정은 2026-08-11 날짜로 표시되어 있다. 법 본문 시행일은 2027-02-12, 시행령 제47조 시행일은 2026-06-03으로 표시되어 있다.