콘텐츠로 바로가기
HY_TECH_BASE

Requirements & Spec

고객의 니즈를 엄격한 엔지니어링 명세로 변환하고, 요구사항의 추적성과 무결성을 관리하는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

요구사항 및 명세(Requirements & Specification, REQ)는 "무엇을 만들 것인가(What to build)"를 정의하는 소프트웨어 개발의 첫 단추이자 가장 핵심적인 엔지니어링 과정을 다룹니다.

성공적인 소프트웨어는 단순히 코드를 잘 짜는 것이 아니라, 비즈니스 가치를 정확히 이해하고 이를 기술적으로 구현 가능한 명세(Specification)로 상세화하는 것에서 시작됩니다. 학습자는 모호한 고객의 언어를 명확한 기능적/비기능적 요구사항으로 분류하고, **SRS(Software Requirements Specification)**를 작성하며, 요구사항 추적 매트릭스(Traceability Matrix)를 통해 설계와 구현이 요구사항을 충실히 반영하고 있는지 검증하는 체계를 익힙니다.

2. Scope & Boundaries

In-Scope

  • Elicitation: 인터뷰, 관찰, 프로토타이핑을 통한 요구사항 도출
  • Analysis & Modeling: 유스케이스, 사용자 스토리, 상태 다이어그램을 통한 구조적 분석
  • Specification: IEEE 830 등 표준 기반의 SRS 작성 및 검증 기법
  • Management & Traceability: 요구사항 변경 관리 및 추적성(Traceability) 도구 활용

Out-of-Scope

  • 어플리케이션 소스 코드 구현 (09-01 SDLC/Implementation 영역)
  • UI/UX 디자인 (12. HCI 영역으로 위임)
  • 거시적 아키텍처 패턴 결정 (09-03 SAD 영역으로 위임)

Boundaries

  • REQ vs. Business Analysis: 비즈니스 분석이 '문제를 정의'하는 수준이라면, REQ는 그 문제를 해결하기 위한 '기술 전제 조건'을 물리적으로 상술합니다.

3. Counterexample

  • 단순히 "할 일 목록(To-do List)"을 적는 것은 REQ 학습이 아닙니다. 특정 요구사항이 **검증 가능(Verifiable)**한지 확인하고, "성능이 좋아야 한다" 대신 "초당 1000건의 트랜잭션을 200ms 이내에 처리해야 한다"와 같은 정량적 비기능 요구사항을 도출하여 명세서에 녹여낼 수 있어야 합니다.

4. Prerequisites

  • SDLC 및 프로세스 (Basic): 요구사항 단계가 전체 공정에서 가지는 위치를 이해해야 합니다. (09-01 SDLC)
  • 컴퓨팅 사고 및 로직 (Basic): 조건문과 논리적 흐름의 엄밀성이 필요합니다. (01. MCL)

5. Learning Map

  1. Extraction: 도메인 전문가로부터 요구사항을 오해 없이 추출하는 인터렉션 기술을 배웁니다. [P2, P5]
  2. Standard Spec: 추출된 요구사항을 엔지니어가 구현할 수 있는 표준 명세(SRS)로 변환합니다. [P2, Industry]
  3. Validation & Review: 작성된 명세의 모순과 누락을 기술적으로 찾아내고 합의하는 수순을 익힙니다. [Industry]
  4. Impact Analysis: 요구사항 변경 시 시스템 전체에 미치는 물리적 영향을 역추적(Tracing)하는 통제력을 갖춥니다. [P2]

6. Learning Topics

Basic

Core: 요구사항의 유형과 분류 (Functional vs. Non-functional)

  • Why to Learn: 요구사항의 성격을 구분하여 적절한 검증 전략을 세우기 위함입니다.
  • What to Learn:
    • 기능 요구사항(What the system does): 입력, 출력, 데이터 처리 로직
    • 비기능 요구사항(Quality Attributes): 성능, 가용성, 보안성, 유지보수성
    • 비즈니스 요구사항 vs 사용자 요구사항 vs 시스템 요구사항의 계층물리
  • How to Learn:
    • 기존 앱(예: 배달 앱)의 기능을 기능/비기능으로 나누어 포스트잇으로 분류 실습
    • 모호한 문장을 '기술적 명세'로 고쳐 쓰는 문장 다듬기 훈련
  • Implement: 특정 서비스의 핵심 요구사항 유형별 분류 매트릭스

Core: 명세서 작성 및 모델링 (SRS & Modeling)

  • Why to Learn: 이해관계자 간의 기술적 합의를 위한 '단일 진실 공급원(SSOT)'을 구축하기 위해서입니다.
  • What to Learn:
    • SRS(Software Requirements Specification) 표준 구조 (IEEE 830/ISO 29148)
    • 유스케이스 다이어그램 및 시나리오 기술 물리
    • 도메인 모델링: 명세에서의 용어 사전(Glossary)과 개념적 엔티티 정의
  • How to Learn:
    • 가상의 미니 프로젝트(예: 도서 대여 시스템)를 위한 5페이지 분량의 SRS 초안 작성
    • 작성된 명세서를 동료와 리뷰하며 '모순(Contradiction)'이나 '모호성' 지적받기
  • Implement: 표준 가이드라인에 따른 SRS(명세서) 완성본

Practical

Core: 요구사항 검증 및 품질 게이트 (V&V in Req)

  • Why to Learn: 잘못된 요구사항이 하위 공정(구현, 테스트)에서 수십 배의 비용으로 폭증하는 것을 막기 위함입니다.
  • What to Learn:
    • 요구사항 검토(Requirements Review) 및 인스펙션 절차
    • 프로토타입을 이용한 실물 검증 물리
    • 수락 테스트(Acceptance Test) 케이스와의 연동 역학
  • How to Learn:
    • 작성된 SRS에서 '테스트 불가능한 문장'을 찾아 '테스트 가능한 문장'으로 리팩토링 실습
    • 피그마(Figma) 등 프로토타이핑 도구를 이용해 추출된 요구사항의 실현 가능성 시뮬레이션
  • Implement: 명세서 품질 평가 점수표 및 수락 기준 정의서

Advanced

Core: 변경 관리 및 추적성 (Traceability Management)

  • Why to Learn: 시스템이 복잡해져도 요구사항의 변경이 어디까지 영향을 주는지 실시간으로 통제하기 위해서입니다.
  • What to Learn:
    • 요구사항 추적성 매트릭스(RTM): 요구사항 - 설계 - 코드 - 테스트 연결 물리
    • 변경 제어 위원회(CCB)와 변경 영향 분석(Impact Analysis)
    • 엔지니어링 영역에서의 Baseline 관리와 변경 이력 추적
  • How to Learn:
    • 특정 요구사항이 변경되었을 때, RTM을 통해 수정해야 할 클래스와 테스트 케이스를 역추적하는 연습
    • 변경 영향 범위(Affected Area)를 시각화하는 의존성 맵 구축
  • Implement: 다단계 요구사항 추적성 매트릭스(RTM) 자동화 구성안

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
SRS 소프트웨어가 수행해야 할 모든 기능 및 제약 조건을 상세히 기록한 엔지니어링 계약 문서입니다. 권장 단일 진실원 IEEE 830 System Design 단순 기획안과 혼동함 P2:SWEBOK core
Traceability 요구사항의 소스부터 설계, 구현, 테스트에 이르는 생애 주기를 양방향으로 추적하는 능력입니다. 심화 영향 분석 RTM Baseline 단순한 '로그'와 혼동함 P2:SWEBOK core
Elicitation 다양한 기법을 통해 이해관계자로부터 명시적/잠재적 요구사항을 이끌어내는 프로세스입니다. 기본 니즈 파악 Analysis Requirement Gathering 질문만 하는 것으로 오해 P2:SWEBOK core
Non-functional Req 시스템이 '어떻게(How)' 동작해야 하는지에 대한 품질 특성(성능, 가용성 등) 및 제약 사항입니다. 기본 품질 보증 Quality Attribute Functional Requirement 기능이 아니라고 경시함 P2:SWEBOK core

8. References

Primary References

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)이 명세 단계에서 확정되어 구현 완료 여부를 객관적으로 판단할 수 있는가?

Concepts & Tags

#requirements-engineering#srs-spec#functional-requirements#traceability-matrix