요구공학 - 고객의 요구사항을 효과적으로 정리하는 방법
요구사항이란 고객의 ‘의도’와 ‘기대’를 실현 가능한 언어로 바꾸는 과정입니다. 그러나 실무에서는 이 요구사항이 모호하거나, 누락되거나, 서로 충돌하는 경우가 많습니다. 이 글에서는 SI 프로젝트 품질 전문가의 관점에서, 고객의 요구를 어떻게 구조화하고, 누락 없이, 오해 없이 정리할 수 있는지를 요구공학 기반으로 설명합니다. ‘요구’가 ‘문제’가 되지 않도록 만드는 것이 실력입니다.
목차
요구사항이란 무엇인가?
요구사항(requirement)은 사용자의 문제를 해결하기 위해 시스템이 갖춰야 할 조건입니다. 단순히 ‘무엇을 하고 싶다’는 의지 표현을 넘어, 기능, 제약조건, 성능, 보안 등 다양한 속성으로 구성됩니다. 명확하고 완전한 요구사항은 프로젝트 성공의 핵심 기반입니다. IEEE 830 기준에 따르면, 요구사항은 식별 가능성, 검증 가능성, 일관성, 변경 용이성을 갖춰야 합니다.
요구사항의 종류와 식별 전략
요구사항은 기능적 요구사항(FR)과 비기능적 요구사항(NFR)으로 나뉩니다. 기능적 요구사항은 시스템이 ‘무엇을’ 해야 하는지를, 비기능적 요구사항은 ‘어떻게’ 해야 하는지를 다룹니다. 이를 식별하기 위해서는 사용자 인터뷰, 기존 시스템 분석, 유사 사례 벤치마킹 등을 활용해야 하며, 초기 단계에서 이 구분이 명확해야 이후 설계와 테스트도 명확해집니다.
| 구분 | 정의 | 예시 |
|---|---|---|
| 기능적 요구사항 (FR) | 시스템이 수행해야 할 기능 | 로그인, 결제처리, 통계생성 |
| 비기능적 요구사항 (NFR) | 성능, 보안, 확장성 등의 운영 조건 | 응답시간 2초 이내, 99.9% 가용성 |
요구사항을 발굴하는 5가지 실전 기법
고객의 말만 듣고는 진짜 요구를 파악하기 어렵습니다. 요구공학에서는 다양한 발굴 기법을 통해 숨어있는 요구를 체계적으로 추출합니다.
- 인터뷰(Interview): 1:1 혹은 소그룹 질의응답을 통한 요구 파악
- 워크숍(Workshop): 다양한 이해관계자가 동시에 참여하는 협업 방식
- 관찰(Observation): 실제 업무 수행 장면을 관찰하여 숨은 요구 추출
- 문서분석(Document Analysis): 기존 시스템, 보고서, 규정 등 분석
- 프로토타입(Prototype): 요구사항 시각화를 통해 피드백 획득
요구사항 검증, 누락과 오해를 방지하는 기술
요구사항 정리 후 반드시 검증 작업이 필요합니다. 검증은 단순히 ‘맞나요?’라고 묻는 것이 아니라, 의도와 문서가 일치하는지를 다양한 관점에서 확인하는 것입니다. IEEE 기준에서는 검증 기준으로 명확성, 일관성, 완전성, 검증 가능성 등을 제시하며, 고객뿐 아니라 개발자, QA, 기획자 등 다각적 관점에서 리뷰하는 것이 좋습니다.
모델링을 활용한 요구사항 시각화
고객은 글보다 그림에 반응합니다. UML이나 BPMN과 같은 모델링 기법을 활용하면 요구사항의 흐름과 구조를 명확히 전달할 수 있습니다. 특히 Use Case Diagram은 사용자의 목표와 시스템의 행위를 쉽게 표현할 수 있어 요구공학 초반 단계에 자주 사용됩니다. Activity Diagram은 업무 플로우를 정리하는 데 효과적이죠.
| 도구 | 주요 용도 | 활용 예시 |
|---|---|---|
| Use Case Diagram | 사용자 목표 중심 기능 정의 | 회원가입, 주문처리 흐름 |
| Activity Diagram | 업무 플로우 정리 | 신청→심사→승인 흐름 |
| BPMN | 프로세스 단위 비즈니스 흐름 표현 | 콜센터 처리 프로세스 |
요구사항 정리 체크리스트
- 기능과 비기능 요구가 구분되었는가?
- 각 요구는 명확하고 측정 가능한가?
- 이해관계자 모두가 해당 요구에 동의했는가?
- 중복, 모순, 누락 요구는 없는가?
- 요구사항 변경관리 프로세스가 정의되어 있는가?
변경관리 프로세스를 사전에 정의하고, 영향도 분석을 통해 일정·비용·품질 측면에서 평가 후 수용 여부를 결정해야 합니다.
감정이 아닌 데이터로 변경 여부를 판단해야 합니다.
인터뷰만으로는 숨겨진 요구를 파악하기 어렵습니다. 관찰, 문서분석, 프로토타입 등 다양한 기법의 병행이 필요합니다.
말보다 행동에서 진짜 요구가 드러납니다.
Use Case는 전체 기능을 조망하기엔 좋지만, 세부 흐름이나 조건 분기 표현에는 한계가 있습니다. Activity Diagram과 병행해야 합니다.
전략적 조합이 요구의 흐름을 명확히 보여줍니다.
우선순위 기반 조정, 이해관계자 간 중재, 영향도 분석 등을 통해 조율합니다. 비즈니스 가치가 가장 높은 요구부터 정리하는 것이 핵심입니다.
의사결정 기준 없이 충돌은 영원히 반복됩니다.
불가능합니다. 요구는 항상 진화하며, 변화에 대응하는 유연한 설계와 관리 프로세스가 요구공학의 핵심입니다.
요구의 변화는 리스크가 아니라 진화의 신호입니다.
요구공학은 단순한 요구사항 수집이 아닙니다. 고객의 니즈를 발굴하고 구조화하며, 설계·개발·테스트까지 일관되게 전달되는 체계를 만드는 것입니다. 요구사항은 문서가 아니라 ‘약속’이며, 프로젝트 성패를 좌우하는 계약서입니다. 실전에서 유용한 정리 방법과 도구를 익히는 것이야말로 품질의 출발점입니다. 이 글이 여러분의 요구공학 실력을 한 단계 높이는 계기가 되길 바랍니다.
요구공학, 요구사항정리, 요구사항관리, 요구사항검증, 소프트웨어요구, 요구모델링, SI요구사항, 시스템분석, 비즈니스요구, 요구정의