요구사항과 요구사항 분석이란 무엇이고 요구사항 분석에 있어서 흔히 저지르는 실수들을 살펴보고, 그러한 실수들을 방지하기 위한 팁/가이드라인을 제공하고자 합니다.

1. 요구사항분석 오류들과 방지를 위한 팁
Aug. 2013
정철호(CHOLHO, JONG)
13년 8월 20일 화요일

2. 목차
Part One - 요구사항 분석과 관련 오류들
1. 요구사항이란 무엇인가?
2. 요구사항 분석이란?
3. 요구사항 분석 관련 오류들
3.1 커뮤니케이션 오류
3.2 발견의 오류
3.3 적용의 오류
Part Two - 요구사항 분석 오류방지의 팁
1. 커뮤니케이션 오류방지 팁
1.1 오류방지 팁 Overview
1.2 팁을 활용한 체크포인트
1.3 요구사항분석서 예시와 체크포인트
1.4 요구사항 추적 매트릭스 예시
2. 발견의 오류방지 팁
3. 적용의 오류방지 팁
Wrap-Up (잊지말아야 할 것들)
13년 8월 20일 화요일

3. 1. 요구사항이란 무엇인가? Part One - 요구사항 분석 관련 오류들
Page 3, CHJONG
(예: 모바일을 통한 매출 증대)
Business 요구사항 Software 요구사항
Business Goal
비 기능적 요구사항
요구사항은 고객의 사업 목표를 충족시키기 위한 것으로, 사용자에게 가치를 제공하여 사업 목표를 달성시키는
Business 요구사항과 Business 요구사항을 충족시키기 위한 수단(제품/서비스 또는 시스템)에 대한 필요사항
과 조건들을 나타내는 Software 요구사항으로 구성된다.
(예: 모바일 캠페인 수행, 모바일 상품 구
매 및 결제 채널 제공, 정부 모바일 금융
규제 준수)
기능적 요구사항
(예: 모바일 Application, 모바일 서비스
관리 포털 - 상품/정책 등, 캠페인 Push
시스템, 기간계 연동 통합 관리 시스템)
(예: 보안 - 사용자 인증 시 입력정
보 보안 방안은 키보드 보안이다,
모바일 Application의 구동시간은
3초 이내이다. 캠페인을 위해
Push될 정보 전송은 실시간 또는
주기적이어야 한다.)
* Business Goal을 위한 가치 제공
* software를 만들어야 하는 이유: 여러
가지 구현방식으로 만족이 가능
* Software 운영 판단 기준으로
Constraints가 주로 비 기능 요구화
(예: 모바일 Application - iOS/
Android/Tablet/공인인증서 지
원, 모바일 서비스 관리 포털 - 다
국어지원/전자정부프레임웍,
캠페인 Push 시스템 - 전용 Agent
또는 외부 Push 연동, 기간계 연
동 통합관리 - 에러관리/재시도,
모바일 서비스 모니터링 - Dash
Board 지원)
* SHALL-BE
(Qualities)
* SHALL-DO
(Features)
13년 8월 20일 화요일

4. 2. 요구사항 분석이란? Part One - 요구사항 분석 관련 오류들
Page 4, CHJONG
(Software) 요구사항 분석은 새로운
제품/서비스를 위해 충족되어야 할
필요사항들 또는 조건들을 결정해
나가는 업무 (요구사항 수집, 해석,
문서화, 검증 및 관리)
요구사항 분석은 프로젝트 시작에
서 끝까지 수행해야하는 업무 - 변화
관리 VS 누구의 관심 대상인가?
고객이 제시하는 비즈니스 요구사
항과 소프트웨어 요구사항은 다름
요구사항 문서화에 대한 표준은 없
음. 단, 요구사항 문서는 설계와 개
발을 위한 주요 정보를 포함하도록
상세해야 함.
요구사항 수집 요구사항 해석
요구사항
문서화
요구사항 검증
요구사항
변화관리
13년 8월 20일 화요일

5. 3. 요구사항 분석 관련 오류들 Part One - 요구사항 분석과 관련 오류들
Page 5, CHJONG
3.1 커뮤니케이션 오류
개발 산출물
고객
비즈니스 분석가
설계자
개발자
요구사항분석가
프로젝트
헌장
제안서
제안요청서
(RFP): 목
표,
Business &
Software
설계서 (화
면, DB, 컴
포넌트 등)
비즈니스
모델 (프로
세스, 업
무)
Software
요구사항
분석서
Business
요구사항
분석서
PM or
Somebody
PM
요구사항을 각자의 언어로 기술한다. (a. 이해
와 전달의 문제 발생)
요구사항 간에 충돌이 발생한다. (b. 충돌)
요구사항이 중간에 사라진다. (c. 누락)
요구사항에 대한 통합 관리가 안된다. (d. 과
정의 생략, e. 추적성, f. 변화 관리의 문제)
제안서 작성자와 프로젝트 헌장 작성자가
다르거나(a), 제안 발표 후 합의된 내용이
헌장에 미 기재 (a, c, e) 및 프로젝트 헌장
의 생략 (a, d), 제안사항 간 충돌(b) 미 작성 또는 미
확보 (a, c, d, e, f)
요구사항 간 내용
불 일치(a,b, e, f)
설계서에 요구사항,
특히 조건과 제약사항
미 기재 (a, c, d, e, f)
설계서 만 참조
(a, c, e, f)
(*)모든 프로젝트 멤버는 요구사항에 대한
(이해), (이끌어냄), (검증)의 책임이 있다.
13년 8월 20일 화요일

6. 3. 요구사항 분석 관련 오류들
Page 6, CHJONG
3.2 발견의 오류
Part One - 요구사항 분석과 관련 오류들
발견의 대상
Business 요구사항을 만족시키는 Software
요구사항이 존재하지 않는다. 또는 반대~
발견의 주체
모든 요구사항은 고객이 제시하는 것이다.
발견의 한계
아직도 (설계가 끝나가는 시점) 해결되지 않
는 이슈 (Consideration과 Assumption)가 존
재한다.
Business Goal
Business 요구사항
숨겨진 Business 요구사항
상응하는 Software 요구사항
미해결 Software 요구사항
나만 아는 Software 요구사항
13년 8월 20일 화요일

7. 3. 요구사항 분석 관련 오류들
Page 7, CHJONG
3.3 적용의 오류
Part One - 요구사항 분석과 관련 오류들
요구사항 관련 문서들을 참조하지 않는다.
자의적 해석 또는 결정을 한다.
/*”Google Cloud Messaging 에러 시에는 SMS로 메시지
를 보내야 한다.” 라는 Software 요구사항 분석서 내용이
설계 문서 (예: Sequence Diagram)에 반영되지 않거나 예
외상황 처리에 대해 정의가 되어있지 경우, 보통 개발자
분들은 생각하기 싫고 귀찮아서 내 버려두거나 알아서 처
리합니다. */
String resultMsg = null;
try {
resultMsg = sendGCMMessage(String Msg);
}
catch (IOException ex) {
resultMsg = “Error :” + ex.getMessage();
}
finally { // 적용되지 않은 비즈니스 로직
resultMsg = sendSMS(String Msg);
]
싫어!
프로젝트 주요
실패 요인
13년 8월 20일 화요일

8. 목차
Part One - 요구사항 분석과 관련 오류들
1. 요구사항이란 무엇인가?
2. 요구사항 분석이란?
3. 요구사항 분석 관련 오류들
3.1 커뮤니케이션 오류
3.2 발견의 오류
3.3 적용의 오류
Part Two - 요구사항 분석 오류방지의 팁
1. 커뮤니케이션 오류방지 팁
1.1 오류방지 팁 Overview
1.2 팁을 활용한 체크포인트
1.3 요구사항분석서 예시와 체크포인트
1.4 요구사항 추적 매트릭스 예시
2. 발견의 오류방지 팁
3. 적용의 오류방지 팁
Wrap-Up (잊지말아야 할 것들)
13년 8월 20일 화요일

9. 1. 커뮤니케이션 오류방지 팁
Page 8, CHJONG
1.1 오류방지 팁 Overview
Part Two - 요구사항 분석 오류방지의 팁
요구사항의 고
객/사용자 관점
유지하라.
요구사항 관련 필
요사항과 조건들
을 점검하라.
명확성, 완전성
및 일관성을 유지
하도록 요구사항
을 기술하라.
요구사항 추적 매트릭스
사용자 언어로 요구사항 기술
5W1H (육하원칙)
3C1A (Conditions, Constraints,
Considerations & Assumptions)
Kick-Off, 각종 Reviews
요구사항 추적성과 변환관리 향상, 충돌 제거
요구사항 이해도와 전달력 증가 (도메인 지식)
요구사항 누락 방지, 공식화 및 묵시적 합의 도출
요구사항 이해도와 전달력 증가
프로젝트 범위 & 잠재적 위험요소들 차단
주요 Business 룰/로직의 누락 방지
13년 8월 20일 화요일

10. 1. 커뮤니케이션 오류방지 팁
1.2 팁을 활용한 체크포인트
Part Two - 요구사항 분석 오류방지의 팁
Business 요구사항 간, Software 요구사항 간 충돌 또는 Business와
Software 요구사항 간 충돌은 없는가? (무결성)
Business요구사항에 상응하는 Software 요구사항이 존재하는가? (추적성)
[요구사항 추적성, 상세화 점검]
요구사항 추적 매트릭스
사용자 언어로 요구사항 기술
5W1H (육하원칙)
3C1A (Conditions, Constraints,
Considerations & Assumptions)
Kick-Off, 각종 Reviews
요구사항 추적성과 변
화관리 향상, 충돌제거
요구사항 이해도와
전달력 증가
요구사항 누락 방지,
요구사항의 공식화
요구사항 이해도와
전달력 증가
프로젝트 범위 관련 잠
재적 위험요소들 차단
주요 Business 룰/
로직의 누락 방지
요구사항 수행에 필요한 주요 사건들을 사용자 언어로 기술하고
있는가? (이해도, 전달력)
주요 사건들에 종속(포함 또는 재 사용)되는 사건들을 사용자 언
어로 기술하고 있는가? (이해도, 전달력)
프로젝트 Kick-Off와 요건/설계 리뷰 시 요구사항을 확인하는가? (공식성)
요구사항 수행 전에 만족되어야 하는 조건이 있는가? (선행조건)
요구사항 수행동안에 지켜져야 할 조건이 있는가? (수행 조건)
요구사항 수행 후 시스템에 기대하는 조건은 무었인가? (후행조건)
요구사항 수행과 관련한 제약이 있는가? (제약사항: 주로 비 기능사항)
[Business Rules / Logic 점검]
사실여부에 대해 확인 필요한 사항/조건이 있는가? (고려사항-잠재위험)
사실일 것이라고 생각(전제)하고 있는 것이 있는가? (전제사항-잠재위험)
요구사항을 육하원칙에 따라서 기술하였는가? (명확성, 완전성, 완료성)
Page 9, CHJONG
13년 8월 20일 화요일

11. 1. 커뮤니케이션 오류방지 팁
Page 10, CHJONG
1.3 요구사항 분석서 예시와 체크포인트
Part Two - 요구사항 분석 오류방지의 팁
Software 요구사항 ID: SW_REQ_1
요구사항: 사용자들은 그들이 원할 때 모바일 기기를 활용해서 여
행 상품을 오프라인보다 5% 할인된 가격에 구매 및 결제할 수 있다.
요구사항 주요사건 흐름
(1) 모바일 캠페인을 통해 사용자는 상품 할인 정보를 받는다.
(2) 사용자가 관심있는 상품정보 링크를 클릭한다.
(3) 기 설치된 모바일 앱이 자동 실행된다. (사용자인증 포함)
(4) 사용자가 클릭한 상품정보가 모바일 앱 화면에 표시된다.
(5) 사용자가 상품구매 버튼을 클릭한다.
(6) 사용자에게 구매 내용 확인 화면이 표시된다.
(7) 사용자가 내용 확인 및 결제 버튼을 클릭한다. (결제 포함)
(8) 구매 내역이 보여지고 모바일 여행 상품권이 발송된다.
종속사건 (사용자 인증) 흐름
(1) 자동 로그인 여부를 확인한다.
(2)-1 자동 로그인 설정 시 인증 성공처리 한다.
(2)-2 자동 로그인 비 설정 시
a. 로그인 화면을 표시한다.
b. 사용자가 패스워드 입력 시 키보드 보안 창을 표시한다.
c. 아이디를 활용해 이중 로그인 여부를 확인한다.
d. 사용자가 입력한 정보로 인증을 수행한다.
- 인증 성공 시 인증 완료
- 인증 실패 시 사용자에게 재 로그인을 묻는 화면을 표시하고
사용자가 취소 시 인증 실패 처리한다.
... (생략)
선행조건: 예약가능한 상품정보가 있어야 한다.
수행조건: 사용자가 상품 구매 진행 시에는 예약 가능한 상품 수량
이 감소되어야 한다.
후행조건: 고객이 구매한 상품정보가 보여진다. 또한, 이중 보안을
원하는 고객의 경우에는 고객의 모바일 기기로 전송된 개인비밀코
드를 입력해야 만 상품정보를 조회할 수 있다.
제약사항: (1) 사용자는 복수의 모바일 기기를 활용한 이중 로그인
을 할 수 없다. (2) 사용자는 동일한 상품에 대한 복수 구매을 할 수
없다. (3) 사용자가 구매한 상품정보의 이중 보안을 원할 경우, 휴
대폰 인증을 제공해야 한다. (4) 상품정보 조회 앱 페이지는 고객
클릭 시 2초 이내에 모바일 기기에 표시되어야 한다.
고려사항: 모바일 사용자 인증은 기존 고객사의 통합아이디 관리시
스템과의 연동으로 수행한다. 이와 관련해 기존 통합아이디 관리
시스템이 이중 로그인 점검 기능을 제공하는 지 확인이 필요하며,
미 제공 시 구현을 고려해야 한다.
전제사항: 모바일 캠페인을 통해 여행 상품을 구매 시에는 오프라
인 상품 대비 5%의 고정할인을 고객에게 제공한다.
리뷰 이력
리뷰(1): 2013년 6월 10일, 아무개 (고객사), 홍길동 (개발사)
리뷰(2): 2013년 8월 10일, 아무개 (고객사), 홍길동 (개발사)
육하원칙 준수: 명확성,
완전성, 완료성
이해도, 전달력
공식성
잠재위험-
해결필요
잠재위험-해결필요
Business Rules 존재 - 설계자, 개발자, 테스터 확인사항들
13년 8월 20일 화요일

12. 1. 커뮤니케이션 오류방지 팁
Page 11, CHJONG
1.4 요구사항 추적 매트릭스 예시
Part Two - 요구사항 분석 오류방지의 팁
구분구분
Software 요구사항 IDID
구분구분
SW_REQ_1 SW_REQ_2 SW_REQ_3 ...
Business
BIZ_REQ_1
RFP Page: 100
제안서 Page: 150
Conditions 유무: 유
Constraints 유무: 무
Issues: Open (2건)
Test Case ID: TC_1
...
Business
요구사항 ID
BIZ_REQ_5
RFP Page: 200
제안서 Page: 170
Conditions 유무: 유
Constraints 유무: 무
Issues: Close
Test Case ID: TC_1
...
... ... ... ... ...
여기에서 Issues 란
Considerations과
Assumptions을 말함
무결성, 추적성
Business Rules
유/무 확인
13년 8월 20일 화요일

13. 오류 유형 개선 포인트 방지 팁
요구사항 추적 매트릭스를 통
해 Business 요구사항과
Software 요구사항과의 매핑
을 확인하라. 프로젝트를 주
관하는 고객부서가 IT조직이
면 Software 요구사항만 있을
수도 있다. (큰 문제 가능성)
[프로젝트 범위와 갈등의 요인 제거 - 반복적 분석]
TBD = true; noCorrespondingReqs = true;
for (each of Business or Software Requirements) {
while (TBD || noCorrespondingReqs) {
프로젝트의 모든 멤버들은 요
구사항 제시의 책임이 있다.
각자의 전문 영역과 경험에
따라서 제시할 수 있는 요구
사항 종류가 다르기 때문이
다.
각 요구사항에 대해 결정되지
않은 것은 설계 전에 제거하
라. 대부분의 프로젝트 범위
변화의 주범이며, 갈등의 주
요 요인이다.
if(allConsiderationsClosed && allAssumptionsClosed){
TBD = false;
}
} //Fetch next Business Requirements
} //Find All Requirements and Handle them Successfully.
2. 발견의 오류방지 팁
Page 12, CHJONG
Part Two - 요구사항 분석 오류방지의 팁
Business 요구사
항을 만족시키는
Software 요구사
항이 존재하지 않
는다. 또는 반대
모든 요구사항은
고객이 제시하는
것이다.
아직도 해결되지
않는 이슈
(Consideration &
Assumption)가
존재한다.
[Do Iterative Requirements Analysis]
(1) 5W1H 활용, 신규 Consideration & Assumption 식별
(2) 요구사항 분석서 / 매트릭스 갱신
(3) 요구사항 매트릭스에 상응하는 Business와 Software
요구사항 존재 시 noCorrespondingReqs = false로 셋팅
(4) 3C1A 점검 및 Consideration과 Assumption이 모두
해결 시 Close
13년 8월 20일 화요일

14. 오류 유형 개선 포인트 방지 팁
요구사항 적용과 Cross
Checking 역할을 수행하라:
요구사항 추적 매트릭스를 활
용해 요구사항 관련 모든 문
서들을 참조하고 자신의 업무
활동에 적용하라.(예: 개발자
의 2C 적용)
[Ground Rule: 요구사항 추적을 실행하라.]
자의적 해석 또는 결정을 하
지 말고 해당 사항(조건)을 처
리 방안을 Consideration과
Assumption에 명기하고 공
지하라. (예: 개발자는 Push
Exception 종류에 따른 처리,
메시지는 String을 저장할 것
인가?, 비동기 메시지 처리도
필요한가? 라는 질문을 쉽게
할 수 있다.)
[Ground Rule: 추적 실패 시에는 이슈화 하라.]
3. 적용의 오류방지 팁
Page 13, CHJONG
Part Two - 요구사항 분석 오류방지의 팁
요구사항 관련 문
서들을 참조하지
않는다.
자의적 해석 또는
결정을 한다.
SW_REQ_1
BIZ_REQ_1
RFP Page: 100
제안서 Page: 150
Conditions 유무: 유
Constraints 유무: 무
Issues: Open (2건)
Test Case ID: TC_1
제안요청서, 제안서,
요구사항분석서 내
용을 보아야 한다.
SW_REQ_2
BIZ_REQ_5
RFP Page: 200
제안서 Page: 170
Conditions 유무: 유
Constraints 유무: 무
Issues: Close to Open
Test Case ID: TC_1
Issues를 Open으로
변경하고 해당 내용
을 요구사항분석서
에 갱신 및 프로젝트
멤버들과 요구사항
추적 매트릭스를 새
로 공유한다.
13년 8월 20일 화요일

15. Warp-Up (잊지 말아야 할 것들)
Page 14, CHJONG
프로젝트 성공의 기준이 고객마다 다르다. (Business VS Software 요구사항)
프로젝트 멤버들은 반드시 Business와 Software 요구사항 모두를 이해해야 한다. 특히,
고객이 Software 요구사항 만 제시할 경우 Business Goal과 요구사항을 확보하지 못하
면 프로젝트 실패 확률이 매우 높다.
요구사항은 충분히 상세하게 정의되어야 한다. (5W1H, 3C1A, 고객의 언어)
요구사항은 고객만이 제시하는 것이 아니다. 프로젝트 멤버 모두가 제시할 수 있다. 나
아가 요구사항은 수집뿐만 아니라 이끌어 내어야 하는 것이다.
프로젝트 멤버의 자의적 해석과 결정이 프로젝트 전체를 실패하게 만들 수 있다.
요구사항 추적 매트릭스를 통해 Business와 Software 요구사항 간의 관계, 요구사항 추
적성, 요구사항 이슈를 포함한 변화관리를 수행하라.
13년 8월 20일 화요일