요구사항 확인 4단계와 분석 모델 정리
정보처리기사 실기 시험의 첫 번째 챕터는 요구사항 확인이며, 시험에서 매회 출제되는 가장 빈도 높은 영역 중 하나이다. 단순한 개념 암기 수준이 아니라 절차의 순서, 각 단계의 산출물, 그리고 럼바우 방법론을 비롯한 분석 모델의 구체적 활용까지 정확히 이해해야 점수로 연결된다. 본 글은 실기 시험에 자주 출제되는 형태로 정형화된 절차를 정리하며, 핵심 1~2개 원칙에 따라 요구사항 개발 4단계 절차와 구조적·객체지향 분석 모델을 중심으로 다룬다. 필기 관점의 UML 개론은 별도 글에서 다루었으므로, 본 글은 시험 답안에 직접 활용할 수 있는 정형화된 표현에 초점을 맞춘다.
요구사항의 분류와 특성
요구사항(Requirement)이란 시스템이 제공해야 할 기능이나 만족시켜야 할 제약 조건을 명세한 진술을 의미한다. 정보처리기사 실기에서는 요구사항을 크게 두 가지 기준으로 분류하는데, 첫째는 기능 여부에 따른 분류이고, 둘째는 출처에 따른 분류이다. 기능 여부에 따른 분류로는 기능적 요구사항(Functional Requirement)과 비기능적 요구사항(Non-functional Requirement)이 있으며, 출처에 따른 분류로는 사용자 요구사항(User Requirement)과 시스템 요구사항(System Requirement)이 있다. 이 두 가지 분류 체계는 시험 답안에서 자주 묻는 항목이므로 정확히 외워두는 것이 중요하다.
기능적 요구사항은 시스템이 무엇을 해야 하는지, 즉 시스템이 제공해야 할 기능과 동작을 기술한다. 로그인 처리, 주문 생성, 결제 승인, 검색 기능과 같은 구체적인 기능들이 모두 여기에 속한다. 비기능적 요구사항은 시스템이 어떻게 동작해야 하는지에 관한 품질 속성을 기술하며, 성능·보안·가용성·신뢰성·사용성·확장성 같은 항목이 여기에 포함된다. 일반적으로 비기능적 요구사항이 기능적 요구사항보다 측정과 합의가 까다롭기 때문에, 정량적인 기준으로 명세하는 것이 중요하다. 사용자 요구사항은 사용자 관점에서 자연어로 작성된 요구사항이며, 시스템 요구사항은 개발자 관점에서 기술적 용어로 작성된 요구사항이다.
좋은 요구사항이 가져야 할 다섯 가지 특성도 시험에서 자주 출제된다. 첫째는 완전성(Completeness)으로, 요구사항이 시스템이 제공해야 할 모든 기능을 빠짐없이 포함해야 한다는 것이다. 둘째는 일관성(Consistency)으로, 요구사항들 사이에 모순이 없어야 한다. 셋째는 명확성(Clarity)으로, 모든 이해관계자가 동일하게 해석할 수 있도록 모호함이 없어야 한다. 넷째는 검증 가능성(Verifiability)으로, 요구사항이 충족되었는지를 객관적으로 확인할 수 있어야 한다. 다섯째는 추적 가능성(Traceability)으로, 요구사항의 출처와 그것이 어떻게 설계·구현·테스트로 이어졌는지를 추적할 수 있어야 한다. 이 다섯 가지 특성은 요구사항의 품질을 평가하는 가장 기본적인 기준이 된다.
요구사항 개발 4단계 절차
요구공학(Requirement Engineering)은 사용자의 요구가 반영된 시스템을 개발하기 위해 요구사항에 대한 도출·분석·명세·확인을 수행하는 구조화된 활동이다. 이 네 단계는 한 번에 직선적으로 진행되는 것이 아니라, 필요에 따라 이전 단계로 되돌아가는 반복적 흐름을 가진다. 각 단계의 영문 명칭과 핵심 활동, 그리고 산출물은 실기 시험의 단골 출제 대상이므로 정확히 외워두어야 한다.
도출(Elicitation) 단계에서는 시스템 요구사항을 가진 다양한 이해관계자로부터 원시 요구사항을 수집한다. 도출 기법으로는 인터뷰, 설문, 워크숍, 브레인스토밍, 관찰, 프로토타이핑, 그리고 기존 문서 분석이 사용된다. 도출 단계의 핵심은 누가 진짜 이해관계자인지를 식별하고, 그들의 요구를 빠짐없이 수집하는 것이다. 분석(Analysis) 단계에서는 도출된 요구사항들 사이의 충돌·중복·누락을 식별하고, 우선순위를 부여하며, 일관성과 완전성을 검토한다. 이 단계의 산출물은 분석 모델이며, 자료흐름도·자료사전·ERD·UML 다이어그램 같은 도구를 활용해 요구사항을 시각화한다.
명세(Specification) 단계에서는 분석 결과를 표준화된 형식으로 문서화하며, 그 산출물이 바로 SRS(Software Requirements Specification, 소프트웨어 요구사항 명세서)이다. 명세 기법은 정형 명세와 비정형 명세로 나뉘는데, 정형 명세는 수학적 원리에 기반해 정확하고 간결한 표현이 가능한 반면, 비정형 명세는 자연어와 그림을 중심으로 작성되어 이해관계자 간 의사소통이 용이하다. 일반적으로 두 방식이 혼합되어 사용된다. 마지막 확인(Validation) 단계에서는 명세된 요구사항이 이해관계자의 실제 요구를 정확히 반영하고 있는지 검증한다. 동료 검토(Peer Review), 워크스루(Walkthrough), 인스펙션(Inspection), 프로토타이핑이 대표적인 확인 기법이며, 누락이나 오류가 발견되면 도출 단계로 돌아가 보완하는 반복적 과정이 수행된다.
요구사항 분석 기법과 분석 모델
요구사항 분석에는 두 가지 큰 흐름이 존재한다. 1970년대부터 발전한 구조적 분석(Structured Analysis)과 1980년대 이후 주류로 자리 잡은 객체지향 분석(Object-Oriented Analysis)이다. 두 접근법은 각각 다른 분석 모델과 도구를 사용하며, 정보처리기사 실기에서는 두 방법론의 도구를 정확히 구분해 외우는 것이 중요하다.
구조적 분석은 시스템을 자료의 흐름과 변환 관점에서 모델링하는 방식이다. 가장 핵심적인 도구가 자료흐름도(Data Flow Diagram, DFD)로, 프로세스(원), 자료 흐름(화살표), 자료 저장소(평행선), 외부 엔티티(사각형) 네 가지 표기법으로 시스템을 표현한다. DFD를 보완하는 도구가 자료사전(Data Dictionary, DD)이며, 데이터의 의미와 구성을 정의하는 메타 문서이다. 자료사전의 표기법으로는 = (정의), + (연결), () (생략 가능), [|] (선택), {} (반복), ** (주석)이 사용되며, 이 기호들은 시험에 자주 출제되므로 반드시 외워두어야 한다. 또한 데이터 모델링을 위한 ERD(Entity-Relationship Diagram)는 엔티티·속성·관계를 표현하며, 데이터베이스 설계와 직결된다. 마지막으로 소단위 명세서(Mini-spec)는 DFD의 최하위 프로세스 내부 로직을 구조적 언어로 기술하는 문서이다.
객체지향 분석은 시스템을 객체와 객체 사이의 상호작용 관점에서 모델링한다. 시험에서 자주 출제되는 객체지향 분석 방법론은 다섯 가지로 정리되며, 각 방법론의 제안자와 특징을 묶어서 외워두어야 한다. 럼바우(Rumbaugh)의 OMT는 가장 널리 알려진 방법론으로, 객체 모델링·동적 모델링·기능 모델링이라는 세 관점으로 시스템을 분석한다. 객체 모델링은 ERD로, 동적 모델링은 상태 다이어그램으로, 기능 모델링은 자료흐름도(DFD)로 표현한다는 매핑이 시험의 단골 출제 항목이다. 부치(Booch)의 방법론은 미시적 개발과 거시적 개발을 구분하고, 자코슨(Jacobson)의 방법론은 유스케이스를 강조해 OOSE(Object-Oriented Software Engineering)라 불린다. 코드(Coad)와 요든(Yourdon)의 방법론은 ERD를 강조하며, 와이어와 멜리어(Wirfs-Brock)의 방법론은 책임 주도 설계(Responsibility-Driven Design)를 강조한다. 이 다섯 방법론은 1990년대 후반 통합되어 오늘날의 UML로 진화했으며, 현대의 객체지향 분석은 사실상 UML 기반으로 수행된다.
메타 디스크립션: 정보처리기사 실기 1장 요구사항 확인의 핵심인 4단계 절차(도출·분석·명세·확인)와 구조적/객체지향 분석 모델(DFD·DD·ERD·럼바우 OMT)을 시험 답안 기준에 맞춰 정리합니다.