요구사항 명세 기법

glorypang 2025. 10. 28. 20:27

728x90

SMALL

정형 명세기법

정의: 요구사항을 수학적 구조(집합, 관계, 논리, 함수)와 형식 문법으로 서술하여, 일관성·정확성·완전성을 검증(증명/모델체킹)할 수 있게 하는 방법.
왜 쓰나 (장점)
- 모호성 제거(자연어 해석 차이 최소화)
- 검증 가능(정리 증명, 모델 체킹, 시뮬레이션)
- 변경 영향 분석이 엄밀
- 안전/미션 크리티컬 도메인에서 신뢰성 확보
한계/주의
- 학습 곡선이 있음(수학/논리 표기)
- 초기 작성 비용↑ → 핵심/고위험 영역에 선택 적용 권장
- 이해관계자 커뮤니케이션을 위해 자연어 요약/도표 병행 필요
대표 접근 분류
- 모델 기반(Model-based): 상태와 불변식을 중심으로 시스템 모델화
  예) Z, VDM, B-Method
- 논리/제약 기반(논리식으로 속성 기술)
  예) Alloy(1차 논리+관계 모델체킹), TLA+ (시간 논리), CSP/π-연산
- 프로세스/동시성 중심
  예) Petri Net, CSP
언제 쓰나
- 안전/금융/의료/항공/원전/철도처럼 오류 비용이 큰 핵심 로직
- 동시성/분산/프로토콜처럼 상태 폭발·경계조건이 많은 영역
- 규칙 엔진/정산/권한 등 복잡한 제약·불변식이 핵심인 모듈

정의: 수학적 표기 없이 자연어·그림·예시로 요구를 기술하는 방식. 이해관계자와의 의사소통·초기 합의에 강함.
대표 형태
- 자연어 요구사항 문서(SRS 초안): 평문 서술(“시스템은 …해야 한다”).
- 시나리오/스토리(시나리오 기반 명세): 상황·행위 흐름을 이야기 형식으로 기술.
- 유스케이스(간략형/서술형): 액터·목표·기본/대체 흐름을 자연어로 정리 (완전 정형은 아님 → 반정형에 가깝지만 비정형 범주로 함께 사용됨).
- 프로토타이핑/와이어프레임/스토리보드: 화면 목업으로 요구를 시각화.
- 인터뷰/워크숍/관찰/설문 산출물: 회의록, 인사이트 노트.
- 페르소나/사용자 여정 맵(Journey Map): 사용자 관점 요구 맥락 정리.
- 결정표/결정트리(라이트): 간단 규칙을 표/트리로 표현(정형 전 단계).
장단점
- 장점: 빠르고 이해하기 쉬움, 비기술 이해관계자 참여 용이, 초기 탐색/합의에 최적.
- 단점: 모호성/중복/불일치 위험↑, 추적성과 검증성 낮음 → 정형/반정형 보완 필요.
언제 쓰나
- 프로젝트 초기 탐색/도메인 이해 단계
- UI/업무 흐름을 빠르게 맞춰볼 때
- 다수 이해관계자와 공감대 형성이 우선일 때

728x90

LIST