Transcript 슬라이드 1

3. Requirement
Engineering
2
“Something required; something wanted or needed”
- Webster’s 9th New Collegiate Dictionary
“Condition or capability needed by a user to
solve a problem or achieve an objective”
- IEEE Standard 729
“Complete statement of WHAT the system will do
without referring to HOW it will do it”
- A traditional definition
“Externally observable characteristic of a desired system”
- Prof. A. Davis, author of
Just Enough Requirements Management
3

현실 속의 문제

문제에 대한 솔루션
Sparks
Electrodes
Factory
Foreman
Order
Entry
Finished
Goods
4
5
As development teams, we spend too little time
trying to understand the problem, and
too much time developing technology-based
Solutions to problems we don’t truly understand.
6

Standish Report:
프로젝트 실패는 대부분 요구사항에 관련된 문제로 인해 실패한다

Causes for Failed Projects
Percentage
불충분한 사용자 의사표현
12.8%
불완전한 요구사항
12.3%
요구사항 변경
11.8%
Savant Studies:


시스템 에러의 56%는 프로젝트 참가자 간 의사소통의 문제로 인해 발생
한다
이로 인한 에러를 수정하기 위해 일정의 82%가 추가된다
7

프로젝트 후반에는 에러 수정 비용이 커진다
프로젝트 단계
상대적 에러 수정 비용
요구사항 단계
1-2
설계 단계
5
코딩 단계
10
단위 테스트 단계
20
시스템 테스트 단계
50
유지보수 단계
200
8
대부분의 에러는 프로젝트 초반에 주입된다


TRW 프로젝트 중 발견된 전체 에러 중 54%가 코딩 단계와 단위 테
스팅 단계 이후에 발견되었다
대부분의 에러는 코딩 단계가 아니라 요구사항 단계에서 비롯되었다
typical
better
effort

Development
time is reduced
with tool
support
9

요구사항은 전체 시스템 개발에 큰 영향을 미친다
People Affected
Depend on Requirements to
클라이언트 / 사용자
자신이 기술한 필요를 검증
관리자
프로젝트 비용 및 일정을 결정
시스템 엔지니어
소프트웨어 개발을 계획
테스터
테스팅을 위한 지침을 개발
소프트웨어 엔지니어
상위 레벨 설계를 위한 지침을 개발
형상관리 담당자
기능 베이스라인을 수립
기타 이해관계자
프로젝트 수행을 위한 여러 지침을 개발
10
[Proverb]
11
12

SRS (Software Requirements Specification)


A document containing a complete description of product’s
external behavior
Corresponds to level 3 in the “what versus how” dilemma
What
How
SRS area
What
How
What
How
Design & implementation area
What
How
What
How
User needs
Product space
(Set of all legal behaviors)
Actual product’s behavior
Architecture/data flow
Module specifications
Algorithms/code
13

요구사항 추출 (Requirements Elicitation)

우선순위화 및 선별 (Prioritization & Triage)

문서화 (Documentation)
14


이해관계자에게 귀를 기울이는 기술
(Art of Listening)
이해관계자에게 적절한 자극을 보내어 그들의 답
변이 청취할 가치가 있도록 유도하는 기술
(Art of Sending Appropriate Stimuli)

이해관계자가 자신의 문제와 요구를 기술할 수
있도록 하는 환경을 조성하는 기술
(Art of Establishing an Environment)
15
1.
2.
3.
4.
5.
Don’t Lose Sight of the Goal
Care
Think Who’s Smart
Speak the Same Language
Use Appropriate Elicitation Methods
16

Reduce the risk of building the wrong system

Obtain early commitment from stakeholders
17


If you don’t really care about solving the
customers’ problem, then don’t “fake”
elicitation!
Find somebody who does
18


Don’t try to convince stakeholders that YOU are smart
– wrong place to do that
Instead, take everybody to show you think the
STAKEHOLDER is smart
Contrast these 2 cases:
I see.
Tell me why
you feel they
are too slow.
My elevators
are
TOO SLOW!
I DON’T THINK SO.
I think you Have an
elevator THROUGHPUT
problem, not a SPEED
problem.
19

Deal with ambiguity



Users and developers should use the same set of
terminology



Miscommunications are caused by word meaning
Ask questions like “What do you mean by X?”
Use supplements



Natural language is ambiguous and often not understandable
Each person uses his/her own expressions
Graphs
Diagrams
Record all new definitions
20

Methods for requirements elicitation:

Interviews
Same Place, Same Time / Few People, Analyst-Driven

Questionnaires
Different Time, Different Place / Many People, Analyst-Observer

Group Sessions
Same or Different Place, Same Time / < 20 People, Analyst Facilitated

Observation
Same Time, Same Place / Analyst-Observer
21
기존 요구사항에
덧붙여…
새로운 후보
요구사항들을
추가한다
22

요구사항 우선순위화 (Prioritization)

요구사항 Triage
23
Why do we need to prioritize requirements?
If too many requirements:
Limited
Time
Money
Skills
Resources
“Can’t get all the
features in
release 1.0”
Requirements
Unselected Requirements
"overflow"
requirements
Deal with Critical Requirements First
Use Incremental Development
Release 1.0
Schedule
2.0
New absolutely
necessary
requirements
3.0
24

$100 테스트



YES/NO 투표



각 요구사항이 받는 금액의 합으로 수치적으로 우선순위를 부여
하지만 게임의 법칙이 왜곡될 가능성이 있다 (참여자들 간
의도적인 합의로 특정 요구사항에만 돈이 쏠릴 수 있음)
간단하고 직관적인 다수결 원칙의 선별
하지만 ‘NO’라고 뜻을 밝힌 사람의 심중을 알 수 없다. 해당 요구사항이 이번 배
포에 불필요하다고 생각하는 것인가, 그렇지 않다면 전적으로 반대하는 것인가?
-2 to +2


각 요구사항이 받는 점수의 총합으로 우선순위를 부여
하지만 ‘0’과 ‘0’을 받아 합계가 ‘0’인 요구사항과 ‘2’와 ‘-2’를 받아 합계가 ‘0’인 요
구사항은 서로 다른 의미를 지니므로 별도로 기록할 필요가 있다
25

AHP (Analytical Hierarchy Process)
Relative Weights:
Feature
2.0
1.0
1.0
0.5
Relative Relative Total
Relative
Relative
Value %
Cost %
Risk % Priority
Benefit Penalty Value
Cost
Risk
Print a material safety
data sheet
2
4
8
5.2
1
2.7
1
3.0
1.22
Query status of a vendor
order
5
3
13
8.4
2
5.4
1
3.0
1.21
Generate a Chemical
Stockroom inventory report
9
7
25
16.1
5
13.5
3
9.1
0.89
See history of a specific
chemical container
5
5
15
9.7
3
8.1
2
6.1
0.87
Search vendor catalogs for
a specific chemical
9
8
26
16.8
3
8.1
8
24.2
0.83
Maintain a list of hazardous
chemicals
3
9
15
9.7
3
8.1
4
12.1
0.68
Modify a pending chemical
request
4
3
11
7.1
3
8.1
2
6.1
0.64
Generate an individual
laboratory inventory report
6
2
14
9.0
4
10.8
3
9.1
0.59
Check training database for
hazardous chemical training record
3
4
10
6.5
4
10.8
2
6.1
0.47
Import chemical structures
from structure drawing tools
7
4
18
11.6
9
24.3
7
21.2
0.33
26
출처:
Azar, J. at al, “Value-Oriented Requirements Prioritization in
Small Development Organizations”, IEEE Software, Jan/Feb, 2007
27

TBI (Technology Builders Incorporated) 社
• 소프트웨어 품질 및 요구관리 분야에 특화된 도구 제공
 CaliberRM : 소프트웨어 요구사항 문서화, 요구사항들 간 traceability 관리
• 1994년 6명의 개발팀으로 출발한 중소 소프트웨어 개발 기업
• 사업 시작 후 작은 성공을 거두어 회사 확장 -> 초기에 특정 사용자
층에 제한되어 있던 stakeholder들이 다양한 소프트웨어 분야로 확
대됨
• Stakeholder들이 다양해짐에 따라 소프트웨어 개선 요구사항 또한
따라서 증가함 -> 개선 요구사항들 간 충돌이 발생
28

Value-Oriented Prioritization (VOP)
• 여러 stakeholder들 간 이해가 상충될 경우 토의를 통한 합의점 도달이 어려
우므로, 객관적이고 특정 stakeholder 그룹에 치우치지 않은 투명한 요구사항
선별 프로세스가 필요함
• VOP 접근법은 기업이 목표로 하는 핵심적인 비즈니스 가치(Core Business
Value)를 객관적인 기준으로 제시하여 모든 요구사항을 평가하는 근거로 사용
• 요구사항 선별 기준을 기업의 비즈니스 가치에 맞춤으로서 stakeholder 간 소
모적인 마찰을 기업의 향후 전략 수준의 토의로 끌어올릴 수 있음
29

1. TBI 운영진이 직접 자신의 핵심 비즈니스 가치를 선별,
카테고리 별로 정리
가치 (Value)
정의 (Definition)
판매 (Sales)
새로운 매출을 창출할 수 있는 가능성 관점에서의
영업 팀을 위한 가치
소비자 만족도
(Customer
Satisfaction)
기존 소비자들을 위한 가치. 직접적인 수입이
창출되지는 않지만 기존의 고객들의 추가적인 구매를
유도하고 유지보수 계약을 연장하도록 하며 주변에
홍보효과를 발휘하도록 하는 간접적인 영향
마케팅 (Marketing)
마케팅 용도로 잠재적 구매자의 관심과 인지를
이끌어내는 가치
전략 (Strategic)
기업의 전략적 목표를 달성하기 위한 가치 –
Integration을 통한 타 기업과의 비즈니스 제휴 등
무결성 (Integrity)
무결성과 관련된 가치 – 데이터 무결성 또는
비즈니스 무결성 등
30

2. 기업의 비즈니스 목표 달성을 위한 역할 비중에 따라 각
카테고리에 비중(Weight) 부여
 1 ~ 10 사이의 점수 (10에 가까울수록 기업의 핵심 비즈니스 목표에 부합)
 TBI의 경우 소비자 만족도의 유지에 자신감을 갖고 있었으므로 소비자 만족도와
무결성에 높은 비중 부여
핵심 비즈니스 가치
비중 (Weight)
판매
소비자
만족도
마케
팅
전략
무결
성
4
6
4
7
10
31

3. 선별할 모든 후보 요구사항들을 검토 – 각 요구사항을
카테고리 별로 다른 관점에서 각각 점수를 책정
 1 ~ 10 사이의 점수를 책정
 각 요구사항의 점수는 속한 카테고리의 비중과 곱해지고, 모든 카테고리에 걸친 점
수가 총합되어 요구사항의 총점을 결정
요구사항
판매
소비자
만족도
마케
팅
전략
무결
성
핵심 비즈니스 가치
4
6
4
7
10
철자 검사
3
8
2
2
0
82
모델링 도구와의 Integration
9
0
6
7
0
109
커스터마이징 가능한 양식
6
5
2
2
0
76
임베딩 가능한 이미지
7
3
4
2
0
72
보안기능 향상
2
4
0
0
9
122
점수
32

4. 모든 요구사항의 점수가 산출된 후, stakeholder들이 모
두 참석하는 미팅을 개최하고 최종 점수를 공개
-> Stakeholder들의 의견을 수렴하고 요구사항들의 점수 검토 및 수정
 가장 많은 토의와 협의를 거치게 되는 단계로, 자신의 이해가 걸린 요구사항이 낮
은 점수를 받을 경우 stakeholder가 채점 시스템에 불만을 가지는 경우도 있었으
나, 시스템의 오류를 지적할 수는 없었음
 결과적으로 모든 stakeholder들이 합의하고 수긍할 수 있는 점수 책정에 다다름
33

5. 최종 점수에 따라 우선순위가 부여된 요구사항들을 목록
으로 작성 후, 각 요구사항에 수반되는 리스크와 비용을 검
토하여 위험성이 높은 요구사항을 배제
요구사항
판매
소비자
만족도
마케
팅
전략
무결
성
핵심 비즈니스 가치
4
6
4
7
10
철자 검사 (31)*
3
8
2
2
0
111
모델링 도구와의 Integration (23)*
9
0
6
7
0
98
커스터마이징 가능한 양식
6
5
2
2
0
76
임베딩 가능한 이미지
7
3
4
2
0
72
보안기능 향상 (12)*
2
4
0
0
9
109
점수
* 비용 및 리스크 감안 후 순위가 변동된 잠재적 요구사항
34

VOP를 적용하기 시작한 1998년 당시 TBI는 40명 규모의
인력을 갖춘 중소기업

3년간 (98~01) VOP를 CaliberRM 개발에 적용

회사 규모는 2001년 150명 규모로 성장, $30M 수익 달성

2001년에 업계 선두 소프트웨어 개발 기업에 의하여 인수
됨
“VOP는 소프트웨어 제품 향상에 있어 기업이 ‘다음에 무엇을 향상시켜야 하
는가’를 알 수 있도록 해준다. 중소기업에 있어 이 결정은 때로 돌이킬 수 없
는 결과를 가져오는 경우가 많다. VOP는 TBI사가 성공적인 결정을 내리도
록 도와서 성공과 직결되도록 했다.”
- TBI Executives Comment
35

이후의 배포에 포함될 “적절한” 기능을 선택한다

결과는 Win-Win 또는 Lose-Lose 이다

결론에 다다르기 어렵다
Cost

요구사항 vs. 일정/비용 리스크
• 엔지니어적 관점
• 요구사항과 비용/리스크/일정을 균형잡음
• 비즈니스 관점
• 요구사항과 비용/리스크/일정/시장성/판매실적/수익/가격책
정/ROI를 균형잡음
36

대부분의 개발 조직이 요구사항 선별을 올바르게
수행하지 않는다



요구사항 선별을 내부적으로, 암묵적으로 수행한다. 따라서 리스크를 떠
안거나 강압이 이루어지고, 정치적 게임이 벌어진다
요구사항 선별을 무시한다면 프로젝트는 필연적으로 지연되며 예산을
초과하게 된다
그렇다 해도 선별은 어차피 피할 수 없다


그리고 프로젝트를 살리기 위해 요구사항의 일부는 결국 버려지게 된다.
하지만 이럴 경우 요구사항 선별이 제대로 이루어지지 않는다
요구사항 선별 조건이 다음과 같아서는 안 된다:
• “아직 덜 만든 게 뭐지?”
• “뭘 버려야 시간을 가장 많이 아낄 수 있지?”
37

새로운 요구사항이 추가될지 여부는 잔여 일정에
의해 결정되도록 한다
자, 여기 우리 요구사항들이 있소.
일반적인
상황:
언제까지 끝내줄 수 있겠소?
9달이
필요하겠습니다.
아니오, 6달 내에
끝내도록 하시오.
38
보다
바람직한
상황:
3개월 주기로 점증적으로 개발할 겁니다.
요구사항 목록이 여기 있어요.
어디 봐요. 요구사항
1번부터 9번까지와
12번은 3달 내에 개
발할 수 있겠네요.
그렇지만 요구사항
17번은 꼭 첫 번째
제품에 포함되어야
해요.
좋아, 요구사항 12번
을 버리고 17번을 넣
는 건 어때요?
39
제대로
팀웍이
이루어지는
상황:
흠, 난 12번이 정말 마음에 드는
데, 3번을 대신 버릴 수 없나요?
글쎄요, 3번과 4번을
같이 포기한다면 가
능하겠죠.
괜찮군요.
40
요구사항 목록화,
부가정보 첨부,
정렬
후보 요구사항
그룹 선택
선택 결과 검토
요구사항
선택 변경
NO?
OK?
완료
41

부가정보가 첨부된 요구사항 목록

요구사항이 개발 일정과 예산에 맞추어짐

모든 이해관계자가 선별 결과에 동의함
42

연습 프로젝트를 수행한다: 수집된 요구사항에 우선순위를
부여하고 3개월 내에 개발 가능한 요구사항을 선별한다


프로젝트 명: “맞춤형 대중교통수단”
목적: 교외 대중교통 시스템의 사용률을 증가시킨다
SMS, 콜 센터, 인터넷 등을 사용하여 대중교
통수단을 요청할 수 있다 (탑승장소, 목적지,
출발시간, 도착시간 등의 정보를 제공)
PTSPC
(Public
Transportation
Service
Provider Center)
최적의 이동 경로와 운임, 예상 도착시간,
기타 교통 정보를 제공한다
43

현재 5명의 인력을 사용할 수 있다; 3개월 내에 프로젝트를 완료하기
위해서는 15 man-month 이하의 공수를 계획해야 한다
요구사항
우선순위
(1~10)
리스크
(1~10)
공수
(MM)
요구사항 #1. 시스템에 고객 등록, 로그인, 로그아웃 등의 기능이 갖추어져야 한다.
1
요구사항 #2. 운전기사가 탑승객의 요청을 조회할 수 있어야 한다.
3
요구사항 #3. 시스템은 인터넷을 통해 서비스 신청을 받을 수 있어야 한다.
2
요구사항 #4. 고객은 탑승하기 앞서 이동경로를 지정할 수 있어야 한다.
3
요구사항 #5. 시스템은 SMS를 통해 서비스 신청을 받을 수 있어야 한다.
2
요구사항 #6. 시스템은 콜 센터를 통해 서비스 신청을 받을 수 있어야 한다.
2
요구사항 #7. 관리자는 인터넷을 통해 서비스 신청을 관리할 수 있어야 한다.
1
요구사항 #8. 관리자는 콜 센터를 통해 고객 프로파일을 수정할 수 있어야 한다.
2
요구사항 #9. 택시와 교통상황 담당자 간 데이터 교환이 가능해야 한다.
3
요구사항 #10. 관리자는 인터넷을 통해 고객 프로파일을 수정할 수 있어야 한다.
1
선택여부
( O / X)
44
結論
善堙川者必杜其源,
선인천자필두기원,
善防奸者必絶其萌.
선방간자필절기맹.
위징(魏徵)의 ‘군서치요 정론(群書治要 政論)’
GET IT RIGT, RIGHT FROM THE START
45