요구사항 분석과 UML 다이어그램의 이해
소프트웨어 프로젝트가 실패하는 가장 큰 원인은 코드 결함이 아니라 잘못된 요구사항이라는 사실은 오랫동안 업계의 정설로 자리 잡고 있다. 미국의 스탠디시 그룹(Standish Group)이 발표하는 카오스 리포트(CHAOS Report)에서도 프로젝트 실패 요인의 상위에는 항상 모호한 요구사항, 변경되는 요구사항, 사용자 참여 부족이 자리하고 있다. 이러한 문제를 체계적으로 해결하기 위해 등장한 활동이 바로 요구사항 분석이며, 분석 결과를 시각적으로 표현하기 위한 표준 모델링 언어가 UML(Unified Modeling Language)이다. 정보처리기사 시험에서도 매회 출제되는 핵심 주제이며, 실무에서는 설계 산출물의 절반 이상이 UML 기반으로 작성되고 있다.
요구사항 분석의 단계와 핵심
요구사항 분석이란 사용자가 시스템에 기대하는 기능과 제약 조건을 식별하고, 이를 명확하고 일관성 있는 형태로 정리하는 활동을 가리킨다. 일반적으로 요구사항 개발 프로세스는 도출(Elicitation), 분석(Analysis), 명세(Specification), 확인(Validation)의 네 단계로 구성된다. 도출 단계에서는 인터뷰, 설문, 워크숍, 관찰, 기존 문서 분석 등의 다양한 기법을 활용해 이해관계자로부터 원시 요구사항을 수집한다. 분석 단계에서는 수집된 요구사항 사이의 충돌, 중복, 누락을 식별하고 우선순위를 부여한다.
요구사항은 크게 기능적 요구사항과 비기능적 요구사항으로 분류된다. 기능적 요구사항은 시스템이 무엇을 해야 하는지를 기술하는 항목으로, 로그인 처리, 주문 생성, 결제 승인과 같은 구체적인 기능을 지칭한다. 비기능적 요구사항은 성능, 보안, 가용성, 사용성, 확장성처럼 시스템이 어떻게 동작해야 하는지에 대한 품질 속성을 의미한다. 두 유형은 모두 중요하지만, 비기능적 요구사항은 측정 가능한 형태로 명세되어야 한다는 점에서 더 까다로운 작업으로 평가된다.
명세 단계에서는 분석된 요구사항을 SRS(Software Requirements Specification) 문서로 정형화하며, 이 과정에서 UML 다이어그램이 핵심 도구로 활용된다. 마지막 확인 단계에서는 명세된 요구사항이 이해관계자의 실제 요구를 정확히 반영하고 있는지 검증하고, 필요한 경우 도출 단계로 돌아가 보완한다. 좋은 요구사항은 완전성, 일관성, 명확성, 검증 가능성, 추적 가능성이라는 다섯 가지 특성을 모두 갖추어야 하며, 이러한 특성을 평가하는 작업이 요구사항 분석의 본질이라 할 수 있다.
UML 14개 다이어그램의 분류
UML은 1997년 OMG(Object Management Group)에 의해 표준화된 객체지향 모델링 언어로, 가장 최신 버전인 UML 2.5에서는 총 14개의 다이어그램을 제공한다. 이 14개 다이어그램은 시스템의 정적인 구조를 표현하는 구조 다이어그램(Structure Diagram) 7개와 시스템의 동적인 행위를 표현하는 행위 다이어그램(Behavior Diagram) 7개로 분류된다. 분석가는 표현하려는 관점이 무엇인지에 따라 적절한 다이어그램을 선택해야 하며, 모든 다이어그램을 작성할 필요는 없다.
구조 다이어그램에 속하는 일곱 가지는 다음과 같다. 클래스 다이어그램(Class Diagram)은 시스템을 구성하는 클래스와 그들 사이의 관계를 표현하며, 객체지향 설계의 가장 기본이 되는 산출물이다. 객체 다이어그램(Object Diagram)은 특정 시점의 객체 인스턴스를 표현하고, 컴포넌트 다이어그램(Component Diagram)은 모듈 단위의 구성 요소와 인터페이스를 보여준다. 배치 다이어그램(Deployment Diagram)은 하드웨어 노드와 소프트웨어 컴포넌트의 물리적 배치를 표현한다. 그 외에 복합 구조 다이어그램, 패키지 다이어그램, 프로필 다이어그램이 구조 다이어그램에 포함된다.
행위 다이어그램에 속하는 일곱 가지는 다음과 같다. 유스케이스 다이어그램(Use Case Diagram)은 시스템의 기능을 사용자 관점에서 표현하며, 요구사항 분석 단계에서 가장 먼저 작성되는 산출물이다. 시퀀스 다이어그램(Sequence Diagram)은 객체 간 메시지 교환을 시간 순서대로 표현하고, 활동 다이어그램(Activity Diagram)은 업무 흐름이나 알고리즘의 절차를 시각화한다. 상태 머신 다이어그램(State Machine Diagram)은 객체가 가질 수 있는 상태와 상태 간 전이를 표현한다. 그 외에 커뮤니케이션 다이어그램, 타이밍 다이어그램, 상호작용 개요 다이어그램이 행위 다이어그램에 포함된다.
요구사항 분석에서 자주 쓰이는 핵심 다이어그램
이론적으로는 14개의 다이어그램이 존재하지만, 실무의 요구사항 분석 단계에서 실제로 가장 자주 활용되는 것은 세 가지로 압축된다. 첫째는 유스케이스 다이어그램으로, 액터(Actor)와 시스템이 제공하는 기능 단위인 유스케이스, 그리고 그 사이의 관계를 표현한다. 액터는 시스템과 상호작용하는 외부 주체를 의미하며, 사람일 수도 있고 외부 시스템일 수도 있다. 유스케이스 사이에는 포함(include), 확장(extend), 일반화(generalization) 같은 관계가 정의되며, 이를 통해 기능의 재사용 구조와 선택적 흐름을 시각적으로 표현할 수 있다.
둘째는 시퀀스 다이어그램으로, 특정 시나리오에서 객체들이 어떤 순서로 메시지를 주고받는지를 시간 축을 따라 표현한다. 가로축에는 객체 또는 액터를 배치하고 세로축으로 시간이 흐르며, 객체 간 메시지 호출이 화살표로 그려진다. 동기 호출과 비동기 호출, 반환 메시지, 자기 호출, 활성 구간(activation bar) 등을 명확히 구분해 표기하기 때문에, 복잡한 비즈니스 로직의 흐름을 정확하게 전달하는 데 매우 효과적인 도구이다. 시퀀스 다이어그램은 특히 API 설계와 마이크로서비스 간 호출 흐름을 문서화할 때 압도적인 빈도로 사용된다.
셋째는 활동 다이어그램으로, 업무 프로세스나 알고리즘의 절차적 흐름을 표현한다. 시작점과 종료점 사이에 액션, 분기점(decision), 병합점(merge), 동시 처리(fork/join) 같은 구성 요소를 배치하여 흐름을 시각화한다. 활동 다이어그램은 플로우차트와 유사해 보이지만, 동시성 표현과 객체 흐름 표시 같은 강력한 기능을 추가로 제공한다. 또한 수영 레인(swimlane)을 활용해 각 활동의 책임 주체를 명시할 수 있어, 업무 분석 단계에서 부서 간 책임 분장을 명확히 하는 데 큰 도움이 된다. 이 세 가지 다이어그램만 능숙하게 작성할 수 있어도 요구사항 분석 산출물의 80퍼센트 이상을 충실하게 표현할 수 있다는 것이 업계의 통념이다.
메타 디스크립션: 요구사항 분석의 4단계 절차와 UML 2.5의 14개 다이어그램 분류, 그리고 실무에서 가장 자주 쓰이는 유스케이스·시퀀스·활동 다이어그램을 정보처리기사 출제 기준에 맞춰 정리합니다.