요구 명세

요구 분석에서 찾아낸 요구사항을

빠짐없이, 모호하지 않게, 검증 가능하게

문서로 정리하는 작업이 ‘요구 명세’이다.

 

개발 대상 시스템이 수행해야 할 모든 기능,

구현 시 고려해야 할 제약 조건,

사용자·개발자가 합의한 성능/품질 기준 등을

명확히 적어 “같은 목표를 바라보게 만드는 문서”가 된다.

---

1) 요구 분석 명세서(SRS)란?

요구 명세를 ‘스펙(spec)’ 형태로 정리한 문서를

요구 분석 명세서(SRS) 라고 한다.

(=Software Requirement Specification)

SRS는 프로젝트 산출물 중에서도 가장 핵심 문서로,

사용자·분석가·개발자·테스터 모두에게 공통 목표와 기준을 제공한다.

 

What vs How: SRS의 핵심 원칙

SRS는 시스템이 어떻게(How) 구현될지가 아니라,

무엇(What)을 수행해야 하는지를 기술한다.

• “무엇을” 제공해야 하는가
  : 기능, 품질, 제약, 인터페이스, 데이터 요구
• “어떻게” 만들 것인가
  : 특정 구조, 특정 알고리즘, 구현 방식, 설계 선택

요약하면, SRS는 “해결 방법”이 아니라

“달성해야 할 목표와 요구”를 적는 문서이다.

---

2) SRS 표준 목차(권고 형태)

요구 명세서는 읽는 사람이 빠르게 찾고,

변경 영향도 분석이 쉽도록

계층 구조로 구성하는 것이 일반적이다.

대표적으로 다음과 같은

항목 구성이 권고된다

(IEEE 830 기준 목차 형태).

 

SRS 목차 예시

대분류	소항목
1. 소개	1.1 SRS의 목적 / 1.2 제품의 범위 / 1.3 정의·동의어·약어 / 1.4 참조 문서 / 1.5 개요
2. 일반적인 기술사항	2.1 제품의 개관 / 2.2 제품의 기능 / 2.3 사용자 특성 / 2.4 제약사항 / 2.5 가정 및 의존성
3. 상세한 요구사항	3.1 외부 인터페이스 / 3.2 기능 요구 / 3.3 성능 요구 / 3.4 논리 DB 요구 / 3.5 설계 제약 / 3.6 시스템 속성 / 3.7 상세요구 사양 구성
4. 추가 정보	4.1 목차 / 4.2 색인

---

3) 요구 명세서 작성 방법(작성 원칙)

요구 명세는 “대충 알아듣는 문서”가 아니라,

합의의 문서이자 검증의 기준이 되어야 한다.

따라서 작성 시 아래 원칙이 중요하다.

 

작성 원칙 체크리스트

시스템이 수행할 모든 기능과 시스템에 영향을
미치는 제약 조건을 명확히 기술한다.

고객과 개발자 모두가 이해하기 쉬운
문장으로 간결하게 작성한다.

모든 요구사항은 반드시
검증 가능(Verifiable) 해야 한다.
↓
 품질 기준, 측정 방법,
검증 방법/기준(테스트 기준)을 함께 명시한다.

요구사항은 시스템의 외부에서
보이는 행위(What) 중심으로 쓴다.
↓
특정 구조/알고리즘 같은
설계 내용을 요구사항 문서에 섞지 않는다.

변경과 추적이 쉽도록 요구사항을
계층적으로 구성한다.

요구사항을 참조하기 쉽도록
고유 식별자(ID) 를 부여해 번호화한다.

모든 요구사항이 중요도가 같지 않으므로
우선순위(Priority) 를 정한다.

---

4) “좋은 요구사항” 문장 형태 예시

요구사항은 “테스트로 확인 가능한 형태”여야 한다.

가장 흔한 실수는 추상적인

표현(빠르게, 충분히, 안정적으로) 을 쓰는 것이다.

 

예시 비교

• 나쁜 예
  : 시스템은 빠르게 응답해야 한다.
• 좋은 예
  : 시스템은 사용자의 검색 요청에 대해
    3초 이내에 응답해야 한다.

이처럼 정량화(숫자/기준/조건)가

들어가면 검증 가능성이 생긴다.

---

5) 요구 분석 명세서 작성 시 유의사항(핵심 6가지)

요구 명세서는 사실상 사용자와

개발자 사이의 “계약서” 같은 문서이다.

그래서 아래 사항을 반드시 지켜야 한다.

1. 누구나 이해 가능하게 작성한다.
- 사용자와 개발자 모두가 “무엇에 동의했는지” 명확히 읽혀야 한다.

2. 요구사항은 쌍방이 동의하고 이해한 내용이어야 한다.
- 사용자는 불가능하거나 비용 초과되는 무리한 요구를 강요하면 안 된다.
- 개발자는 기능/일정/비용을 정확히 공유해야 한다.

3. 목표 시스템이 수행할 모든 기능을 정확히 기술한다.
- 기능 요구는 요구 명세서의 핵심이다.

4. 시스템에 영향을 주는 모든 제약 조건을 기술한다.
- 반응 시간, 목표 HW, 비용 상한, 사용자 특성, 특정 언어 사용 요구 등

5. 시스템 인수를 위한 테스트 기준을 제공해야 한다.
- “기대 수준”을 정량적으로 써야 한다.

6. 시스템 품질의 우선순위와 측정 방법을 명시한다.
- 어떤 시스템은 정확성이, 어떤 시스템은 속도/사용성이 더 중요할 수 있다.

---

마무리 정리

요구 명세(SRS)는 개발을 시작하기 전에

“모두가 같은 그림을 보게” 만드는 문서이다.

핵심은 한 문장으로 정리된다.

SRS는 How가 아니라 What을 쓴다.
그리고 모든 요구사항은 검증 가능해야 한다.

 

이 기준만 지켜도 “개발 중에 말 바뀌는 문제”,

“테스트 기준이 없는 문제”, “기능 누락” 같은 리스크가 크게 줄어든다.