Functional Non-functional Requirement
3줄 요약
- Functional Requirement는 시스템이 사용자에게 제공해야 하는 행동, API, 상태 전이를 정의한다.
- Non-functional Requirement는 그 행동이 어느 정도의 latency, throughput, availability, durability, security, retention으로 동작해야 하는지 정의한다.
- 좋은 요구사항 리뷰는 기능 목록을 API 계약, SLO, 제약, 가정, 검증 방법으로 바꿔 설계 선택의 기준을 만든다.
핵심 정리
- 기능 요구사항은 “무엇을 할 수 있어야 하는가”를 다룬다.
- 비기능 요구사항은 “얼마나 빠르게, 얼마나 많이, 얼마나 안정적으로, 어떤 조건에서 해야 하는가”를 다룬다.
- 제약은 반드시 지켜야 하는 조건이고, 가정은 아직 검증되지 않은 임시 전제다.
- API 계약은 성공 응답뿐 아니라 실패, 중복 요청, pending, 취소, 조회 가능 시점을 포함한다.
- SLO는 설계 리뷰의 기준이며, 알림과 운영 지표로 이어져야 한다.
- 요구사항이 모호하면 cache, queue, replica, shard 같은 선택의 옳고 그름을 판단할 수 없다.
판단 순서
- 기능을 endpoint, caller, 입력, 출력, 상태 전이로 나눈다.
- 기능별 성공, 실패, 중복, 취소, 재시도 시나리오를 적는다.
- latency, throughput, availability, retention, security 요구를 숫자로 바꾼다.
- 법규, 비용, 기술 스택, 일정처럼 바꿀 수 없는 제약을 표시한다.
- 트래픽, 사용자 행동, 데이터 증가량처럼 불확실한 값은 가정으로 분리한다.
- 가정을 검증할 방법과 검증 전 설계의 위험을 남긴다.
상세본 구성
01. Functional Requirement 정리 상세.md는 기능 범위, API 계약, 상태 전이, 제외 범위를 다룬다.02. Non-functional Requirement 상세.md는 품질 속성을 SLO와 설계 선택으로 연결한다.03. Latency Throughput Availability 상세.md는 p95 budget, peak 처리량, 가용성 계산을 다룬다.04. Constraint Assumption 질문법 상세.md는 제약과 가정을 분리하고 검증 계획을 세우는 법을 다룬다.05. 요구사항 리뷰 템플릿 상세.md는 실제 설계 리뷰에서 빠지기 쉬운 항목을 템플릿으로 고정한다.
헷갈리는 지점
- 기능 요구사항과 API 목록을 같은 것으로 보기 쉽다. API는 기능을 노출하는 수단일 뿐이다.
- 핵심은 사용자 결과, 상태 전이, 실패 응답, 제외 범위를 함께 정의하는 것이다.
- 비기능 요구사항을 “빠르게”, “안정적으로”처럼 형용사로 남기기 쉽다.
- 핵심은 p95, QPS, error budget, 보존 기간, 복구 목표처럼 측정 가능한 기준으로 바꾸는 것이다.
- 가정을 사실처럼 쓰기 쉽다. 설계가 깔끔해 보이기 때문이다.
- 핵심은 가정임을 표시하고, 언제 어떤 데이터로 검증할지 정하는 것이다.
확인 질문
- 확인 질문: Functional Requirement와 Non-functional Requirement의 차이는 무엇인가?
- 답변: Functional은 시스템이 해야 하는 행동이고, Non-functional은 그 행동의 품질 기준과 운영 조건이다.
- 확인 질문: 요구사항을 숫자로 바꾸는 이유는 무엇인가?
- 답변: latency, throughput, availability 같은 기준이 있어야 cache, queue, replica, timeout 같은 선택을 평가할 수 있기 때문이다.
- 확인 질문: 제약과 가정을 분리해야 하는 이유는 무엇인가?
- 답변: 제약은 설계가 반드시 지켜야 하고, 가정은 검증 실패 시 설계를 바꿀 수 있어야 하기 때문이다.
참고 자료 기준