요구분석
프로젝트가 시작되면
개발 단계의 “출발선”은 언제나 같다.
사용자가 무엇을 원하는지 파악하고,
합의 가능한 형태로 정리하는 일이다.
요구분석이 어려운 이유는 단순하다.
설계/구현/테스트는 틀리면 비교적 “수정”이 가능하지만,
요구가 틀리면 처음부터 다시 만드는 비용이 발생한다.
그래서 요구분석은 소프트웨어 개발의 성패를 좌우하는 단계가 된다.
소프트웨어 요구란 무엇인가?
요구(Requirements)란 고객/사용자의 요청을 바탕으로
시스템이 무엇을 해야 하는지(What)와
어떤 특징/조건을 가져야 하는지를 명확히 확정한 것이다.
사용자의 관점에서 찾아내되
시스템화 관점에서 다듬고 고쳐서
이해관계자와 합의 가능한 문장으로 만드는 것이 핵심이다.
결국 프로젝트가 성공했다고 말하려면
보통 이 3가지를 만족해야 한다.
- 시스템이 요구를 만족한다
- 비용이 초과되지 않는다
- 일정 내에 인도된다
그래서 '진짜 요구'를 찾는 작업은
프로젝트 성공의 필수 조건이 된다.
요구분석의 키포인트 (What 중심)
요구분석 단계에서 가장 중요한 태도는 이것이다.
“어떻게(How) 만들지”보다
“무엇(What)을 담을지”에 집중한다.
즉, 특정 언어/프레임워크/DB/내부 구조 같은
구현 선택은 뒤 단계(설계)에서 다루고
요구분석에서는 업무 목표, 필요한 기능,
품질 조건, 제약 조건, 상호작용을 정리한다.
요구분석 단계: 3단계 흐름
요구분석은 보통 아래 3단계로 진행된다.
1) 요구 추출
- 고객/사용자/이해관계자에게서
기대와 요구를 “찾아내는” 단계이다. - 현재 문제(As-Is)와 목표(To-Be)를 확인한다.
2) 요구 분석 및 정의
- 추출한 요구를 정리해 충돌/중복/모호함을 제거한다.
- 이해관계자와 합의할 수 있도록 정의된 형태로 만든다.
3) 요구 확인
- 문서로 정리된 요구가 정말 사용자를 만족시키는지 검증한다.
- 누락/오해가 있으면 다시 추출 단계로 되돌아가 수정한다.
요구 분석을 통해 문제를 찾아내고 새로운 시스템이
이를 해결하기 위한 동작, 서비스들을 정리하여 문서화한다.
이를 요구 분석 명세서 또는 요구 분석서라고 한다.
이해관계자의 중요성
요구란 시스템에 대한 고객의 요청을 확정한 것이다.
어떤 업무가 있고 어떤 문제가 있고 어떤 기능을
어떤 조건으로 제공해야 하는지를 잘 정리한 것이다.
하지만 같은 시스템을 봐도 이해관계자마다
우선순위가 다르기 때문에 진정으로 원하는
요구를 찾아내는 일은 쉬운 일이 아니다.
기술 배경이 있는 관련자
: 처리량, 반응시간, 안정성 선호
경영/비즈니스 배경이 있는 관련자
: 비용, 고객만족, 리스크, 규정 준수 선호
예를 들어 의료 보험 시스템에서
- 보험공단은 비용 절감과 청구 규칙 엄격화를 원할 수 있고
- 병원/약국은 청구 절차를 단순화해 빠른 지급을 원할 수 있다
이 차이를 조율하지 않으면 요구가 계속 흔들린다.
그래서 요구분석은
이해관계자를 식별·분류하고, 참여시키고,
요구를 관리하는 과정이 된다.
요구 vs 제약
요구분석에서 자주 헷갈리는 것이 요구와 제약이다.
요구
: 시스템이 제공해야 하는 능력/동작/규칙 (무엇을 해야 하는가)
제약
: 설계·구현의 선택지를 제한하는 조건 (무엇으로/어떻게 만들어야 하는가)
예)
- “Java로 개발해야 한다”
→ 제약 (구현 옵션을 제한함) - “규격을 초과한 우편물은 접수 거부해야 한다”
→ 요구 (업무 규칙을 시스템이 수행해야 함)
이 둘을 섞어 쓰면 문서가 혼란스러워지고, 합의가 꼬이기 쉽다.
기능 요구 (Functional Requirements)
시스템이 무엇을 하는지를 말한다.
시스템과 외부 요소들 간의 인터랙션이라 볼 수 있는데
기능적 요구를 결정 하려면 시스템이 어떤 상태일 때
외부의 데이터나 명령을 받아들여 무슨 반응을 하는지 기술한다.
보통 “시스템은 ~할 수 있어야 한다” 형태로 표현된다.
예를 들면 항공권 예약 시스템에서
‘시스템은 항공편을 검색할 수 있어야 한다’
같은 것이 기능 요구이다
요구 분석의 표준인 IEEE 표준 830에서는
기능 요구로 다음과 같은 사항이 포함되어야 한다고 제시한다.
1) 입력의 검증
2) 정확한 작업 순서
3) 비정상적인 상태에 대한 응답 및 복구
(=오버플로우, 네트워크 오류)
4) 매개변수의 유효성
5) 입출력 관계
결국 기능 요구는 외부 사용자에게 직접적으로
혜택을 줄 수 있는 시스템의 기능을 말 한다.
기능 요구의 종류와 사례
| 분류 | 질문 | 사례(ATM) |
| 기능 | 시스템이 무엇을 하는가? | 현금/수표 인출, 조회, 입금, 송금 |
| 시스템이 언제 그 일을 하는가? | 24시간 | |
| 시스템이 운용될 때 여러 가지 다른 모드가 있는가? | 준비 중, 유지보수 중 | |
| 언제 어떻게 시스템이 변경되거나 확장되는가? | 지폐/수표 규격이 바뀔 때 | |
| 자료 | 입력, 출력이 무엇이며 어떤 형태를 갖는가? | 현금카드, 현금, 수표 |
| 얼마나 자주 자료를 받고 내보내는가? | 매일 수천 건 | |
| 자료가 얼마나 정확하여야 하나? | 100% 정확 | |
| 시스템에 유입되는 자료의 양 | 200바이트 × 수천 건 | |
| 데이터는 일정 기간 동안 보관되어야 하나? | 20년 | |
| 입출력 | 다른 시스템에서 유입, 배출되는 입력은 무엇인가? | 계좌 정보 |
| 데이터의 특정한 형태가 있는가? | 문자와 숫자 | |
| 자료 전달에 사용되는 특정 미디어가 있는가? | 없음 | |
| 사용자 | 누가 시스템을 사용할 것인가? | 은행 고객 |
| 사용자가 여러 그룹인가? | 3그룹(고객, 은행원, AS 엔지니어) | |
| 각 사용자 그룹의 컴퓨터 사용 경험은? | 초보 | |
| 각 사용자 그룹에 따라 필요한 교육은? | 행원 교육 |
비기능 요구
기능 자체가 아니라 기능을
뒷받침하는 조건/품질/제한이다.
예를 들면 시스템이 질의에 대한 결과가
3초 이내에 화면에 보여야 한다든지.
구매요청에 대한 회신이 4시간 전에
이루어져야 한다는 성능에 대한 요구가
비기능 요구다.
예)
-응답시간: 모든 화면은 5초 이내 표시
- 가용성: 99% 이상 가동
- 보안: 전송 파일 암호화
- 복구: 장애 후 1시간 내 복구
- 사용성: 터치스크린, 음성 안내, 다국어 지원 등
비기능 요구는 소프트웨어에 대한
다양한 제약 조건이라 할 수 있다.
대표적인 조건은 다음과 같다.
1) 외부 인터페이스
2) 메모리 제약
3) 성능 요구
4) 사용자의 특성과 가정
5) 설치 환경의 적합성
비기능 요구의 종류와 사례
| 분류 | 질문 | 사례(ATM) |
| 성능 | 시스템의 속도, 반응 시간, 처리율 | 10초, 10건/시간 |
| 시스템에 의하여 처리되는 자료의 크기 | 200MB/일 | |
| 품질 | 신뢰성, 가용성, 유지보수성 등 품질 특성 요구 | 99% 가동률 복구 허용 시간: 1시간 결함 발견 즉시 가동 중지 및 격리 플랫폼 변경 시 작업일 1일 이내 완성 |
| 시스템이 결함을 찾아내고 격리시켜야 하나? | ||
| 시스템 가동되는 평균 시간 | ||
| 시스템의 작업이 중단된 후 다시 복구될 때까지 허용되는 시간 |
||
| 얼마나 쉽게 위치/플랫폼을 변동할 수 있는가? | ||
| 안전 | 계좌 해킹 인출 방지책은? | IC 칩 사용 |
| 화재/홍수/도난 등 재난 대비 방지책은? | 불연재, 화재경보기, 도난 방지기 | |
| 보안 | 자료와 시스템에 대한 접근이 통제되어야 하는가? | 시스템 접근 권한 부여 담당자 지정제 카드키 및 지문인식 |
| 사용자 간 타인의 데이터/프로그램 접근 방지 방법은? | ||
| 물리적 보안 대책은 무엇인가? | ||
| 시스템의 백업 기간 및 책임자는 누구인가? | ||
| 사용성 | 사용자 인터페이스 방법은? | 터치스크린 |
| 메뉴의 언어는? | 한글 및 영문 | |
| 사용자 오류를 최소화하는 방안은? | 음성 안내 |
요구 대상에 의한 분류
요구하는 대상에 따라 요구의 종류를 나눌 수 있다.
1) 비즈니스 요구
- 소프트웨어 적용 업무 사례로부터 획득하는 요구 사항
- 잔고 조회
- 계좌이체
2) 아키텍처 및 설계 요구
- 비즈니스 요구보다는 더 상세한 요구 사항으로
구현에 필요 한 전체적인 설계와 관련된 요구 사항
- 고객은 등록된 자동이체 대시 보드를 볼 수 있다.
- 청구 세부 정보를 추가, 수정 및 삭제할 수 있다.
- 고객은 CMS를 구성하고 다양한 이체 작업에 대한
문자 알림을 휴대폰으로 보낼 수 있다.
또한 과거 지급된 자동이체의 기록을 볼 수 있다.
3) 시스템 및 통합 요구
- 개발자가 코딩하는 데 필요한 아주 상세한 요구 사항
- 유틸리티 제공자 이름
- 관계/고객 번호
- 자동 결제 - 예/아니오
- 전체 청구서 지불 - 예/아니오
- 자동 지불 한도
- 청구 금액이 지정된 금액을 초과하는 경우 지불하지 않는다.
'개주 훈련일지 > 📚 코살대 교본 학습' 카테고리의 다른 글
| 소프트웨어 요구 사항 추출 (0) | 2025.12.26 |
|---|---|
| SQL) 분산 데이터베이스와 성능 (0) | 2025.12.26 |
| SQL) 데이터베이스 구조와 성능 (0) | 2025.12.25 |
| SQL) 대량 데이터에 따른 성능 (0) | 2025.12.25 |
| SQL) 반정규화와 성능 (0) | 2025.12.24 |