소프트웨어 요구사항 명세서, 한 번에 이해하기
"만들어달라는 대로 만들었는데 왜 다르다고 하죠?" 개발하다 보면 이런 상황이 생긴다. 처음부터 뭘 만들지 글로 정확하게 정리해두면 이런 일이 줄어드는데, 그게 바로 소프트웨어 요구사항 명세서(SRS) 다. 핵심부터 한 줄로 정리하면 이렇다.
소프트웨어 요구사항 명세서 (SRS, Software Requirements Specification) = 만들 소프트웨어가 무엇을, 어떻게, 어느 수준으로 동작해야 하는지를 글로 정리한 문서
쉽게 비유하면
건축 설계도면이라고 생각하면 됨! 집 짓기 전에 "방은 몇 개, 화장실은 어디, 창문은 어느 방향"을 설계도에 다 적어두잖아. 그걸 보고 시공사가 집을 짓는다. 설계도 없이 "대충 예쁘게 지어주세요" 하면 의뢰인이랑 시공사가 서로 다른 집을 생각하고 있어서 나중에 다 뜯어고치게 된다.
SRS가 딱 그 설계도다.
- 설계도 없이 짓기 = 요구사항 없이 개발 → 나중에 다 뜯어고침
- 설계도 있는 공사 = SRS 기반 개발 → 방향이 명확하고 기준이 생김
완벽한 설계도가 없어도 착공은 할 수 있지만, 나중에 고치는 비용이 훨씬 크다. 그래서 미리 정리해두는 게 무조건 이득인 것 같음!
자세히
요구사항의 두 종류
SRS에서 다루는 요구사항은 크게 두 가지로 나뉜다.
기능 요구사항 (Functional Requirements)
"시스템이 무엇을 해야 하나"에 대한 것. 실제 기능들이다.
- 유저는 이메일과 비밀번호로 로그인할 수 있다
- 로그인 실패 3회 시 계정이 5분간 잠긴다
- 관리자는 유저 목록을 조회·삭제할 수 있다
비기능 요구사항 (Non-Functional Requirements)
"시스템이 얼마나 잘 해야 하나"에 대한 것. 품질 기준들이다.
- 응답 시간은 1초 이내여야 한다 (성능)
- 동시 접속자 1만 명을 버텨야 한다 (확장성)
- 개인정보는 암호화해서 저장해야 한다 (보안)
- 서비스 가용성 99.9% 이상 (안정성)
기능 요구사항은 "뭘 하냐", 비기능 요구사항은 "얼마나 잘 하냐" 같음!
SRS의 핵심 구성 요소
문서마다 조금씩 다르지만, 보통 이런 내용을 담는다.
1. 개요 (Introduction)
- 이 소프트웨어가 왜 만들어지는지
- 누가 쓰는 문서인지 (개발팀? 클라이언트?)
- 용어 정의 (헷갈리는 단어 미리 통일)
2. 전체 설명 (Overall Description)
- 제품이 뭔지, 어떤 맥락에서 쓰이는지
- 주요 사용자(User Type) 정의
- 제약 조건 (기술 스택, 예산, 법적 규정 등)
3. 기능 요구사항 (Functional Requirements)
- 기능 목록을 구체적으로 작성
- "~할 수 있다" 형태로 명확하게
4. 비기능 요구사항 (Non-Functional Requirements)
- 성능, 보안, 확장성, 가용성 기준
5. 외부 인터페이스 요구사항
- 연동할 외부 API, 결제 시스템 등
좋은 요구사항의 조건
요구사항을 쓸 때 이 조건을 지켜야 나중에 안 싸운다.
- 명확함 — "빠르게"가 아니라 "1초 이내"
- 측정 가능 — "많은 유저"가 아니라 "동시 접속자 1만 명"
- 실현 가능 — 기술적으로 불가능한 건 아닌지 확인
- 추적 가능 — 나중에 "이 기능 왜 만들었어?"에 답할 수 있게
모호한 요구사항이 제일 위험하다. "직관적인 UI" 같은 말은 읽는 사람마다 다 다르게 이해함!
실사용 예
실제로 SRS가 어떻게 쓰이는지 보면 이렇다.
사이드 프로젝트 PRD로 쓰이는 경우
스타트업이나 사이드 프로젝트에선 SRS보다 가벼운 PRD(Product Requirements Document) 로 많이 쓴다. 형식은 덜 딱딱하지만 담는 내용은 비슷하다. Notion 페이지 하나에 "이 기능은 이렇게 동작해야 한다"를 정리해두는 게 미니 SRS인 거다.
협업할 때 기준이 되는 경우
- 디자이너가 화면 그릴 때: "로그인 실패 3회 시 잠금" → 잠금 화면 UI 필요하다는 걸 알 수 있음
- 개발자가 구현할 때: "응답 1초 이내" → 성능 최적화 얼마나 해야 하는지 기준이 생김
- QA가 테스트할 때: 요구사항이 테스트 케이스가 됨. "로그인 3회 실패 → 잠겨야 한다" 그대로 테스트
클라이언트 외주 작업의 경우
요구사항 문서 없이 외주 받으면 나중에 "이건 말 안 했잖아요"가 계속 나온다. SRS나 PRD에 범위(Scope)를 명확히 적어두면 "계약한 것"이 생기는 거라 분쟁이 줄어드는 것 같음!
한 방 정리
| 구분 | 내용 |
|---|---|
| 한 줄 정의 | 만들 SW가 뭘 어떻게 해야 하는지 정리한 설계 문서 |
| 비유 | 건축 설계도면 |
| 두 종류 | 기능 요구사항(뭘 하냐) + 비기능 요구사항(얼마나 잘 하냐) |
| 좋은 요구사항 | 명확 + 측정 가능 + 모호하지 않음 |
| 실무 버전 | PRD (Product Requirements Document) |
쉽게 외우면 "만들기 전에 뭘 만들지 글로 합의하는 것" — 귀찮아도 미리 써두면 나중에 뜯어고치는 것보다 훨씬 싸게 먹히는 게 SRS 같음!
