Requirements Analysis & its' Faults Prevention

요구사항분석 오류들과 방지를 위한 팁

Aug. 2013정철호(CHOLHO, JONG)

13년 8월 20일 화요일

목차

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 (잊지말아야 할 것들)


1. 요구사항이란 무엇인가? Part One - 요구사항 분석 관련 오류들

, 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)


2. 요구사항 분석이란? Part One - 요구사항 분석 관련 오류들

, CHJONG

(Software) 요구사항 분석은 새로운 제품/서비스를 위해 충족되어야 할 필요사항들 또는 조건들을 결정해 나가는 업무 (요구사항 수집, 해석, 문서화, 검증 및 관리)

요구사항 분석은 프로젝트 시작에서 끝까지 수행해야하는 업무 - 변화관리 VS 누구의 관심 대상인가?

고객이 제시하는 비즈니스 요구사항과 소프트웨어 요구사항은 다름

요구사항 문서화에 대한 표준은 없음. 단, 요구사항 문서는 설계와 개발을 위한 주요 정보를 포함하도록 상세해야 함.

요구사항 수집 요구사항 해석 요구사항문서화 요구사항 검증 요구사항

변화관리


3. 요구사항 분석 관련 오류들 Part One - 요구사항 분석과 관련 오류들

, 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)

(*)모든 프로젝트 멤버는 요구사항에 대한 (이해), (이끌어냄), (검증)의 책임이 있다.


3. 요구사항 분석 관련 오류들

, CHJONG

3.2 발견의 오류

Part One - 요구사항 분석과 관련 오류들

발견의 대상Business 요구사항을 만족시키는 Software 요구사항이 존재하지 않는다. 또는 반대~발견의 주체모든 요구사항은 고객이 제시하는 것이다.발견의 한계아직도 (설계가 끝나가는 시점) 해결되지 않는 이슈 (Consideration과 Assumption)가 존재한다.

Business Goal

Business 요구사항

숨겨진 Business 요구사항상응하는 Software 요구사항미해결 Software 요구사항나만 아는 Software 요구사항


3. 요구사항 분석 관련 오류들

, 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);]

싫어!

프로젝트 주요 실패 요인


목차

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 (잊지말아야 할 것들)


1. 커뮤니케이션 오류방지 팁

Page 8, CHJONG

1.1 오류방지 팁 Overview

Part Two - 요구사항 분석 오류방지의 팁

요구사항의 고객/사용자 관점 유지하라.

요구사항 관련 필요사항과 조건들을 점검하라.

명확성, 완전성 및 일관성을 유지하도록 요구사항을 기술하라.

요구사항 추적 매트릭스

사용자 언어로 요구사항 기술

5W1H (육하원칙)

3C1A (Conditions, Constraints, Considerations & Assumptions)

Kick-Off, 각종 Reviews

요구사항 추적성과 변환관리 향상, 충돌 제거

요구사항 이해도와 전달력 증가 (도메인 지식)

요구사항 누락 방지, 공식화 및 묵시적 합의 도출

요구사항 이해도와 전달력 증가

프로젝트 범위 & 잠재적 위험요소들 차단

주요 Business 룰/로직의 누락 방지



1.2 팁을 활용한 체크포인트


Business 요구사항 간, Software 요구사항 간 충돌 또는 Business와 Software 요구사항 간 충돌은 없는가? (무결성)Business요구사항에 상응하는 Software 요구사항이 존재하는가? (추적성)

[요구사항 추적성, 상세화 점검]

요구사항 추적 매트릭스

사용자 언어로 요구사항 기술

5W1H (육하원칙)

3C1A (Conditions, Constraints, Considerations & Assumptions)

Kick-Off, 각종 Reviews

요구사항 추적성과 변화관리 향상, 충돌제거


요구사항 누락 방지, 요구사항의 공식화


프로젝트 범위 관련 잠재적 위험요소들 차단

주요 Business 룰/로직의 누락 방지

요구사항 수행에 필요한 주요 사건들을 사용자 언어로 기술하고 있는가? (이해도, 전달력)주요 사건들에 종속(포함 또는 재 사용)되는 사건들을 사용자 언어로 기술하고 있는가? (이해도, 전달력)

프로젝트 Kick-Off와 요건/설계 리뷰 시 요구사항을 확인하는가? (공식성)

요구사항 수행 전에 만족되어야 하는 조건이 있는가? (선행조건)요구사항 수행동안에 지켜져야 할 조건이 있는가? (수행 조건)요구사항 수행 후 시스템에 기대하는 조건은 무었인가? (후행조건)요구사항 수행과 관련한 제약이 있는가? (제약사항: 주로 비 기능사항)

[Business Rules / Logic 점검]

사실여부에 대해 확인 필요한 사항/조건이 있는가? (고려사항-잠재위험)사실일 것이라고 생각(전제)하고 있는 것이 있는가? (전제사항-잠재위험)

요구사항을 육하원칙에 따라서 기술하였는가? (명확성, 완전성, 완료성)

Page 9, CHJONG



Page 10, CHJONG

1.3 요구사항 분석서 예시와 체크포인트


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 존재 - 설계자, 개발자, 테스터 확인사항들



Page 11, CHJONG

1.4 요구사항 추적 매트릭스 예시


구분구분Software 요구사항 ID ID

구분구분SW_REQ_1 SW_REQ_2 SW_REQ_3 ...

Business

BIZ_REQ_1

RFP Page: 100제안서 Page: 150Conditions 유무: 유Constraints 유무: 무Issues: Open (2건)Test Case ID: TC_1

...

Business 요구사항 ID

BIZ_REQ_5

RFP Page: 200제안서 Page: 170Conditions 유무: 유Constraints 유무: 무Issues: CloseTest Case ID: TC_1

...

... ... ... ... ...

여기에서 Issues 란 Considerations과 Assumptions을 말함

무결성, 추적성

Business Rules 유/무 확인


오류 유형 개선 포인트 방지 팁

요구사항 추적 매트릭스를 통해 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


Business 요구사항을 만족시키는 Software 요구사항이 존재하지 않는다. 또는 반대

모든 요구사항은 고객이 제시하는 것이다.

아직도 해결되지 않는 이슈(Consideration & Assumption)가 존재한다.

[Do Iterative Requirements Analysis]

(1) 5W1H 활용, 신규 Consideration & Assumption 식별(2) 요구사항 분석서 / 매트릭스 갱신(3) 요구사항 매트릭스에 상응하는 Business와 Software 요구사항 존재 시 noCorrespondingReqs = false로 셋팅(4) 3C1A 점검 및 Consideration과 Assumption이 모두 해결 시 Close


오류 유형 개선 포인트 방지 팁

요구사항 적용과 Cross Checking 역할을 수행하라: 요구사항 추적 매트릭스를 활용해 요구사항 관련 모든 문서들을 참조하고 자신의 업무 활동에 적용하라.(예: 개발자의 2C 적용)

[Ground Rule: 요구사항 추적을 실행하라.]

자의적 해석 또는 결정을 하지 말고 해당 사항(조건)을 처리 방안을 Consideration과 Assumption에 명기하고 공지하라. (예: 개발자는 Push Exception 종류에 따른 처리, 메시지는 String을 저장할 것인가?, 비동기 메시지 처리도 필요한가? 라는 질문을 쉽게할 수 있다.)

[Ground Rule: 추적 실패 시에는 이슈화 하라.]

3. 적용의 오류방지 팁

Page 13, CHJONG


요구사항 관련 문서들을 참조하지 않는다.

자의적 해석 또는 결정을 한다.

SW_REQ_1

BIZ_REQ_1

RFP Page: 100제안서 Page: 150Conditions 유무: 유Constraints 유무: 무Issues: Open (2건)Test Case ID: TC_1

제안요청서, 제안서, 요구사항분석서 내용을 보아야 한다.

SW_REQ_2

BIZ_REQ_5

RFP Page: 200제안서 Page: 170Conditions 유무: 유Constraints 유무: 무Issues: Close to OpenTest Case ID: TC_1

Issues를 Open으로 변경하고 해당 내용을 요구사항분석서에 갱신 및 프로젝트멤버들과 요구사항 추적 매트릭스를 새로 공유한다.


Warp-Up (잊지 말아야 할 것들)

Page 14, CHJONG

프로젝트 성공의 기준이 고객마다 다르다. (Business VS Software 요구사항)

프로젝트 멤버들은 반드시 Business와 Software 요구사항 모두를 이해해야 한다. 특히, 고객이 Software 요구사항 만 제시할 경우 Business Goal과 요구사항을 확보하지 못하면 프로젝트 실패 확률이 매우 높다.

요구사항은 충분히 상세하게 정의되어야 한다. (5W1H, 3C1A, 고객의 언어)

요구사항은 고객만이 제시하는 것이 아니다. 프로젝트 멤버 모두가 제시할 수 있다. 나아가 요구사항은 수집뿐만 아니라 이끌어 내어야 하는 것이다.

프로젝트 멤버의 자의적 해석과 결정이 프로젝트 전체를 실패하게 만들 수 있다.

요구사항 추적 매트릭스를 통해 Business와 Software 요구사항 간의 관계, 요구사항 추적성, 요구사항 이슈를 포함한 변화관리를 수행하라.


Requirements Analysis & its' Faults Prevention

Documents

Transcript of Requirements Analysis & its' Faults Prevention