소프트웨어 공학 100 주제 시리즈의 11번째 글이다. (카테고리: 요구사항 공학)

한 줄 요약

요구사항 공학은 “무엇을 만들까” 를 묻는 일이 아니라 현실 세계의 목표와 소프트웨어 명세 사이의 관계를 다루는 일이다. 도출·분석·명세·검증은 순서가 아니라 계속 되도는 활동이고, 그 고리의 핵심은 “명세가 세계에 대한 가정과 합쳐졌을 때 정말 목표를 만족하는가” 를 따지는 것이다.

왜 필요한가

기초는 요구사항 분석 글에서 다뤘다. 네 활동의 이름, 기능·비기능 구분, 좋은 문장의 조건까지. 이 글은 그 다음 질문을 다룬다.

  • 명세대로 정확히 만들었는데 왜 현장에서는 “이게 아니다” 라는 말이 나오는가?
  • 도출을 언제 끝내야 하는가? 끝이 있긴 한가?
  • 검증(verification)과 확인(validation)은 무엇이 다르고, 요구사항 단계에서 어느 쪽을 해야 하는가?

이 질문에 답하지 못하는 팀은 대개 같은 패턴으로 실패한다. 요구사항 문서는 깔끔하고 테스트도 모두 통과하는데, 배포 후 사용자가 “주말엔 그렇게 안 쓴다”, “그 장비는 그 신호를 안 보낸다” 같은 말을 한다. 문서가 틀린 게 아니라 문서가 기대고 있던 세계에 대한 가정이 틀린 것이다. 요구사항 공학의 원전들은 바로 이 지점을 정면으로 다룬다.

핵심 개념

정의: “현실 세계의 목표” 에서 출발한다

Nuseibeh 와 Easterbrook 는 ICSE 2000 의 로드맵 논문 Requirements Engineering: A Roadmap (DOI)에서 Zave 의 정의를 “가장 명확한 정의 중 하나” 로 인용한다.

요구사항 공학은 소프트웨어 시스템의 현실 세계 목표, 기능, 제약을 다루는 소프트웨어 공학의 한 분야다. 또한 이 요소들이 소프트웨어 행위의 정밀한 명세와 맺는 관계, 그리고 그것들이 시간에 따라, 소프트웨어 제품군에 걸쳐 진화하는 것을 다룬다. — P. Zave, Classification of research efforts in requirements engineering, ACM Computing Surveys, 1997

이 정의는 세 가지를 강조한다. 시스템을 만드는 이유(why)인 현실 세계의 목표, 그 목표와 정밀한 명세 사이의 관계, 그리고 요구는 시간에 따라 진화한다는 전제다.

세계와 기계: S, K ⊢ R

요구사항 공학의 가장 중요한 이론적 틀은 Zave 와 Jackson 의 Four Dark Corners of Requirements Engineering (ACM TOSEM, 1997)에서 나온다. 이들은 세 종류의 기술(description)을 구분한다.

기호 이름 무엇을 말하나 예: 주차장 출구 차단기
R 요구사항(requirement) 환경에서 일어나기를 바라는 일 요금을 낸 차만 나간다
K 영역 지식(domain knowledge) 기계와 무관하게 원래 참인 환경의 성질 차단기가 올라가 있을 때 차 한 대만 지나간다. 센서는 차가 지나가면 신호를 낸다
S 명세(specification) 기계가 환경과 맞닿는 지점에서 할 행동 결제 완료 신호를 받으면 차단기를 올리고, 통과 신호를 받으면 내린다

그리고 요구사항 공학이 “끝났다” 고 말할 수 있는 조건을 이렇게 쓴다.

\[S, K \vdash R\]

명세 S 와 영역 지식 K 가 함께 있을 때 요구 R 이 따라 나와야 한다. 위 예에서 K 의 “차 한 대만 지나간다” 가 거짓이라면(앞차에 바짝 붙어 두 대가 나가는 꼬리물기), S 를 완벽하게 구현해도 R 은 깨진다. 소프트웨어 버그가 아니다. 세계에 대한 가정의 버그다.

이 틀은 실무에 두 가지를 준다.

  1. 요구사항 문서에는 기능만이 아니라 가정(K)도 명시적으로 적어야 한다. 가정이 바뀌면 어떤 요구가 위험해지는지 추적할 수 있다.
  2. 테스트가 모두 통과해도(S 가 맞아도) R 이 보장되지 않는다. K 를 확인하는 활동, 즉 현장 관찰·운영 데이터 확인이 따로 필요하다.

활동 모델: 넷인가 다섯인가

교과서적 분류는 도출·분석·명세·검증의 넷이다. SWEBOK V3 의 소프트웨어 요구사항 장은 요구사항 프로세스, 도출, 분석, 명세, 검증, 실무 고려사항 등으로 지식 영역을 나누고, 소프트웨어 요구사항을 “현실 세계의 어떤 문제를 풀기 위해 무언가가 보여야 하는 성질” 로 정의한다. 현재 판은 2024년에 나온 SWEBOK V4이고, 소프트웨어 요구사항은 여전히 첫 번째 지식 영역이다.

Nuseibeh 와 Easterbrook 는 같은 일을 다르게 자른다.

SWEBOK 식 Nuseibeh & Easterbrook 식 차이
도출 도출(eliciting) “수집(capture)” 이 아니라 “끌어냄” — 요구는 저기 놓여 있지 않다
분석 모델링·분석 모델이 분석의 수단
명세 소통(communicating) 문서는 목적이 아니라 소통 수단
검증 합의(agreeing) 이해관계자 사이 충돌 해소가 검증의 절반
(관리) 진화(evolving) 변경은 예외가 아니라 정상 상태

그리고 이 활동들이 “순서대로 설명되지만 실제로는 서로 얽혀 있고 반복적이며 전체 생명주기에 걸친다” 고 명시한다. 도출을 “끝내는” 시점은 없다. 다만 다음 결정을 내리기에 충분한 시점이 있을 뿐이다.

검증(verification)과 확인(validation)

요구사항 단계에서 둘을 섞으면 엉뚱한 활동에 시간을 쓴다.

구분 질문 요구사항 단계의 예 기법
검증 문서가 제대로 쓰였나? 모순·누락·모호함이 없는가, 형식 규칙을 지키나 인스펙션, 체크리스트, 정적 검사
확인 맞는 것을 적었나? 이해관계자가 실제로 원하는 것인가 프로토타입, 시나리오 워크스루, 시연

Nuseibeh 와 Easterbrook 는 인스펙션·형식 분석이 기술의 일관성에 집중하는 반면, 프로토타이핑·시나리오는 현실 문제와의 대응을 시험한다고 구분한다. 그리고 확인이 어려운 이유를 두 가지로 든다. 하나는 철학적이다. 과학 이론처럼 요구사항도 관찰로 “증명” 할 수는 없고 반박할 수 있을 뿐이다. 그래서 확인은 테스터처럼 요구를 깨뜨리는 실험을 고안해야 한다. 다른 하나는 사회적이다. 이해관계자의 목표가 서로 충돌한다.

프로세스 표준: ISO/IEC/IEEE 29148

ISO/IEC/IEEE 29148:2018은 시스템·소프트웨어의 생명주기 전반에 걸친 요구사항 공학 프로세스와 산출물을 정하고, ISO/IEC/IEEE 15288·12207 의 요구사항 관련 프로세스에 대한 지침을 제공한다. 좋은 요구사항 문장의 조건은 SE100 #016 에서 따로 다룬다. 여기서 기억할 것은 이 표준이 요구사항을 층위로 본다는 점이다. 이해관계자의 필요가 이해관계자 요구사항으로, 그것이 다시 시스템·소프트웨어 요구사항으로 변환된다. 변환마다 가정과 결정이 끼어들고, 그것을 기록하는 것이 추적성(SE100 #019)이다.

실무 적용

한 바퀴를 작게 도는 RE 루프

 ┌────────── 목표(why) ──────────┐
 │                               ▼
[도출]──▶[모델링·분석]──▶[명세+가정 기록]──▶[확인: 깨뜨려 보기]
   ▲                                           │
   └──────── 새 질문·충돌·변경 ◀────────────────┘

스프린트마다 이 고리를 한 번 도는 것이 목표다. 큰 문서를 한 번 쓰는 게 아니다.

요구 기록에 “가정” 칸을 넣는다

id: REQ-PARK-007
goal: 요금 미납 차량이 출차하지 못하게 해 미수금을 줄인다
requirement: 결제가 확인된 차량만 출구를 통과한다          # R
specification: |                                            # S
  결제 완료 이벤트 수신 시 차단기를 올린다.
  통과 센서 신호 수신 후 차단기를 내린다.
assumptions:                                                # K
  - id: K1
    text: 차단기가 올라간 동안 통과하는 차량은 한 대다
    evidence: 미확인 — 현장 CCTV 1주 표본으로 확인 필요
  - id: K2
    text: 통과 센서는 오토바이도 감지한다
    evidence: 제조사 사양서 확인 필요
validation:
  - 현장 관찰로 K1 반례(꼬리물기) 빈도 확인
  - 결제 실패·네트워크 단절 시나리오 워크스루
owner: 주차운영팀

evidence: 미확인 이 남아 있는 가정이 곧 위험 목록이다. 가정이 틀린 것으로 드러나면(꼬리물기가 잦다) 명세를 바꿀지(차량 수 카운트), 요구를 바꿀지(사후 청구로 전환), 영역을 바꿀지(물리적 게이트 추가)를 결정한다.

도출 기법 고르기

상황 잘 맞는 기법 이유
이해관계자가 말로 설명할 수 있는 업무 인터뷰, 워크숍 빠르고 비용이 낮다
암묵지가 많은 현장 업무 관찰, 작업 동행 사람들은 자기가 하는 일을 정확히 말하지 못한다
여러 부서가 얽힌 흐름 협업 모델링(SE100 #018) 부서 간 경계의 오해가 드러난다
무엇을 원하는지 본인도 모름 프로토타입(SE100 #020) 보여 줘야 반응이 나온다

체크리스트: “도출을 멈춰도 되는가”

  • 이번 결정(이번 스프린트에 무엇을 만들지)에 필요한 질문에 모두 답했는가?
  • 남은 미지수는 나중에 바꿔도 비용이 작은 것인가?
  • 핵심 가정(K)마다 증거가 있거나, 확인 계획이 있는가?
  • 충돌하는 이해관계자 목표를 누가 어떻게 결정했는지 기록했는가?

흔한 오해와 함정

  • “요구사항은 ‘무엇’ 이고 설계는 ‘어떻게’ 다.” Zave 와 Jackson 은 이 경구가 요구사항 공학을 요약하던 시대는 지났다고 썼다. 한 층위의 ‘어떻게’ 는 아래 층위의 ‘무엇’ 이 된다. 더 쓸모 있는 구분은 환경에 대한 기술(R, K)과 기계에 대한 기술(S)이다.
  • “테스트가 다 통과했으니 요구사항을 만족한다.” 테스트는 S 를 확인할 뿐이다. K 를 확인하지 않은 시스템은 실험실에서만 맞다.
  • “이번에는 요구사항을 확정하고 시작하자.” 진화는 정의에 포함된 성질이다. 확정이 아니라 변경 비용이 낮은 구조(작은 증분, 추적성, 자동화된 인수 테스트)를 목표로 한다.
  • 확인을 문서 리뷰로 대신한다. 리뷰는 주로 검증이다. 문서에 고개를 끄덕이는 것과 시스템을 받아들이는 것은 다르다.

확인 문제

  1. Zave 의 정의에서 “현실 세계의 목표” 를 강조하는 것이 실무에 주는 의미는?
  2. S, K ⊢ R 에서 K 가 거짓일 때 어떤 일이 생기는가? 이 글의 예 말고 하나를 들어 보라.
  3. 검증과 확인을 구분하고, 요구사항 단계에서 각각의 대표 기법을 하나씩 들라.
  4. 요구 기록에 가정(assumption) 칸을 두면 무엇이 좋아지는가?

풀이

  1. 기능 목록이 아니라 그 기능이 필요한 이유를 기록하게 만든다. 이유가 있어야 우선순위를 정하고, 더 싼 대안을 제안하고, 범위를 줄일 때 무엇을 지킬지 판단할 수 있다.
  2. 명세를 완벽히 구현해도 요구가 깨진다. 예: “사용자는 비밀번호를 남과 공유하지 않는다” 를 가정한 접근 통제는 계정 공유가 흔한 현장에서 “본인만 열람한다” 는 요구를 보장하지 못한다.
  3. 검증은 문서가 제대로 쓰였는지(모순·누락·모호함) — 인스펙션. 확인은 맞는 것을 적었는지(실제 필요와 일치) — 프로토타입이나 시나리오 워크스루.
  4. 명세가 기대는 세계의 성질이 드러나, 그 가정을 확인하는 활동을 계획할 수 있고, 가정이 깨졌을 때 영향받는 요구를 바로 찾을 수 있다.

더 읽을거리 (References)