[SW Engineering] 05. 요구사항 공학(Requirement Engineering)

 

이번 포스팅에서 다룰 주제는 소프트웨어 개발 프로젝트의 성패를 가르는 가장 기초적이면서도 중요한 단계, 바로 '요구사항 공학(Requirements Engineering)'입니다.

"고객이 원하는 것이 무엇인가?"를 정확히 파악하지 못하면, 아무리 코드를 잘 짜도 결국 실패한 프로젝트가 됩니다. 따라서 이번 글에서는 요구사항의 정의와 종류부터, 제대로 작성하는 법(가이드라인), 그리고 확실하게 검증하는 기법까지 상세하게 정리합니다.

1. 요구사항 공학이란? (What is Requirements Engineering?)

요구사항 공학은 고객이 시스템에 요구하는 서비스와 시스템이 운영되고 개발될 때의 제약조건을 확립하는 과정입니다.

• 요구사항(Requirement): 서비스에 대한 고수준의 추상적인 진술부터 상세한 수학적 명세까지 다양합니다. 이는 입찰의 기초가 되기도 하고(추상적), 계약 그 자체가 되기도 하기 때문입니다(구체적).

1) 요구사항의 유형

1. 사용자 요구사항 (User requirements): 고객을 위해 자연어와 다이어그램으로 작성된 서비스 및 제약조건입니다.
2. 시스템 요구사항 (System requirements): 계약의 일부가 될 수 있는, 시스템 기능과 제약조건에 대한 상세하고 구조화된 문서입니다.

애자일(Agile)에서의 요구사항

애자일 방법론에서는 상세한 시스템 요구사항 문서를 만드는 것을 시간 낭비로 보기도 합니다. 대신 사용자 스토리(User stories) 형태로 요구사항을 점진적으로 표현합니다.

2. 요구사항의 분류: 기능 vs 비기능

요구사항은 크게 기능적 요구사항, 비기능적 요구사항, 그리고 도메인 요구사항으로 나뉩니다.

1) 기능적 요구사항 (Functional Requirements)

시스템이 무엇을 해야 하는지(What the system should do)를 정의합니다.

• 특정 입력에 어떻게 반응하고, 특정 상황에서 어떻게 동작해야 하는지 기술합니다.
• 시스템이 해서는 안 되는 것을 명시하기도 합니다.

예시: 테트리스 게임

• 블록은 초당 한 줄의 속도로 떨어져야 한다.
• 사용자는 블록을 좌우, 아래로 이동시키거나 90도 회전할 수 있어야 한다.
• 게임을 일시 정지(Pause)할 수 있는 키가 있어야 한다.

• 주의점: "게임을 끝낸다(End)"라는 표현이 개발자에게는 '일시 중지 후 메뉴로 이동', 사용자에게는 '프로그램 종료'로 해석될 수 있는 것처럼 모호함을 피해야 합니다. 요구사항은 원칙적으로 완전(Complete)하고 일관성(Consistent) 있어야 합니다.

2) 비기능적 요구사항 (Non-functional Requirements)

시스템의 속성이나 제약조건(Constraints)을 정의합니다.

• 신뢰성, 응답 시간, 저장 공간 요구사항 등이 포함됩니다.
• 특정 IDE나 언어 사용 같은 프로세스 제약도 포함될 수 있습니다.
• 중요성: 비기능 요구사항을 만족하지 못하면 시스템 자체가 쓸모없어질 수 있어, 기능 요구사항보다 더 치명적일 수 있습니다.

검증 가능한 비기능 요구사항

"사용하기 쉬워야 한다" 같은 모호한 목표(Goal)보다는, 객관적으로 테스트 가능한 검증 가능한(Verifiable) 형태로 작성해야 합니다.

속성	측정 지표 (Metrics) 예시
속도	초당 처리 트랜잭션 수, 이벤트 응답 시간
사용 편의성	훈련 시간, 도움말 프레임 수
신뢰성	고장 간 평균 시간(MTTF), 가용성(Availability)
견고성	고장 후 복구 시간

MTTF, Availability 등은 이후에 구체적으로 다룰 예정입니다.

3) 도메인 요구사항 (Domain Requirements)

놓치기 쉬운 것이 바로 도메인 요구사항입니다.

• 시스템이 운영되는 도메인(분야)의 특성 때문에 생기는 제약조건입니다.
• 주의: 고객이 따로 말하지 않아도 해당 분야의 법규나 물리적 법칙 때문에 반드시 지켜야 하는 사항들입니다. 도메인 전문가들은 이를 너무 당연하게 여겨 인터뷰 때 말해주지 않는 경우가 많으므로 주의 깊게 파악해야 합니다.

 

3. 요구사항 공학 프로세스

요구사항 공학은 일반적으로 다음 4가지 활동이 반복적(Iterative)으로 수행됩니다.

1. 도출 (Elicitation)
2. 분석 (Analysis)
3. 검증 (Validation)
4. 관리 (Management)

4. 요구사항 도출 및 분석 (Elicitation and Analysis)

소프트웨어 엔지니어는 이해관계자(Stakeholders)와 함께 시스템이 제공해야 할 서비스, 도메인 정보, 제약조건 등을 찾아냅니다.

1) 도출의 어려움

• 이해관계자는 자신이 진짜 무엇을 원하는지 모를 때가 많습니다.
• 이해관계자마다 요구사항이 충돌할 수 있습니다.
• 분석 과정 중에 요구사항이 계속 변합니다.

2) 도출 기법

• 인터뷰 (Interviewing): 미리 준비된 질문을 하는 폐쇄형 인터뷰와 이슈를 탐색하는 개방형 인터뷰가 있습니다.
• 민족지학 (Ethnography): 사회과학자가 사용자가 일하는 현장을 직접 관찰합니다. 사용자가 말로 설명하지 못하는 실제 업무 흐름(암묵적 지식)을 파악하는 데 효과적입니다.
• 스토리와 시나리오 (Stories and Scenarios): 실제 시스템 사용 예시를 통해 이해관계자가 쉽게 공감하고 피드백할 수 있게 합니다.

예시: 자취방 구하기 서비스 (똘똘이 이야기) 

• 상황: 설곽이는 방을 구할 때마다 일일이 비교하고 방문하는 게 번거롭다.
• 기능 요청 1: 예산, 반려동물 여부, 학교 거리 등을 입력하면 맞는 방을 보여달라.
• 기능 요청 2 (카드 내역 연동): 마음에 드는 방을 고르면, 내 카드 내역을 분석해 자주 가던 상점과의 거리를 계산해 달라.

 

5. 요구사항 명세 (Requirements Specification)

수집된 요구사항을 문서로 작성하는 과정입니다. 이때 '어떻게 작성하느냐'가 매우 중요합니다.

1) 자연어 명세의 문제점

자연어(Natural language)는 직관적이지만 다음과 같은 3가지 문제가 발생하기 쉽습니다.

1. 명확성 부족 (Lack of clarity): 읽기 쉽게 쓰려다 정확성을 잃을 수 있습니다.
2. 요구사항 혼동 (Requirements confusion): 기능/비기능 요구사항을 구분하지 않고 섞어 쓰는 경우가 많습니다.
3. 요구사항 융합 (Requirements amalgamation): 여러 요구사항을 한 문장에 뭉뚱그려 표현하여 개발자가 놓치게 만듭니다.

2) 좋은 요구사항 작성을 위한 가이드라인

위의 문제를 피하기 위해 다음 원칙을 반드시 지켜야 합니다.

• 표준 포맷 사용: 모든 요구사항에 대해 표준화된 양식(템플릿)을 만들어 사용합니다.
• 일관된 용어 사용 (Shall vs Should):
  • Shall: 반드시 지켜야 하는 필수 요구사항에 사용합니다.
  • Should: 있으면 좋은 바람직한 요구사항에 사용합니다.
• 텍스트 강조: 요구사항의 핵심 부분은 굵게 표시하거나 하이라이트 합니다.
• 전문 용어 지양: 컴퓨터 공학 전문 용어(Jargon) 사용을 피합니다.
• 근거(Rationale) 포함: 왜 이 요구사항이 필요한지 이유를 함께 적습니다.

5.3 구조화된 명세 (Structured Specifications)

자연어의 한계를 보완하기 위해 표준 양식(Form)을 사용할 때는 다음 항목들을 구체적으로 정의해야 합니다.

• 기능 정의: 무엇을 하는 기능인가?
• 입력 (Inputs): 입력값은 무엇이며 어디서 오는가?
• 출력 (Outputs): 출력값은 무엇이며 어디로 가는가?
• 동작 (Action): 구체적으로 어떤 액션을 취하는가?
• 선후 조건 (Pre/Post conditions): 기능 실행 전제 조건과 실행 후 상태.
• 부작용 (Side effects): 기능 실행으로 인해 발생하는 부수적인 효과.

 

6. 요구사항 검증 (Requirements Validation)

요구사항이 고객이 진짜 원하는 것을 정의했는지 확인합니다. 배포 후 요구사항 오류를 수정하는 비용은 구현 오류 수정 비용의 최대 100배가 들 수 있기 때문에 매우 중요합니다.

1) 검증 체크리스트

• 유효성 (Validity): 고객의 필요를 충족하는가?
• 일관성 (Consistency): 충돌하는 요구사항은 없는가?
• 완전성 (Completeness): 모든 기능이 포함되었는가?
• 현실성 (Realism): 예산과 기술로 구현 가능한가?
• 검증 가능성 (Verifiability): 테스트할 수 있는가?

2) 🛠️ 구체적인 검증 기법

체크리스트를 눈으로만 보는 것이 아니라, 실제로 다음 활동들을 수행해야 합니다.

1. 요구사항 리뷰 (Requirements reviews): 팀원들이 모여 요구사항 문서를 체계적으로 읽고 수동으로 분석합니다.
2. 프로토타이핑 (Prototyping): 시스템의 실행 가능한 모델(프로토타입)을 빠르게 만들어 고객에게 직접 보여주고 확인받습니다.
3. 테스트 케이스 생성 (Test-case generation): 요구사항을 보고 테스트 케이스를 미리 만들어 봅니다.
   • Tip: 만약 테스트 케이스를 만들기 어렵다면? 그 요구사항은 검증 불가능(Not verifiable)하거나 모호한 것이므로 수정해야 합니다.

 

7. 요구사항 변경 관리 (Requirements Management)

시스템 설치 후에도 비즈니스 우선순위 변경, 새로운 하드웨어 도입, 법규 변경 등으로 인해 요구사항은 항상 변합니다.

따라서 변경 제안을 공식적으로 접수하고, 시스템에 미치는 영향을 평가하여 반영하는 공식적인 프로세스를 통해 관리해야 합니다.

8. 요약

요구사항 공학은 단순히 고객의 말을 받아적는 것이 아닙니다. 기능/비기능 요구사항을 명확히 구분하고, 표준화된 포맷과 명확한 용어(Shall/Should)를 사용하여 명세해야 합니다. 또한 리뷰, 프로토타이핑, 테스트 케이스 생성 등의 기법을 통해 철저히 검증하고, 끊임없이 변하는 요구사항을 체계적으로 관리하는 것이 프로젝트 성공의 열쇠입니다.

 

물론 이 말들이 매우 추상적이지만 최대한 프로젝트 및 실무에서 적용해보려고 하면 점점 "코더"가 아니라 "엔지니어"의 길로 나아가는 방법이라고 생각합니다.