Requirement Engineering & Analysis

1. Overview

요구사항 공학과 분석(Requirement Engineering & Analysis)은 "고객이 말한 것"과 "고객이 진짜로 원하는 것" 사이의 끔찍한 간극을 좁히고, 애매모호한 문장 덩어리들을 엔지니어가 코드로 짜낼 수 있는 명확하고 검증 가능한 수학적 명제로 번역해 내는 통역의 물리학을 해부합니다.

학습자는 "시스템이 빨라야 한다"는 쓰레기 같은 문장을 찢어버리고, "동시 접속자 10,000명일 때 99%의 응답이 200ms 이내여야 한다"로 깎아내는 비기능적 요구사항(NFR)의 정량화를 뜯어봅니다. 나아가 사용자(Actor)가 시스템과 어떻게 상호작용하는지 유즈케이스(Use Case)와 유저 스토리(User Story)로 묘사하는 행위 기반 분석을 장악합니다. 마지막으로, 요구사항이 바뀌면 코드 어디를 고쳐야 하는지 역추적(Traceability)하는 생명줄을 세워, 스파게티처럼 꼬인 요구사항-설계-코드의 사슬을 통제하는 추적성(Traceability) 관리 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Functional vs Non-Functional: 기능적 요구사항(결제, 로그인)과 비기능적 요구사항(성능, 보안, 가용성).
• User Story & Use Case: "As a [Role], I want [Goal], so that [Benefit]" 구문과 Actor-System 간의 시나리오.
• INVEST Criteria: 좋은 유저 스토리가 가져야 할 6가지 조건 (Independent, Negotiable, Valuable, Estimable, Small, Testable).
• Traceability Matrix: 요구사항 ID와 소스코드/테스트 케이스를 맵핑하여 변경 충격을 추적하는 2차원 매트릭스.

Out-of-Scope

• UML Class Diagram / ERD 설계: 시스템 내부의 정적인 데이터 구조와 객체 관계 설계 $\rightarrow$ 09-03 Architecture & Design 영역으로 위임.
• BDD(Behavior-Driven Development) 테스트 코드: Given-When-Then을 실제 자동화 테스트 코드로 작성하는 법 $\rightarrow$ 09-04 QA & Quality Assurance 영역으로 분리.

Boundaries

• 요구사항(Requirement) vs 설계(Design): 요구사항 공학의 황금률은 "시스템이 **무엇(What)**을 해야 하는지 명시하되, 어떻게(How) 할 것인지 지시하지 마라"입니다. "고객은 상품을 장바구니에 담을 수 있어야 한다(What)"는 요구사항입니다. "장바구니는 Redis 캐시를 써서 0.1초 안에 저장해야 한다(How)"는 설계입니다. 분석 단계에서 How가 튀어나오면 엔지니어의 아키텍처 선택권이 박탈당하는 아키텍처적 선 넘기(Boundary Violation)에 명확한 선을 긋습니다.

3. Counterexample

• 애매함의 파국 (Ambiguity Disaster): 기획서에 "관리자 페이지는 많은 데이터를 띄워도 버벅거리지 않아야 한다"라고 적혀 있습니다. 개발자는 100건을 띄우고 1초 만에 뜨니 완벽하다고 납품했습니다. 고객은 10만 건을 띄웠더니 서버가 뻗었다며 소송을 걸었습니다. "많은", "버벅거리지", "빠른" 같은 정량화되지 않은 형용사(Adjective)가 요구사항 문서에 침투하여 발생한 끔찍한 계약 붕괴입니다.
• 거대 유저 스토리의 폭발 (Epic Monster): PO가 유저 스토리를 하나 던져줍니다. "고객으로서, 나는 넷플릭스처럼 동영상을 보고 결제하고 리뷰를 남기고 싶다." 이 스토리는 개발자가 2주(Sprint) 안에 도저히 끝낼 수 없는 거대한 코끼리(Epic)입니다. 이 스토리를 작고 독립적으로(Small & Independent) 썰어내지 않아, 스프린트 마지막 날 "하나도 완성 못 했습니다"라는 변명을 낳게 한 요구사항 분할(Decomposition) 실패의 재앙입니다.

4. Prerequisites

• 소프트웨어 생명주기 (Basic): SDLC에서 요구사항 분석 단계의 위치. (09-01-01 SDLC Models)
• 도메인 지식의 이해 (Basic): 비즈니스 용어를 코드로 옮기기 위한 기본적 소통 능력.

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 무엇과 어떻게의 분리 (What vs How)

• Why to Learn: 고객은 자신이 진짜로 원하는 게 뭔지 모른 채 "여기에 버튼 달아주세요(How)"라고 요구합니다. 이대로 짰다가 쓸모없는 쓰레기가 되는 걸 막고, 진짜 문제(What)를 발굴해 내기 위함입니다.
• What to Learn:
  • Concepts: Elicitation (요구사항 도출), Analysis (분석), Functional Requirements (기능적 요구사항), Problem Domain vs Solution Domain.
  • Skills: "비밀번호 찾기 시 SMS로 인증번호를 쏘는 팝업을 만들어주세요(How)"라는 고객의 요구를, "사용자는 잊어버린 계정에 대한 접근 권한을 안전하게 복구할 수 있다(What)"로 치환하고, 이메일 링크나 소셜 로그인 같은 더 나은 솔루션을 역제안하는 Elicitation 설계.
• How to Learn:
  • 1단계: 고객의 착각: 포드의 명언입니다. "사람들에게 뭘 원하냐고 물었으면, '더 빠른 마차'를 원한다고 했을 겁니다." 고객은 문제(What: 빨리 가고 싶다)를 말하지 않고 자기가 아는 얄팍한 해결책(How: 빠른 마차)을 요구합니다.
  • 2단계: Why의 5번 추적 (5 Whys): 개발자는 앵무새처럼 마차를 만들면 안 됩니다. "왜 빠른 마차가 필요하죠?" $\rightarrow$ "서울에 빨리가야 하니까요." $\rightarrow$ "아하, 빠르고 지치지 않는 이동 수단(What)이 필요하군요! 마차 대신 자동차를(How) 제안합니다." 요구사항 공학은 고객의 입을 막고 뇌 속의 진짜 의도를 강제로 끄집어내는 심리전에 가깝다는 것을 해부합니다.
• Implement: 요구사항 문장 리팩터링 모사. Bad (How 침범): "유저 테이블의 Status 컬럼을 0에서 1로 업데이트하는 체크박스를 UI 좌측 상단에 배치한다." (엔지니어의 DB 설계와 UI 설계 권한 뺏음). Good (What 집중): "관리자는 블랙리스트 유저의 계정을 클릭 한 번으로 활성화(Activate)할 수 있어야 한다." (이후 DB를 어찌 짤지, 버튼을 어디 둘지는 설계자의 몫).

Recommended

Core Topic 02: 문학을 수학으로, 비기능적 요구사항 (Quantifying the NFRs)

• Why to Learn: 소프트웨어의 뼈대를 무너뜨리는 건 "버튼이 안 눌려요(기능)"가 아니라 "사람이 몰리니까 터져요(성능)"입니다. 아키텍처를 좌우하는 NFR을 엄밀한 숫자로 못 박아 계약의 모호함을 박살 내기 위함입니다.
• What to Learn:
  • Concepts: Non-Functional Requirements (NFR), Quality Attributes (품질 속성 - Performance, Availability, Security, Scalability), Quantifiable Metrics.
  • Skills: "시스템은 고가용성을 가져야 한다"는 쓰레기 문장을 "시스템의 연간 다운타임은 52.56분을 초과하지 않아야 한다 (99.99% Availability)"로 정량화하여 아키텍처(이중화) 규모를 산정하기.
• How to Learn:
  • 1단계: 기능(Functional) vs 비기능(Non-Functional): 기능은 "장바구니 담기"처럼 시스템이 '무엇을' 하는지입니다. 비기능은 그 장바구니가 '얼마나 빠르고, 얼마나 안전하게' 동작하는지를 따지는 시스템의 체력(Quality)입니다.
  • 2단계: 형용사의 척결: 요구사항 명세서에 "빠르게, 안전하게, 확장성 있게, 많은" 같은 단어가 들어가면 그 즉시 찢어버려야 합니다. '빠르다'의 기준은 고객은 0.1초, 개발자는 3초입니다.
  • 3단계: 수학적 임계값 (Threshold): "사용자 로그인 요청은 동시 접속 1,000명 상황에서 95번째 백분위수(p95) 기준 200ms 이내에 처리되어야 한다." 이렇게 숫자로 못을 박아야만, 아키텍트가 "이 정도 성능이면 인메모리 DB(Redis)를 깔아야겠네" 하고 하드웨어와 아키텍처 뼈대를 설계할 수 있는 절대적 근거가 됨을 뜯어봅니다.
• Implement: NFR 기반 아키텍처 추론 매트릭스 도출. Req 1: "초당 100건 요청, 2초 내 응답". $\rightarrow$ 단일 RDBMS + 단일 WAS 머신으로 커버 가능 (비용 $100). `Req 2`: "초당 10만 건 요청, 50ms 내 응답".$\rightarrow$Redis Cluster + MQ + 마이크로서비스 30대 + 로드밸런서 강제됨 (비용$10,000). NFR 숫자 하나가 프로젝트 예산과 인프라를 100배 뒤흔드는 나비효과 렌더링.

Practical

Core Topic 03: 개발 가능한 단위로 쪼개기, 유저 스토리 (User Stories & INVEST)

• Why to Learn: 기획자가 던져준 수백 페이지짜리 워드 문서를 개발자가 읽지 않는 문제를 해결하기 위해, 요구사항을 유저의 입장에서 3줄로 요약하고 개발(Sprint) 가능한 크기로 썰어내는 애자일 기법을 장악하기 위함입니다.
• What to Learn:
  • Concepts: User Story, Role-Goal-Benefit, Epic, Acceptance Criteria (인수 조건), INVEST Criteria.
  • Skills: "나는 쇼핑몰 고객으로서(Role), 장바구니에 담은 물건들의 총가격을 보고 싶다(Goal). 그래야 내 예산 안에 맞는지 확인할 수 있으니까(Benefit)." 구문 작성 및 이를 완료로 판정할 인수 조건(Given-When-Then) 정의.
• How to Learn:
  • 1단계: 가치 중심의 3단 논법: 유저 스토리는 기술 용어를 배제합니다. As a <Role>, I want <Goal>, so that <Benefit>. 이 짧은 문장 하나가 왜 이 코드를 짜야 하는지(Benefit) 개발자에게 강력한 동기부여를 줍니다.
  • 2단계: INVEST 잣대: PO가 쓴 스토리가 쓰레기인지 아닌지 판별합니다. I(독립적인가?), N(협상 가능한가?), V(고객에게 가치 있나?), E(개발 일정을 추정할 수 있나?), S(2주 안에 짤 수 있을 만큼 작은가?), T(테스트로 검증 가능한가?).
  • 3단계: 에픽(Epic) 쪼개기: "나는 넷플릭스처럼 동영상을 보고 싶다"는 너무 큽니다(S 위배). 이를 "나는 동영상 재생 버튼을 누르고 싶다", "나는 동영상 해상도를 조절하고 싶다", "나는 자막을 켜고 싶다"로 잘게 썰어내어(Slice) 스프린트 컨베이어 벨트에 하나씩 태우는 기막힌 분할술을 해부합니다.
• Implement: Epic 쪼개기 및 인수 조건(Acceptance Criteria) 도출 모사. Epic: "고객은 결제를 할 수 있다." (너무 큼). Story 1: "고객은 신용카드로 1회성 결제를 할 수 있다." (Small 도달). Acceptance Criteria (통과 조건):
  1. 결제 금액이 0원 이하이면 에러 팝업을 띄운다.
  2. 카드사 통신 지연 시 10초 뒤 타임아웃 처리를 한다. 개발자가 코드 짜기 전 if/else 예외 처리 목록을 완벽히 손에 쥐게 되는 명세화 과정 시각화.

Advanced

Core Topic 04: 스파게티의 추적자, 요구사항 추적 매트릭스 (The Matrix of Traceability)

• Why to Learn: 프로젝트 런칭 직전 기획 1개가 바뀌었을 때, "도대체 어느 코드와 어느 테스트 케이스를 고쳐야 하는지" 몰라서 시스템 전체가 무너지는 사이드 이펙트(Side Effect)의 공포를 통제하기 위함입니다.
• What to Learn:
  • Concepts: Requirements Traceability Matrix (RTM), Forward Traceability, Backward Traceability, Impact Analysis (영향도 분석).
  • Skills: 요구사항 REQ-01 $\rightarrow$ 설계 문서 Design-A $\rightarrow$ 소스코드 Payment.java $\rightarrow$ 테스트 케이스 TC-01을 매핑한 엑셀(또는 Jira) 표를 기반으로, 기획 변경 시 수정해야 할 타격 반경(Blast Radius)을 수학적으로 계산하기.
• How to Learn:
  • 1단계: 추적의 끊어짐: "비밀번호 길이를 8자리에서 12자리로 바꿔주세요." 요구사항이 변경되었습니다. 프론트엔드 개발자는 회원가입 UI의 유효성 검사 코드를 12자리로 바꿨습니다. 끝인 줄 알았죠? 하지만 백엔드의 DB 스키마(VARCHAR(10)), 백엔드 API 유효성 로직, 기존 유저 비밀번호 마이그레이션 배치(Batch) 프로그램은 까맣게 잊었습니다. 시스템이 배포되자마자 에러 폭탄이 터집니다.
  • 2단계: RTM (거미줄 매트릭스): 애초에 요구사항 ID와 소스코드/테스트 코드를 1<1>, 1 거미줄처럼 엮어(Mapping) 놓는 겁니다. REQ-01이 바뀌면, 화살표를 따라가(Forward Traceability) 프론트 UI, 백엔드 엔티티, DB 스키마 스크립트, 단위 테스트 코드 4군데를 고쳐야 한다는 리스트가 1초 만에 튀어나옵니다. 반대로 뜬금없는 쓰레기 코드가 발견되면, 화살표를 거꾸로 타올라가(Backward Traceability) "어? 이 코드는 연결된 기획서가 없네? 당장 지워!"라고 판단하는 무자비한 관리 통제력을 뜯어봅니다.
• Implement: Impact Analysis(영향도 분석) 역추적 그래프 엔진. 입력 데이터: Req-Auth -> [UI_Login.js, AuthController.java, UserDB.sql, Test_Auth.py]. 명령어: Change_Request(Req-Auth, "도입: 2FA 인증"). 출력: "경고! Req-Auth 변경으로 인해 타격받는 의존성 컴포넌트는 총 4개입니다. Test_Auth.py의 통과율이 즉각 0%로 떨어질 예정입니다." 스파게티 코드의 의존성을 멱살 잡고 끌고 나오는 시각적 트리 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Requirements Engineering (Elicitation, Analysis, Specification)
• [P5] SFIA - Requirements Definition and Management (REQM)

Secondary

• [Software Engineering] Ian Sommerville - Requirements Engineering and Traceability
• [User Stories Applied] Mike Cohn - Writing Agile User Stories (INVEST)

Industry

• [IEEE Std 29148] - Systems and software engineering — Life cycle processes — Requirements engineering
• [Atlassian Agile Coach] - Epics, Stories, Themes, and Initiatives

9. Final Checklist

Primary

• 고객이 요구하는 "해결책(Solution/How)"의 함정에 빠지지 않고, 근본적인 "문제(Problem/What)"를 도출(Elicitation)해 내어 엔지니어의 아키텍처 설계 자유도를 확보하는 방어술을 설명할 수 있는가?
• "비밀번호는 안전하게 보관되어야 한다"는 모호한 문장을 "비밀번호는 PBKDF2 알고리즘과 Salt를 적용해 해시 처리되어 DB에 저장되어야 한다"처럼 비기능적 요구사항(NFR)으로 정량/명세화할 수 있는가?

Secondary

• 애자일 팀에서 2주(Sprint) 내에 개발 불가능한 거대한 유저 스토리(Epic)를 건네받았을 때, 이를 독립적이고(Independent) 테스트 가능한(Testable) 크기로 쪼개는 INVEST 원칙을 적용할 수 있는가?
• 유저 스토리가 "개발 완료"되었음을 기획자와 개발자가 멱살 잡고 싸우지 않고 상호 동의하기 위해, Given-When-Then 포맷의 '인수 조건(Acceptance Criteria)'을 코딩 전에 선제적으로 작성하는 이유를 증명할 수 있는가?

Industry

• 프로젝트 후반부에 NFR 중 가용성(Availability) 임계치가 99.9%에서 99.99%로 상향 조정되었을 때, 이것이 로드밸런서 이중화, DB 레플리케이션 등의 인프라 아키텍처 재설계(Impact)에 미치는 거대한 연쇄 타격을 논증할 수 있는가?
• 소스코드 저장소(Git)에서 발견된 수백 줄의 로직이 요구사항 추적 매트릭스(RTM) 상의 어떤 비즈니스 기획과도 연결되지 않는 역추적(Backward Traceability) 실패 사례일 때, 이를 데드 코드(Dead Code)나 오버 엔지니어링으로 간주하고 잘라내는(Pruning) 아키텍트의 결단을 시뮬레이션할 수 있는가?