Requirements & Spec

1. Overview

요구사항 및 명세(Requirements & Specification, REQ)는 고객이 모호하게 던진 "빠르고 좋은 시스템 만들어주세요"라는 말을, 엔지니어가 코드로 옮길 수 있는 **수학적으로 엄밀하고 검증 가능한 계약(Contract)**으로 번역하는 소프트웨어 공학의 첫 단추를 다룹니다.

개발 실패의 80%는 코딩을 못해서가 아니라, 처음부터 '엉뚱한 것'을 만들었기 때문에 발생합니다. 학습자는 현업의 숨겨진 니즈를 캐내는 도출(Elicitation) 기법부터, 그 니즈를 시스템이 무엇을 할지(기능 요구사항)와 어떻게 견딜지(비기능 요구사항)로 쪼개는 분석 과정을 배웁니다. 나아가 IEEE 830 표준이나 사용자 스토리(User Story) 같은 규격화된 문서로 명세(Specification)하고, 요구사항이 바뀌었을 때 소스 코드의 어느 줄이 영향을 받는지 추적(Traceability)하는 거시적 통제력을 확보합니다.

2. Scope & Boundaries

In-Scope

• 요구사항 추출과 분석 (Elicitation & Analysis): 인터뷰, 유스케이스(Use Case), 도메인 모델링, 기능적(Functional) vs 비기능적(Non-functional) 요구사항의 분리.
• 요구사항 명세 (Specification): SRS(Software Requirements Specification) 표준, BDD(Behavior-Driven Development) 시나리오 작성, 사용자 스토리(User Story) 매핑.
• 검증 및 확인 (Verification & Validation, V&V): "요구사항 자체가 맞는가?"를 따지는 타당성 조사, 수락 기준(Acceptance Criteria).
• 요구사항 추적 및 변경 관리 (Management): RTM(Requirements Traceability Matrix)을 통한 전 주기 추적성 확보, 변경 제어 위원회(CCB)의 역할.

Out-of-Scope

• 코드 레벨의 단위 테스트 구현: 수락 기준을 텍스트로 적는 것을 넘어, JUnit이나 PyTest 코드를 짜는 행위 $\rightarrow$ 09-04. QA & Quality Assurance 영역으로 위임.
• 세부적인 시스템 아키텍처 다이어그램: 요구사항을 기반으로 마이크로서비스를 나누고 UML 클래스를 그리는 작업 $\rightarrow$ 09-03. Architecture & Design 영역으로 위임.

Boundaries

• REQ vs. Testing (09-04): REQ가 '이 시스템이 통과해야 할 객관적 기준(수락 조건)'을 글로 적어내는 '문제 출제자'의 역할이라면, Testing은 그 문제지를 들고 실제 코드를 실행시켜 채점하는 '시험 감독관'의 역할입니다. 명세가 똑바로 안 되어 있으면 테스터는 무엇이 버그인지조차 알 수 없습니다.

3. Counterexample

• "알아서 잘"이라는 저주 (Vagueness Fallacy): 명세서에 "사용자가 많아도 시스템이 안 끊기게 해주세요"라고 적어놓고 개발을 시작하는 행위. 이는 엔지니어링 명세가 아니라 소설입니다. 올바른 명세는 **"동시 접속자 10,000명 상황에서 99%의 API 요청이 200ms 이내에 응답해야 한다"**처럼 숫자로 측정 및 **테스트 가능(Testable)**해야 합니다. 측정할 수 없는 요구사항은 구현할 수도 없고, 완성(Done)을 증명할 수도 없습니다.
• 추적 불가능한 요구사항 (Orphan Requirement Fallacy): 코드를 짜다가 개발자 마음대로 '있으면 좋을 것 같은 기능(Gold Plating)'을 슬쩍 집어넣거나, 반대로 명세서에는 있는데 코드에는 구현되지 않은 기능이 방치되는 현상. 모든 소스 코드와 테스트 케이스는 반드시 **요구사항 식별자(ID)**로 역추적(Traceability)되어야 합니다. RTM 매트릭스에 연결되지 않은 잉여 코드나 누락된 기능은 설계의 무결성을 파괴하는 주범입니다.

4. Prerequisites

• SDLC 및 프로세스 (Basic): 애자일에서는 요구사항이 '스프린트 백로그' 형태로 쪼개지고, 폭포수에서는 '거대한 SRS 문서'로 떨어지는 공정(Process)의 차이를 알아야 명세법을 맞출 수 있습니다. (09-01. SDLC)
• 자료 구조 및 데이터베이스 설계 (Recommended): 요구사항에 등장하는 '명사'들을 도메인 엔티티(Entity)로 추출하려면 기본적인 데이터 모델링 감각이 필요합니다. (06. DPG)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 요구사항의 추출과 분류 (Elicitation & Classification)

• Why to Learn: "버튼을 크게 만들어주세요"라는 피상적 요구 뒤에 숨은 "노인 사용자가 눈이 침침해서 클릭을 못 한다"는 진짜 문제를 찾아내기 위함입니다.
• What to Learn:
  • Concepts: 도출(Elicitation) 기법 (인터뷰, 설문, 관찰, 프로토타이핑).
  • Skills: 기능적 요구사항(Functional Req) vs 비기능적 요구사항(Non-Functional Req: 보안, 성능, 가용성).
  • Tools: 피그마(Figma) 프로토타입.
  • Trade-offs: 요구사항을 초반에 완벽하게 확정 지으려다 시간을 다 보내는 '분석 마비(Analysis Paralysis)' vs 대충 듣고 코딩부터 했다가 나중에 갈아엎는 '재작업(Rework) 비용'.
• How to Learn:
  • 1단계: "넷플릭스 같은 동영상 스트리밍 서비스"를 만든다고 가정하고, 브레인스토밍을 통해 기능적 요구(예: 영상 검색, 재생, 이어보기)와 비기능적 요구(예: 4K 해상도 로딩 2초 이내, 동시 접속 100만 명)를 포스트잇으로 분류합니다.
  • 2단계: 그중 "추천 시스템을 만들어달라"는 요구사항에 대해, 텍스트로만 설명할 때 생기는 오해를 막기 위해 와이어프레임(Wireframe) 프로토타입을 그려 고객과 소통하는 시뮬레이션을 수행합니다.
• Implement: 자신이 기획 중인 사이드 프로젝트의 기능을 FURPS+(기능, 사용성, 신뢰성, 성능, 지원성) 프레임워크에 맞춰 20줄 이상의 요구사항 목록으로 세분화한 초안 작성.

Recommended

Core Topic 02: 요구사항 명세서와 모델링 (SRS & Modeling)

• Why to Learn: 개발자 A, B, C가 명세서를 읽었을 때 서로 다른 상상을 하지 않도록, 다의성이 배제된 단일 진실의 원천(SSOT)을 작성하기 위해서입니다.
• What to Learn:
  • Concepts: 명세(Specification)의 8대 품질 속성 (명확성, 완전성, 일관성, 테스트 가능성 등), 유스케이스(Use Case).
  • Skills: IEEE 830 표준 기반의 SRS 문서 작성, 애자일 사용자 스토리(User Story) 템플릿("As a , I want <goal/desire> so that ").
  • Tools: Confluence, Jira.
  • Trade-offs: 수백 페이지에 달하는 엄격한 IEEE 830 문서가 주는 법적/구조적 안정성 vs 포스트잇 하나에 적힌 유저 스토리의 소통 중심적인 민첩함.
• How to Learn:
  • 1단계: "사용자는 로그인을 할 수 있다"라는 문장을, "사용자가 이메일과 비밀번호를 입력하고 확인 버튼을 누르면, 시스템은 DB와 대조하여 일치 시 메인 화면으로 리다이렉트한다. 실패 시 3회까지 재시도를 허용하며..."와 같이 상세한 유스케이스 시나리오(기본 흐름/예외 흐름)로 팽창시킵니다.
  • 2단계: 애자일 방식으로 전환하여, 이를 "나는 [보안을 중시하는 유저]로서 [안전하게 로그인]하길 원한다, 왜냐하면 [내 결제 정보를 보호하기 위해]"라는 사용자 스토리로 쪼개고 뒷면에 수락 기준(Acceptance Criteria)을 명시합니다.
• Implement: 특정 도메인(예: 온라인 도서관)의 대출 기능에 대해, 정상 흐름 1개와 예외 흐름(예: 연체자, 재고 없음) 3개를 포함한 엄격한 유스케이스 명세서 작성.

Practical

Core Topic 03: 요구사항 검증과 확인 (V&V in Requirements)

• Why to Learn: 이미 코드를 수만 줄 짠 뒤에 아키텍처를 뒤엎는 데 드는 비용(100배)을 막기 위해, 문서 단계에서 모순을 잡아내기 위함입니다.
• What to Learn:
  • Concepts: 검증(Verification: 우리가 제품을 올바르게 만들고 있는가?) vs 확인(Validation: 우리가 올바른 제품을 만들고 있는가?).
  • Skills: 요구사항 인스펙션(Inspection), 워크스루(Walkthrough), 수락 기준(Acceptance Criteria) 정의.
  • Tools: 요구사항 리뷰 체크리스트.
  • Trade-offs: 요구사항에 "초 단위의 실시간 데이터 동기화"를 적어두고 승인하는 순간, 이 문장 한 줄 때문에 백엔드 아키텍처에 카프카(Kafka)와 웹소켓(WebSocket)이 강제 도입되어 인프라 비용이 수십 배 폭증하는 나비효과.
• How to Learn:
  • 1단계: 동료가 쓴 요구사항 명세서를 읽고, "관리자는 모든 사용자의 비밀번호를 볼 수 있어야 한다"(보안 위반)라거나 "속도가 엄청 빨라야 한다"(테스트 불가) 같은 독소 조항과 논리적 모순을 빨간펜으로 첨삭하는 인스펙션(Inspection)을 진행합니다.
  • 2단계: 해당 요구사항이 완료되었음을 판정하기 위한 BDD(Behavior-Driven Development) 형식의 GIVEN-WHEN-THEN 수락 시나리오를 작성합니다.
• Implement: 작성된 요구사항 명세서를 기반으로, "이 조건이 통과되면 개발이 완료된 것으로 간주하고 잔금을 치르겠다"고 합의할 수 있는 객관적인 수락 테스트(Acceptance Test) 시나리오 5개 도출.

Advanced

Core Topic 04: 요구사항 추적성과 변경 통제 (Traceability & Change Management)

• Why to Learn: 고객이 "이 요구사항 하나만 취소해 주세요"라고 할 때, 그 요구사항과 얽혀 있는 수백 개의 소스 코드와 테스트 케이스를 누락 없이 솎아내기 위해서입니다.
• What to Learn:
  • Concepts: 요구사항 추적성 매트릭스(RTM: Requirements Traceability Matrix), 베이스라인(Baseline).
  • Skills: 정방향 추적(요구사항 $\rightarrow$ 설계 $\rightarrow$ 코드 $\rightarrow$ 테스트)과 역방향 추적의 물리적 연결, 변경 영향 분석(Impact Analysis).
  • Tools: Jira Requirement Links, Excel RTM.
  • Trade-offs: 함수 하나를 짤 때마다 RTM 시트에 요구사항 ID를 기록해야 하는 극악의 행정적 오버헤드 vs 의료/항공 소프트웨어에서 소스 코드 한 줄이 어떤 요구사항 때문에 존재하는지 100% 입증하지 못하면 승인이 거절되는 규제 컴플라이언스(Compliance).
• How to Learn:
  • 1단계: 엑셀을 열고 열(Column)에 [요구사항 ID - 설계 문서 장절 - 클래스/메서드 이름 - 테스트 케이스 ID]를 만들어, 기능 하나가 생명 주기 전체를 관통하는 연결 고리(Matrix)를 시각화합니다.
  • 2단계: 고객이 "결제 수단에서 암호화폐를 빼주세요"라고 변경(Change Request)을 요청했을 때, RTM을 역추적하여 암호화폐와 관련된 API 컨트롤러, DB 스키마, 결제 실패 테스트 케이스를 모조리 찾아내어 '변경 영향도 보고서'를 작성하는 시뮬레이션을 수행합니다.
• Implement: GitHub Issue나 Jira를 활용하여, Issue(요구사항) $\rightarrow$ Pull Request(코드) $\rightarrow$ GitHub Action(테스트)가 하나의 ID 번호로 묶여서 상태가 추적되도록 자동화된 추적성(Traceability) 파이프라인 셋업 가이드.

7. Terminology

8. References

Primary References

• [P2] SWEBOK v4.0 - Software Requirements — International engineering standard.
• [P5] SFIA v9 - Requirements Definition and Management — Industry specific skills.

Secondary References

• [Software Requirements (3rd Edition)] Karl Wiegers — The definitive guide.
• [Writing Better Requirements] Ian Alexander — Practical specification advice.

Industry References

• [IEEE Standard 830-1998] — Recommended Practice for SRS (Historical Guide).
• [The Strangler Fig Pattern in Requirements] — Adapting reqs for modernization.

9. Final Checklist

Primary Checklist

• 비즈니스 사용자의 '모호한 언어'를 '기술적으로 검증 가능한 명세'로 100% 변환 가능한가? (P2)
• 작성된 요구사항이 SRS 표준 템플릿(IEEE 830 등)을 따르며, 모순되는 항목이 없는가? (P2)

Secondary Checklist

• 모든 요구사항에 고유 ID가 부여되어 있으며, 이를 테스트 케이스와 1<1로> 매핑하는 RTM을 구축했는가?
• 시스템의 성능 목표(비기능 요구사항)가 구체적인 측정 지표(Latency, Throughput)와 함께 명시되었는가?

Industry Checklist

• 요구사항 변경 시, 영향 분석(Impact Analysis)을 통해 수정 범위를 사전에 물리적으로 예측할 수 있는가? (SFIA)
• 고객 수락 기준(Acceptance Criteria)이 명세 단계에서 확정되어 구현 완료 여부를 객관적으로 판단할 수 있는가?