Requirement Engineering & Analysis

1. Overview

요구공학 및 분석(Requirement Engineering & Analysis, REA)은 비즈니스 언어인 '희망(Wishes)'을 기술 언어인 '명세(Specification)'로 번역하여, 개발팀이 물리적으로 무엇을 만들어야 하는지 명확한 수치와 규칙으로 정의하는 탐정의 공학입니다.

학습자는 요구사항을 끌어내는 추출(Elicitation) 단계부터, 이를 문서화하는 명세(Specification), 그리고 잘못된 이해가 하드웨어 비용으로 이어지지 않게 막는 **검증(Validation)**의 수리적 수순을 배웁니다. 특히, 기능적 요구사항(속도, 보안 등)과 비기능적 요구사항의 물리적 우선순위를 결정하는 기법과, 요구사항의 변화를 끝까지 추적하는 **추적성(Traceability)**의 논리 구조를 익힙니다. 이를 통해 "원하는 게 아니었는데"라는 최악의 물리적 붕괴를 예방하는 하이엔드 소프트웨어 기획 전문가 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Elicitation Techniques: 인터뷰, 설문, 브레인스토밍을 통한 요구사항의 물리적 포착
• Analysis & Modeling: 유스케이스(Use Case), 사용자 스토리(User Story), 도메인 모델링의 수리적 수순
• Documentation Standards: SRS(Software Requirements Specification)의 구조적 물리 설계
• Verification & Validation: 일관성 검사, 프로토타입을 통한 실질적 가치 수치 증명
• Requirement Management: 변경 제어(Change Control) 및 버저닝의 물리적 수순

Out-of-Scope

• 고객과의 계약 및 비용 정산 등의 일반 영업 행위 (비즈니스 영역으로 위임)
• 시스템 아키텍처의 구체적인 물리 설계 상세 (09-01-03 Architecture 영역에서 분담)

Boundaries

• REA vs. Architecture: REA가 '무엇(What)을 해결할 것인가'라는 문제의 정의에 집중한다면, Architecture(09-01-03)는 그 문제를 '어떻게(How) 기술적으로 구체화할 것인가'라는 해답의 물리 구조에 집중하여 경계를 가릅니다.

3. Counterexample

• 단순히 "고객 말 받아적기"라 설명하는 것은 REA 학습이 아닙니다. 왜 비기능 요구사항(성능) 목표가 명확한 수치(예: 응답속도 100ms 이내)로 정의되지 않았을 때 하드웨어 인프라 설계가 중구난방이 되는지 수리적으로 증명할 수 있어야 하며, 요구사항 추적성 결여가 코드 변경 시 전체 시스템의 어느 기능이 물리적으로 파괴되는지 알 수 없게 만드는 '블라인드 스팟' 현상을 논증하지 못한다면 REA의 본질을 이해하지 못한 것입니다.

4. Prerequisites

• SDLC Models & Agile Dynamics (Basic): 09-01-01의 개발 수명 주기 흐름 이해가 필수입니다.
• Computing Logic (Recommended): 명확한 조건문 및 논리적 엄격함 이해가 권장됩니다. (01-01-01)

5. Learning Map

1. Hearing the Unseen: 사용자의 막연한 말 뒤에 숨겨진 진짜 물리적 니즈를 발굴합니다.
2. Transforming to Logic: 발굴된 니즈를 하드웨어가 이해할 수 있는 논리적 모델(유스케이스 등)로 수리 정제합니다.
3. Writing the Law: 시스템이 반드시 지켜야 할 규칙인 SRS를 세상에 내놓습니다.
4. Guardians of Continuity: 개발이 끝날 때까지 요구사항이 변질되지 않도록 추적의 끈(Traceability)을 팽팽히 유지합니다.

6. Learning Topics

Basic

Core: 요구사항의 유형과 추출 (Elicitation Basics)

• Why to Learn: 만들고 나서 "이게 아닌데" 소리를 듣지 않기 위해 사용자의 진짜 생각을 물리적으로 포착하기 위해서입니다.
• What to Learn:
  • Functional vs Non-functional: '무엇을 하는가'와 '어떻게 성능을 내는가'의 수리적 구분
  • Elicitation Methods: 인터뷰, 설문, 관찰법 등 데이터 수집 물리 수순
  • Stakeholder Identification: 요구사항을 뱉어낼 이해관계자의 논리적 그룹화
• How to Learn:
  • 특정 서비스를 위한 가상의 고객 인터뷰를 진행하고, 횡설수설하는 대화 속에서 5가지 핵심 요구사항을 수리적으로 추출 실습
  • 사용자 스토리($User Story$)를 "As a..., I want..., So that..." 형식에 맞춰 작성
• Implement: 요구사항의 우선순위를 'Must-have'부터 수치로 정하는 RequirementPriority 리스트

Recommended

Core: 요구사항 분석 및 모델링 (Requirements Analysis)

• Why to Learn: 복잡한 비즈니스 로직을 오류 없이 개발팀에 전달하기 위한 물리 도면을 그리기 위함입니다.
• What to Learn:
  • Use Case Diagram: 시스템과 외부 행위자 사이의 물리적 상호작용 시각화
  • Data Flow Diagram (DFD): 데이터가 시스템 내부를 흐르는 수리적 물리 경로 추적
  • Prototyping: 요구사항의 모호함을 제거하기 위한 가상의 물리 모형 제작
• How to Learn:
  • ATM 인출 과정을 유스케이스와 시퀀스 다이어그램으로 그려보며, 예외 상황(잔액 부족 등)의 논리적 누락을 발견하는 실습
  • 프로토타입을 본 사용자가 초기 요구사항을 어떻게 수치적으로 수정하는지 피드백 데이터 기록
• Implement: 유스케이스별로 성공 시나리오와 예외 시나리오를 명세하는 ScenarioTemplate

Practical

Core: 명세화 및 SRS의 구조 (Specification Mechanics)

• Why to Learn: 법률 문서처럼 엄격한 명세서를 통해 하드웨어 구현의 모호성을 물리적으로 근절하기 위해서입니다.
• What to Learn:
  • SRS Structure: IEEE 표준 등에 따른 명세서의 물리적 구성 요소
  • SMART Requirements: 구체적(Specific), 측정 가능(Measurable) 등 수리적 작성 규칙
  • Verification Techniques: 인스펙션(Inspection), 워크스루(Walkthrough)의 물리적 검토 수순
• How to Learn:
  • "빨라야 한다"라는 모호한 요구를 "1,000건 동시 처리 시 응답 지연 500ms 이내"라는 물리적 수치로 교정하는 훈련
  • 동료와 SRS 문서를 교차 검토하며, 논리적 모순이나 중복을 찾아내는 디버깅 실습
• Implement: 요구사항 하나가 테스트 케이스와 어떻게 연결되는지 매핑하는 TraceabilityMatrix (RTM)

Advanced

Core: 변경 관리와 추적성 거버넌스 (Management Governance)

• Why to Learn: 개발 중간에 터져 나오는 요구 변경을 시스템 붕괴 없이 수리적으로 수용하기 위함입니다.
• What to Learn:
  • Change Management Process: 변경 요청(CR)의 영향도 수치 분석 및 승인 물리 절차
  • Impact Analysis: 요구사항 변경이 하위 모듈과 데이터베이스에 미치는 물리적 파장 산출
  • Tool-based Traceability: 소프트웨어를 통한 전 생명주기 요구사항 추적 물리학
• How to Learn:
  • 도메인 하나가 바뀌었을 때, RTM을 통해 수정이 필요한 API와 UI 리스트를 즉각 추출하는 물리 실험 실습
  • 요구사항 변경으로 인한 개발 리터치 비용($Rework Cost$)을 수리적으로 시뮬레이션
• Implement: 신규 요구사항 등록 시 하위 작업들에 미치는 '영향 점수'를 계산하는 ImpactScore 도구

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Requirements — Requirements standard.
• [P5] SFIA v9 - Software Engineering / Requirements definition and management — Professional skills.

Secondary

• [Requirements Engineering: Processes and Techniques] Gerald Kotonya — Process focus.
• [Software Requirements] Karl Wiegers — Practical SRS guide.

Industry

• [IEEE Std 830-1998: Recommended Practice for Software Requirements Specifications] — Structural standard.
• [BABOK Guide: A Guide to the Business Analysis Body of Knowledge] — Business context.

9. Final Checklist

Primary

• '기능 요구사항'과 '비기능 요구사항'이 하드웨어 리소스 할당 측면에서 왜 상충($Trade-off$)하는지 설명 가능한가? (P2)
• '요구사항 분석' 과정에서 발견된 '모호성'이 최종 제품의 물리적 결함으로 이어지는 과정을 기술할 수 있는 가? (P2)

Secondary

• 사용자 스토리가 기술 명세(SRS)를 완전히 대체하지 못하는 비즈니스/공학적 한계를 소통 가능한가?
• '요구사항 추적성($RTM$)'이 결여된 프로젝트에서 시스템 업그레이드 시 발생하는 물리적 리스크를 논증할 수 있는 가?

Industry

• 실무 기획 단계에서 'MoSCoW' 기법을 사용하여 우선순위를 정할 때의 수리적 의사결정 근거를 제안할 수 있는 가? (SFIA)
• 고객의 갑작스러운 요구사항 변경 시, '영향도 분석($Impact Analysis$)'을 통해 개발 기간 지연 수치를 산출할 수 있는 가?