Page 1


책1.indb 1

2017-04-18 오후 4:02:42


XII

목차

Part

01

소프트웨어 요구사항: 무엇을, 왜, 누가

01 _ 필수 소프트웨어 요구사항 소프트웨어 요구사항의 정의

5

“요구사항”의 여러 해석

5

요구사항의 단계와 유형

6

세 단계로 요구사항 작성하기

13

제품 요구사항 vs. 프로젝트 요구사항

15

요구사항 개발과 관리

16

요구사항 개발

17

요구사항 관리

19

모든 프로젝트는 요구사항을 갖는다

20

좋은 사람이 나쁜 요구사항을 만날 때

21

사용자 참여 부족

21

부정확한 계획

22

점점 늘어나는 사용자 요구사항

22

모호한 요구사항

23

금도금

23

간과된 이해관계자

24

좋은 요구사항 프로세스의 이점

24

02 _ 고객 관점의 요구사항

책1.indb 12

기대치 차이

28

누가 고객인가?

29

고객과 개발자 간의 협력 관계

32

소프트웨어 고객을 위한 요구사항 권리장전

33

소프트웨어 고객을 위한 요구사항 의무장전

36

요구사항을 존중하는 문화 만들기

40

의사결정자 식별하기

42

요구사항 합의에 도달하기

43

요구사항 기준

44

합의에 도달하지 못하면 어떻게 할까?

45

애자일 프로젝트에서 요구사항에 동의하기

45

2017-04-18 오후 4:02:45


XIII

목차

03 _ 요구공학의 우수 사례 요구사항 개발 프로세스 프레임워크

51

우수 사례: 요구사항 도출

54

우수 사례: 요구사항 분석

57

우수 사례: 요구사항 명세

59

우수 사례: 요구사항 검증

60

우수 사례: 요구사항 관리

62

우수 사례: 지식

64

우수 사례: 프로젝트 관리

65

새로운 사례 시작하기

68

04 _ 비즈니스 분석가

책1.indb 13

비즈니스 분석가의 역할

72

비즈니스 분석가의 업무

74

분석가의 필수 역량

76

분석가의 필수 지식

81

비즈니스 분석가 육성

81

전직 사용자

82

전직 개발자나 테스터

83

전직(혹은 현직) 프로젝트 관리자

83

주제 전문가

84

초심자

84

애자일 프로젝트에서 분석가의 역할

85

협력적인 팀 구성하기

86

2017-04-18 오후 4:02:45


XIV

목차

02

05 _ 비즈니스 요구사항 정립하기

요구사항 개발

원하는 비즈니스 이득 식별하기

91

제품 비전 및 프로젝트 범위

92

상충하는 비즈니스 요구사항

94

Part

비즈니스 요구사항 정의하기

비전 범위 문서 1. 비즈니스 요구사항

91

95 97

2. 범위 및 한계

104

3. 비즈니스 컨텍스트

106

범위 표현 기법

108

컨텍스트 다이어그램

108

생태계 맵

110

기능 트리

111

이벤트 목록

112

범위에 집중하기

113

범위 결정을 위해 비즈니스 목표 활용하기

114

범위 변경의 영향력 평가하기

114

애자일 프로젝트의 비전과 범위

115

완료 여부 결정을 위해 비즈니스 목표 활용하기

116

06 _ 고객의 목소리 찾기 사용자 클래스

책1.indb 14

120

사용자 분류하기

120

사용자 클래스 식별하기

123

사용자 페르소나

126

사용자 대표와 함께하기

127

제품 챔피언

128

외부 제품 챔피언

130

제품 챔피언에 대한 기대

130

다수의 제품 챔피언

131

제품 챔피언의 아이디어 수용하기

133

피해야 할 제품 챔피언의 함정

134

2017-04-18 오후 4:02:45


XV

목차

애자일 프로젝트의 사용자 대표

134

상충하는 요구사항 해결하기

136

07 _ 요구사항 도출 요구사항 도출 기법

141

인터뷰

142

워크숍

144

포커스 그룹

147

관찰

148

설문지

149

시스템 인터페이스 분석

150

사용자 인터페이스 분석

151

문서 분석

151

프로젝트 요구사항 도출 계획

152

요구사항 도출 준비

154

요구사항 도출 활동 수행하기

156

요구사항 도출 후속 조치

159

노트 정리 및 공유

159

미해결 이슈 문서화하기

159

고객 의견 분류하기

160

요구사항 도출 완료 시점은 어떻게 알 수 있을까?

164

요구사항 도출 시 주의할 점

165

가정 요구사항과 암묵적 요구사항

166

누락된 요구사항 찾기

167

08 _ 사용자 요구사항 이해하기

책1.indb 15

유스케이스와 사용자 스토리

171

유스케이스 접근법

175

유스케이스와 사용 시나리오

177

유스케이스 식별하기

185

유스케이스 탐색하기

187

2017-04-18 오후 4:02:45


XVI

목차

유스케이스 검증하기

189

유스케이스와 기능적 요구사항

190

피해야 할 유스케이스의 함정

192

사용 중심 요구사항의 장점

193

09 _ 규칙에 따르기 비즈니스 규칙의 분류체계

198

팩트

199

제약조건

200

동작 활성자

201

추론

203

계산

203

원자 수준의 비즈니스 규칙

204

비즈니스 규칙 문서화하기

205

비즈니스 규칙 발견하기

207

비즈니스 규칙 및 요구사항

209

모두 함께 묶기

210

10 _ 요구사항 문서화하기 소프트웨어 요구사항 명세서

217

불완전성 다루기

220

사용자 인터페이스와 SRS

221

소프트웨어 요구사항 명세서 템플릿

책1.indb 16

215

요구사항 명명하기

222

1. 소개

224

2. 전반적인 설명

225

3. 시스템 기능

227

4. 데이터 요구사항

227

5. 외부 인터페이스 요구사항

229

6. 품질 속성

231

7. 국제화 및 현지화 요구사항

232

8. [기타 요구사항]

232

2017-04-18 오후 4:02:46


XVII

목차

부록 A: 용어사전

232

부록 B: 분석 모델

233

애자일 프로젝트에서의 요구사항 명세서

233

11 _ 좋은 요구사항 작성하기 좋은 요구사항의 특징

237

요구사항 문장의 특징

237

요구사항 모음의 특징

239

요구사항 작성을 위한 지침

241

시스템/사용자 관점

242

스타일에 따라 작성하기

243

세부 수준

246

표현 기법

248

모호함 피하기

249

불완전성 피하기

252

개선 전후의 요구사항 샘플

254

12 _ 백문이 불여일견

책1.indb 17

요구사항 모델 만들기

260

고객의 목소리로 분석 모델 만들기

262

올바른 표현 기법 선택하기

263

데이터 흐름 다이어그램

266

스윔레인 다이어그램

270

상태 전이 다이어그램과 상태표

272

대화상자 맵

275

의사결정 일람표와 의사결정 트리

280

이벤트 반응표

281

UML 다이어그램에 대한 몇 마디

284

애자일 프로젝트에서 모델 만들기

285

당부사항

286

2017-04-18 오후 4:02:46


XVIII

목차

13 _ 데이터 요구사항 명세화하기 데이터 관계 모델 만들기

288

데이터 사전

291

데이터 분석

295

보고서 명세화하기

296

보고서 요구사항 도출하기

297

보고서 명세의 고려사항

298

보고서 명세 템플릿

299

대시보드 보고서

301

14 _ 기능, 그 이상을 향해 소프트웨어 품질 속성 품질 속성 찾기

품질 요구사항 정의하기

306 307 312

외부 품질 속성

312

내부 품질 속성

327

Planguage로 품질 요구사항 명세화하기

333

품질 속성의 트레이드오프

334

품질 속성 요구사항 구현하기

336

제약조건

337

애자일 프로젝트에서 품질 속성 다루기

339

15 _ 프로토타이핑을 활용한 위험 감소

책1.indb 18

프로토타이핑: 무엇을 그리고 왜

344

목업과 개념 증명

345

일회성 프로토타입과 진화형 프로토타입

346

종이 프로토타입과 전자 프로토타입

350

프로토타입으로 작업하기

351

프로토타입 평가

355

프로토타이핑의 위험

357

2017-04-18 오후 4:02:46


XIX

목차

프로토타입의 출시 압력

357

구제화 정도에 기인한 산만함

358

비현실적인 성능 예측

358

프로토타입에 과도한 노력 투자하기

359

프로토타이핑 성공 요소

359

16 _ 중요한 것 먼저: 요구사항 우선순위 할당하기 왜 요구사항의 우선순위를 나눠야 하는가?

362

몇 가지 우선순위 화용론

363

우선순위와 심리적 게임

365

몇 가지 우선순위 할당 기법

366

할까? 말까?

367

짝 비교와 순위 나누기

367

3단계 규모 조정

368

MoSCoW

370

100달러

371

가치와 비용, 위험에 따른 우선순위 할당하기

372

17 _ 요구사항 검증하기

책1.indb 19

검증과 확인

380

요구사항 검토하기

381

검사 프로세스

382

결함 체크리스트

388

요구사항 검토 팁

390

요구사항 검토의 어려움

391

요구사항 프로토타이핑하기

393

요구사항 테스트하기

394

인수 기준에 따라 요구사항 검증하기

398

인수 기준

399

인수 테스트

400

2017-04-18 오후 4:02:46


XX

목차

18 _ 요구사항 재사용 왜 요구사항을 재사용하는가?

403

요구사항 재사용의 관점

404

재사용 범위

405

수정 범위

406

재사용 메커니즘

406

재사용을 위한 요구사항 정보의 종류

408

일반적인 재사용 시나리오

409

소프트웨어 제품군

409

시스템 리엔지니어링 및 교체

409

기타 재사용 기회

410

요구사항 패턴

411

재사용에 유용한 도구

412

요구사항을 재사용할 수 있게 만들기

413

요구사항 재사용 장벽과 성공 요소

415

재사용 장벽

415

재사용 성공 요소

417

19 _ 요구사항 개발, 그 이상을 향해 요구사항 노력 산정하기

421

요구사항을 기반으로 프로젝트 계획하기

425

요구사항을 기반으로 프로젝트 규모와 필요한 노력 산정하기 425 요구사항과 일정 산정

요구사항을 기반으로 설계 및 구현하기

책1.indb 20

428 429

아키텍처와 할당

429

소프트웨어 설계

431

사용자 인터페이스 설계

432

요구사항에서 테스트까지

434

요구사항에서 성공까지

436

2017-04-18 오후 4:02:46


XXI

목차

Part

03

다양한 프로젝트 유형을 위한 요구사항

20 _ 애자일 프로젝트 폭포수 개발 방법의 한계

441

애자일 개발 방법론

442

요구사항에 대한 애자일 접근 방식의 필수 요소

443

고객 참여

443

문서의 상세 수준

444

백로그와 우선순위 할당

444

시기

445

에픽, 사용자 스토리, 기능, 맙소사! 변경 예측

446 447

애자일 프로젝트에 요구사항 사례 실천하기

448

애자일로 갈아타기: 이제 뭘 하지?

448

21 _ 개선 프로젝트와 교체 프로젝트

책1.indb 21

예측 가능한 문제

451

기존 시스템에 적용할 수 있는 요구사항 기법

452

비즈니스 목표에 따라 우선순위 할당하기

453

갭 주의하기

454

성능 수준 유지하기

455

기존 요구사항이 존재하지 않을 때

456

어떤 요구사항을 명세화해야 할까?

457

기존 시스템의 요구사항을 찾는 방법

459

신규 시스템 도입 장려하기

460

반복할 수 있을까?

461

2017-04-18 오후 4:02:46


XXII

목차

22 _ 패키지 솔루션 프로젝트 패키지 솔루션 선택을 위한 요구사항

464

사용자 요구사항 개발하기

465

비즈니스 규칙 고려하기

466

필요한 데이터 식별하기

466

품질 요구사항 정의하기

466

솔루션 평가하기

467

패키지 솔루션을 구현하기 위한 요구사항

470

구성 요구사항

470

통합 요구사항

471

확장 요구사항

471

데이터 요구사항

472

비즈니스 프로세스 변경

472

패키지 솔루션의 일반적인 문제

473

23 _ 외주 프로젝트 요구사항의 적절한 명세화 수준

475

인수자와 납품업체 간 상호작용

477

변경 관리

479

인수 기준

480

24 _ 비즈니스 프로세스 자동화 프로젝트 비즈니스 프로세스 모델 만들기

책1.indb 22

482

요구사항 도출을 위해 현재 프로세스 활용하기

483

미래의 프로세스 먼저 설계하기

485

비즈니스 성과 지표 모델 만들기

485

비즈니스 프로세스 자동화 프로젝트의 우수사례

487

2017-04-18 오후 4:02:47


XXIII

목차

25 _ 비즈니스 분석 프로젝트 비즈니스 분석 프로젝트의 개요

489

비즈니스 분석 프로젝트를 위한 요구사항 개발

491

의사결정을 활용해 작업에 우선순위 할당하기

492

정보가 사용되는 방법 정의하기

493

데이터 니즈 구체화하기

495

데이터를 변환하기 위한 분석 정의

498

분석의 진화적 특성

500

26 _ 임베디드 및 기타 실시간 시스템 프로젝트

책1.indb 23

시스템 요구사항, 아키텍처 및 할당

503

실시간 시스템 모델 만들기

505

컨텍스트 다이어그램

505

상태 전이 다이어그램

506

이벤트 반응표

507

아키텍처 다이어그램

509

인터페이스

510

타이밍 요구사항

512

임베디드 시스템을 위한 품질 속성

513

임베디드 시스템의 도전과제

519

2017-04-18 오후 4:02:47


XXIV

목차

Part

04

요구사항 관리

27 _ 요구사항 관리 사례 요구사항 관리 프로세스

523

요구사항 기준

525

요구사항 버전​​관리

526

요구사항 속성

528

요구사항 상태 추적

529

요구사항 이슈 해결

532

요구사항 노력 측정

533

애자일 프로젝트에서 요구사항 관리

534

왜 요구사항을 관리하는가?

536

28 _ 변경의 발생 왜 변경을 관리하는가?

538

범위 추가 관리하기

539

변경 관리 정책

540

변경 관리 프로세스의 기본 개념

541

변경 관리 프로세스 기술서

542

1. 목적 및 범위

543

2. 역할과 책임

543

3. 변경 요청 상태

543

4. 시작 기준

544

5. 작업

544

6. 종료 기준

545

7. 변경 관리 상태 보고서

546

부록: 각 요청이 포함하는 속성

546

변경 관리 위원회

547

CCB 헌장

548

합의 재협상하기

549

변경 관리 도구

책1.indb 24

547

CCB 구성

549

2017-04-18 오후 4:02:47


XXV

목차

변경 활동 측정하기

550

변경 영향 분석

552

영향 분석 절차

552

영향 분석 템플릿

555

애자일 프로젝트의 변경 관리

556

29 _ 요구사항의 연결 고리 요구사항 추적하기

560

요구사항 추적을 위한 동기부여

562

요구사항 추적 매트릭스

564

요구사항 추적을 위한 도구

567

요구사항 추적 절차

569

요구사항 추적은 타당한가? 정말 필요한 것인가?

570

30 _ 요구공학을 위한 도구 요구사항 개발 도구

574

요구사항 도출 도구

574

프로토타이핑 도구

575

모델링 도구

575

요구사항 관리 도구

576

RM 도구의 기능

579

요구사항 도구의 선택과 구현

책1.indb 25

576

RM 도구 사용의 이점

582

도구 선택하기

582

도구와 프로세스 준비하기

582

사용자의 도구 도입 촉진하기

584

2017-04-18 오후 4:02:47


XXVI

목차

Part

05

요구공학 구축하기

31 _ 요구사항 프로세스 개선하기 요구사항이 다른 프로젝트 프로세스와 연관되는 방법

589

요구사항 및 다양한 이해관계자 그룹

592

변경에 대한 합의 구하기

593

소프트웨어 프로세스 개선의 기본 원칙

595

근본 원인 분석

597

프로세스 개선 주기

598

현재 방법 평가하기

599

개선 활동 계획하기

600

프로세스 만들기, 시험하기, 공개하기

601

결과 평가하기

602

요구공학 프로세스 자산

603

요구사항 개발 프로세스 자산

605

요구사항 관리 프로세스 자산

606

아직 멀었나?

607

요구사항 프로세스 개선 로드맵 만들기

610

32 _ 소프트웨어 요구사항과 위험 관리 소프트웨어 위험 관리의 기본 원칙

614

프로젝트 위험 문서화하기

615

위험 관리 계획

618

요구사항 관련 위험

619

요구사항 도출

619

요구사항 분석

622

요구사항 명세서

622

요구사항 검증

623

요구사항 관리

624

위험 관리는 여러분의 친구다

책1.indb 26

613

위험 관리 요소

625

2017-04-18 오후 4:02:47


XXVII

목차

책1.indb 27

에필로그

626

부록 A _ 현재 요구사항 실천 지침에 대한 자기 평가

628

부록 B _ 요구사항 문제 해결 가이드

634

부록 C _ 요구사항 문서 샘플

652

용어사전

675

참고문헌

683

2017-04-18 오후 4:02:47


XXVIII

들어가며

지난 수십 년에 걸친 경험에도 불구하고, 많은 소프트웨어 조직이 제품의 요구사항을 이해하고 문서 화하며 관리하는 것을 힘들어한다. 사용자 의견 부족, 불완전한 요구사항, 요구사항 변경, 비즈니스 목표에 대한 잘못된 이해가 수많은 정보 기술 프로젝트가 완전히 성공하지 못하는 주된 이유다. 어 떤 소프트웨어 팀은 고객 및 다른 출처로부터 요구사항을 도출하는 데 능숙하지 않기도 하다. 고객 의 경우 요구사항 활동에 참여할 시간이 없거나 참을성이 부족한 경우도 있다. 대부분의 경우, 프로 젝트 참가자들은 “요구사항”이 무엇인지에 대해서도 동의하지 않는다. 어떤 사람은 “엔지니어는 고 객 요구사항을 해독하기보다 킹스맨( Kingmen)의 1963년 고전 파티 음악인 “Louie Louie”를 해독 하는 게 낫다”라고 말하기도 했다. 『소프트웨어 요구사항』의 2차 개정판은 10년 전에 출판됐다. 기술 분야에서 10년은 긴 시간이다. 그 동안 많은 것들이 변했지만 변하지 않은 것들도 있다. 지난 10년간 주요 요구사항 동향은 다음과 같다. ■■ 비즈니스

분석이 전문 분야로서 자리 잡고, 전문 자격증 및 국제 비즈니스 분석 협회(International Institute of Business

Analysis) 및 국제 요구공학 위원회(International Requirements Engineering Board) 같은 단체가 생겨남 ■■ 데이터베이스를

연동하는 요구사항 관리 도구와 프로토타이핑, 모델링, 시뮬레이션 등 요구사항 개발 활동을 지원하는 도구

의 성숙 ■■ 애자일

개발 방법론 사용의 증가 및 애자일 프로젝트에서 요구사항 처리 기술의 진화

■■ 요구사항

지식을 표현하기 위한 시각적인 모델 사용의 증가

그래서 변하지 않은 것은 무엇일까? 이 주제가 중요하고 의미 있게끔 만들어 주는 요소가 두 가지 있다. 첫째, 소프트웨어 공학 및 컴퓨터 과학의 여러 학부 교육과정에서 (요구사항 개발과 관리 모 두를 아우르는) 요구공학의 중요성을 충분히 강조하지 않는다는 것이다. 둘째, 소프트웨어 분야에 종사하는 우리에게는 도전적인 기술과 프로세스 솔루션에 푹 빠져버리는 경향이 있다는 것이다. 종종 우리는 요구사항 도출이나 소프트웨어 및 시스템 프로젝트에서 하는 대부분의 작업이 주로 인간의 상호작용으로 이뤄진다는 사실을 인식하지 못할 때가 있다. 다양한 도구를 통해 지리적으 로 떨어져 있는 사람들이 효율적으로 협업할 수 있기는 하지만 협업을 자동화하는 마법 같은 신기 술은 없다. 우리는 요구사항 개발 및 관리를 위해 2차 개정판에서 제시했던 실천 지침들이 여전히 유효하고 다 양한 소프트웨어 프로젝트에 적용 가능하다고 생각한다. 창조적인 비즈니스 분석가나 제품 관리자,

책1.indb 28

2017-04-18 오후 4:02:47


XXIX

들어가며

제품 주인은 특정 환경의 니즈에 잘 부합하도록 이러한 지침을 신중하게 도입하고 조율할 것이다. 3 차 개정판에는 애자일 프로젝트에서 요구사항을 다루는 방법에 대한 장과, 여러 장에서 애자일 개발 환경에서 실천 사례를 도입하고 적용하는 방법을 설명하는 수많은 절이 새롭게 추가됐다. 소프트웨어 개발은 적어도 컴퓨터 처리만큼의 의사소통을 필요로 하지만 교육 과정과 프로젝트 활 동 모두 의사소통보다는 컴퓨터 처리를 강조하는 경우가 많다. 이 책에서는 효율적인 요구공학 방법 을 적용한 수십 개의 도구를 제공하며, 이러한 도구를 통해 의사소통을 용이하게 하고 소프트웨어 실무자나 관리자, 마케팅 담당자, 고객에게 도움을 준다. 이 책에서 제시하는 기법들은 주류 “우수 사례”의 툴킷으로 구성되며, 이국적인 신기술이나 모든 요구사항 문제를 해결하는 데 도움이 되는 정교한 방법론은 아니다. 이 책에서는 일반적인 요구사항 관련 경험을 이야기(다 맞는 말뿐인)하는 수많은 일화와 관련 기사를 제공한다(여러분도 이와 유사한 경험을 갖고 있을 것이다). 바로 우리 주변에 있고 다양한 프로젝트 경험에서 우러나온 실제 경험에 가까운 “진짜 이야기”를 찾아보라. 1999년에 초판이 출판된 이래로, 우리는 각자 다양한 프로젝트에 참여했고, 다양한 규모와 유형의 회사나 정부 기관에서 사람들에게 소프트웨어 요구사항에 대해 수백 번에 걸쳐 강의했다. 우리는 이 러한 실천 사례가 프로젝트 규모와 상관없이, 신규 개발이든 개선 프로젝트이든, 현지 팀이든 분산 된 팀이든, 전통적인 개발 방법을 사용하든 애자일 방법을 사용하든 상관없이 대부분의 모든 프로젝 트에 유용하다는 사실을 발견했다. 그러한 기법들은 소프트웨어 프로젝트뿐 아니라 하드웨어 및 시 스템 공학 프로젝트에도 적용할 수 있다. 여느 다른 기술 사례와 마찬가지로 이 방법을 제대로 사용 하는 법을 학습하기 위해서는 식견과 경험을 활용해야 할 것이다. 이러한 실천 지침을 프로젝트에서 적절한 사람과의 효율적인 의사소통에 유용한 도구로 생각하자.

이 책이 제공하는 이점 여러분이 수행할 수 있는 모든 소프트웨어 프로세스 개선에서 요구사항 관례 개선이 가장 유익한 결 과다. 이 책에서는 실용적이고 입증된, 여러분에게 도움이 될 수 있는 기법들을 설명한다. ■■ 프로젝트

초기부터 고품질의 요구사항을 작성해서 재작업을 최소화하고 생산성을 극대화

■■ 비즈니스

목표를 달성하는 고품질의 정보 시스템 및 상용 제품 전달

■■ 범위와 ■■ 높은

책1.indb 29

요구사항 모두를 예상 및 제어하에 두는 범위 추가와 요구사항 변경 관리

고객 만족도 달성

2017-04-18 오후 4:02:48


XXX

들어가며

■■ 유지보수,

개선, 지원 비용 절감

우리의 목표는 소프트웨어 제품 개발 주기에서 여러분이 요구사항 도출 및 분석, 요구사항 명세서 작성 및 검증, 요구사항 관리에 사용하는 프로세스를 개선할 수 있도록 돕는 것이다. 우리가 설명하 는 기술은 실용적이고 현실적이다. 우리 모두 바로 이 기술을 여러 번 사용했고, 그때마다 항상 좋은 결과를 얻을 수 있었다.

대상 독자 소프트웨어를 포함한 모든 시스템의 요구사항을 정의하고 이해하는 데 참여하는 누구든지 이 책에 서 유용한 정보를 찾을 수 있을 것이다. 주요 대상 독자는 개발 프로젝트에서 비즈니스 분석가나 요 구공학 엔지니어의 역할을 하는 개인으로서, 전일제 전문가이거나 때때로 분석가 역할을 수행하는 다른 팀원이 될 수 있다. 그다음 대상 독자는 사용자 기대치를 이해하고 만족시켜야 하며, 효율적인 요구사항 생산 및 검토에 참여하는 아키텍트나 설계자, 개발자, 테스터, 혹은 기타 다른 기술 관련 구성원이다. 제품이 상업적으로 성공하기 위한 기능과 속성을 구체화해야 하는 마케팅 담당자 및 제 품 관리자는 이러한 실천 지침이 가치 있다는 사실을 알게 될 것이다. 프로젝트 관리자는 제품의 요 구사항 활동을 계획하고 추적하는 방법과 요구사항 변경을 다루는 방법을 배울 수 있다. 비즈니스나 기능, 품질 니즈를 충족하는 제품을 정의하는 데 참여하는 이해관계자 또한 대상 독자에 해당한다. 이 책은 최종 사용자와 소프트웨어 제품을 구입하거나 계약하는 고객, 여러 이해관계자가 요구사항 프로세스와 각자의 역할의 중요성을 이해하는 데 도움될 것이다.

이 책의 구성 이 책은 총 5부로 구성돼 있다. 1부 “소프트웨어 요구사항: 무엇을, 왜, 누가”에서는 몇 가지 정의로 시작한다. 만약 여러분이 기술적 측면에 가까운 사람이라면 핵심 고객에게 고객-개발 간 협력을 다 룬 2장을 공유하자. 3장에서는 요구사항 개발 및 관리에 대한 수십 개의 “우수 사례” 및 요구사항 개 발을 위한 전반적인 프로세스 프레임워크를 요약한다. 비즈니스 분석가의 역할(및 기타 다른 이름 으로 불리는 역할)은 4장의 주제다. 2부 “요구사항 개발”은 프로젝트의 비즈니스 요구사항을 정의하는 방법으로 시작한다. 2부의 다른

책1.indb 30

2017-04-18 오후 4:02:48


XXXI

들어가며

장에서는 적절한 고객 대표를 찾는 방법과 이들로부터 요구사항을 도출하는 방법, 사용자 요구사항 과 비즈니스 규칙, 기능적 요구사항, 데이터 요구사항, 비기능적 요구사항 등을 문서화하는 방법을 설명한다. 12장에서는 자연어로 작성된 글을 보완하기 위해 다양한 관점에서 요구사항을 표현하는 다양한 시각 모델을 설명하며, 15장에서는 위험을 줄이기 위해 프로토타입을 사용하는 방법을 설명 한다. 2부의 나머지 장에서는 요구사항의 우선순위를 나누는 법, 검증하는 법, 재사용하는 법을 살 펴본다. 요구사항이 프로젝트 작업의 다른 측면에 어떻게 영향을 미치는지 얘기하며, 2부가 끝난다. 3부는 이번 개정판에 처음으로 등장하며, 모든 유형의 제품을 개발하는 애자일 프로젝트, 개선 및 교체 프로젝트, 패키지 솔루션 통합 프로젝트, 외주 프로젝트, 비즈니스 프로세스 자동화 프로젝트, 비즈니스 분석 프로젝트, 임베디드 및 기타 실시간 시스템 등 다양한 유형의 프로젝트에서 가장 효 과적인 요구사항 접근법을 제안하는 장을 포함하고 있다. 요구사항 관리의 원칙 및 실천 지침이 4부의 주제이며, 요구사항 변경을 다루는 기법에 중점을 둔 다. 29장에서는 요구사항 추적이 개별 요구사항과 출처 및 하위 개발 산출물을 연결하는 방법을 설 명한다. 4부는 팀이 요구사항을 개발하고 관리하는 방법을 향상시킬 수 있는 상용 도구를 설명하는 것으로 마무리한다. 이 책의 마지막인 5부 “요구공학 구축하기”에서는 개념적인 부분을 실천하는 데 도움될 것이다. 31 장은 새로운 요구사항 기법을 여러분이 속한 그룹의 개발 프로세스에 통합하는 데 도움될 것이다. 일반적인 요구사항 관련 프로젝트 위험은 32장에서 설명한다. 부록 A의 자기 평가는 개선이 필요한 영역을 선택하는 데 도움이 된다. 다른 두 개의 부록은 요구사항 문제 해결 가이드와 요구사항 문서 예제를 제공하며 이를 통해 앞의 내용들이 모두 어떻게 적용되는지 확인할 수 있다.

사례 연구 이 책에서 설명하는 방법들을 설명하기 위해 화학약품 관리 시스템이라고 하는 중간 규모의 정보 시 스템 등 실제 프로젝트를 기반으로 한 다양한 사례 연구의 예를 제공한다. 이 프로젝트를 이해하기 위해 화학에 대해 알아야 하는 것은 아니니 걱정하지는 말자. 사례 연구에 대한 참가자 간의 토론이 책 전반에 걸쳐 나온다. 조직이 어떤 유형의 소프트웨어를 개발하든 이러한 대화 내용과 관련 지을 수 있을 것이다.

책1.indb 31

2017-04-18 오후 4:02:48


XXXII

들어가며

원칙에서 실천으로 새로운 지식을 실제 행동으로 옮길 때 발생하는 장애물을 극복하기 위한 에너지를 모으는 데는 어려 움이 따른다. 요구사항 개선을 위한 여행을 돕기 위해 대부분의 장에서는 해당 장의 내용을 즉시 적용 하기 위해 바로 시작할 수 있는 행동을 담은 “다음 단계는”이라는 내용으로 마무리한다. 여러 장에서 요구사항 문서, 검토 체크리스트, 요구사항 우선순위 스프레드시트, 변경 관리 프로세스, 기타 다른 프로세스 자산 등의 템플릿을 제안한다. 이러한 내용은 이 책의 웹 사이트에서 내려받을 수 있다. ■ http://aka.ms/SoftwareReq3E/files

여러분의 애플리케이션에서 바로 이러한 기법을 사용할 수 있도록 자료를 활용하자. 아주 작은 개선 이라도 오늘 당장 시작하자. 어떤 사람들은 새로운 요구사항 기술을 시도하는 것을 주저할 것이다. 여러분의 동료나 고객, 관리 자를 교육하는 데 이 책을 활용하자. 그들에게 이전 프로젝트에서 겪은 요구사항 관련 문제를 상기 시키고 새로운 방법을 통해 얻을 수 있는 이점에 대해 논의하자. 더 나은 요구사항 실천 지침을 적용하기 위해 새로운 개발 프로젝트를 시작할 필요는 없다. 21장에 서는 개선 및 교체 프로젝트에 다양한 기법을 도입하는 방법을 설명한다. 요구사항 실천 지침을 점 진적으로 개발하는 것은 다음번 주요 프로젝트를 준비하기 위한 위험이 낮은 프로세스 개선 방법 이다. 요구사항 개발의 목표는 팀이 허용 가능한 위험 수준으로 제품의 다음 단계를 설계 및 개발하기에 충분한 요구사항들을 축적하는 것이다. 재작업, 수용 불가능한 제품, 일정 증가의 위험을 최소화하 기 위해 요구사항에 충분히 관심을 가질 필요가 있다. 이 책은 제대로 된 제품의 진짜 요구사항을 개 발하기 위해 적절한 사람과 협력할 수 있는 도구를 제공한다.

책1.indb 32

2017-04-18 오후 4:02:48


XXXIII

들어가며

정오표 및 도서 지원 우리는 이 책과 보조 자료의 정확성을 기하기 위해 모든 노력을 다했다. 이 책이 출판된 이후에 보고 되는 오류는 oreilly.com의 마이크로소프트 프레스( Microsoft Press) 사이트에 실릴 것이다. ■ http://aka.ms/SoftwareReq3E/errata

보고되지 않은 오류를 찾을 경우 위 페이지에 신고할 수도 있다. 추가 지원이 필요한 경우 마이크로소프트 프레스의 도서 지원 담당자( mspinput@microsoft.com) 에게 이메일을 보내주길 바란다. 마이크로소프트 소프트웨어의 제품 지원은 위의 주소에서 하고 있지 않으므로 유의하기 바란다.

독자 의견 마이크로소프트 프레스에서는 독자의 만족이 최우선 과제이며, 피드백은 가장 소중한 자산이다. 이 책에 대한 여러분의 생각을 알려주기 바란다. ■ http://aka.ms/tellpress

설문조사는 짧고, 우리는 여러분의 의견과 아이디어를 하나하나 읽어볼 것이다. 여러분의 의견에 미 리 감사를 표한다!

기타 연락처 계속 대화를 이어가보자! 트위터에서 기다리겠다. ■ http://twitter.com/MicrosoftPress

책1.indb 33

2017-04-18 오후 4:02:48


XXXIV

감사의 글

이 책은 두 명의 저자가 한 팀으로 협업해서 세상에 나올 수 있었습니다. 많은 분들이 전체 원고를 검토하고 개선을 위한 수많은 제안을 하는 데 시간을 투자해 주셨습니다. 깊이 감사 드립니다. 매우 귀중한 의견을 남겨 준 짐 브로소, 조앤 데이비스, 개리 K. 에반스, 조이시 그레입스, 티나 하이덴라 이크, 켈리 모리슨 스미스, 조이스 스타츠 박사에게 특히 감사드립니다. 케빈 브레넌, 스티븐 데이비 스, 앤 하틀리, 에밀리 아이엠, 매트 리치, 자닌 맥코넬, 야곱 모하메드, 존 파커로부터 추가 검토를 받았습니다. 각 분야의 전문가가 해당 절이나 장을 검토하기도 했으며 매우 상세한 의견을 주시기도 했습니다. 타냐 채버리, 마이크 콘, 알렉스 딘 박사, 엘렌 가티스디너, 쉐인 해스티, 제임스 훌건, 필 쿠프만 박사, 마크 쿨락, 셜리 사틴, 롭 시실리아, 베시 스톡데일에게 감사합니다. 록산느 밀러와 스 티브 윗올의 깊은 통찰력과 큰 참여에 대해 특별히 감사의 인사를 드립니다. 우리는 여러 사람들과 책의 주제에 대해 논의했으며, 이들의 전문적인 경험과 전달해준 참고 자료로 더 많은 것을 배울 수 있었습니다. 짐 브로소, 나넷 브라운, 나이젤 버드, 캐서린 부시, 타냐 채버리, 제니퍼 도일, 개리 에반스, 스콧 프랜시스, 사라 게이츠, 데이비드 겔퍼린 박사, 마크 케린, 놈 커스, 스콧 메이어스 박사, 존 파커, 캐시 레이놀즈, 빌 트로스키, 리카르도 발레디 박사, 이안 왓슨 박사 님께서 도움 주신 것에 감사 드립니다. 또한 우리에게 자신의 일화인 “진짜 이야기”를 들려 주신 많 은 분들께 감사 드립니다. 셀리벨의 많은 직원이 이 책에 도움을 주셨습니다. 특정 절을 검토하고, 빠르게 의견을 주고 설문 조사에 참여했으며, 직접 작성한 블로그 자료를 공유하고, 여러 장에 대한 최종 편집과 그림, 그리 고 다양한 운영 문제에 도움을 줬습니다. 아제 바드리, 제이슨 벤필드, 앤소니 첸, 켈 콘돈, 앰버 데 이비스, 제레미 고어, 조이시 그레입스, 존 제르슨, 멜라니 노렐, 데이비드 라인하르트, 베시 스톡데 일, 크리스틴 월머스에게 감사 드립니다. 덕분에 수월하게 작업할 수 있었습니다. 캔데스 호칸슨의 편집에 대단히 감사 드립니다. 원고 검토 편집자인 데번 머스그레이브, 프로젝트 편집자인 캐롤 딜링햄, S4Carlisle 퍼블리싱 서비 스의 프로젝트 편집자인 크리스티앙 홀드너, 교열 편집자 캐시 크라우스, 교정자 니콜 슐럿, 색인 작 성자 모린 존슨, 식자공 삼바시범 샌가란, 제작 아티스트인 발라가네산 M.과 스리니바산 R., 가네스 바부 G. 칼 등 마이크로소프트 프레스의 많은 분들께 감사 드립니다. 데번 머스그레이브와 벤 라이 언의 오랜 관계와 우정에 특별히 감사 드립니다.

책1.indb 34

2017-04-18 오후 4:02:48


XXXV

감사의 글

지난 수년 동안 요구사항 교육 과정을 수강한 수백 명의 학생들이 전해준 의견과 질문은 요구사항 문제에 대한 우리의 생각을 자극하는 데 가장 큰 도움이 됐습니다. 우리의 컨설팅 경험과 독자에 게 받은 많은 것을 생각하게 하는 질문은 실무자들이 매일 어떤 문제로 고군분투하는지 알 수 있게 했고, 이러한 어려운 주제에 대해 생각하는 데 이바지했습니다. 여러분의 경험을 공유하고 싶다면

karl@processimpact.com 또는 joy.beatty@seilevel.com으로 연락해 주시기 바랍니다. 언제나처럼 칼은 아내인 크리스 잠비토에게 고맙다는 말을 전합니다. 그녀는 언제나 참을성 있고 유 머러스했습니다. 칼은 지속적으로 작업에 임할 수 있게 유도하고 훌륭히 공헌한 조이에게 감사의 인 사를 전합니다. 그녀와의 작업은 매우 재미있었고, 덕분에 더욱 값진 책을 만들 수 있었습니다. 검 토자가 고통받기 전에 아이디어를 내고, 어려운 의사결정을 내리며, 초안에 대해 끈질기게 잔소리를 해주는 누군가가 있어 좋았습니다. 조이는 작가의 꿈을 다시 꿀 수 있게 해준 남편 토니 해밀턴과 하루하루의 우선순위를 수월하게 유 지할 수 있게 해준 딸 스카이, 가족이 즐거운 시간을 보내는 데 중심이 되어 준 션과 에스텔에게 감 사의 인사를 전합니다. 조이는 소프트웨어 요구사항 분야를 적극 추진하기 위해 공헌하는 모든 셀리 벨 직원들에게 특별한 감사의 말을 전합니다. 그녀는 두 명의 동료이자 친구, 이 책이 최고가 될 수 있게 도와준 앤소니 첸과 이러한 노력을 지속적으로 격려해준 롭 스팍스에게 고맙다는 말을 전합니 다. 마지막으로 조이는 공동 저자가 될 수 있게 해주고, 매일매일 새로운 것을 알려줬으며, 함께 작 업하는 것에 절대적인 기쁨을 느낄 수 있게 해준 칼에게 큰 감사의 인사를 드립니다.

책1.indb 35

2017-04-18 오후 4:02:48


01 소프트웨어 요구사항: 무엇을, 왜, 누가

1장 필수 소프트웨어 요구사항 2장 고객 관점의 요구사항 3장 요구공학의 우수 사례 4장 비즈니스 분석가

책1.indb 1

2017-04-18 오후 4:02:49


01 필수 소프트웨어 요구사항

“안녕하세요? 필, 인사팀의 마리아입니다. 당신이 개발한 인사시스템에 문제가 생겼어요. 시스템 상에서 이 름이 스파클 스타라이트(Sparkle Starlight)인 직원의 이름을 변경할 수가 없네요. 도와주실 수 있나요?” “그분이 스타라이트라는 남자와 결혼했나요?” “아니요, 그냥 이름만 바꾼 거에요.”라고 마리아는 대답했다. “그게 문제네요. 누군가와 결혼한 경우에만 이름 을 변경할 수 있도록 개발됐을 거에요.” “음... 이름만 변경할 수도 있다는 것은 생각지도 못했네요. 시스템에 대해 얘기할 때 이런 가능성에 대해 들 은 바가 없는 것 같아요.”라고 필은 말했다. “저는 직원들이 자기가 원할 때 언제든지 이름을 변경할 수 있다는 것을 아시는 줄 알았어요.” 마리아가 말했 다. “금요일까지 이 문제가 해결되지 않으면 스파클은 이번 달 급여를 받지 못할 거에요. 그때까지 버그를 고 칠 수 있을까요?”

책1.indb 2

2017-04-18 오후 4:02:49


01 _ 필수 소프트웨어 요구사항

3

“이건 버그가 아닙니다!” 필은 반박했다. “저는 이런 기능이 필요한지 전혀 몰랐어요. 지금은 신규 성과 평가 시스템 개발 때문에 바쁩니다. 이번 달 말까지 수정은 가능하겠지만 금요일까지는 무리에요. 미안합니다. 다 음부터는 이런 사항들을 미리 얘기해 주시고 문서로 작성해 주세요.” “스파클에게는 뭐라고 해야 할까요?” 마리아가 물었다. “월급을 못 받으면 엄청 화낼 거에요.” “이봐요 마리아, 이게 제 잘못이 아니잖아요.” 필은 항의했다. “누구나 언제든 이름을 변경할 수 있어야 한다 고 애초부터 이야기해줬다면 이런 일은 발생하지 않았을 겁니다. 당신의 마음을 읽지 못한 걸 저보고 책임지 라고 할 순 없어요.” 마리아는 흥분하며 화를 냈다. “정말 이런 문제들 때문에 컴퓨터가 싫어지네요. 가능한 한 빨리 해결하고 연 락 줄 수 있나요?”

만약 여러분이 고객 입장에서 이런 대화를 나눈 경험이 있다면 소프트웨어 시스템이 꼭 필요한 일 을 제대로 처리하지 않았을 때 얼마나 당황스러운지 알고 있을 것이다. 어쨌든 여러분은 중요한 수 정 요청을 처리해줄 개발자에게 휘둘리기 싫을 것이다. 반면 개발자는 시스템을 개발한 후에야 사 용자가 기대하는 기능이 무엇이었는지 알 수 있다는 것에 좌절한다. 애초에 명확했어야 했을 것들 이 나중에서야 시스템 수정 요청으로 나타나 진행 중인 프로젝트를 방해하는 것은 개발자를 짜증 나게 한다. 소프트웨어 세계의 많은 문제점들은 사람이 제품의 요구사항을 학습하고, 문서화하며, 합의하고, 수 정하는 과정에서 발생하는 미흡함이 원인이 된다. 필과 마리아의 경우처럼 비공식적인 정보 취합, 암시적인 기능, 잘못 전달된 가정, 형편없이 구체화된 요구사항, 대충 처리하는 변경 프로세스 등이 일반적인 문제 영역이다. 소프트웨어 제품에서 발견되는 결함의 40~50%는 요구사항 단계에서 발 생한다고 다수의 연구를 통해 밝혀졌다( Davis 2005). 충분하지 않은 사용자 기초 자료와 고객 요 구사항 구체화 및 관리의 부족은 실패하는 프로젝트의 주요 원인이 된다. 이러한 증거에도 불구하고 많은 조직들은 여전히 비효율적인 요구사항 방법론을 사용한다. 요구사항만큼 프로젝트의 모든 이해관계자의 이익이 교차하는 곳은 어디에도 없다. (이해관계자에 대한 자세한 내용은 2장 “고객 관점의 요구사항”을 참고한다.) 고객, 사용자, 비즈니스 분석가, 개발 자 등이 이해관계자에 포함된다. 이러한 접점을 잘 다루면 고객을 기쁘게 하고 개발자를 만족스럽게 한다. 그러나 이를 잘 다루지 못하면 제품의 품질과 비즈니스 가치를 떨어뜨리는 오해와 갈등의 원 인이 된다. 요구사항은 소프트웨어 개발과 프로젝트 관리 활동의 토대가 되기 때문에 모든 이해관계 자는 품질이 우수한 제품을 만들기 위해 요구사항 실천 지침들을 적용하는 데 충실해야 한다.

책1.indb 3

2017-04-18 오후 4:02:49


4

PART 01 _ 소프트웨어 요구사항: 무엇을, 왜, 누가

그러나 요구사항을 만들고 관리하는 건 어려운 일이다! 어디에도 지름길이나 마법 같은 해법은 없 다. 한 가지 다행인 점은 수많은 조직이 같은 문제를 해결하고자 노력했기 때문에 다양한 상황에 적 용할 수 있는 기법을 찾을 수 있다는 것이다. 수십 개의 실천 지침이 담긴 이 책이 도움될 것이다. 이 러한 실천 지침은 마치 전에 없던 새로운 시스템을 만드는 것처럼 보이기도 한다. 그러나 이들 중 대 부분은 개선이나 교체, 리엔지니어링(21장 “개선 프로젝트와 교체 프로젝트” 참조) 프로젝트에 적 용할 수도 있으며, 상용 패키지 솔루션(22장 “패키지 솔루션 프로젝트” 참조)을 통합하는 프로젝트 에도 적용할 수 있다. 애자일 개발 프로세스에 따라 점진적으로 제품을 개발하는 프로젝트 팀 역시 각 단계를 진행하기 위해 요구사항을 이해할 필요가 있다(20장 “애자일 프로젝트” 참조). 이번 장에서는 다음과 같은 같은 도움을 얻을 수 있을 것이다. ■■ 소프트웨어 ■■ 제품

요구사항 도메인에서 사용되는 핵심 용어의 이해

요구사항과 프로젝트 요구사항 구분

■■ 요구사항 ■■ 발생할

개발과 요구사항 관리 구분

수 있는 요구사항 관련 문제에 대비

중요 이 책에서는 기업의 내부적인 용도나 상업용, 계약을 통해 제공되는 소프트웨어 또는 소프트웨어를 포함하는 모든 것들에 대해 “시스템”, “제품”, “애플리케이션”, “솔루션”과 같은 용어를 두루 사용한다.

요구사항 수준 진단하기 현재 진행 중인 프로젝트에서 아래의 요소 중 몇 개가 해당하는지 확인해 봄으로써 여러분이 속한 조직의 요구사항 실무 수준을 간단히 파악할 수 있다. 3~4개 이상의 항목이 해당한다면 이 책이 여러분에게 크게 도움될 것이다. ■

프로젝트의 비즈니스 목표, 비전, 범위가 명확히 정의된 적이 없었다.

고객이 너무 바빠 요구사항에 대해 분석가나 개발자들과 시간을 보내기가 어려웠다.

팀이 요구사항을 이해하기 위해 고객 대표와 직접 이야기할 수 있는 방법이 없었다.

고객이 모든 요구사항을 중요하다고 생각해 우선순위를 할당할 수 없었다.

코드를 작성할 때 모호하거나 누락된 정보로 인해 개발자가 추측에 의존해 개발해야만 했다.

개발자와 이해관계자의 의사소통이 소프트웨어에 대한 고객의 니즈보다는 사용자 인터페이스와 기능에 집중 돼 있었다.

책1.indb 4

고객이 요구사항을 절대 승인하지 않았다.

고객이 제품 출시나 이를 위한 반복주기와 관련된 요구사항에 동의한 후에도 계속 요구사항을 변경했다.

2017-04-18 오후 4:02:49


01 _ 필수 소프트웨어 요구사항

5

요구사항 변경 승인으로 인해 프로젝트의 범위가 증가했지만 필요한 자원이 추가되지 않고 기능 삭제가 이뤄 지지 않아 일정에 차질이 생겼다.

요구사항 변경 요청이 제대로 관리되지 않아 아무도 변경 요청의 상태를 알지 못했다.

고객의 요구에 따라 개발자가 기능을 구현했지만 아무도 사용하지 않았다.

프로젝트 종료 시점에 모든 명세는 만족했지만, 고객이나 비즈니스 목표를 충족시키지는 못했다.

소프트웨어 요구사항의 정의 사람들이 요구사항에 대한 논의를 시작할 때 처음부터 용어 문제에 봉착하곤 한다. 각기 다른 관찰 자는 단순한 문장으로 사용자 요구사항, 소프트웨어 요구사항, 비즈니스 요구사항, 기능적 요구사 항, 시스템 요구사항, 제품 요구사항, 프로젝트 요구사항, 사용자 스토리, 기능, 제약조건 등을 설명 할 것이다. 다양한 요구사항 산출물에 사용하는 이름 또한 다양하다. 요구사항에 대한 고객의 정의 가 개발자에게는 상위 제품 콘셉트처럼 들릴 수도 있다. 또한 개발자가 생각하는 요구사항이 사용자 에게는 좀 더 자세한 사용자 인터페이스를 설계하는 것처럼 들릴 수도 있다. 이 같은 다양한 해석은 혼란과 좌절을 야기한다.

“요구사항”의 여러 해석 컴퓨터 프로그래밍이 탄생한 지 수십 년이 지난 지금도 소프트웨어 전문가들은 “요구사항”이 무엇 인지에 대해 여전히 격렬한 논쟁을 벌이고 있다. 이 책에서는 이런 논쟁에 합류하기보다는 우리가 찾은 몇 가지 유용한 정의를 소개한다. 컨설턴트인 브라이언 로렌스는 요구사항이란 “설계안을 도출하기 위한 모든 것”이라고 제안했다 ( Lawrence 1997). 많은 종류의 정보가 이 범주에 속하므로 나쁘지 않은 정의다. 결국 요구사항 개 발에서 가장 중요한 것은 최후에는 고객의 니즈를 만족시킬 수 있는 적절한 설계안을 이끌어내는 것이기 때문이다. 요구사항의 또 다른 정의는 요구사항이란 제품이 반드시 이해관계자에게 가치를 제공해야 한다는 특성이라는 것이다. 이 역시 나쁘지는 않지만 그리 정확한 의미도 아니다. 우리가 가장 선호하는 정의 중 하나는 이안 소머빌과 피트 소이어의 정의다( Ian Sommerville and Pete

Sawyer 1997). 요구사항이란 무엇을 구현해야 하는가에 대한 명세다. 요구사항은 시스템이 동작하는 방법이나 시스템 속성 혹은 특성을 설명한 것이다. 이는 시스템 개발 프로세스의 제약조건이라고 볼 수도 있다.

책1.indb 5

2017-04-18 오후 4:02:49


6

PART 01 _ 소프트웨어 요구사항: 무엇을, 왜, 누가

이 정의는 다양한 유형의 정보가 “요구사항”이라고 포괄적으로 이야기한다. 요구사항은 외부에서 시스템의 동작을 바라보는 사용자 관점과 내부 특성을 바라보는 개발자 관점 모두를 아우른다. 이는 특정 조건에서의 시스템 동작과 예정된 운영자가 시스템을 제대로(심지어 즐겁게) 사용하기 위한 속성 모두를 포함한다. 함정 프로젝트의 모든 이해관계자가 요구사항에 대해 동일한 개념을 가지고 있다고 가정하지 말자. 먼저 정의를 정확히 짚고 넘어가야 항상 같은 관점에서 얘기할 수 있다.

“요구사항”의 사전적 의미 소프트웨어 분야에 종사하는 사람들은 “요구사항”의 의미를 뭔가 요구되는 것이나 필요한 것, 필요 나 필요성과 같은 사전적 정의 그대로 사용하지 않는다. 사람들은 우선순위가 낮은 요구사항은 구현 되지 않을 수도 있으므로 요구사항에 우선순위를 할당해야 하는지에 대해 궁금해하기도 한다. 정말 필요하지 않다면 요구사항이 아니라고 주장하기도 한다. 그렇다면 이런 정보 조각들을 뭐라고 불러 야 할까? 현재 진행 중인 프로젝트에서 아직 구체화되지 않은 요구사항을 다음 배포 시점으로 미룬 다면 여전히 이 요구사항에 대해 고려해야 할까? 당연히 고려해야 할 것이다. 소프트웨어 요구사항은 시간 차원을 포함한다. 요구사항은 현재 시제로 현 시스템의 기능을 설명한 다. 가까운 미래(높은 우선순위), 좀 더 먼 미래(중간 우선순위), 아주 먼 미래(낮은 우선순위)일 수 도 있다. 심지어 어떤 필요에 의해 정의됐다가 폐기되어 과거 시제가 될 수도 있다. 비록 어떤 비즈 니스적인 이유로 구현될 리 없다는 것을 알고 있더라도 이것이 요구사항인지에 대해 논의하느라 시 간을 낭비하지 말자. 요구사항은 말 그대로 요구사항일 뿐이다.

요구사항의 단계와 유형 요구사항 정보에는 수많은 유형이 있으므로 먼저 “요구사항”이라는 단어가 내포하고 있는 일련의 형용사에 대해 알아둘 필요가 있다. 이번 절에서는 요구사항 도메인에서 주로 접하게 되는 몇 가지 용어의 정의를 설명한다(표 1-1 참조).

책1.indb 6

2017-04-18 오후 4:02:49


01 _ 필수 소프트웨어 요구사항

7

표 1-1 요구사항 정보의 일부 유형

용어

정의

비즈니스 요구사항

제품 개발 조직이나 제품을 구매하는 고객의 고수준 비즈니스 목표

비즈니스 규칙

어떤 비즈니스 양상을 정의하거나 제약하는 정책이나 지침, 표준, 규정. 이 자체만으로도 소프트웨 어 요구사항이면서 다양한 소프트웨어 요구사항의 근원이기도 하다.

제약조건

개발자가 제품을 설계하거나 구현하며 선택이 필요할 때 이에 영향을 미치는 제약

외부 인터페이스 요구사항

소프트웨어 시스템과 사용자나 기타 다른 소프트웨어 시스템, 하드웨어 장비와의 관계에 대한 설명

기능

사용자에게 가치를 제공하고 일련의 기능적 요구사항에 기술된 한 가지 이상의 논리적으로 연계된 시스템 기능

기능적 요구사항

특정 조건에서 발생하는 소프트웨어 시스템 동작에 대한 설명

비기능적 요구사항

시스템이 꼭 제공해야 하는 속성이나 특징, 혹은 시스템이 고려해야 하는 제약조건에 대한 설명

품질 속성

제품의 서비스나 성능 특성을 기술하는 비기능적 요구사항의 한 종류

시스템 요구사항

소프트웨어로만 구성되거나 하드웨어와 같이 구성되는 등 다수의 서브시스템을 포함하는 제품의 최상위 요구사항

사용자 요구사항

특정 사용자 클래스가 시스템을 통해 반드시 수행해야 하는 목표나 태스크, 혹은 원하는 제품 속성

소프트웨어 요구사항은 비즈니스 요구사항, 사용자 요구사항, 기능적 요구사항의 세 단계로 나뉜다. 그뿐만 아니라 모든 시스템은 다수의 비기능적 요구사항을 갖고 있다. 그림 1-1의 모델은 이처럼 다 양한 유형의 요구사항에 대해 생각해 볼 수 있게 한다. 통계학자 조지 박스( George E. P. Box) 박 사가 한 유명한 말이 있다. “기본적으로 모든 모델은 틀렸다. 그러나 그중 몇몇은 유용하다.”( Box

and Draper 1987) 그림 1-1도 마찬가지다. 이 모델이 모두 다 포함하고 있지는 않지만 여러분에 게 필요한 요구사항 지식을 정리하는 데 유용한 지침을 제공한다. 그림 1-1의 타원형은 요구사항 정보의 유형을 나타내며, 직사각형은 이러한 정보를 담는 문서를 나 타낸다. 또한 실선 화살표는 일반적으로 해당 정보의 유형이 화살표가 가리키는 문서에 담겨 있음을 의미한다. (소프트웨어 요구사항에서 비즈니스 규칙과 시스템 요구사항은 각각 비즈니스 규칙 카탈 로그나 시스템 요구사항 명세서로 별도로 저장된다.) 점선 화살표는 하나의 정보 유형이 요구사항 의 근원이거나 다른 요구사항에 영향을 미치는 것을 의미한다. 데이터 요구사항은 이 다이어그램에 서는 명확히 보여지지 않는다. 기능이 데이터를 생성하므로 데이터 요구사항은 세 단계 여기저기에 나타날 수 있다. 7장 “요구사항 도출”에서 다양한 유형의 요구사항 정보에 대해 다수의 예제와 함께 알아보겠다.

책1.indb 7

2017-04-18 오후 4:02:50


8

PART 01 _ 소프트웨어 요구사항: 무엇을, 왜, 누가

비즈니스 요구사항

비즈니스 규칙

비전 범위 문서

품질 속성

사용자 요구사항

사용자 요구사항 문서 외부 인터페이스 시스템 요구사항

기능적 요구사항

제약조건

소프트웨어 요구사항 명세서 그림 1-1 여러 유형의 요구사항 정보 관계도. 실선 화살표는 “저장됨”을 의미하며, 점선 화살표는 “근원이 됨”이나 “영향을 미침”을 의미한다.

중요 이 책에서 이야기하는 요구사항은 대부분 문서를 뜻하지만 그림 1-1과 같이 전통적인 종이 문서나 전자 문서 일 필요는 없다. 대신 요구사항 지식을 담기 위한 그릇으로 생각하자. 이런 그릇은 보통 전통적인 문서일 수도 있으 나 스프레드시트나 다이어그램, 데이터베이스, 요구사항 관리 도구 혹은 이것들을 조합한 것이 될 수도 있다. 이 책 에서는 이러한 그릇을 지칭할 때 편의상 “문서”라는 용어를 사용할 것이다. 또한 형식과 상관 없이 각 그룹에 저장 할 정보 유형을 식별할 수 있는 템플릿을 제공할 것이다. 각 산출물에 대한 호칭은 조직이 이것들의 이름과 각 산출 물에 저장되는 정보의 유형, 정보가 구성되는 방법에 동의하는 것보다 덜 중요하다.

비즈니스 요구사항은 조직이 성취하고자 하는 비즈니스 성과와 같이 조직이 시스템을 구현하는 이 유를 설명한다. 조직이나 고객(시스템을 요청하는)의 비즈니스 목표가 주안점이다. 어떤 항공사에 서 공항 창구 직원을 유지하는 비용의 25%를 절감하고 싶다고 해보자. 이 목표를 달성하기 위해 승 객들이 공항에서 비행기 탑승 수속을 밟을 수 있는 키오스크를 개발하면 될 것이라고 생각할 수 있 다. 비즈니스 요구사항은 일반적으로 프로젝트의 자금 스폰서나 대상 고객, 실사용자의 관리자, 마 케팅 부서, 제품 혜안가( product visionary)로부터 나온다. 우리는 비즈니스 요구사항을 비전 범위 문서에 기록하는 것을 선호한다. 때때로 프로젝트 헌장( project charter)이나 비즈니스 사례, 시장

책1.indb 8

2017-04-18 오후 4:02:50


01 _ 필수 소프트웨어 요구사항

9

또는 마케팅 요구사항 문서 등과 같은 전략적 지침 문서가 이러한 목적으로 사용되기도 한다. 비즈 니스 요구사항을 구체화하는 과정은 5장 “비즈니스 요구사항 정립하기”에서 다룬다. 이 책의 목표를 위해 비즈니스 니즈나 시장 기회는 이미 확인된 것으로 가정한다. 사용자 요구사항은 누군가에게 가치를 제공하기 위해 사용자가 제품을 통해 수행해야만 하는 목표 나 태스크를 설명한다. 사용자 요구사항의 범위는 사용자의 만족도에 중대한 영향을 미치는 제품 속성이나 특징에 대한 설명도 포함한다. 사용자 요구사항을 표현하는 방법으로 유스케이스( Kulak

and Guiney 2004), 사용자 스토리( Cohn 2004), 이벤트 반응표 등이 있다. 이상적인 경우 실제 사용자 대표가 이런 정보를 제공한다. 사용자 요구사항은 사용자가 시스템으로 무엇을 할 수 있는지 를 기술한다. 항공사 웹사이트나 공항 키오스크를 이용한 “비행기 탑승 수속”을 유스케이스의 한 가 지 예로 들 수 있다. 동일한 요구사항을 사용자 스토리로 작성하면 “나는 승객으로서 비행기에 탑승 하기 위해 비행기 탑승 수속을 하고 싶다.”라고 읽을 것이다. 대부분의 프로젝트가 여러 사용자 클래 스를 갖고 있으며, 요구사항을 도출하는 이해관계자도 가지고 있다는 사실을 기억하자. 8장 “사용 자 요구사항 이해하기”에서 이런 모델을 살펴볼 것이다. 어떤 이는 사용자로부터 직접 요구사항을 얻기보다는 다양한 이해관계자로부터 습득하는 게 더 현실적이라는 의미로 “이해관계자 요구사항” 이라는 좀 더 넓은 범위의 용어를 사용하기도 한다. 확실히 맞는 말이긴 하지만 우리는 실사용자가 제품을 통해 달성하고자 하는 바가 무엇인지를 이해하는 수준에 모든 관심을 집중한다. 기능적 요구사항은 특정 조건하에서의 소프트웨어의 동작을 구체화한다. 이 요구사항은 사용자가 태스크(사용자 요구사항)를 완료할 수 있도록 개발자가 구현해야 하는 것을 기술하기 때문에 비즈 니스 요구사항을 만족한다. 프로젝트의 성공을 위해서는 세 단계의 요구사항을 정리하는 것이 꼭 필 요하다. 기능적 요구사항은 “승객은 탑승 수속을 마친 모든 비행 편에 대한 탑승권을 인쇄할 수 있어 야 한다.” 또는 “만약 승객의 프로파일에 선호 좌석이 지정돼 있지 않으면 예약 시스템은 좌석을 지 정해야 한다.”와 같이 대개 “~해야 한다”의 형태로 작성된다. 비즈니스 분석가( BA; Business Analyst) 1는 소프트웨어 시스템의 예상 동작을 필요한 만큼 최대 한 기술하는 소프트웨어 요구사항 명세서( SRS; Software Requirements Specification)에 기능적 요구사항을 작성한다. SRS는 개발, 테스트, 품질 보증, 프로젝트 관리, 관련 프로젝트 기능에 사용 된다. 사람들은 이런 산출물을 비즈니스 요구사항, 기능 명세, 요구사항 문서 등 각기 다른 이름으로 부른다. SRS는 요구사항 관리 도구에 저장된 정보를 기반으로 만든 보고서로서 산업 표준 용어이기

1

“비즈니스 분석가”는 프로젝트에서 요구사항 관련 활동을 이끄는 데 가장 큰 책임을 가진 프로젝트 내 역할을 의미한다. BA의 역할은 다양한 이름으로 불린다. 비즈니스 분 석가의 역할에 대한 자세한 내용은 4장 “비즈니스 분석가”를 참조한다.

책1.indb 9

2017-04-18 오후 4:02:50


10

PART 01 _ 소프트웨어 요구사항: 무엇을, 왜, 누가

때문에 이 책에서는 SRS라고 일관되게 표현할 것이다( ISO/IEC/IEEE 2011). SRS에 대한 자세한 내용은 10장 “요구사항 문서화하기”를 참조한다. 시스템 요구사항은 다수의 구성요소나 서브시스템으로 이뤄진 제품에 대한 요구사항을 설명한다 ( ISO/IEC/IEEE 2011). 이러한 맥락에서 “시스템”이란 용어가 단순히 정보 시스템만을 의미하지는 않는다. 시스템은 소프트웨어로만 이뤄질 수도 있지만 소프트웨어와 하드웨어 서브시스템을 포함할 수도 있다. 사람과 프로세스 모두 시스템의 일부이기 때문에 특정 시스템 기능이 사람의 행동에 대 응될 수도 있다. 어떤 이들은 “시스템 요구사항”이란 용어를 소프트웨어 시스템의 상세 요구사항이 라는 의미로 사용하지만 이 책에서는 그렇게 사용하지 않는다. “시스템”의 좋은 예는 슈퍼마켓 점원의 단말기다. 슈퍼마켓에는 휴대용 바코드 스캐너도 있고 저울 이 달린 바코드 스캐너도 있다. 점원은 키보드와 모니터, 금전 등록기를 가지고 있다. 고객카드와 신 용카드 또는 현금카드를 위한 카드 리더기와 숫자 키보드( PIN pad), 그리고 동전 자동 교환기도 있 을 것이다. 구매 영수증 출력용 프린터, 신용카드 영수증 프린터뿐만 아니라 일반적으로 별로 신경 쓰지 않는 쿠폰을 출력하기 위한 프린터 등 최대 세 가지의 프린터도 찾아볼 수 있을 것이다. 이러한 하드웨어 장치는 모두 소프트웨어의 통제하에 상호작용한다. 시스템 또는 제품 전반에 대한 요구사 항은 비즈니스 분석가로 하여금 특정 구성요소 서브시스템에 할당해야 하는 기능을 도출하고 그러 한 구성요소 서브시스템 간의 인터페이스를 이해하도록 이끈다. 비즈니스 규칙은 기업 정책이나 정부 규제, 산업 표준, 계산 알고리즘을 포함한다. 9장 “규칙에 따 르기”에서 확인하겠지만 비즈니스 규칙은 어떤 특정 소프트웨어 애플리케이션의 범주 바깥에 존재 하기 때문에 소프트웨어 요구사항 자체를 말하지는 않는다. 그러나 종종 관련 규칙을 준수하기 위해 시스템이 꼭 포함해야 하는 기능에 대해 이야기하기도 한다. 어떨 때는 기업 보안 정책과 같이 비즈 니스 규칙이 기능에 구현돼야 하는 특정 품질 속성의 근원이 되기도 한다. 따라서 특정 비즈니스 규 칙까지 어떤 기능적 요구사항의 근원을 추적할 수 있다.

SRS는 기능적 요구사항뿐 아니라 각종 비기능적 요구사항도 포함한다. 품질 속성은 품질 요소, 서 비스 요구사항의 품질, 제약조건으로도 알려져 있으며, “~성”으로 끝나는 단어로도 알려져 있다. 이 는 성능, 안전성, 가용성, 이식성과 같은 다양한 측면에서 사용자나 개발자, 유지보수 담당자에게 중 요한 제품의 특징을 설명한다. 다른 비기능적 요구사항에서는 시스템과 외부 세계 사이의 인터페이 스를 설명한다. 이들은 통신 인터페이스뿐 아니라 기타 다른 소프트웨어 시스템, 하드웨어 구성요 소, 사용자 간의 연결을 포함한다. 설계와 구현 제약조건은 제품을 개발하는 동안 개발자의 선택권 을 제한한다.

책1.indb 10

2017-04-18 오후 4:02:50


01 _ 필수 소프트웨어 요구사항

11

만약 뭔가 비기능적이라면 과연 그것은 무엇인가? 수년 동안 소프트웨어 제품을 위한 요구사항은 기능적 또는 비기능적인 것 중 하나로 폭넓게 분류됐다. 기능적 요 구사항은 명확하다. 기능적 요구사항은 다양한 조건에서 관찰할 수 있는 시스템 동작을 설명한다. 반면 많은 사람 들은 “비기능적”이란 용어를 싫어한다. 이 형용사는 요구사항이 아니라고 설명하지만 그것이 무엇인지는 설명하지 않는다. 우리는 이 문제에 공감하지만 완벽한 해결책을 갖고 있지는 않다. 기능적 요구사항과 달리 비기능적 요구사항은 시스템이 무엇을 수행하는지가 아니라 시스템이 어떻게 잘 수행하 는지를 설명한다. 시스템의 중요한 특징이나 특성을 설명할 수도 있다. 이러한 시스템의 가용성, 사용성, 보안, 성능 및 기타 다른 특징들은 14장 “기능, 그 이상을 향해”에서 다룬다. 혹자는 비기능적 요구사항을 품질 속성과 동의어 로 생각하기도 하지만 이는 지나치게 제한적인 생각이다. 예를 들면, 설계와 구현 제약조건 또한 외부 인터페이스 요구사항처럼 비기능적 요구사항이다. 여전히 다른 비기능적 요구사항은 플랫폼, 이식성, 호환성, 제약조건과 같이 시스템이 운영되는 환경을 말한다. 많 은 제품들 또한 규정 준수나 규제, 인증 요구사항의 영향을 받는다. 문화나 언어, 법, 통화, 용어, 맞춤법, 기타 사용 자의 특성을 고려해야 하는 제품을 위한 현지화 요구사항이 있을 수도 있다. 이러한 요구사항이 비기능적이란 용어 로 구체화됐다 하더라도 비즈니스 분석가는 일반적으로 시스템이 지닌 동작과 속성을 모두 보장하기 위해 무수한 기능 조각들을 찾아낼 것이다. 이러한 한계에도 불구하고 적절하고 포괄적인 대안이 없다 보니 이 책에서는 “비기능적 요구사항”란 용어를 사용 하고 있다. 이런 종류의 정보를 정확히 뭐라 부를지 걱정하기보다 이것들이 요구사항 도출 및 분석 활동의 일부인 지 확실히 확인하자. 모든 필요한 기능을 갖고 있어도 (종종 언급하던) 품질 기대치에 부합하지 않아 사용자의 마음 에 들지 않을 수도 있다.

하나의 기능( feature)은 하나 이상의 논리적으로 연관된 시스템 기능( capability)으로 이뤄지며, 각 기능( capability)은 사용자에게 가치를 제공하고 일련의 기능적 요구사항으로 설명된다. 고객이 필요로 하는 제품 기능 목록은 사용자 작업과 관련된 요구를 설명한 것과 다르다. 웹 브라우저 즐겨 찾기, 맞춤법 검사, 어떤 운동 장비의 사용자 맞춤 프로그램 정의 기능, 안티 멀웨어 제품의 바이러 스 서명 자동 갱신 등의 기능을 예로 들 수 있다. 기능은 다양한 사용자 요구사항을 포함할 수 있으 며, 각각은 사용자가 각 사용자 요구사항에 기술돼 있는 작업을 수행할 수 있도록 특정 기능적 요구 사항이 구현돼야 함을 암시한다. 그림 1-2는 기능을 특정 사용자 요구사항과 관련돼 있고 일련의 기능적 요구사항으로 구체화할 수 있는 일련의 계층적인 소기능으로 분리하는 방법을 보여주는 분 석 모델인 기능 트리를 보여준다( Beatty and Chen 2012).

책1.indb 11

2017-04-18 오후 4:02:50


12

PART 01 _ 소프트웨어 요구사항: 무엇을, 왜, 누가

웹 브라우저 즐겨찾기

쿠키

즐겨찾기 추가하기

즐겨찾기 내보내기

즐겨찾기로 이동하기 확장 기능

즐겨찾기 수정하기 1. 시스템은 축소 및 확장 가능한 계층 트리로 즐겨찾기를 화면에 출력할 수 있어야 한다. 2. 사용자는 즐겨찾기의 순서를 변경할 수 있어야 한다. 3. 시스템은 즐겨찾기의 속성을 화면에 출력할 수 있어야 한다. 4. 사용자는 즐겨찾기의 이름, URL, 설명을 수정할 수 있어야 한다.

기호 설명

기능

사용자 요구사항 1. 기능적 요구사항

그림 1-2 기능, 사용자 요구사항, 기능적 요구사항 간의 관계

이처럼 다양한 종류의 요구사항을 설명하기 위해 텍스트 편집기 프로그램의 차기 버전을 개발하는 프로젝트에 대해 생각해보자. 비즈니스 요구사항으로 “미국 외 판매량을 6개월 안에 25% 증가시켜 야 한다.”를 들 수 있다. 마케팅 담당자는 경쟁사 제품이 영어 맞춤법 검사만 제공한다는 것을 파악 하고 자사의 신규 버전에서 다국어 맞춤법 검사 기능을 추가하기로 결정했다. 이에 따라 사용자 요 구사항에 “맞춤법 검사를 위한 언어 선택”, “맞춤법 오류 찾기”, “사전 단어 추가” 등의 작업이 포함 될 수 있다. 맞춤법 검사에는 철자가 틀린 단어 강조하기, 자동 교정, 교체 제안 단어 출력, 문서 전 체에서 철자가 틀린 단어를 올바른 단어로 교체하는 전역 교정 등 다양한 기능적 요구사항을 가지고 있다. 사용성 요구사항은 소프트웨어가 특정 언어와 문자 집합을 사용하기 위해 현지화하는 방법을 구체화한다.

책1.indb 12

2017-04-18 오후 4:02:50


01 _ 필수 소프트웨어 요구사항

13

세 단계로 요구사항 작성하기 그림 1-3은 다양한 이해관계자가 세 단계의 요구사항 도출에 어떻게 참여하는지 보여준다. 각기 다 른 조직은 이들 활동에 필요한 역할을 다양한 이름으로 부른다. 조직 내에서 누가 이런 활동을 하는 지 생각해보자. 회사 내부의 별도 조직에서 개발하는지, 아니면 독립적인 상용 소프트웨어 개발 회 사인지에 따라 역할의 이름이 달라진다. 기업적 역할

상업적 역할

비즈니스적인 필요성

시장의 요청이나 제품 콘셉트

관리자

마케팅 담당자 비즈니스 요구사항

비즈니스 분석가 및 사용자 대표

제품 관리자

사용자 요구사항

비즈니스 분석가 또는 제품 관리자

비즈니스 분석가

기능적 요구사항

개발자, 테스터

그림 1-3 각 이해관계자가 요구사항 개발에 참여하는 방법의 예

관리자나 마케팅 담당자는 확인된 비즈니스 니즈나 시장 니즈, 흥미로운 신규 제품 콘셉트를 기반으 로 기업을 효율적으로 운영하거나(사내 정보 시스템) 시장에서 성공적으로 경쟁하는 데(상용 제품) 도움이 되는 소프트웨어의 비즈니스 요구사항을 정의한다. 기업 환경에서 비즈니스 분석가는 사용 자 요구사항을 식별하기 위해 일반적으로 사용자 대표와 함께 일한다. 상용 제품을 개발하는 기업은 제품 관리자를 임명해 새로운 제품에 포함할 기능을 결정한다. 각 사용자 요구사항과 기능은 비즈니 스 요구사항 달성을 목표로 해야 한다. BA나 제품 관리자는 사용자 요구사항으로부터 사용자가 목

책1.indb 13

2017-04-18 오후 4:02:51


Software requirements 3rd  

칼 위거스, 조이 비티 지음 | 최상호, 임성국 옮김 | IT Leaders 시리즈_026 | ISBN: 9791158390594 | 42,000원 | 2017년 04월 28일 발행 | 752쪽 | Requirement, 요구공학, 요구사항, 이해관...

Read more
Read more
Similar to
Popular now
Just for you