현행 시스템 분석과 요구사항 분류
현행 시스템 분석 대상과 절차를 살펴보고 기능·비기능 요구사항의 분류 기준을 익힌다.
현행 시스템 분석의 목적
현행 시스템 분석은 새 시스템의 범위와 이행 방향을 정하기 위해 현재 운영 중인 환경과 업무를 확인하는 활동이다. 핵심은 “무엇이 존재하는가”뿐 아니라 “무엇과 연결되고, 무엇을 바꾸면 어디까지 영향이 가는가”를 파악하는 것이다.
공식 범위의 여섯 분석 대상
현행 시스템 분석 요소도
| 분석 대상 | 확인할 내용 | 대표 결과 |
|---|---|---|
| 플랫폼 기능 | 제공 기능, 사용자·공급자, 서비스 간 상호작용 | 기능 목록, 플랫폼 구성도 |
| 플랫폼 성능 특성 | 응답 시간, 처리량, 자원 사용률, 가용 시간 | 성능 현황, 병목 후보 |
| 운영체제 | 종류·버전, 지원 여부, 호환성, 라이선스 | OS 구성표, 제약 사항 |
| 네트워크 | 구성, 통신 경로, 대역폭, 지연, 방화벽 구간 | 네트워크 구성도 |
| DBMS | 제품·버전, 데이터 규모, 이중화, 연계 방식 | DBMS 현황, 데이터 의존성 |
| 비즈니스 융합 | 업무 목표, 규칙, 조직, 기술이 결합되는 지점 | 업무 흐름, 개선 요구 후보 |
운영체제·네트워크·DBMS의 내부 동작 원리를 깊게 학습하는 것이 아니라, 응용 소프트웨어 설계에 영향을 주는 현행 조건을 식별하는 것이 목적이다.
분석 절차
- 범위와 목적 설정: 조사할 업무·시스템·조직 경계를 정한다.
- 자료 수집: 구성도, 인터페이스 목록, 운영 문서, 장애 기록, 사용자 인터뷰 등을 확보한다.
- 구성·기능·인터페이스 파악: 시스템별 역할과 데이터 이동을 연결한다.
- 기술 환경 분석: 아키텍처, 소프트웨어, 하드웨어, 네트워크 제약을 확인한다.
- 문제·제약·의존성 정리: 변경 영향과 위험을 기록한다.
- 검토와 기준화: 이해관계자와 사실 여부를 확인한다.
현재 사실과 개선안을 분리한다
- AS-IS 사실: “주문 시스템은 A DBMS 11버전을 사용한다.”
- 문제·제약: “공급사 지원 종료로 보안 패치가 제한된다.”
- TO-BE 후보: “지원되는 버전으로 전환한다.”
세 문장을 한 문장에 섞으면 분석 결과와 설계 결정이 혼동된다.
요구사항의 분류
내용 기준
| 구분 | 질문 | 예 |
|---|---|---|
| 기능 요구사항 | 시스템이 무엇을 수행해야 하는가? | 사용자는 주문을 취소할 수 있어야 한다. |
| 비기능 요구사항 | 어느 수준·조건으로 수행해야 하는가? | 주문 조회는 정상 부하에서 2초 이내 응답해야 한다. |
| 제약 조건 | 선택 가능한 설계·구현을 무엇이 제한하는가? | 기존 사내 인증 체계를 사용해야 한다. |
제약 조건을 비기능 요구사항의 한 종류로 분류하는 문헌도 있으므로, 시험에서는 제시된 분류 기준을 먼저 확인한다.
표현 수준 기준
- 사용자 요구사항: 사용자의 목표와 업무 언어 중심으로 표현한다.
- 시스템 요구사항: 시스템이 구현·검증할 수 있도록 더 구체적으로 표현한다.
이 분류는 기능·비기능 분류와 교차한다. 예를 들어 사용자 수준의 품질 요구사항도, 시스템 수준의 기능 요구사항도 존재할 수 있다.
검증 가능한 요구사항 문장
비기능 요구사항은 다음 요소를 포함하면 판정하기 쉬워진다.
대상 + 조건 + 측정 항목 + 기준값 + 검증 방법
예: “동시 사용자 1,000명 조건에서 주문 조회 API의 95%는 2초 이내 응답하며 성능 시험으로 확인한다.”
“빠르게 처리한다”, “사용하기 편해야 한다”처럼 기준이 없는 표현은 시험 가능한 요구사항으로 보기 어렵다.