요구사항 명세 기법 (Requirements Specification Techniques)

**요구사항 명세(要求事項明細)**란
요구공학 과정에서 도출·분석된 요구사항을
개발자와 사용자가 공통으로 이해할 수 있는 형태로 문서화하는 단계를 말한다.

즉, 사용자의 요구를 기술적 언어로 바꿔
개발의 기준이 되는 “요구사항 명세서(SRS, Software Requirements Specification)”를 만드는 과정이다.

이 명세서는
소프트웨어 설계·구현·테스트의 기준이 되기 때문에
정확성, 명확성, 완전성, 일관성이 핵심 품질 요소다.

요구사항 명세의 가장 큰 목적은
**“사용자의 요구를 구체적이고 모호함 없이 표현하는 것”**이다.

이를 통해 개발자는 명확한 설계 기준을 세울 수 있고,
사용자와의 오해나 요구 해석 오류를 줄일 수 있다.

요구사항 명세는 크게 두 가지 방식으로 구분된다.

이 둘은 표현 방법과 활용 목적이 다르다.

비정형 명세는
일상적인 언어나 그림, 표기법 등을 활용해 요구사항을 표현하는 기법이다.
즉, 수학적 공식이 아닌 자연어 중심의 기술 방식이다.

이 방법은 이해하기 쉽고, 커뮤니케이션에 유리하지만
표현이 주관적이라 모호성이 생기기 쉽다.

비정형 명세 기법의 주요 예시는 다음과 같다.

자연어 기술(Natural Language Description)
일반 문장으로 요구사항을 서술하는 방법.
가장 간단하지만 모호한 표현이 발생하기 쉽다.
구조적 명세(Structured Specification)
데이터 흐름도(DFD), 자료사전(DD), 구조 차트 등을 이용하여
시스템의 처리 구조를 시각적으로 표현한다.
유스케이스 다이어그램(Use Case Diagram)
사용자의 관점에서 시스템의 기능을 표현하는 UML 기반 도식화 방법.
시나리오 명세(Scenario-Based Specification)
실제 사용 흐름을 이야기 형태로 기술.
예: “사용자가 로그인 버튼을 누르면 시스템은 입력값을 검증한다.”

정리하자면,
비정형 명세는 “읽기 쉽고, 빠르게 이해되지만 모호성이 크다.”

정형 명세는
수학적 기호, 논리식, 상태 전이 모델 등 형식화된 언어를 이용해 요구사항을 기술하는 기법이다.

자연어 표현의 모호함을 없애고,
요구사항의 정확성과 일관성을 보장하기 위해 사용된다.

정형 명세는 수학적 기초(집합론, 논리, 상태기계 등)에 기반하기 때문에
자동 검증이나 테스트 생성에도 활용된다.

정형 명세 기법의 주요 예시는 다음과 같다.

Z 명세 기법(Z Notation)
집합론(Set Theory)과 1차 논리(First-Order Logic)에 기반한 명세 언어.
시스템의 상태와 연산을 수학적으로 정의한다.
VDM (Vienna Development Method)
시스템을 수학적으로 모델링하여 요구사항을 표현하고 검증하는 방법.
Petri-Net (페트리 네트)
상태와 이벤트를 그래프 형태로 나타내는 수학적 모델.
동시성(Concurrent)과 병렬 처리 시스템 표현에 유용하다.
State Transition Diagram (상태 전이도)
시스템의 상태 변화(입력 → 처리 → 출력)를 도식화한 정형적 모델.

정형 명세의 장점은 정확성, 일관성, 자동 검증 가능성,
단점은 전문적 지식과 수학적 이해가 필요하다는 점이다.

요약하자면,

비정형 명세는 “쉽게 쓴 설명서”라면,
정형 명세는 “수학적으로 증명 가능한 기술서”이다.

요구사항의 복잡도와 프로젝트의 성격에 따라 기법을 달리 선택한다.

실제 프로젝트에서는 두 가지 방식을 **혼합(Hybrid)**하여 사용하는 경우가 많다.

“요구사항 명세 기법은 도출된 요구사항을 명확하고 구체적으로 기술하기 위한 기법으로,
비정형 명세 기법은 자연어나 도식적 표현을 사용하고,
정형 명세 기법은 수학적, 논리적 기법을 이용하여 표현한다.”

시험 키워드:
비정형 = 자연어, 도표, 시나리오 / 정형 = 수학, 논리, 상태 전이, Z, VDM, Petri-Net

🪶 단어 정리 (한국식 한자 + 영어 어원 + 뜻풀이)

요구사항(要求事項) / Requirement
구할 요(要), 구할 구(求), 일 사(事), 항목 항(項)
: 사용자가 시스템에 바라는 기능이나 조건. 영어 require는 라틴어 requirere(다시 찾다, 요구하다)에서 유래.

명세(明細) / Specification
밝을 명(明), 자세할 세(細)
: 어떤 내용을 구체적이고 세밀하게 기술하는 것. 영어 specify는 라틴어 specere(보다)에서 유래.

정형(定型) / Formal
정할 정(定), 틀 형(型)
: 일정한 형식이나 규칙에 맞춘 상태. 영어 formal은 라틴어 forma(형태, 구조)에서 유래.

비정형(非定型) / Informal
아닐 비(非), 정할 정(定), 틀 형(型)
: 형식에 구애받지 않고 자유롭게 표현된 상태.

기법(技法) / Technique
재주 기(技), 법 법(法)
: 일정한 목적을 이루기 위한 방법이나 기술. 영어 techne(기술, 숙련)에서 유래.

논리(論理) / Logic
논할 론(論), 다스릴 리(理)
: 사고의 법칙과 근거를 연구하는 학문. 영어 logos(이성, 말)에서 유래.

상태(狀態) / State
형상 상(狀), 모양 태(態)
: 사물이나 시스템이 일정 시점에서 가지고 있는 조건.

전이(轉移) / Transition
구를 전(轉), 옮길 이(移)
: 한 상태에서 다른 상태로 바뀌는 과정. 영어 transire(건너가다)에서 유래.

요구공학 (Requirements Engineering) (0)	2025.10.11
기능 요구사항과 비기능 요구사항 (0)	2025.10.11
하드웨어 구성 파악과 이중화(二重化) – 서버는 왜 ‘복제’를 두려워하지 않는가 (0)	2025.10.11
현행 시스템을 파악하는 과정 – 구조를 읽고, 논리를 해부하다 (0)	2025.10.11
XP(eXtreme Programming) 개발방법론: “극단의 단순함으로 품질을 높이다” (0)	2025.10.11