레슨 04: 요구사항 공학(Requirements Engineering)¶

이전: 03. 애자일과 반복 개발 | 다음: 05. 소프트웨어 모델링과 UML

요구사항 공학(Requirements Engineering)은 모든 소프트웨어 프로젝트의 성패를 좌우하는 토대입니다. 연구에 따르면, 요구사항 단계에서 발생한 오류 — 잘못 이해된 기능, 누락된 제약, 상충되는 목표 — 는 시스템이 배포된 이후에 수정할 때 초기에 발견했을 때보다 10배에서 100배 더 많은 비용이 든다고 일관되게 밝히고 있습니다. 이 레슨은 요구사항의 전체 생명주기를 다룹니다: 이해관계자가 실제로 필요로 하는 것을 발견하고, 그 필요를 정확히 문서화하고, 검증하고, 프로젝트가 발전함에 따라 통제하는 과정입니다.

난이도: ⭐⭐⭐

선수 학습: - 레슨 01 — 소프트웨어 공학이란 무엇인가 - 레슨 02 — 소프트웨어 개발 생명주기 - 레슨 03 — 애자일과 반복 개발

학습 목표: - 기능 요구사항(Functional Requirements)과 비기능 요구사항(Non-Functional Requirements) 및 제약(Constraints)을 구별한다 - 주어진 이해관계자 상황에 적합한 도출(Elicitation) 기법을 적용한다 - SMART 기준과 IEEE 830 / ISO 29148 품질 기준을 충족하는 요구사항을 작성한다 - 잘 구조화된 소프트웨어 요구사항 명세서(Software Requirements Specification, SRS)를 작성한다 - Given/When/Then 형식의 인수 기준(Acceptance Criteria)과 함께 사용자 스토리를 작성한다 - 요구사항 추적성 매트릭스(Requirements Traceability Matrix, RTM)를 구축하고 활용한다 - MoSCoW와 카노 모델(Kano model)을 사용하여 요구사항 우선순위를 정한다 - 프로젝트 전반에 걸쳐 요구사항 변경을 관리하는 전략을 설명한다

1. 요구사항이란 무엇인가?¶

요구사항(requirement)은 이해관계자를 만족시키기 위해 시스템이 수행해야 하는 것 또는 갖춰야 하는 품질에 대한 서술입니다. 요구사항은 소프트웨어가 필요한 사람과 그것을 만드는 사람 사이의 계약을 형성합니다. 요구사항을 올바르게 파악하는 것은 공학에서 가장 어려운 지적 과제 중 하나입니다. 왜냐하면 요구사항은 인간의 의도 — 모호하고 문맥에 의존적이며 종종 부분적으로 무의식적인 — 와 명확하고 검증 가능해야 하는 전산적 명세 사이의 간극을 이어야 하기 때문입니다.

1.1 기능 요구사항(Functional Requirements)¶

기능 요구사항(FR)은 시스템이 나타내야 하는 행동(behaviors)을 기술합니다: 허용되는 입력, 수행하는 계산, 생성하는 출력입니다.

예시: - "시스템은 등록된 사용자가 등록된 이메일 주소로 발송된 6자리 코드를 통해 비밀번호를 재설정할 수 있도록 해야 한다." - "결제 서비스는 거래의 99%에 대해 2초 이내에 신용카드 승인을 완료해야 한다."

기능 요구사항은 시스템이 무엇을 해야 하는가?라는 질문에 답합니다.

1.2 비기능 요구사항(Non-Functional Requirements)¶

비기능 요구사항(NFR) — 품질 속성(quality attributes) 또는 시스템 품질(system qualities)이라고도 불림 — 은 시스템이 기능을 얼마나 잘 수행하는지를 기술합니다. 특정 기능을 지시하지 않으면서 해결책의 공간을 제한합니다.

범주	예시
성능(Performance)	응답 시간, 처리량, 지연 시간
신뢰성(Reliability)	MTBF, 가용성(예: 99.9% 가동 시간)
보안(Security)	인증, 인가, 데이터 암호화
사용성(Usability)	학습 용이성, 접근성(WCAG 2.1 AA)
유지보수성(Maintainability)	모듈성, 테스트 가능성, 기술 부채 한계
확장성(Scalability)	동시 사용자, 수평/수직 확장
이식성(Portability)	지원 운영체제, 브라우저
규정 준수(Compliance)	GDPR, HIPAA, PCI-DSS

NFR은 전체 시스템에 걸쳐 영향을 미치기 때문에 기능 요구사항보다 아키텍처적으로 더 중요한 경우가 많습니다. "시스템은 99.99%의 시간 동안 가용해야 한다"는 요구사항은 모든 레이어에서 이중화, 장애 조치 메커니즘, 모니터링을 강제합니다.

1.3 제약(Constraints)¶

제약은 엄밀히 기능적이거나 비기능적이지 않으면서 설계 선택지를 제거하는 요구사항입니다:

"시스템은 Python 3.11 이상으로 구현해야 한다."
"시스템은 고객의 온프레미스 VMware 클러스터에 배포해야 한다."
"프로젝트는 6개월 이내에 초기 릴리스를 제공해야 한다."

1.4 요구사항 계층구조¶

요구사항은 다양한 추상화 수준에 존재합니다:

비즈니스 요구사항    (WHY — 비전, 목표, ROI)
        |
사용자 요구사항      (WHO/WHAT — 사용자 목표, 유스케이스)
        |
시스템 요구사항      (WHAT — 상세 기능 + NFR)
        |
설계 제약           (HOW — 기술, 플랫폼 선택)

프로젝트 실패의 일반적인 원인은 시스템 수준의 요구사항을 비즈니스 목표인 것처럼 취급하거나, 사용자 요구가 이해되기 전에 설계 제약으로 곧장 건너뛰는 것입니다.

2. 요구사항 공학 프로세스¶

요구사항 공학(RE)은 단일 단계가 아니라 다섯 가지 긴밀하게 연결된 활동으로 구성된 지속적인 프로세스입니다.

  ┌─────────────┐
  │    도출     │  ← 이해관계자 요구 발견
  └──────┬──────┘
         │
  ┌──────▼──────┐
  │    분석     │  ← 충돌 해결, 모델링, 우선순위 결정
  └──────┬──────┘
         │
  ┌──────▼───────────┐
  │      명세        │  ← 정확하고 검증 가능한 요구사항 작성
  └──────┬───────────┘
         │
  ┌──────▼──────┐
  │    검증     │  ← 요구사항의 정확성 및 완전성 확인
  └──────┬──────┘
         │
  ┌──────▼──────┐
  │    관리     │  ← 요구사항 추적, 변경 통제, 추적성 유지
  └─────────────┘

실무에서는 이러한 활동들이 프로젝트 전반에 걸쳐 반복됩니다. 폭포수 프로젝트에서도 요구사항은 설계와 테스트 과정에서 다시 나타납니다.

2.1 도출(Elicitation)¶

도출은 이해관계자 및 기타 출처로부터 요구사항을 발견하는 프로세스입니다. 가장 인력 집약적인 단계이며 간극이 가장 많이 발생하는 단계입니다.

주요 어려움: - 이해관계자들은 잘못된 것을 보기 전까지 자신이 원하는 것을 알지 못함 - 도메인 전문가는 자신의 도메인은 알지만 기술이 무엇을 할 수 있고 없는지는 모름 - 서로 다른 이해관계자들이 상충되는 목표를 가짐 - 암묵적 지식(사람들이 "당연히 아는" 것)은 자발적으로 명시화되는 경우가 드묾

2.2 분석(Analysis)¶

분석 단계에서 엔지니어는: - 이해관계자 요구사항 간의 충돌을 감지하고 해결함 - 중복되거나 동일한 요구사항을 파악함 - 실현 가능성(기술적, 재정적, 일정)을 검토함 - 시스템에 대해 추론하기 위해 모델(유스케이스, 데이터 흐름도, 엔터티-관계 다이어그램)을 구축함

2.3 명세(Specification)¶

명세는 문서화된 산출물 — 소프트웨어 요구사항 명세서(SRS), 사용자 스토리 백로그 또는 이와 동등한 것 — 을 생성하며, 여기서 요구사항은 검증 가능할 만큼 정확하게 서술됩니다.

2.4 검증(Validation)¶

검증은 이것이 올바른 요구사항인가?를 묻습니다. 이는 시스템이 요구사항을 올바르게 구현하는지 묻는 확인(verification)과 구별됩니다. 검증 기법에는 다음이 포함됩니다:

구조적 워크스루(walkthrough) 및 검토
프로토타이핑
테스트 케이스 도출 (테스트를 작성할 수 없다면 요구사항이 너무 모호한 것일 수 있음)
공식 검사(Fagan inspection)

2.5 관리(Management)¶

요구사항 관리는 다음을 포함합니다: - 통제된 저장소에 요구사항 저장 - 상태 추적 (제안됨, 승인됨, 구현됨, 테스트됨, 폐기됨) - 공식 변경 통제 위원회(CCB, Change Control Board)를 통한 변경 요청 처리 - 추적성 링크 유지

3. 도출 기법¶

단일 기법이 모든 프로젝트나 모든 이해관계자 그룹에 효과적이지는 않습니다. 숙련된 요구사항 엔지니어는 여러 기법을 조합합니다.

3.1 인터뷰(Interviews)¶

이해관계자와의 일대일 또는 소그룹 대화. 인터뷰는 다음과 같은 형태가 있습니다:

구조화(Structured): 고정된 질문 세트, 다수의 이해관계자에 걸쳐 일관성 확보에 적합
비구조화(Unstructured): 자유로운 대화, 예상치 못한 우려 사항 발견에 적합
반구조화(Semi-structured): 후속 질문에 유연성을 허용하는 주제 가이드

팁: - 개방형 질문을 하세요: "대시보드가 필요하신가요?" 대신 "일반적인 업무 하루를 설명해 주세요" - 진술된 요구 아래의 실제 필요를 파악하기 위해 5 Why(다섯 번의 왜) 기법을 사용하세요 - (허락을 받고) 녹음하고 전사하세요; 기억은 신뢰할 수 없습니다

3.2 설문지와 설문조사(Questionnaires and Surveys)¶

이해관계자가 많거나 지리적으로 분산된 경우, 설문조사는 인터뷰가 할 수 없는 규모로 확장할 수 있습니다. 다음에 가장 적합합니다:

기존 활동의 빈도 수량화 ("이 보고서를 얼마나 자주 생성하나요?")
알려진 대안들 중 선호도 순위 결정
더 넓은 모집단을 대상으로 인터뷰에서 도출된 결론을 검증

한계점: 설문조사는 예상치 못한 답변을 탐색할 수 없습니다.

3.3 관찰(Observation, 민족지학적 방법)¶

분석가가 방해 없이 자연스러운 업무 환경에서 사용자를 관찰합니다. 이는 사용자가 자동화되어 인터뷰에서 명시화할 수 없는 암묵적 지식을 드러냅니다:

"나는 항상 주문을 입력하기 전에 팩스 기계를 확인한다" (어디에도 문서화되지 않은 단계)
화면이 실제로 사용되는 순서 (의도된 순서와 다를 수 있음)

3.4 워크숍(JAD / Requirements Workshops)¶

공동 애플리케이션 개발(JAD, Joint Application Development) 세션은 이해관계자, 개발자, 진행자를 하루에서 여러 날 동안 함께 모읍니다. 이점:

모든 관계자가 참석한 상태에서 실시간으로 결정이 내려짐
충돌이 즉시 표면화되고 해결됨
공유된 이해가 빠르게 형성됨

강한 진행 능력이 필요합니다; 잘못 운영된 워크숍은 이해관계자를 양극화할 수 있습니다.

3.5 프로토타이핑(Prototyping)¶

저충실도 프로토타입(종이 스케치, 와이어프레임 또는 클릭스루 목업)은 이해관계자가 구체적인 것에 반응함으로써 원하는 것을 명시화하는 데 도움을 줍니다. 이는 UI 중심 애플리케이션에 특히 효과적입니다.

유형: - 폐기형(Throwaway/Exploratory): 요구사항 도출만을 위해 구축된 후 폐기됨 - 진화형(Evolutionary): 정제되어 결국 실제 시스템이 됨

위험: 이해관계자들이 프로토타입이 최종 제품 일정을 나타낸다고 가정할 수 있음

3.6 유스케이스(Use Cases)¶

유스케이스는 사용자(액터)가 목표를 달성하기 위해 시스템과 상호작용하는 방법을 설명하는 시나리오입니다. 유스케이스는 이해관계자와 협력하여 도출하는 기법이자 명세 산출물이기도 합니다. 비기술적인 이해관계자가 접근할 수 있는 내러티브 형식으로 기능 요구사항을 포착합니다.

3.7 문서 분석(Document Analysis)¶

기존 문서 검토: 현재 시스템 매뉴얼, 비즈니스 프로세스 설명, 규제 기준, 경쟁사 제품, 산업 표준. 레거시 시스템을 교체할 때 유용합니다.

3.8 브레인스토밍(Brainstorming)¶

참여자들이 즉각적인 비판 없이 아이디어를 생성하는 촉진된 아이디어 발상 세션입니다. 요구사항으로 좁히기 전에 해결책 공간을 확장하기 위해 초기에 유용합니다.

4. 좋은 요구사항 작성법¶

모호하거나 테스트 불가능하거나 모순된 요구사항은 요구사항이 전혀 없는 것보다 더 나쁩니다 — 무언가가 결정되었다는 거짓된 인식을 만들기 때문입니다.

4.1 SMART 기준¶

글자	의미	확인 질문
S	구체적(Specific)	무엇이 필요한지 명확한가?
M	측정 가능(Measurable)	충족 여부를 검증할 수 있는가?
A	달성 가능(Achievable)	기술적·경제적으로 실현 가능한가?
R	관련성 있음(Relevant)	실제 이해관계자 요구로 추적 가능한가?
T	시간 제한(Time-bound)	마감 또는 버전 목표가 있는가?

4.2 일반적인 요구사항 결함¶

결함	예시	수정
모호함	"시스템은 빠르게 응답해야 한다"	"95번째 백분위수에서 200ms 미만"으로 명시
검증 불가	"시스템은 사용자 친화적이어야 한다"	사용성 지표 정의 (예: 작업 완료율 > 90%)
복합 요구사항	"시스템은 모든 이벤트를 로그 기록하고 보관해야 한다"	두 개의 별도 요구사항으로 분리
설계를 내포	"시스템은 관계형 데이터베이스를 사용해야 한다"	필요성을 서술: "데이터는 영구적이고 쿼리 가능해야 한다"
수동태 함정	"오류는 처리되어야 한다"	"시스템은 검증 실패를 감지한 후 1초 이내에 사용자에게 오류 메시지를 표시해야 한다"
무한정	"시스템은 모든 브라우저를 지원해야 한다"	지원되는 특정 브라우저와 최소 버전 목록 명시

4.3 IEEE 830 / ISO 29148 품질 속성¶

IEEE 830 표준 (현재 ISO/IEC/IEEE 29148:2018로 대체됨)은 개별 요구사항에 대한 품질 속성을 정의합니다:

정확함(Correct): 이해관계자 요구를 정확하게 반영함
명확함(Unambiguous): 단 하나의 해석만 존재함
완전함(Complete): 구현하거나 테스트하는 데 필요한 정보가 누락되지 않음
일관성(Consistent): 다른 요구사항과 모순이 없음
순위 매김(Ranked) (중요도/안정성 기준): 우선순위와 변동성이 알려져 있음
검증 가능(Verifiable): 요구사항이 충족되었음을 확인할 수 있는 테스트가 최소한 하나 이상 존재함
수정 가능(Modifiable): 변경이 일관되게 이루어질 수 있도록 구조화됨
추적 가능(Traceable): 출처가 알려져 있으며 설계와 테스트로 순방향 추적이 가능함

4.4 언어 관례¶

조동사를 일관되게 사용하세요: - Shall(해야 한다) — 필수 요구사항 - Should(해야 한다, 권장) — 권장 사항 (바람직하지만 필수가 아님) - May(할 수 있다) — 선택 사항 - Will(일 것이다) — 세계에 대한 사실 서술 (요구사항이 아님)

모든 요구사항은 단일하고 식별 가능한 주체 (누가 또는 무엇이 무언가를 해야 하는지)를 참조해야 합니다:

나쁜 예: "비밀번호는 최소 여덟 자 이상이어야 한다."
좋은 예: "시스템은 여덟 자 미만의 비밀번호를 거부하고
       '비밀번호는 최소 8자 이상이어야 합니다.'라는 메시지를 표시해야 한다."

5. 소프트웨어 요구사항 명세서¶

소프트웨어 요구사항 명세서(SRS, Software Requirements Specification)는 요구사항 공학의 주요 산출물입니다. IEEE 830은 표준 구조를 제공하며; ISO/IEC/IEEE 29148이 이를 개선했습니다.

5.1 표준 SRS 구조¶

1. 소개(Introduction)
   1.1 목적(Purpose)
   1.2 범위(Scope)
   1.3 정의, 두문자어, 약어(Definitions, Acronyms, Abbreviations)
   1.4 참조(References)
   1.5 개요(Overview)

2. 전체 설명(Overall Description)
   2.1 제품 관점(Product Perspective)
   2.2 제품 기능(Product Functions, 고수준 요약)
   2.3 사용자 클래스 및 특성(User Classes and Characteristics)
   2.4 운영 환경(Operating Environment)
   2.5 설계 및 구현 제약(Design and Implementation Constraints)
   2.6 사용자 문서(User Documentation)
   2.7 가정 및 의존성(Assumptions and Dependencies)

3. 시스템 기능(System Features, 기능 요구사항)
   3.x 기능명
      3.x.1 설명 및 우선순위(Description and Priority)
      3.x.2 자극/응답 시퀀스(Stimulus/Response Sequences)
      3.x.3 기능 요구사항(Functional Requirements)

4. 외부 인터페이스 요구사항(External Interface Requirements)
   4.1 사용자 인터페이스(User Interfaces)
   4.2 하드웨어 인터페이스(Hardware Interfaces)
   4.3 소프트웨어 인터페이스(Software Interfaces)
   4.4 통신 인터페이스(Communications Interfaces)

5. 비기능 요구사항(Non-Functional Requirements)
   5.1 성능 요구사항(Performance Requirements)
   5.2 안전 요구사항(Safety Requirements)
   5.3 보안 요구사항(Security Requirements)
   5.4 소프트웨어 품질 속성(Software Quality Attributes)
   5.5 비즈니스 규칙(Business Rules)

6. 기타 요구사항(Other Requirements)

부록(Appendices)
색인(Index)

5.2 실무에서의 SRS 작성¶

애자일 환경에서는 SRS가 다음으로 대체되거나 보완되는 경우가 많습니다: - 사용자 스토리의 제품 백로그 (살아있는 우선순위화된 목록) - 제품 비전 문서 ("왜" 및 "누구를 위해") - 각 스토리의 완료 기준(Definition of Done) 및 인수 기준(acceptance criteria)

그러나 안전 필수적, 규제적, 또는 계약적 소프트웨어(의료 기기, 항공 전자, 정부 조달)의 경우 공식 SRS는 법적·기술적으로 여전히 필요합니다.

5.3 요구사항 식별자¶

모든 요구사항은 추적성과 변경 통제를 지원하기 위해 고유하고 안정적인 식별자를 가져야 합니다:

SRS-FUNC-AUTH-001: The system shall authenticate users via username and password.
SRS-FUNC-AUTH-002: The system shall lock an account after five consecutive failed login attempts.
SRS-NFR-PERF-001: The authentication response shall complete within 500 ms for 99% of requests under normal load.

일반적인 명명 규칙: [DOC]-[TYPE]-[SUBSYSTEM]-[SEQ]

6. 사용자 스토리와 인수 기준¶

애자일 개발에서 요구사항은 종종 사용자 스토리 — 사용자 관점에서 기능에 대한 짧고 비공식적인 설명 — 로 표현됩니다.

6.1 사용자 스토리 템플릿¶

As a [role],
I want [feature/capability],
so that [benefit/value].

예시:

As a registered customer,
I want to save my shipping address to my account,
so that I do not have to re-enter it on future orders.

As a system administrator,
I want to receive an email alert when disk usage exceeds 80%,
so that I can take preventive action before storage runs out.

6.2 좋은 사용자 스토리를 위한 INVEST 기준¶

글자	의미
I	독립적(Independent) — 어떤 순서로도 개발 가능
N	협상 가능(Negotiable) — 대화를 통해 세부 사항 변경 가능
V	가치 있음(Valuable) — 이해관계자에게 가치를 제공
E	추정 가능(Estimable) — 팀이 노력을 추정할 수 있음
S	작음(Small) — 하나의 스프린트 내에 맞음
T	테스트 가능(Testable) — 인수 기준을 작성할 수 있음

6.3 인수 기준(Acceptance Criteria)¶

인수 기준은 스토리가 완료된 것으로 간주되는 조건을 정의합니다. Given/When/Then (Gherkin) 형식은 자동화를 가능하게 합니다:

Feature: Password Reset

  Scenario: Successful password reset via email
    Given a registered user with email "alice@example.com"
    And the user is on the "Forgot Password" page
    When the user enters "alice@example.com" and submits
    Then the system sends a reset code to "alice@example.com"
    And the user is shown the message "Check your email for a reset code"

  Scenario: Invalid email address
    Given a user is on the "Forgot Password" page
    When the user enters "notregistered@example.com" and submits
    Then the system shows the same success message
    And no email is sent
    # (security: do not reveal whether email exists)

  Scenario: Expired reset code
    Given a user received a reset code more than 30 minutes ago
    When the user submits the expired code
    Then the system displays "This code has expired. Request a new one."
    And the user is redirected to the "Forgot Password" page

Gherkin 시나리오는 자동화된 인수 테스트(예: Cucumber, Behave, SpecFlow)의 명세로도 활용됩니다.

6.4 에픽과 스토리 분할¶

스토리는 하나의 스프린트(1~2주) 내에 맞아야 합니다. 더 큰 항목은 에픽(epic)이라고 불리며 분할되어야 합니다. 일반적인 분할 패턴:

패턴	예시
사용자 역할별	"관리자가 사용자 관리" → 생성, 편집, 비활성화를 위한 별도 스토리
데이터 유형별	"보고서 내보내기" → CSV, PDF, Excel을 별도 스토리로
워크플로 단계별	"체크아웃 완료" → 장바구니 추가, 배송 입력, 결제 입력, 확인
정상/비정상 경로별	먼저 성공 경로; 오류 처리는 후속 스토리로
성능별	먼저 기능 스토리, 그 다음 성능 NFR 스토리

7. 요구사항 추적성¶

요구사항 추적성 매트릭스(RTM, Requirements Traceability Matrix)는 요구사항을 그 출처 및 구현하고 검증하는 산출물에 연결하는 표입니다.

7.1 추적성 유형¶

역방향 추적성(Backward traceability): 요구사항 → 출처 (이해관계자, 규정, 비즈니스 목표)
순방향 추적성(Forward traceability): 요구사항 → 설계 요소 → 코드 모듈 → 테스트 케이스

7.2 RTM 예시¶

요구사항 ID	설명	출처	설계 문서	코드 모듈	테스트 케이스
FR-AUTH-001	이메일/비밀번호를 통한 사용자 로그인	이해관계자 인터뷰 (J. Smith)	ARCH-3.2	auth/login.py	TC-AUTH-001
FR-AUTH-002	5회 연속 실패 후 계정 잠금	OWASP ASVS 2.2.1	ARCH-3.3	auth/lockout.py	TC-AUTH-005
NFR-PERF-001	로그인 < 500ms (p99)	클라이언트와의 SLA	ARCH-7.1	—	PT-001

7.3 추적성의 이점¶

영향 분석: 요구사항이 변경될 때 어떤 설계, 코드, 테스트가 영향을 받는지 즉시 파악
커버리지 분석: 모든 요구사항에 최소한 하나의 테스트가 있음을 보장
완전성 검사: 모든 설계 요소가 요구사항으로 추적됨을 보장 (금도금 방지)
규제 준수: 안전 필수 요구사항이 구현되고 테스트되었음을 증명

8. 요구사항 우선순위 결정¶

모든 요구사항이 동등하게 중요하거나 긴급한 것은 아닙니다. 우선순위 결정은 범위 결정, 릴리스 계획, 절충 협상을 안내합니다.

8.1 MoSCoW 방법¶

범주	의미	가이드
Must have(반드시 필요)	협상 불가; 없으면 제품 실패	노력의 약 60%; 항상 MVP에 포함
Should have(있어야 함)	높은 가치지만 출시에 필수는 아님	시간이 허용되면 포함
Could have(있으면 좋음)	없어도 영향이 적은 좋은 기능	이후 릴리스 목표
Won't have(이번 릴리스에 없음)	이번 릴리스 범위 밖	기대치 관리를 위해 공식적으로 제외

MoSCoW는 단순하며 비기술적인 이해관계자들도 널리 이해합니다. 주요 위험은 모든 이해관계자가 자신의 요구사항을 "Must have"에 원한다는 것입니다.

8.2 카노 모델(Kano Model)¶

카노 모델은 고객 만족에 미치는 효과에 따라 기능을 분류합니다:

범주	특성	예시
기본(Basic/Must-be)	예상됨; 없으면 불만족을 야기하지만 있어도 만족감을 주지 않음	로그인 작동; 데이터 저장됨
성능(Performance/Linear)	많을수록 좋음; 만족도가 수준에 따라 비례함	더 빠른 로드 시간, 더 높은 저장 용량
흥분(Excitement/Delighter)	예상치 못함; 있으면 기쁨을 주고 없어도 수용 가능	개인화된 추천
무관심(Indifferent)	고객이 어느 방향으로도 신경 쓰지 않음	일부 UI 크롬 요소
역방향(Reverse)	존재 자체가 불만족을 야기	강제적인 소셜 공유

카노 모델은 팀이 미충족된 기본 속성을 희생하면서 성능 속성에 과도하게 투자하는 것을 방지하는 데 도움을 줍니다.

8.3 가중 점수(Weighted Scoring)¶

각 요구사항에 가중 기준을 기반으로 점수를 할당합니다:

점수 = (비즈니스 가치 × 0.4) + (전략적 적합도 × 0.3) + (위험 감소 × 0.2) + (고객 요청 빈도 × 0.1)

요구사항은 그런 다음 점수에 따라 순위가 매겨집니다. 이는 MoSCoW보다 더 엄격하며 ROI 분석이 필요할 때 유용합니다.

8.4 가치 대 노력 매트릭스¶

요구사항을 2×2 그리드에 표시합니다:

높은 가치 │ 빠른 성과(Quick Wins) ★ │ 주요 프로젝트(Major Projects)
          │                         │
낮은 가치  │ 채우기(Fill-Ins)        │ 감사 없는 작업(Thankless Tasks) ✗
          └─────────────────────────┴──────────────
              낮은 노력                 높은 노력

빠른 성과를 우선하고; 주요 프로젝트를 계획하고; 채우기를 일정에 포함하고; 감사 없는 작업을 피하세요.

9. 변경되는 요구사항 관리¶

요구사항 변경은 불가피합니다 — 프로세스의 실패가 아닙니다. 연구에 따르면 프로젝트가 완료되기 전에 요구사항의 25~50%가 변경됩니다. 목표는 변경을 방지하는 것이 아니라 관리하는 것입니다.

9.1 요구사항 변경의 원인¶

이해관계자들은 작동하는 소프트웨어를 볼 때만 명확성을 얻음
비즈니스 환경이 발전함 (새로운 규제, 경쟁사 움직임, 시장 피드백)
기술적 발견이 원래 요구사항의 실현 불가능성을 드러냄
인사 변경 — 새로운 이해관계자가 새로운 우선순위를 가져옴

9.2 변경 통제 프로세스¶

1. 변경 요청(Change Request) 제출 (누구나)
   ↓
2. 영향 분석 (요구사항 엔지니어 + 아키텍트)
   → 영향받는 요구사항, 설계, 코드, 테스트
   → 일정 및 비용 영향
   ↓
3. 변경 통제 위원회(CCB) 검토
   → 승인 / 거부 / 연기
   ↓
4. 승인된 경우: SRS 업데이트, RTM 업데이트, 팀에 통보
   ↓
5. 변경 구현 및 검증

9.3 변동성 처리 전략¶

변동성 높은 요구사항 연기: 불안정한 항목을 이후 릴리스를 위한 "주차장" 백로그에 배치
확장성을 위한 설계: 변동성이 높은 영역이 최소한의 파급 효과로 변경될 수 있도록 시스템 아키텍처 구성
점진적 제공: 자주 작동하는 소프트웨어를 릴리스; 각 릴리스는 복잡해지기 전에 오해를 드러냄
스프린트 경계에서의 요구사항 워크숍: 정기적으로 검토 및 재우선순위화

9.4 기준선과 버전 관리¶

요구사항 기준선(requirements baseline)은 공식적으로 합의되고 형상 관리 하에 놓인 요구사항의 스냅샷입니다. 기준선 이후의 모든 변경은 공식 변경 요청이 필요합니다. 기준선은 명명되며 (예: "v1.0 기준선") 마일스톤 (계약 서명, 설계 검토, 코드 동결)에 대응합니다.

10. 도구¶

도구	유형	사용 사례
Jira	이슈 트래커 / 스토리 백로그	애자일 사용자 스토리 관리, 스프린트 계획
Azure DevOps	ALM 스위트	작업 항목, 보드, RTM 통합
IBM DOORS / DOORS Next	요구사항 관리	안전 필수, 규제, 대규모 프로젝트
Confluence	위키 / 문서화	SRS 작성, 이해관계자 협업
Figma / Balsamiq	프로토타이핑 / 와이어프레이밍	UI 요구사항 도출
Cucumber / Behave	BDD 테스트 자동화	실행 가능한 인수 기준 (Gherkin)
ReqIF	교환 형식	RE 도구 간 상호 운용성 (자동차, 항공우주)

11. 요약¶

요구사항 공학은 모호한 이해관계자의 의도를 정확하고 검증 가능한 명세로 변환합니다. 다섯 가지 핵심 활동 — 도출, 분석, 명세, 검증, 관리 — 은 프로젝트 전반에 걸쳐 반복적으로 수행됩니다.

주요 핵심 사항:

기능 요구사항은 행동을 기술하고; 비기능 요구사항은 품질 속성을 기술합니다. 둘 다 필요합니다.
도출은 인터뷰, 관찰, 워크숍, 프로토타이핑, 유스케이스 등 여러 기법이 필요한 인간적 활동입니다.
좋은 요구사항은 구체적이고, 측정 가능하고, 달성 가능하고, 관련성 있고, 시간 제한이 있어야 하며 (SMART) IEEE/ISO 품질 속성을 충족해야 합니다: 정확하고, 명확하고, 완전하고, 일관되고, 검증 가능하고, 추적 가능해야 합니다.
공식 SRS는 IEEE 830 / ISO 29148에 따라 구조화됩니다; 애자일 프로젝트는 일반적으로 Gherkin 인수 기준이 있는 사용자 스토리의 제품 백로그를 사용합니다.
모든 요구사항은 고유 식별자를 가져야 하며 출처, 설계 산출물, 테스트 케이스에 요구사항 추적성 매트릭스로 연결되어야 합니다.
빠른 합의를 위해 MoSCoW를 사용하거나 고객 만족을 이해하기 위해 카노 모델을 사용하여 우선순위를 정하세요.
요구사항은 반드시 변경됩니다; 공식 변경 요청, 영향 분석, 기준선 설정을 통해 변경을 관리하세요.

12. 연습 문제¶

연습 1: 요구사항 분류

다음 각각을 기능 요구사항(FR), 비기능 요구사항(NFR), 또는 제약(C)으로 분류하고 결함을 파악하세요:

a. "시스템은 빨라야 한다." b. "애플리케이션은 OAuth 2.0을 통해 사용자를 인증해야 한다." c. "시스템은 React 18을 사용하여 구현해야 한다." d. "체크아웃 페이지는 4G 연결에서 사용자의 95%에 대해 1.5초 이내에 로드되어야 한다." e. "모든 데이터는 암호화되고 매일 백업되어야 한다."

연습 2: 잘못된 요구사항 재작성

다음 잘못 작성된 요구사항을 SMART 및 ISO 29148 품질 기준을 충족하도록 재작성하세요:

a. "시스템은 많은 동시 사용자를 처리해야 한다." b. "UI는 직관적이어야 한다." c. "시스템은 정보를 저장하기 위해 데이터베이스를 사용해야 한다." d. "오류는 정상적으로 처리되어야 한다."

연습 3: 사용자 스토리와 인수 기준

도서관 관리 시스템을 구축하고 있습니다. 세 개의 사용자 스토리를 작성하세요 (도서관 회원 한 명, 사서 한 명, 관리자 한 명): 각각 최소 두 개의 Gherkin 인수 기준 시나리오를 포함하고, 스토리당 최소 하나의 시나리오는 오류나 경계 사례를 다뤄야 합니다.

연습 4: 요구사항 추적성 매트릭스

다음 요구사항을 바탕으로 최소한의 RTM을 설계하세요:

FR-001: 사용자는 제목, 저자 또는 ISBN으로 책을 검색할 수 있다.
FR-002: 사용자는 대출 중인 책에 예약을 걸 수 있다.
NFR-001: 최대 1,000개의 결과를 반환하는 쿼리에 대해 검색 결과는 2초 이내에 표시되어야 한다.

열을 추가하세요: 출처, 설계 참조, 구현 모듈, 테스트 케이스 ID. 요구사항별로 최소 하나의 테스트 케이스 ID를 생성하세요.

연습 5: 우선순위 결정

라이드 공유 앱 MVP를 위한 다음 후보 기능들이 있습니다. MoSCoW를 사용하여 분류하고 선택 이유를 설명하세요:

현재 위치에서 라이드 예약
예약 전 요금 추정
운전자와 승객 간의 앱 내 채팅
운전자 평점 및 리뷰
다중 정류장 라이드
라이드 이력 및 영수증
프로모션 할인 코드
라이드 중 실시간 GPS 추적
미래 라이드 예약
라이드별 탄소 상쇄 추적

13. 더 읽을거리¶

ISO/IEC/IEEE 29148:2018 — 요구사항 공학 프로세스 및 산출물에 관한 국제 표준
Wiegers, K. & Beatty, J. — Software Requirements (3rd ed., Microsoft Press, 2013) — 가장 포괄적인 실무 가이드
Cockburn, A. — Writing Effective Use Cases (Addison-Wesley, 2000) — 고전적인 유스케이스 참고서
Cohn, M. — User Stories Applied (Addison-Wesley, 2004) — 애자일 스토리 실무
Pohl, K. — Requirements Engineering: Fundamentals, Principles, and Techniques (Springer, 2010) — 엄밀한 학문적 처리
IREB — Certified Professional for Requirements Engineering (CPRE) Handbook — 자격증 단체 및 참조 용어집
OWASP ASVS — Application Security Verification Standard — 보안 NFR의 출처

이전: 03. 애자일과 반복 개발 | 다음: 05. 소프트웨어 모델링과 UML