SRS Engineering (IEEE 830)

1. Overview

SRS 엔지니어링과 명세화(SRS Engineering & IEEE 830)는 허공에 흩어진 고객의 말과 요구사항 도출의 파편들을 끌어모아, 오해의 여지가 1%도 없는 **법적 계약서이자 아키텍처의 절대 헌법인 요구사항 명세서(SRS, Software Requirements Specification)**를 주조해 내는 공학적 글쓰기를 해부합니다.

학습자는 문학적이고 애매모호한 자연어(Natural Language)가 개발자에게 얼마나 큰 재앙을 가져오는지 뜯어보고, IEEE 830 표준의 엄격한 템플릿과 정형화된 서식으로 이를 통제합니다. 나아가 유저가 시스템을 어떻게 괴롭히고(Input) 시스템이 어떻게 화답하는지(Output)를 그림으로 박아넣는 유즈케이스(Use Case) 다이어그램과 시나리오를 장악합니다. 마지막으로, 단순한 텍스트를 넘어 상태 기계(State Machine)나 수학적 모델을 동원해 단 하나의 버그(모순)도 허용하지 않는 정형 명세(Formal Methods) 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• IEEE 830 SRS Standard: 문서의 구조 (1. Introduction, 2. Overall Description, 3. Specific Requirements).
• Use Case Modeling: 액터(Actor), 유즈케이스, 관계(Include, Extend), 시나리오 명세서(Main Success Scenario, Alternate Paths).
• Characteristics of Good SRS: 정확성(Correct), 모호성 없음(Unambiguous), 완전성(Complete), 일관성(Consistent), 검증 가능성(Verifiable).
• Formal vs Informal: 자연어를 쓰는 비정형 명세와, 수학 및 논리학 기호를 쓰는 정형 명세(Z notation 등)의 트레이드오프.

Out-of-Scope

• Agile User Story 작성법: 에픽(Epic) 쪼개기와 INVEST 원칙 등 애자일의 가벼운 명세법 $\rightarrow$ 09-01-02 Req Engineering 영역에서 기학습.
• 아키텍처 문서화 (C4 Model): 이미 확정된 요구사항을 바탕으로 내부 뼈대를 그리는 작업 $\rightarrow$ 09-01-03 Architecture Documentation 영역으로 위임.

Boundaries

• Agile User Story vs Traditional SRS (IEEE 830): 유저 스토리는 "대화를 시작하기 위한 엽서(Placeholder)"입니다. 애자일에서는 개발자와 기획자가 매일 얼굴을 보며 대화로 빈틈을 채웁니다. 반면 전통적 SRS는 "얼굴 안 보고 이 문서만 던져주면, 인도에 있는 외주 개발팀이 100% 똑같은 시스템을 찍어낼 수 있어야 하는" 법적 도면입니다. 인공위성, 의료 기기, 금융 코어 시스템처럼 단 하나의 예외 케이스(Alternate Path) 누락이 수백억의 소송으로 이어지는 도메인에서 SRS가 왜 필수 불가결한지 그 무거운 경계를 명확히 긋습니다.

3. Counterexample

• 애매함의 모순 (Unambiguous 붕괴): 명세서에 "비밀번호는 영문과 숫자를 포함해야 한다"라고 적혀 있습니다. 개발자 A는 영문 1자 + 숫자 1자로 짰고, 개발자 B는 영문만 8자 쓰거나 숫자만 8자 써도 통과되게(OR 조건) 짰습니다. "포함해야 한다"라는 자연어의 논리적 모호함(AND인지 OR인지) 때문에 개발팀 전체가 제각각 코드를 짜서 인증 시스템이 완전히 박살 난 비정형 명세의 비극입니다.
• 유즈케이스의 예외 누락 (Unhappy Path): 유즈케이스 시나리오에 "유저가 상품을 고르고 카드를 긁으면 결제가 완료된다(Main Success Scenario)"만 잔뜩 써놨습니다. 개발자가 그대로 짰습니다. 오픈 첫날, 유저가 카드를 긁었는데 한도 초과가 나거나(Alternate Path 1), 카드사 서버가 죽어 10초 타임아웃이 나면(Alternate Path 2) 어떻게 해야 할지 명세된 게 없어서 앱이 그냥 튕겨버렸습니다(Crash). 행복한 길(Happy Path)만 그리고 지옥(예외 흐름)을 빼먹은 삼류 명세의 결과입니다.

4. Prerequisites

• 요구사항 도출 (Basic): 고객의 니즈를 뽑아내는 5-Whys와 JAD 기법. (09-02-01 Elicitation Physics)
• UML 다이어그램 개론 (Basic): 시스템의 정적/동적 구조화 개념.

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 공학적 글쓰기의 해부학 (The IEEE 830 Anatomy)

• Why to Learn: 기획자가 의식의 흐름대로 쓴 중구난방 문서 때문에 개발자가 개발 내내 문서를 뒤지며 고통받는 것을 막고, 전 세계 표준 프레임워크(IEEE 830)의 폴더 구조를 통해 문서의 내비게이션을 통제하기 위함입니다.
• What to Learn:
  • Concepts: IEEE 830 Standard, SRS (Software Requirements Specification), Section 1 (Introduction), Section 2 (Overall Description), Section 3 (Specific Requirements).
  • Skills: "우주선 궤도 계산 모듈"을 개발할 때, 문서 1장에는 목적과 용어 정리(Definitions)를, 2장에는 사용자 환경과 제약조건(메모리 1MB 제한)을, 3장에는 y=ax+b 입력/출력 룰을 깎아 넣는 표준 인덱싱(Indexing) 적용하기.
• How to Learn:
  • 1단계: 도입 (Introduction): 이 문서가 왜 쓰여졌고, 독자가 누구인지 명시합니다. 특히 '용어 사전(Glossary)'이 핵심입니다. "여기서 '사용자'라 함은 로그인한 유저만 뜻한다"라고 못 박아 뒤에서 발생하는 해석의 차이를 원천 봉쇄합니다.
  • 2단계: 전체 조망 (Overall Description): 시스템이 외부망(API)과 어떻게 엮이는지(Context), 유저의 수준은 어떤지, OS나 하드웨어 제약(메모리 2GB 한도)은 무엇인지 시스템이 처한 '물리적 환경'을 깔아줍니다.
  • 3단계: 구체적 명세 (Specific Requirements): 밥줄입니다. 개발자가 이것만 보고 코드를 짤 수 있어야 합니다. 3.1. 기능적 요구사항(로그인, 결제), 3.2. 성능 요구사항(0.5초 응답), 3.3. 보안 요구사항(AES256)을 완벽한 리스트 형태로 나열하는 거대한 목차의 힘을 해부합니다.
• Implement: 엉망진창 기획서 $\rightarrow$ IEEE 830 템플릿 리팩터링 모사. 입력(Unstructured): "이 앱은 주부들을 위한 건데, 화면이 크고 장바구니 결제가 돼야 함. 서버는 AWS 쓰고 비번은 암호화 ㄱㄱ." 출력(IEEE 830):
  • 2.1 User Characteristics: "주요 타겟은 4050 여성, 글자 폰트 사이즈 최소 14pt (제약조건)."
  • 3.1 Functional: "장바구니 결제 (REQ-F-01)."
  • 3.2 Non-Functional: "AWS 인프라 기반 99.9% 가용성(REQ-NF-01)." 막연한 스토리가 뼈대 있는 공학 문서로 재조립되는 파이프라인 시각화.

Recommended

Core Topic 02: 지옥의 시나리오 발굴, 유즈케이스 (Use Case & The Unhappy Path)

• Why to Learn: 고객은 언제나 "성공하는 해피엔딩"만 말하지만, 서버를 죽이는 건 언제나 "비정상적인 예외 케이스"입니다. 유즈케이스 시나리오를 통해 발생 가능한 모든 에러 분기점을 샅샅이 뒤져내기 위함입니다.
• What to Learn:
  • Concepts: Actor (액터), Use Case, <<include>> (필수 포함), <<extend>> (선택 확장), Main Success Scenario (해피 패스), Alternate Paths (예외/대체 흐름).
  • Skills: "ATM 출금" 유즈케이스를 그릴 때, 카드 삽입 $\rightarrow$ 비번 입력 $\rightarrow$ 돈 나옴(Main)뿐만 아니라, 비번 3회 틀림(Alternate 1), 잔액 부족(Alternate 2), 지폐 걸림(Alternate 3)의 예외 흐름을 문서화하여 개발자의 if-else 지옥을 미리 맵핑하기.
• How to Learn:
  • 1단계: Actor와 Boundary: 유즈케이스 다이어그램을 그립니다. 큰 네모(시스템)를 치고, 밖에는 사람 졸라맨(고객)과 네모 졸라맨(외부 은행 서버)을 그립니다. 시스템 안에는 동그라미(출금, 입금)를 그립니다. "누가 우리 시스템을 찌르는가?" 경계를 긋습니다.
  • 2단계: Include vs Extend: 공통 로직을 분리합니다. '출금'을 하든 '입금'을 하든 무조건 '인증(로그인)'을 해야 합니다. 이건 <<include>> 화살표로 묶습니다. 반면 출금하다가 에러 났을 때만 영수증을 뽑아주는 건 <<extend>>로 선택적 확장 처리를 합니다.
  • 3단계: Unhappy Path (지옥의 명세): 동그라미를 텍스트 시나리오로 풀어씁니다. 가장 중요한 건 Main 시나리오 밑에 달린 수십 개의 Alternate Paths(예외 흐름)입니다. 여기서 "서버 타임아웃", "유효성 검사 실패"를 모조리 잡아내지 않으면, 나중에 QA 단계에서 시스템이 와르르 무너지는 뼈아픈 역학을 뜯어봅니다.
• Implement: Use Case 시나리오 분기 커버리지 시뮬레이션. 유즈케이스 UC-01: 항공권 예매. Main: 날짜 선택 $\rightarrow$ 좌석 선택 $\rightarrow$ 결제 완료. Alt 1 (좌석 선점 충돌): 결제 버튼 누른 순간 다른 유저가 먼저 예매함 $\rightarrow$ 에러 팝업 후 좌석 선택 창으로 롤백. Alt 2 (결제 서버 타임아웃): 30초 대기 후 결제 실패 처리 $\rightarrow$ 유저에게 SMS 알림. 이 텍스트(Alternate Paths)들이 백엔드 코드의 try-catch 블록 개수와 정확히 1<1로> 매핑되는 코드 구현 선행 지표 렌더링.

Practical

Core Topic 03: 틈 없는 방탄복, 좋은 명세서의 5원칙 (The 5 Pillars of Good SRS)

• Why to Learn: 두꺼운 문서라고 좋은 문서가 아닙니다. 코딩 전에 논리적 모순이나 빠진 구멍을 찾아내어, 아키텍처가 붕괴하는 것을 막는 문서 품질 검증(QA)의 잣대를 장악하기 위함입니다.
• What to Learn:
  • Concepts: Unambiguous (모호성 없음), Complete (완전성), Consistent (일관성), Verifiable (검증 가능성), Traceable (추적 가능성).
  • Skills: "시스템은 가급적 빨리 리부팅되어야 한다"는 쓰레기 명세를 "10초 이내에 리부팅(Verifiable)"으로, 1페이지의 "비밀번호 8자리"와 5페이지의 "비밀번호 12자리"가 충돌하는 모순(Inconsistent)을 찾아내 리팩터링하기.
• How to Learn:
  • 1단계: Unambiguous (해석의 단일화): "A와 B 또는 C가 오면 차단한다." 이 문장은 (A and B) or C인지, A and (B or C)인지 헷갈립니다. 개발자 2명이 다르게 짤 확률 100%입니다. 논리 기호나 테이블을 써서 단 하나의 해석만 나오게 짓뭉갭니다.
  • 2단계: Consistent (자아 분열 방지): 100장짜리 문서입니다. 3장에선 "배송비 무료"라 하고, 7장에선 "제주도는 배송비 3천 원"이라 합니다. 충돌입니다. 용어와 비즈니스 룰이 문서 전체에서 완벽한 논리적 정합성을 가져야 합니다.
  • 3단계: Verifiable (테스트 통과 여부): "사용자 UI가 직관적이어야 한다." 테스트 코드로 짤 수 있습니까? 없습니다. "사용자가 3번의 클릭 이내에 결제 페이지에 도달해야 한다." 테스트 가능합니다(Verifiable). 테스트 코드로 짤 수 없는 명세는 존재 가치가 없다는 매서운 심판을 해부합니다.
• Implement: SRS 방탄성(Quality) 린터(Linter) 로직 모사. 문장 스캐너가 SRS 텍스트를 읽음. Detect: "충분한 메모리를 할당한다." $\rightarrow$ [Error] Ambiguous & Unverifiable ("충분한"의 기준 부재). Detect: "에러 발생 시 로그를 남긴다." $\rightarrow$ [Error] Incomplete (어떤 로그 포맷? 어디에 저장?). 자연어를 정적 분석(Static Analysis)하여 컴파일 에러를 뿜어내듯 명세서의 결함을 쳐내는 품질 통제 애니메이션.

Advanced

Core Topic 04: 수학이 된 요구사항, 정형 명세 (Formal Methods)

• Why to Learn: 수백만 명의 목숨이 달린 자율주행 자동차나 항공기 제어 시스템에서, "자연어"가 가진 모호함의 여지 0.0001%마저 수학 기호로 압살해 버리는 극한의 무결점 명세를 장악하기 위함입니다.
• What to Learn:
  • Concepts: Formal Methods (정형 기법), Mathematical Logic (수리 논리학), Z Notation, State Machine, Model Checking.
  • Skills: "엘리베이터가 문이 열린 채로 움직여서는 안 된다"는 자연어 요구사항을, 상태 기계(State Machine)와 논리 명제(수학 공식)로 변환하여 시스템의 모순(Deadlock, Safety Property 위반)을 수학적으로 증명하기.
• How to Learn:
  • 1단계: 자연어의 한계: 아무리 규칙을 잘 지켜 써도 사람의 말(자연어)에는 구멍이 생깁니다. 금융망 코어나 우주선에서는 이 구멍이 수백억의 손실을 낳습니다.
  • 2단계: 수학 기호로 쓰기 (Z Notation 등): 요구사항을 한글이나 영어로 쓰지 않습니다. 집합(Set), 명제(Logic), 함수(Function) 기호로 씁니다. If State=DOOR_OPEN, then Velocity=0.
  • 3단계: 모델 체킹 (수학적 증명): 이렇게 명세서를 수학 공식으로 짜놓으면, '모델 체커(Model Checker)'라는 컴퓨터 프로그램이 이 공식을 돌려봅니다. "야, 네가 짠 수식대로 돌리다 보니까, 조건 A와 B가 동시에 겹치면 문이 열린 채로 엘리베이터가 움직이는 모순(Violation)이 수학적으로 발견됐어!" 코드를 짜기도 전에 설계의 결함을 수학적으로 증명(Prove)해 버리는, 엔지니어링의 최고봉을 뜯어봅니다.
• Implement: Model Checker(상태 기계 검증) 시뮬레이터. 요구사항: 1) 기차는 선로가 비어있을 때만 진입(Enter) 가능. 2) 2대의 기차가 선로 진입을 동시 대기함. Model Checker Run: 가능한 모든 상태(State Space) 탐색 중... [CRITICAL FAILURE]: 기차 1과 기차 2가 동시에 '선로 비어있음' 신호를 받고 동시에 진입하여 충돌(Collision State)하는 경로 발각 (Race Condition). 자연어 문서에서는 절대 발견하지 못했을 동시성 버그를, 코딩 전 수학적 명세로 미리 찢어발기는 궁극의 무결점 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Requirements Specifications (IEEE 830, Formal Methods)
• [P5] SFIA - Requirements Definition and Management (REQM) - Specification Standards

Secondary

• [Writing Effective Use Cases] Alistair Cockburn - Actors, Goals, and Scenarios
• [Software Engineering] Ian Sommerville - Formal Specification and Model Checking

Industry

• [IEEE Std 830-1998] - Recommended Practice for Software Requirements Specifications
• [NASA Software Engineering Requirements] - Formal Methods application in safety-critical systems

9. Final Checklist

Primary

• 개발 1개월 차에 고객이 "내가 원한 건 이게 아니다"라며 계약을 파기하려 할 때, IEEE 830 구조로 작성되고 고객의 서명(Sign-off)을 받은 SRS 문서가 어떻게 개발팀을 보호하는 법적 방패가 되는지 논증할 수 있는가?
• 시스템에 개입하는 외부 주체(Actor)와 기능(Use Case)을 매핑하는 다이어그램을 그릴 때, 여러 유즈케이스에서 중복으로 쓰이는 로직(예: 로그인)을 <<include>>로 분리하여 명세서의 응집도를 높일 수 있는가?

Secondary

• 유즈케이스 시나리오를 작성할 때, 성공하는 흐름(Main Success Scenario)만 적고 끝내는 오류를 범하지 않고 네트워크 단절, 결제 실패 등의 예외 흐름(Alternate Paths)을 집요하게 발굴하여 백엔드 에러 핸들링 코드를 사전 정의할 수 있는가?
• 좋은 요구사항의 5원칙 중 '검증 가능성(Verifiable)' 측면에서, "시스템 UI는 사용자 친화적이어야 한다"는 명세가 왜 쓰레기인지 비판하고, 이를 테스트 코드로 짤 수 있는 정량적 문장으로 리팩터링할 수 있는가?

Industry

• 거대한 시스템 명세서(SRS) 20페이지의 "주문 시 재고가 차감된다"와 50페이지의 "주문 취소 시 재고는 수동으로 복구한다"는 비즈니스 룰이 빚어내는 일관성 붕괴(Inconsistent)를 정적 리뷰로 어떻게 색출할 것인가?
• 의료용 방사선 조사기 제어 소프트웨어를 개발할 때, 자연어 명세의 모호함 때문에 방사선이 과다 노출되는 참사를 막기 위해 상태 기계(State Machine)와 모델 체커(Model Checker)를 동원하는 정형 기법(Formal Methods)의 수학적 방어망을 설계할 수 있는가?