기술사 학습노트 | imt-log

기술사 학습노트›소프트웨어공학›요구사항명세서

Software Engineering · 정보관리기술사 / 컴퓨터시스템응용기술사

요구사항명세서(SRS, Software Requirements Specification)

이해관계자의 요구를 분석·정제하여 시스템이 제공해야 할 기능, 성능, 제약, 인터페이스, 품질 요구를 명확하고 검증 가능한 문서로 정의한 소프트웨어 개발의 기준 문서

정보관리기술사컴퓨터시스템응용기술사요구사항명세서SRS요구공학기능요구사항비기능요구사항요구사항추적성검증가능성기준선관리

Ⅰ.개요 및 등장배경

가. 요구사항명세서의 정의

요구사항명세서(SRS, Software Requirements Specification)는 소프트웨어 시스템이 무엇을 수행해야 하는지, 어떤 품질 수준을 만족해야 하는지, 어떤 제약조건과 외부 인터페이스를 가져야 하는지를 명확하게 기술한 공식 문서이다. 요구사항명세서는 고객, 사용자, 발주자, 개발자, 테스터, 운영자, 감리자 등 여러 이해관계자 사이의 공통 기준 역할을 하며, 분석 결과를 설계·구현·테스트·검수로 연결하는 기준선이 된다. 즉 요구사항명세서는 단순한 요청사항 목록이 아니라, 시스템 개발 범위와 품질 기준, 수용 조건을 합의한 계약적·기술적 기준 문서라고 할 수 있다.

기술사 관점에서 요구사항명세서는 요구공학의 산출물 중 가장 중요한 문서이다. 요구사항 수집 단계에서 얻은 고객의 말은 모호하고 중복되며 때로는 상충된다. 따라서 요구사항명세서는 수집된 요구를 분석, 분류, 정제, 우선순위화, 검증 가능한 표현으로 변환하여 개발과 검수에 사용할 수 있는 형태로 만들어야 한다. 좋은 요구사항명세서는 완전성, 일관성, 명확성, 추적성, 검증가능성, 변경가능성, 실현가능성을 갖춰야 하며, 나쁜 요구사항명세서는 범위 변경, 재작업, 일정 지연, 비용 초과, 검수 분쟁의 직접 원인이 된다.

나. 등장배경

• 프로젝트 실패 원인의 상당 부분이 요구사항 오류에서 발생하면서, 요구사항을 명확히 문서화하고 합의하는 체계가 필요해졌다.
• 고객과 개발자 사이의 언어 차이로 인해 “원한 것”과 “만든 것”이 달라지는 문제가 반복되었다.
• 대규모 SI, 공공, 금융, 국방, 의료 시스템에서 요구사항 추적성과 검수 기준의 중요성이 커졌다.
• 애자일과 DevOps 환경에서도 백로그, 사용자 스토리, 인수기준 등 요구사항 기준의 명확성이 여전히 중요해졌다.
• 규제와 감리, 품질보증, 테스트 자동화 요구가 증가하면서 요구사항과 테스트 케이스의 연결이 필수화되었다.
• 외주 개발과 계약 기반 프로젝트에서 산출물 범위, 변경관리, 검수 기준을 명확히 하기 위한 문서가 필요해졌다.

다. 요구사항명세서의 목적

요구사항명세서의 목적은 첫째, 시스템 범위와 기능을 명확히 하여 개발팀과 고객 간의 이해 차이를 줄이는 것이다. 둘째, 설계와 구현의 기준을 제공하여 개발자가 무엇을 만들어야 하는지 명확히 알 수 있도록 한다. 셋째, 테스트와 검수의 기준을 제공하여 요구사항 충족 여부를 객관적으로 확인할 수 있게 한다. 넷째, 요구사항 변경이 발생했을 때 영향도 분석과 변경관리를 가능하게 한다. 다섯째, 프로젝트 종료 후 유지보수와 기능개선 시 시스템의 의도와 제약을 이해하는 기준 자료로 활용된다.

라. 기술사 답안 관점

요구사항명세서 답안은 “요구사항을 잘 적은 문서”라는 수준을 넘어, 프로젝트 전 생명주기를 통제하는 기준선이라는 관점으로 서술해야 한다. 요구사항명세서는 요구사항 정의서, 업무명세서, 설계서, 테스트 케이스와 연결되며, 요구사항 추적 매트릭스(RTM)를 통해 요구사항이 설계, 구현, 테스트, 검수까지 누락 없이 반영되었는지 관리한다. 따라서 답안에는 요구사항의 분류, SRS의 구성 항목, 좋은 요구사항의 품질 조건, 작성 절차, 추적성, 변경관리, 검증 기준을 반드시 포함하는 것이 좋다.

요구사항명세서는 시스템이 제공해야 할 기능·품질·제약·인터페이스를 명확하고 검증 가능하게 정의한 소프트웨어 개발의 기준 문서이다.
답안에서는 고객과 개발자 간 합의, 설계·구현·테스트 기준, 추적성, 변경관리, 검수 기준으로서의 역할을 함께 설명해야 한다.

Ⅱ.구성도 및 구성요소

가. SRS 문서 품질 게이트형 구성도

요구사항명세서 작성과 활용의 품질 게이트 구조

이해관계자 요구가 수집·분석·명세화·검증·승인을 거쳐 요구사항 기준선으로 확정되고, 이후 설계·구현·테스트·검수까지 추적되는 구조이다.

요구 수집

인터뷰, 워크숍, 설문, 현행 시스템 분석, 문서 분석, 프로토타입을 통해 이해관계자 요구를 수집한다.

요구 분석·정제

모호성, 중복, 상충, 누락, 실현 가능성, 우선순위를 분석하고 기능/비기능 요구로 분류한다.

요구 명세화

시스템이 수행할 기능, 데이터, 인터페이스, 성능, 보안, 제약조건을 명확한 문장과 표로 기술한다.

SRS 기준선

범위
기능요구
비기능요구
인터페이스
데이터 요구
제약조건
인수기준
추적성

검증·리뷰

완전성, 일관성, 명확성, 검증가능성, 추적성을 검토하고 고객·개발·테스트 관점에서 리뷰한다.

승인·기준선화

승인된 SRS를 요구사항 기준선으로 확정하고 변경은 변경관리 절차를 통해 통제한다.

추적·검수 연계

요구사항을 설계, 코드, 테스트 케이스, 결함, 검수 항목과 연결하여 누락과 범위 변동을 관리한다.

① 요구 수집

② 분석·분류

③ 명세화

④ 검증·승인

⑤ 추적·변경관리

요구사항 ID

설계 항목

테스트 케이스

검수 기준

구성도 해석

SRS는 작성으로 끝나는 문서가 아니라 요구 수집부터 검수까지 연결되는 품질 게이트이자 추적성 허브로 작동한다.

답안 포인트

명세서 품질은 문장 길이가 아니라 완전성, 일관성, 명확성, 검증가능성, 추적성, 변경관리 가능성으로 판단한다.

나. 구성요소

구분	요소	설명
문서 개요	목적 및 범위	SRS 작성 목적, 시스템 범위, 대상 사용자, 관련 문서, 용어 정의를 기술한다.
전체 설명	제품 관점	시스템이 기존 업무 또는 외부 시스템과 어떤 관계를 가지는지 설명한다.
전체 설명	사용자 특성	주요 사용자 유형, 권한, 숙련도, 업무 책임을 정의한다.
기능	기능 요구사항	시스템이 수행해야 할 업무 기능, 처리 절차, 입력, 출력, 예외 처리를 기술한다.
품질	비기능 요구사항	성능, 보안, 가용성, 신뢰성, 사용성, 확장성, 유지보수성, 호환성 요구를 기술한다.
연계	외부 인터페이스	사용자 인터페이스, 시스템 인터페이스, 하드웨어 인터페이스, API, 파일 연계 요구를 정의한다.
데이터	데이터 요구사항	주요 엔터티, 데이터 항목, 코드, 데이터 보존, 이력, 품질, 마이그레이션 요구를 기술한다.
통제	제약조건	법규, 표준, 기술스택, 운영환경, 보안정책, 개발방법론, 일정·예산 제약을 포함한다.
검증	인수기준	요구사항이 충족되었는지 확인할 수 있는 테스트 및 검수 기준을 명확히 정의한다.
관리	추적성 정보	요구사항 ID, 출처, 우선순위, 관련 설계·테스트·결함 정보를 연결한다.

요구사항명세서의 구성요소는 목적·범위, 전체 설명, 기능 요구, 비기능 요구, 인터페이스, 데이터 요구, 제약조건, 인수기준, 추적성 정보로 구성된다.
Ⅱ.가 구성도는 SRS가 요구 수집과 검수 사이에서 품질 게이트와 추적성 허브 역할을 수행한다는 점을 강조한 형식이다.

Ⅲ.동작방식 및 아키텍처

가. 요구사항명세서 작성 절차

• 1단계 이해관계자 식별: 발주자, 사용자, 운영자, 관리자, 개발자, 외부 연계기관 등 요구 출처를 식별한다.
• 2단계 요구사항 수집: 인터뷰, 워크숍, 설문, 현장 관찰, 문서 분석, 로그 분석, 프로토타입을 통해 요구를 수집한다.
• 3단계 요구사항 분석: 요구의 모호성, 중복, 상충, 누락, 기술적 실현 가능성, 비용과 일정 영향을 분석한다.
• 4단계 요구사항 분류: 기능 요구, 비기능 요구, 데이터 요구, 인터페이스 요구, 제약조건, 인수기준으로 나눈다.
• 5단계 요구사항 명세화: 요구사항 ID, 설명, 입력, 처리, 출력, 예외, 우선순위, 출처, 검증 방법을 구조적으로 작성한다.
• 6단계 요구사항 검증: 완전성, 일관성, 명확성, 추적성, 검증가능성, 실현가능성을 기준으로 리뷰한다.
• 7단계 승인 및 기준선 설정: 승인된 요구사항명세서를 기준선으로 확정하고 이후 변경은 변경관리 절차로 통제한다.
• 8단계 추적관리: 요구사항을 설계, 구현, 테스트 케이스, 결함, 검수 항목과 연결하여 누락과 변경 영향을 관리한다.

나. 좋은 요구사항의 품질 특성

품질 특성	설명	나쁜 예	좋은 예
완전성	필요한 기능과 제약이 빠짐없이 포함되어야 한다.	회원관리 기능 제공	회원 가입, 수정, 탈퇴, 휴면전환, 본인확인 기능을 제공
명확성	읽는 사람마다 다르게 해석되지 않아야 한다.	빠르게 조회되어야 함	95% 요청은 2초 이내 응답해야 함
일관성	서로 모순되는 요구가 없어야 한다.	비회원 주문 불가 / 비회원 주문 가능	비회원은 장바구니 가능, 주문은 회원전환 후 가능
검증가능성	테스트나 검수로 만족 여부를 판단할 수 있어야 한다.	사용자가 편리해야 함	주요 기능은 3단계 이내 화면 이동으로 완료 가능해야 함
추적성	요구 출처와 설계·테스트 연결이 가능해야 한다.	ID 없이 문장 나열	REQ-F-001처럼 고유 ID와 출처, 테스트 ID를 부여
실현가능성	기술, 비용, 일정, 법적 조건에서 구현 가능해야 한다.	무제한 동시접속 보장	최대 10,000명 동시접속 시 평균 응답 3초 이하
변경가능성	변경 시 영향도 파악과 수정이 쉬워야 한다.	중복·분산 기술	요구사항 단위별 ID, 버전, 변경이력을 관리

다. 기능 요구사항과 비기능 요구사항

요구사항명세서에서 가장 중요한 구분은 기능 요구사항과 비기능 요구사항이다. 기능 요구사항은 시스템이 수행해야 하는 행위와 업무 처리 내용을 의미한다. 예를 들어 로그인, 주문 등록, 결제 승인, 재고 차감, 보고서 출력이 기능 요구사항이다. 반면 비기능 요구사항은 시스템이 어떤 품질 수준으로 동작해야 하는지를 나타낸다. 성능, 보안, 가용성, 확장성, 사용성, 접근성, 이식성, 유지보수성, 감사추적, 장애복구 요구가 여기에 포함된다. 기능 요구사항이 “무엇을 할 것인가”라면, 비기능 요구사항은 “얼마나 잘, 얼마나 안전하게, 어떤 조건에서 할 것인가”를 정한다.

라. 요구사항 추적성과 변경관리

요구사항명세서는 작성 후 고정된 문서가 아니라 프로젝트 진행 중 변경과 추적의 기준으로 활용된다. 요구사항 추적성은 요구사항이 설계, 구현, 테스트, 검수 항목에 어떻게 반영되었는지를 연결하는 능력이다. 이를 위해 요구사항 추적 매트릭스(RTM)를 사용하며, 각 요구사항 ID별로 설계 문서, 코드 모듈, 테스트 케이스, 결함, 승인 상태를 연결한다. 변경이 발생하면 해당 요구사항과 연결된 설계, 코드, 테스트, 일정, 비용 영향을 분석해야 한다. 이러한 추적성이 부족하면 기능 누락, 과잉 개발, 검수 분쟁이 발생하기 쉽다.

요구사항 추적 예시 REQ-F-001 회원 로그인 기능 → 설계: DES-AUTH-010 → 구현: AuthController, AuthService → 테스트: TC-AUTH-001, TC-AUTH-002 → 검수: 로그인 성공/실패/잠금 정책 확인

마. SRS 검토 체크리스트

• 요구사항별 고유 ID와 출처가 있는가?
• 기능 요구사항과 비기능 요구사항이 명확히 분리되어 있는가?
• 모호한 표현, 주관적 표현, 중복 표현이 없는가?
• 각 요구사항은 테스트 또는 검수로 확인 가능한가?
• 요구사항 간 충돌이나 상충이 없는가?
• 외부 인터페이스와 데이터 요구가 누락되지 않았는가?
• 우선순위와 중요도가 명시되어 있는가?
• 변경 발생 시 영향도 분석이 가능한 구조인가?

요구사항명세서는 이해관계자 식별, 요구 수집, 분석, 분류, 명세화, 검증, 승인, 추적관리 순서로 작성·운영된다.
좋은 SRS는 완전성, 명확성, 일관성, 검증가능성, 추적성, 실현가능성, 변경가능성을 만족해야 한다.

Ⅳ.실무적용 및 사례

가. 프로젝트 유형별 적용 사례

프로젝트 유형	SRS 적용 방식	효과
공공 SI	제안요청서, 과업지시서, 요구사항정의서와 연계하여 상세 기능과 검수 기준을 명세한다.	검수 분쟁 감소, 범위 통제, 감리 대응 용이
금융 시스템	업무 규칙, 보안, 성능, 감사로그, 장애복구 요구를 상세히 기술한다.	규제 준수, 장애 리스크 감소, 테스트 기준 명확화
모바일 앱	화면 흐름, 사용자 권한, API 연계, 알림, 성능 요구를 사용자 관점에서 명세한다.	UX 혼선 감소, 개발·디자인·QA 협업 강화
외주 개발	기능 목록, 산출물, 인수기준, 변경절차를 계약과 연계한다.	범위 변경 분쟁 방지, 납품 기준 명확화
AI 서비스	데이터 요구, 모델 성능 기준, 설명가능성, 편향 점검, 운영 모니터링 요구를 포함한다.	AI 결과 검증과 운영 위험 통제 가능
클라우드 전환	이관 범위, 가용성, 보안, 백업, RTO/RPO, 운영 자동화 요구를 명세한다.	전환 범위 명확화, 운영 품질 확보

나. 요구사항명세서 작성 예시

항목	예시
요구사항 ID	REQ-F-LOGIN-001
요구사항명	사용자 로그인
설명	사용자는 등록된 아이디와 비밀번호를 입력하여 시스템에 로그인할 수 있어야 한다.
입력	아이디, 비밀번호
처리	사용자 인증 정보를 검증하고, 실패 횟수가 5회 이상이면 계정을 잠금 처리한다.
출력	로그인 성공 시 메인 화면 이동, 실패 시 오류 메시지 표시
예외	미등록 사용자, 비밀번호 오류, 잠금 계정, 휴면 계정 처리
비기능 조건	인증 요청의 95%는 2초 이내 응답해야 하며, 비밀번호는 해시 처리되어 저장되어야 한다.
검수 기준	정상 로그인, 실패 로그인, 5회 실패 잠금, 휴면계정 로그인 제한 테스트를 통과해야 한다.

다. 주요 문제점과 대응 방안

문제점	발생 원인	대응 방안
요구사항 모호성	“빠르게”, “편리하게”, “적절히” 같은 주관적 표현 사용	정량 기준, 화면 예시, 처리 조건, 검수 기준으로 구체화한다.
요구사항 누락	이해관계자 식별 부족과 현행 업무 분석 미흡	워크숍, 업무 시나리오, 프로토타입, 체크리스트를 활용한다.
요구사항 상충	부서별 요구가 서로 다르거나 우선순위가 불명확	우선순위 조정 회의와 의사결정 책임자를 명확히 한다.
비기능 요구 누락	기능 위주로만 명세하고 성능·보안·가용성을 빠뜨림	품질속성 체크리스트와 운영 요구사항 검토를 적용한다.
검증 불가능	테스트 기준 없이 추상적 요구로 작성	각 요구사항에 인수기준과 테스트 가능 조건을 포함한다.
추적성 부족	요구사항 ID와 설계·테스트 연결이 없음	RTM을 작성하고 요구사항 관리도구로 변경 이력을 관리한다.
변경 통제 실패	승인 없이 요구가 수시로 추가·변경됨	기준선 설정, 변경요청서, 영향도 분석, 변경승인 절차를 운영한다.

라. 실무 운영 포인트

실무에서 요구사항명세서는 프로젝트 초기에만 작성하고 방치되는 문서가 되어서는 안 된다. 개발 중 변경되는 요구사항은 반드시 변경관리 절차를 거쳐야 하며, 변경된 요구는 설계, 구현, 테스트, 일정, 비용에 미치는 영향을 분석해야 한다. 특히 외주 개발이나 공공 프로젝트에서는 요구사항명세서가 검수와 계약 분쟁의 기준이 되므로 요구사항별 인수기준을 명확히 작성해야 한다. 애자일 프로젝트에서도 SRS의 형식은 가볍게 가져갈 수 있지만, 사용자 스토리와 인수조건, 비기능 요구, 릴리즈 기준은 반드시 관리되어야 한다.

요구사항명세서는 공공 SI, 금융, 모바일 앱, 외주 개발, AI 서비스, 클라우드 전환 등 다양한 프로젝트에서 범위와 검수의 기준으로 활용된다.
실무 성공요인은 모호성 제거, 비기능 요구 포함, 인수기준 명시, 추적성 확보, 변경관리 체계 운영이다.

Ⅴ.비교분석 및 발전전망

가. 요구사항명세서와 관련 산출물 비교

구분	요구사항명세서(SRS)	요구사항정의서	설계서
중심 질문	시스템이 무엇을 만족해야 하는가?	사용자와 업무가 무엇을 요구하는가?	어떻게 구현할 것인가?
작성 관점	시스템 요구와 검증 기준 중심	업무 요구와 사용자 요구 중심	구조, 컴포넌트, DB, 인터페이스 중심
활용 시점	분석 이후부터 테스트·검수까지	요구 수집·분석 단계	설계·구현 단계
주요 내용	기능, 비기능, 인터페이스, 제약, 인수기준	업무 요구, 개선 요구, 사용자 요구	아키텍처, 상세 설계, 데이터 설계, API 설계
관계	요구사항정의서의 사용자 요구가 SRS로 정제되고, SRS는 설계서와 테스트 케이스의 기준이 된다.

나. 전통적 SRS와 애자일 요구관리 비교

구분	전통적 SRS	애자일 요구관리
문서 형태	상세하고 공식적인 문서 중심	사용자 스토리, 백로그, 인수조건 중심
변경 대응	기준선 설정 후 변경관리 절차 적용	반복 주기마다 우선순위와 범위 조정
장점	계약, 검수, 감리, 대규모 프로젝트 통제에 유리	변화 대응과 사용자 피드백 반영에 유리
위험	초기 문서가 무거워지고 변경 대응이 느릴 수 있음	비기능 요구와 전체 추적성이 약해질 수 있음
적용 방향	프로젝트 성격에 따라 문서 상세도는 조정하되, 요구의 명확성·검증가능성·추적성은 반드시 유지해야 한다.

다. 기능 요구사항과 비기능 요구사항 비교

구분	기능 요구사항	비기능 요구사항
의미	시스템이 수행해야 하는 기능과 처리	시스템이 만족해야 하는 품질 속성과 제약
예시	회원가입, 주문등록, 결제승인, 보고서 출력	응답시간, 보안, 가용성, 확장성, 접근성
검증 방식	기능 테스트, 시나리오 테스트, 인수 테스트	성능 테스트, 보안 점검, 장애 테스트, 사용성 평가
누락 시 영향	기능 미구현, 업무 처리 불가	성능 저하, 보안 취약, 운영 불안정, 사용자 불만

라. 발전전망

• 요구사항 관리도구 고도화: 요구사항, 설계, 테스트, 결함, 배포를 통합 관리하는 ALM 도구 활용이 확대될 것이다.
• AI 기반 요구사항 분석: 모호한 문장 탐지, 중복 요구 식별, 테스트 케이스 자동 생성, 영향도 분석에 AI가 활용될 것이다.
• 애자일·DevOps 연계 강화: SRS는 무거운 문서보다 백로그, 인수조건, 테스트 자동화와 연결되는 살아있는 요구관리 체계로 발전할 것이다.
• 비기능 요구 중요성 증가: 보안, 개인정보, 성능, 접근성, 복원력, AI 윤리 요구가 명세서에 더 중요하게 반영될 것이다.
• 모델 기반 요구공학 확대: 요구사항을 자연어 문서뿐 아니라 모델, 시나리오, 상태전이도, 프로토타입으로 함께 표현하는 방식이 강화될 것이다.
• 계약·분쟁 예방 기능 강화: 외주 개발과 공공 사업에서 SRS의 인수기준과 변경관리 기준이 더욱 중요한 관리 요소가 될 것이다.

마. 기술사 답안 정리

요구사항명세서 답안은 “정의 → 등장배경 → SRS 품질 게이트형 구성도 → 구성요소 → 작성 절차 → 품질 특성 → 추적성과 변경관리 → 실무 적용 → 비교분석 → 발전전망” 순으로 작성하면 안정적이다. 반드시 포함해야 할 키워드는 기능 요구사항, 비기능 요구사항, 외부 인터페이스, 데이터 요구, 제약조건, 인수기준, 완전성, 일관성, 명확성, 검증가능성, 추적성, RTM, 기준선, 변경관리이다. 특히 SRS가 설계·구현·테스트·검수까지 연결되는 기준 문서라는 점을 강조해야 좋은 답안이 된다.

답안 암기 포인트: “SRS = 요구사항을 명확·검증가능·추적가능하게 정리하여 설계·구현·테스트·검수의 기준선으로 삼는 문서”로 정리하면 된다.

요구사항명세서는 소프트웨어 개발의 시작점이자 검수 기준이며, 요구사항 오류로 인한 재작업과 분쟁을 줄이는 핵심 산출물이다.
향후에는 ALM, AI 기반 요구분석, 애자일 백로그, 자동 테스트, 비기능 요구 강화와 결합되어 살아있는 요구관리 체계로 발전할 것이다.

블로그: 기술사 학습노트 · imt-log.tistory.com

← [소프트웨어공학] 목록