지난 글에서는 프로젝트 관리와 계획, 위험 점수 산정까지 정리해보았다. 이번 글에서는 요구 분석을 하는 방법에 대해서 정리해보려고 한다.
1. 요구
요구 분석은 소프트웨어 개발의 실질적인 첫 단계이다. 이전 단계에서는 프로세스 모델, 방법론, 프로젝트 계획 등을 통해 전체적인 방향과 일정을 설정했고, 요구 분석 단계에서는 고객의 실제 요구를 기반으로 시스템을 구체화하는 작업을 수행한다.
1.1. 요구 분석의 단계
요구 분석은 사용자의 요구를 이해하고 정리하는 과정으로, 다음 세 단계로 구성된다.
- 요구 추출
- 개발할 시스템에 대해 사용자 및 고객의 기대와 요구사항을 수집하는 단계이다.
- ex) 인터뷰, 설문, 관찰
- 요구 분석 및 정의
- 추출한 요구를 정리하고, 이해관계자(stakeholer) 간 합의 가능한 형태로 명확하게 정의하는 단계이다.
- 모호한 요구를 제거하고 충돌되는 요구를 조정하는 것이 핵심이다
- 요구 확인
- 정의된 요구사항이 실제로 사용자와 고객의 요구를 만족하는지 검증하는 단계이다.
위의 세 단계를 그림으로 나타내면 다음과 같다.
1.2. 요구의 개념
요구란 시스템에 대해 고객이 필요로 하는 기능이나 조건을 명확히 정의한 것을 의미한다.
프로젝트의 성공 여부는 단순히 요구를 구현하는 것이 아니라, 진정한 요구를 정확히 파악하는 것에 달려 있다.
또한 요구는 다양한 이해관계자(Stakeholer)의 관점이 반영되기 때문에 이들의 요구를 조정하고 통합하는 과정이 중요하다.
+) 제약사항과 요구는 명확히는 다른 문제이다.
- 요구(Requirement): 시스템이 반드시 수행해야 하는 기능이나 조건
- 제약사항(Constraint): 시스템을 개발할 때 따르는 제한 조건
예를 들어, "특정 기능을 구현해야 한다"는 요구에 해당하고, "개발 언어는 Java를 사용해야 한다"는 제약사항에 해당한다.
즉, 제약사항은 해결 방법을 제한하는 요소이며, 요구는 문제를 정의하는 요소라고 볼 수 있다.
1.3. 요구의 분류
요구는 다음과 같이 크게 두 종류로 나뉜다.
- 기능 요구: 고객이 요구하는 시스템이 처리할 기능
- 동사로 표현된다.
- ex) 사용자는 로그인할 수 있어야 한다.
- 비교적 명확하게 정의할 수 있으며 쉽게 파악이 가능하다.
- 일반적으로 유스케이스(Use Case)형태로 표현된다.
- 동사로 표현된다.
- 비기능 요구: 요청된 기능 이외에 시스템이 갖추어야 할 조건과 특징
- ex) 응답 속도, 고장에서 회복되는 시간, 보안 등
- 성능과 관련된 형용사로 표현된다.
- 제품의 속성이며, 품질 속성 시나리오로 정리된다.
1.3.1. 기능 요구
기능 요구에 대해서 조금 더 자세히 정리해보려고 한다.
기능 요구는 시스템이 수행해야 하는 기능과 동작을 의미한다. 즉, 사용자가 시스템을 통해 수행할 수 있는 작업과 시스템이 특정 입력에 대해 어떤 출력을 만들어내는지를 정의한다.
예를 들어, 현금인출기(ATM)를 구현한다고 했을 때, 기능 요구는 다음과 같다.
- 현금 인출
- 잔금 조회
- 계좌 이체
- 현금 서비스
이와 같이 기능 요구는 사용자가 수행하는 작업 또는 시스템이 제공하는 기능 단위로 표현된다.
기능 요구는 시스템과 외부 요소(사용자, 다른 시스템 등) 간의 상호작용을 중심으로 정의된다.
- 특정 입력이나 명령을 받으면 시스템이 이를 처리하고, 그에 따른 결과를 출력하는 형태로 구성
즉, 기능 요구는 다음과 같은 흐름을 가진다.
- 입력(Input) → 처리(Process) → 출력(Output)
또한, 시스템의 상태에 따라 어떤 동작을 수행해야 하는지도 함께 정의된다.
기능의 요구와 종류의 사례는 다음 표를 참고하면 된다.
+) 위 사례에서 성능, 정확도, 처리량과 같은 일부는 비기능 요구사항에 해당하지만, 자료, 입출력, 사용자와 같은 항목은 요구사항을 정의하기 위한 구성 요소로 보는 것이 적절하다.
1.4 요구 추출
앞선 계획 단계에서 수행한 타당성 분석 결과가 긍정적이라면, 프로젝트는 사용자로부터 요구사항을 수집하는 요구 추출 단계로 시작된다.
이 단계에서는 소프트웨어가 제공해야 할 기능과 서비스에 대한 사용자의 기대와 아이디어를 파악하는 것이 핵심이다.
요구 추출은 다음과 같은 과정을 통해 이루어진다.
- 요구에 대한 정보 출처 파악
- 사시스템과 관련된 이해관계자(Stakeholder)를 식별하고, 누가 요구를 제공할 수 있는지, 시스템의 범위가 어디까지인지 결정한다.
- 요구에 대한 정보 취합
- 소프트웨어가 적용될 도메인(응용 분야)에 대한 정보를 수집하고, 사용자의 요구사항을 다양한 방법을 통해 확보한다.
- 요구와 제한 사항 정리
- 수집된 요구사항과 함께 시스템에 적용되는 제약조건을 정리하고, 초기 형태의 요구사항으로 구조화한다.
요구사항을 수집하기 위한 방법은 다양하며, 대표적인 기법은 다음과 같다.
- 고객 발표: 고객이 시스템에 대해 설명하는 방식으로, 초기 요구사항과 전체적인 개념을 파악하는 데 유용하다.
- 가이드라인
- 고객 업무를 잘 이해하는 관리자나 운영 책임자가 발표하는 것이 바람직하다.
- 발표하기 전 개발팀은 필요한 정보가 무엇인지 미리 검토해야 한다.
- 모호하거나 의심되는 부분은 질문을 통해 명확히 해야 한다.
- 구현 방법에 대한 논의보다는 요구사항 이해에 집중해야 한다.
- 발표 자료는 공유하여 팀 전체가 참고할 수 있도록 해야 한다.
- 2시간 이상 발표 지양해야 한다.
- 가이드라인
- 문헌, 양식 조사: 기존 자료를 분석하여 요구사항을 도출하는 방법이다.
- 유사한 프로젝트 사례 조사
- 업무 관련 문서 및 양식 분석
- 산업 및 기업 표준 확인
- 관련 법규 및 정부 정책 조사
- 인터뷰: 이해관계짜와 직접 대화를 통해 요구사항을 수집하는 방법이다.
- TAM, SAM으로 가상의 고객(페르소나)를 설정하고 실제 인터뷰 진행
- 사용자가 자연스럽게 요구를 이야기할 수 있는 환경을 조성하는 것이 중요하다.
- 가이드라인
- 다양한 이해관계자를 대상으로 인터뷰를 진행한다.
- 충분한 시간을 확보하여 여유 있게 진행한다.
- 중요한 이해관계자와는 여러 차례 인터뷰를 수행한다.
- 설문: 다수의 이해관계자로부터 의견을 수집할 때 사용하는 방법이다.
- 관리자 및 사용자 등 다양한 대상에게 적용 가능하다.
- 무기명 설문을 통해 솔직한 의견을 유도할 수 있다.
- 이해 당사자들의 관심과 내부정보, 개선 의견 도출
- 감추어진 정보를 끌어내기 쉬움
- 간단하고 중요한 이슈에 집중해야 하며 적절하고 잘 기술된 질문으로 구성해야 한다.
- 브레인스토밍 회의: 여러 사람이 자유롭게 아이디어를 제시하는 방식이다.
- 비판 없이 아이디어를 최대한 많이 도출하는 것이 목적이다.
- 필요 시 익명성을 보장하여 참여도를 높일 수 있다.
- JAD(Joint Application Development): 집중 브레인스토밍 세션
- 관찰과 작업 분석: 사용자의 실제 작업 환경을 직접 관찰하여 요구사항을 도출하는 방버이다.
- 프로토타이핑: 시스템의 일부 기능을 빠르게 구현하여 요구사항을 구체화하는 방법이다.
- 최종 시스템 예상 기능 중 일부를 빠르게 구현한 프로그램
- Paper Prototype: 가장 단순한 형태로, 그림을 순서대로 그린 것
- 모의 사용자 인터페이스: 가장 흔한 형태로, 프로토타이핑 언어로 작성하며 제한된 기능만 실행 가능
+) 요구 정보의 출처
요구사항은 다양한 출처로부터 수집될 수 있으며, 대표적인 출처는 다음과 같다.
- 고객: 시스템 개발을 요청하고 비용을 지불하는 주체로 프로젝트의 방향과 목표를 결정하는 핵심 이해관계자
- 도메인 전문가: 해당 비즈니스 분야에 대한 전문 지식을 가진 사람으로, 요구사항을 제공하는 전문가
- 이해당사자(Stakeholder): 시스템 개발 및 운영으로 인해 직간접적으로 영향을 받는 모든 사람(고객, 사용자, 관리자 등)
- 사용자: 시스템을 직접 사용하는 사람
- 역공학: 기존 시스템(레거시 시스템)이나 관련 문서를 분석하여 요구사항을 도출하는 방법
1.5 요구 분석
앞서 1.4에서 추출한 요구 후보들이 명확학고 안전한지, 모호하거나 모순되지 않는지를 분석하고 이를 바탕으로 최종 요구사항으로 확정하는 과정이 요구 분석 단계이다.
도출된 요구사항이 좋은 요구인지 판단하기 위해서는 다음과 같은 특성을 만족하는지 확인해야 한다.
- 원자적(atomic): 하나의 요구사항은 하나의 목적만을 가져야 하며, 여러 기능이 복합적으로 포함되어서는 안된다.
- 완전성(complete): 요구사항이 수행되기 위해 필요한 정보가 모두 포함되어 있어야 한다.
- 비모호성(unambiguous)과 통일성(consistent): 요구사항은 명확하게 해석될 수 있어야 한다.
- 추적성(traceable): 각 요구사항은 고유 식별자를 가져야 하며, 설계, 구현, 테스트 단계까지 추적이 가능해야 한다.
- 우선순위화(prioritize): 요구사항 간의 중요도를 구분하여 개발 순서나 의사결정에 활용할 수 있어야 한다.
- 테스트 가능성(testable): 요구사항은 객관적으로 검증할 수 있도록 측정 가능하고 명확하게 작성되어야 한다.
1.5.1. 도메인 분석
소프트웨어를 구축하기 위해서는 문제가 무엇인지 이해하고, 이를 해결하기 위해 어떤 요구사항이 필요한지 파악해야 한다.
이때 문제와 요구가 발생하는 배경이 되는 영역을 도메인(Domain)이라 하며 도메인을 이해하는 과정이 도메인 분석이다.
도메인을 한 마디로 정의하면 요구의 배경이다. 이러한 도메인 분석은 설계 및 모델링에 필요한 여러 개념과 비즈니스 규칙을 파악하는 것이 목적이다.
즉,
- 해당 분야에서 사용되는 개념을 명확히 정의하고 이를 시스템에서 사용할 수 있는 형태로 정리하는 과정이다.
도메인 분석은 다음과 같은 단계로 진행된다.
- 도메인 개념 찾기
- 도메인의 목적, 구조, 동작을 구성하는 주요 개념을 식별한다.
- 객체 (ex. 환자, 의사 등)
- 프로세스 (ex. 예약 진료 등)
- 사람 (ex. 사용자, 관리자 등)
- 규칙 (ex. 진료 절차)
- 초기 단계에서 용어를 명확히 정의하는 것이 매우 중요하다.
- 도메인의 목적, 구조, 동작을 구성하는 주요 개념을 식별한다.
- 도메인 사전 작성
- 도출된 개념들을 체계적으로 정리하고 동일한 의미를 가지도록 표준화하는 작업이다.
- 비즈니스 규칙 정리
- 해당 도메인에서 반드시 지켜야 하는 규칙이나 제약조건을 정리한다.
의료 시스템의 도메인 분석 예시를 한 번 알아보자.
일반적으로 의료 기관은 다음과 같은 도메인 개념이 파악되어야 한다.
- 예약
- 접수
- 진료와 검사
- 입원
- 퇴원
이와 같은 개념들을 기반으로 도메인 사전을 구성하고, 각 개념의 의미를 명확하게 정의한다.
비즈니스 규칙은 다음과 같이 기술할 수 있다.
- ID 001: 환자는 질병으로부터 고통받는 사람이며 의사나 응급실, 다른 의료기관에서 진료를 의뢰받는다.
- 타입: 사실(Fact), 소스: 도메인 사전
1.5.2 시나리오 기반 분석
소프트웨어를 개발에는 다양한 이해관계자가 참여하며, 개발자와 사용자 간의 커뮤니케이션에서 가장 큰 문제는 전문 용어와 관점 차이로 인한 이해의 어려움이다.
이러한 문제를 해결하기 위한 방법 중 하나가 시나리오 기반 분석이다.
시나리오 기반 분석은 사용자의 입장에서 시스템 사용 상황을 이야기 형태로 표현하여 요구사항을 이해하는 방법이다.
이때 5W1H(Who, What, When, Where, Why, How)를 활용하면 보다 구체적으로 시나리오를 작성할 수 있다.
- Who: 누가 사용하는지
- What: 무엇을 하는지
- When / Where: 언제, 어디서 사용하는지
- Why: 왜 사용하는지
- How: 어떻게 사용하는지
사용자 시나리오의 예시는 다음과 같다.
- <사용자/역할(who)>는
- <목표/혜택/이익(why)>를 얻기 위하여
- <행위/작업(what)>을 원한다.
형식에 맞추어 사용자 스토리를 작성하면, 다음과 같은 예시가 나오고, 기능을 구현하며 관리하게 된다.
- <고객>은
- <현찰을 받기> 위하여
- <ATM에서 현금을 인출하기>를 원한다.
1.5.3. 유스케이스
앞서 1.5.1에서 도메인 분석은 시스템을 모델링하기 위한 개념적 기반을 제공하는 과정이다. 즉, 도메인 분석은 직접 모델을 만드는 것이 아니라 모델링에 필요한 개념을 정의하고 정리하는 단계이다.
도메인 분석과 실제 시스템 모델링을 연결하는 작업이 유스케이스를 도출하는 과정이다. 이를 유스케이스 모델링이라고 하며, 시스템이 사용자에게 제공하는 기능과 동작을 표현하는 방법이다.
유스케이스 모델은 다음과 같은 요소로 구성된다.
- 액터(Actor): 시스템과 상호작용하는 외부 주체
- 유스케이스(Use Case): 시스템이 제공하는 기능
- 시스템 범위(System Boundary): 시스템의 경계
- 관계(Relationship): 요소 간의 관계
이런 유스케이스를 도출/분석하는 과정은 일반적으로 다음과 같은 단계로 이루어진다.
- 액터 찾기
- 유스케이스 찾기
- 유스케이스 사이의 관계 찾기
유스케이스는 유스케이스 다이어그램으로 표현된다.
유스케이스 다이어그램은 시스템이 제공하는 기능과 사용자 간의 관계를 시각적으로 나타내는 도구이며, 요구사항을 분석하고 이해하는 데 활용된다.
유스 케이스 다이어그램의 구성 요소는 다음과 같다.
- Use Case: 시스템 기능
- Actor: 시스템과 상호작용하는 외부 주체(사용자, 외부 시스템 등)
다음 수강신청 시스템의 유스케이스 다이어그램 그림을 참고하면 이해가 쉽다.
위 그림에 대해서 설명하면 다음과 같다.
- Actor: 학생, 교수, 교직원
- Use Case: 수강신청, 수강취소, 수강 과목 열람, 개설 과목 열람, 로그인, 강좌 등록, 강의 변경, 강좌 삭제, 수강생 열람, 강의 과목 선택
그럼, 이 유스케이스 다이어그램에서 사용되는 Actor나 Use Case는 무엇일까?
- Actor
액터는 시스템과 상호작용하는 외부 엔티티로, 명확한 역할과 이름을 가져야 한다. 액터는 시스템 내부가 아니라 시스템 외부에 존재해야 한다.
유스케이스 다이어그램에서 액터가 될 수 있는 것은 사용자가 맡은 일이나 다른 시스템이다. 즉, 액터는 시스템에게 서비스를 제공하거나 제공받는다.
다음과 같은 질문들을 통해 액터를 도출할 수 있다.
- 어떤 사용자 그룹이 작업을 수행하기 위해 시스템의 지원을 받는가?
- 어떤 사용자 그룹이 시스템의 주요기능을 사용하는가?
- 어떤 사용자 그룹이 유지 보수와 관리 등의 부수적 기능을 사용하는가?
- 시스템이 다른 외부 하드웨어나 소프트웨어 시스템과 동작하는가?
- Use Case
유스케이스는 특정 액터가 시스템을 통해 목표를 달성하는 일련의 시나리오 집합을 의미한다.
즉, 하나의 유스케이스는 정상적인 흐름뿐 아니라 예외 상황 및 오류 흐름까지 포함한 전체 동작을 나타낸다. 또한 유스케이스는 사용자 시나리오를 기반으로 도출될 수 있다.
이러한 유스케이스를 찾는 방법은 다양하다.
- 개발자와 사용자가 함께 시나리오 작성 후 이를 기반으로 정의
- 기존 도메인 문서 활용(지침서, 업무 매뉴얼, 절차 문서 등)
- 질문 기반 접근을 통한 도출
- 액터가 시스템에 어떤 작업을 수행하기를 원하는가?
- 액터가 원하는 정보는 무엇인가?
- 누가 데이터를 생성하는가고 수정하거나 삭제하는가?
- 액터는 언제, 얼마나 자주 시스템과 상호작용하는가?
- 액터는 어떤 이벤트를 통해 시스템으로부터 정보를 얻는가?
위와 같은 방법으로 유스케이스를 도출한 후, 이를 구체적으로 문서화한 것을 유스케이스 명세라고 한다. 유스케이스 명세는 하나의 기능에 대해 시작 ~ 종료 흐름을 상세하기 기술하는 문서이다. 다음 그림을 한 번 확인해보자.
위 그림에 대해서 설명하면 다음과 같다.
- 유스케이스 이름: 수강 신청
- 액터: 학생
- 시작 조건: 학생이 재학 중이고 로그인이 되어야 함
- 기본 흐름 정의
- 대안 흐름
- 실제 시스템에서 발생할 수 있는 예외 상황을 반영하기 때문에 매우 중요하다.
- 종료 조건
즉, 유스케이스 명세는 하나의 기능을 "시작, 처리, 예외, 종료"까지 완전하게 표현하는 문서이며 이를 통해 요구사항을 명확히 하고 설계 및 테스트 기준을 도출할 수 있다.
- 유스케이스 관계 찾기
유스케이스 간의 관계를 정의하는 것은 매우 중요하다. 이를 통해 다이어그램의 복잡도를 줄이고, 시스템의 구조를 더 명확하게 이해할 수 있다.
유스케이스 간 관계는 다음과 같이 3가지로 구분된다.
- 대안 흐름: 기본 유스케이스에서 이벤트 흐름이 변형되거나 선택 또는 예외인 경우
- 포함 관계
- 유스케이스 사이의 중복을 제거할 수 있다.
- 어떤 유스케이스가 다른 유스케이스를 포함하는 관계로, 공통된 동작을 분리하여 재사용할 수 있다.
- ex) "예금", "현금 인출", "고객 인증"의 유스케이스가 존재한다.
- "예금"과 "현금 인출"은 "고객 인증"의 유스케이스가 동일하게 필요하다.
- 따라서 다이어그램에 표현할 때는 다음 그림과 같이 "고객 인증" 유스케이스를 별도로 분리하고 다른 유스케이스에서 포함 관계로 연결한다.
- 확장 관계
- 유스케이스가 특정 조건에서 추가적인 동작으로 확장되는 관계이다.
- ex) "결제"와 "멤버십 할인"이라는 유스케이스가 있다고 가정해보자.
- "결제"라는 유스케이스는 독립적으로 존재 가능하다.
- 그렇지만, "결제" 유스케이스는 멤버십이 존재한다면 "멤버십 할인"이라는 유스케이스로 확장될 수 있다.
- 따라서 아래와 같이 관계를 표현할 수 있다.
1.6. 요구 명세
요구 분석을 통해 정리된 요구사항을 빠짐없이 명확하고 일관되게 문서화하는 과정을 요구 명세라고 한다.
이 과정은 사용자와 개발자 간의 이해를 돕고, 시스템 개발의 기준을 마련하기 위해 반드시 필요하다.
요구사항을 정리하여 작성한 문서를 요구분석 명세서(Software Requirement Specification, SRS)라고 하고, IEEE 830에 표준 형식이 존재한다. 이 SRS에는 시스템이 어떻게(How) 수행될 것인가가 아니라 무엇(What)을 수행할 것인가에 대하여 기술한다.
Gilbert가 제안한 요구 분석서를 작성할 때 주의사항이 존재하는데, 다음과 같다.
- 요구 명세서는 사용자와 개발자 모두가 쉽게 이해할 수 있도록 작성해야 한다.
- 요구 분석서에 기술된 조건은 개발자와 사용자가 모두 동의한 것이어야 한다.
- 요구 분석서는 목표 시스템에 의하여 수행될 모든 기능을 정확히 기술하여야 한다.
- 요구 분석서는 목표 시스템에 영향을 주는 모든 제약 조건을 기술한다.
- 요구 분석서는 시스템의 인수를 위한 테스트 기준을 제공해야 한다.
- 요구 분석서는 원하는 시스템의 품질과 상대적인 중요도 및 품질을 재는 방법이 기술되어야 한다.
1.7. 요구 검증
사용자의 요구가 도출되고, 요구분석 명세서를 다 작성했으면, 이제 올바르게 기술되었는지 검토하는 활동이 필요하다. 이러한 과정을 요구 검증이라고 한다.
요구 검증 사항은 다음 표를 확인하면 된다.
'학교공부 > [소프트웨어공학]' 카테고리의 다른 글
| [소프트웨어공학] - 설계 원리 (1) | 2026.04.21 |
|---|---|
| [소프트웨어공학] - 요구 모델링 (0) | 2026.04.21 |
| [소프트웨어공학] - 프로젝트 관리와 계획 (0) | 2026.04.21 |
| [소프트웨어공학] - 프로세스와 방법론 (1) | 2026.04.21 |
