추가 적립 안내

소프트웨어 개발에서 근간이 되는 요구사항에 관한 핵심 지식과 실전 경험을 제공한다

성공적인 요구사항 계획, 도출, 분석, 명세화, 검증 및 관리를 위한 20가지 핵심 실무 사례를 제시해서 팀 전체가 주요 개념, 용어, 기술 및 근거에 대한 이해를 공유하고 모든 프로젝트에서 더욱 효과적으로 협업할 수 있도록 한다.
이러한 핵심 실무 사례는 개발 팀이 비즈니스 문제를 이해하고, 적절한 참가자를 참여시키고, 더 나은 해결책을 명확하게 표현하고, 의사 소통을 개선하고, 가장 가치 있는 기능을 올바른 순서로 구현하고, 변화와 성장에 적응하는 데 큰 도움을 줄 것이다.

소프트웨어 요구사항에 관한 단 한 권의 책을 고르라면 단연코 이 책이다!

이 책 《소프트웨어 요구사항의 정수》를 꼭 읽지 않아도 된다. 그러나 소프트웨어 프로젝트에서 어떤 형태로든 요구사항을 다루고 있다면, 이 책이 필독서라고 생각한다!
-Joy Beatty, ArgonDigital의 COO

요구사항 엔지니어링의 각 하위 영역에는 수많은 개별 실무 사례practice가 포함되어 있다. 이 책의 내용이 바로 그것이다. 이 책에서는 거의 모든 프로젝트의 성공에 특히 크게 기여하는 20가지 핵심 실무 사례에 대해 설명한다. 요구사항 활동을 주도하든, 요구사항 활동에 참여하든, 자신의 업무를 수행하기 위해 요구사항에 의존하든, 이러한 핵심 실무 사례를 적용하면 더 효과적일 것이다. 이 실무 사례들은 템플릿, 스프레드시트 도구, 체크리스트 및 기타 작업 보조 도구로도 제공될 수 있다.
20개의 실무 사례는 요구 사항 엔지니어링 하위 영역별로 분류되어 있으며, 각 하위 영역에는 4개의 요구사항 개발의 실무 사례와 1개의 요구사항 관리의 실무 사례가 포함되어 있다. 3장에서는 요구사항 도출을 언급하고, 4장에서는 분석 실무 사례를 설명하며, 5장에서는 요구사항 명세를 다루고, 6장에서는 주요 검증 실무 사례에 대해 설명한다. 가장 중요한 요구사항 관리 실무 사례는 7장에 나와 있다.

주요 내용
■ 문제를 명확히 하고, 비즈니스 목표를 정의하고, 해결책의 경계를 설정한다.
■ 이해 당사자 및 의사 결정자를 식별한다.
■ 사용자의 직무, 이벤트 및 응답을 탐구한다.
■ 데이터 개념 및 관계를 평가한다.
■ 품질 속성을 도출 및 평가한다.
■ 요구사항 및 요구사항 집합을 분석하고, 모델 및 프로토타입을 생성하며, 우선순위를 설정한다.
■ 일관되고 구조화되고 잘 문서화된 방식으로 요구사항을 지정한다.
■ 요구사항 변경을 검토, 테스트 및 관리한다.

Steve Blais(《Business Analysis: Best Practices for Success》의 저자이자 《Business Analysis for Practitioners》)
칼과 캔디스는 전통적인 BA 접근 방식과 애자일 소프트웨어 개발자를 위해 사용자 스토리를 정의하는 BA 방식 모두에게 적용할 수 있는 많은 실무 사례로 이 책을 ‘애자일’하게 만들었다. 《소프트웨어 요구사항의 정수》는 칼이 수년 동안 우리에게 제공한 모든 훌륭한 조언과 충고를 이 한 권의 책에 요약해 놓았다. 내가 이 책을 썼더라면 좋았을 텐데…

Shane Hastie(SoftEd의 글로벌 딜리버리 책임자이자 InfoQ.com의 ‘문화 및 방법’ 수석 편집자)
이 책은 실용적인 조언과 훌륭한 예시, 그리고 소프트웨어 제품을 구축하는 사람들이 현실에서 직면하는 어려운 질문에 대한 답변으로 가득 차서 유용하고 접근하기 쉬우며 명료하다. 어떤 역할로든 소프트웨어 구축에 관여하는 사람이라면, 이 책을 통해 제품이 고객의 요구를 충족하고 진정한 가치를 제공할 수 있도록 하는 방법에 대한 지침을 얻을 수 있을 것이다.

Laura Brandenburg(《How to Start a Business Analyst Career》의 저자)
이 책은 주요 비즈니스 분석의 실무 사례에 대해 접근하기 쉽고, 명확하게 작성되어, 잘 정리된 내용을 원하는 초보 및 숙련된 비즈니스 분석가 모두에게 매우 유용한 자원이다. 칼과 캔디스는 비즈니스 분석 프로세스에 통합하여 더 효과적으로 만들 수 있는 간단한 실무 사례들로 복잡한 기능을 분류하는 데 탁월한 능력을 발휘했다.

Mike Cohn(《사용자 스토리》의 저자이자 Scrum Alliance 공동 창립자)
요구사항 공학 분야에서 최근 10년간 가장 많이 판매된 10종을 읽어보았는데, 이 한 권의 책에는 그 10종의 책을 합친 것보다 더 유용한 정보가 간결하게 담겨 있다. 그때 ‘이 책을 참고했더라면 좋았을 텐데!’ 하는 아쉬움이 남는다.

James Robertson(《Mastering the Requirements Process》의 저자)
다이아몬드는 엄청난 양의 탄소 원자가 압축될 때 만들어지며, 압축이 결정화되어 다이아몬드를 형성한다. 칼과 캔디스도 이와 비슷한 일을 해냈는데, 방대한 요구사항 지식을 ‘핵심 실무 사례’라고 부르는 20가지 보석으로 압축했다. 이러한 실무 사례는 모든 이에게 사용을 권장할 만큼 매우 유용하다.

옮긴이 머리말 viii
추천사 xiii
감사의 글 xviii
베타리더 후기 x
추천 서문 xvi

CHAPTER 1 소프트웨어 요구사항의 핵심 1
요구사항 정의 2
요구사항 엔지니어링의 모범 실무 사례 5
누가 이 모든 일을 하는가? 8
몇 가지 반복되는 주제 9
요구사항의 수명과 시간 10
시작하기 10

CHAPTER 2 기반 마련하기 12
실무 사례 #1: 해결책을 찾기 전에 문제를 이해한다 13
_비즈니스 문제 13 / 실제 문제 도출하기 14 / 비즈니스 문제에 집중하기 16 / 관련 실무 사례 17
실무 사례 #2: 비즈니스 목표를 정의한다 18
_비즈니스 요구사항 18 / 비즈니스 목표 21 / 성공 지표 22 / 제품 비전 23 / 관련 실무 사례 24
실무 사례 #3: 해결책의 경계를 정의한다 25
_해결책 개념 구체화하기 26 / 컨텍스트 설정하기 27 / 생태계 확장하기 28 / 해결책의 경계 적용하기 29 / 관련 실무 사례 31
실무 사례 #4: 이해 당사자를 식별하고 특성을 파악한다 32
_이해 당사자 탐색하기 32 / 이해 당사자, 고객 및 사용자 부류 34 / 이해 당사자의 특성 파악하기 36 / 관련 실무 사례 37
실무 사례 #5: 권한이 있는 의사 결정자를 파악한다 38
_누가 결정하는가? 39 / 그들은 어떻게 결정할까? 40 / 결정 후에는 어떻게 될까? 41 / 관련 실무 사례 42

CHAPTER 3 요구사항 도출 43
실무 사례 #6: 사용자가 해결책으로 수행해야 하는 작업을 이해한다 45
_사용에 초점 두기 46 / 사용자 요구사항 도출하기 46 / 유스케이스 해부하기 49 / 사용 중심 요구사항 정보 적용하기 50 / 관련 실무 사례 50
실무 사례 #7: 이벤트 및 응답을 식별한다 51
_이벤트 유형 52 / 이벤트 명시하기 53 / 관련 실무 사례 57
실무 사례 #8: 데이터 개념 및 관계를 평가한다 57
_데이터 개체와 관계 이해하기 58 / 데이터 이해도 향상시키기 60 / 데이터 세부 정보가 성공을 결정한다 62 / 숨어있는 데이터 요구사항 찾기 64 / 관련 실무 사례 65
실무 사례 #9: 품질 속성을 도출하고 평가한다 65
_품질 속성 도출하기 66 / 품질 속성이 갖는 의미 67 / 품질 속성 절충하기 68 / 품질 속성 지정하기 69 / 관련 실무 사례 71

CHAPTER 4 요구사항 분석 72
실무 사례 #10: 요구사항을 분석한다 73
_개별 요구사항 분석하기 74 / 요구사항 집합 분석하기 78 / 관련 실무 사례 80
실무 사례 #11: 요구사항 모델을 작성한다 81
_올바른 모델 선택하기 82 / 모델을 사용하여 이해한 것을 구체화하기 84 / 반복적 모델링 86 / 관련 실무 사례 88
실무 사례 #12: 프로토타입을 만들고 평가한다 88
_프로토타입을 만드는 이유 89 / 프로토타입 제작과 사용하기 90 / 프로토타입의 운명 93 / 관련 실무 사례 93
실무 사례 #13: 요구사항의 우선순위를 지정한다 94
_우선순위 지정 시 할 일 94 / 우선순위에 영향을 미치는 요인 95 / 우선순위 부여 기법 96 / 품질 속성의 우선순위를 정하기 위한 쌍별 비교 98 / 분석적 우선순위 지정 방법 99 / 관련 실무 사례 100

CHAPTER 5 요구사항 명세 102
실무 사례 #14: 일관된 방법으로 요구사항을 작성한다 104
_몇 가지 일반적인 요구사항 패턴 104 / 추상화 수준 106 / 요구사항 속성 108 / 비기능적 요구사항 109 / 관련 실무 사례 110
실무 사례 #15: 체계적인 방식으로 요구사항을 구성한다 110
_요구사항 템플릿 110 / 소프트웨어 요구사항 명세 112 / 요구사항 관리 도구 114 / 관련 실무 사례 115
실무 사례 #16: 비즈니스 규칙을 식별하고 문서화한다 116
_비즈니스 규칙 정의 116 / 비즈니스 규칙 찾기 118 / 비즈니스 규칙 문서화하기 119 / 비즈니스 규칙 적용하기 120 / 관련 실무 사례 121
실무 사례 #17: 용어집을 만든다 122
_의사 소통 동기화하기 122 / 관련 실무 사례 125

CHAPTER 6 요구사항 검증 126
실무 사례 #18: 요구사항을 검토하고 테스트한다 127
_요구사항 검토 127 / 요구사항 테스트하기 129 / 인수 기준 130 / 분석 모델 테스트하기 132 / 효율적으로 요구사항 테스트하기 133 / 품질을 최우선으로 생각하기 134 / 관련 실무 사례 135

CHAPTER 7 요구사항 관리 136
실무 사례 #19: 요구사항 기준선을 설정하고 관리한다 137
_요구사항 기준선 정의 137 / 두 가지 기준선 전략 138 / 기준선에 포함된 요구사항 식별하기 139 / 기준선에 대한 합의 얻기 140 / 여러 기준선 및 기준선 변경 관리하기 142 / 관련 실무 사례 143
실무 사례 #20: 요구사항 변경을 효과적으로 관리한다 144
_요구사항 변경 예상하기 145 / 변경 관리 프로세스 정의하기 146 / 영향에 대한 변경사항 평가하기 149 / 변경 결정이 내려진 후 150 / 적은 변경을 찾아서 150 / 관련 실무 사례 151

부록: 실무 사례 요약 153
참고문헌 155
찾아보기 163

실무 사례 #11 요구사항 모델을 작성한다
요구사항 지식을 표현하는 데 텍스트가 유일한 방법은 아니며, 때로는 최선의 방법도 아니다. 무수한 세부 사항 속에서 길을 잃고 큰 그림을 놓치거나 오류를 간과하기 쉽다. 시각적 요구사항 모델인 다이어그램은 문서화된 해결책 요구사항과는 다른 관점에서 요구사항 정보를 살펴볼 수 있는 좋은 방법을 제공한다. 강력한 요구사항 모델들을 만들면 BA가 상위 수준의 정보를 빠르게 반복 처리할 수 있으므로 보다 정확한 세부 요구사항으로 이어지는 통찰력을 부여해준다. 또한 현재 현실을 반영하기 위해 제품이 변경되면 모델을 쉽게 업데이트할 수 있으며, 이는 반복적인 프로젝트에서 특히 유용하다. 요구사항 모델링에 대한 숙련도는 필수적인 BA 기술이다(Wiegers, n.d.). 모델은 여러 가지 방법으로 요구사항 분석을 지원한다. (81쪽)

실무 사례 #12 프로토타입을 만들고 평가한다
이상적으로는 비즈니스 분석가가 사용자에게 필요한 것이 무엇인지 간단히 물어본 다음 요구사항 명세에 답변을 기록할 수 있다. 하지만 현실에서는 사용자가 “필요한 것이 무엇인지 말할 수는 없지만, 직접 보면 알 수 있을 겁니다I’ll know it when I see it, IKIWISI”라고 대답할 가능성이 더 높다. 두문자어인 IKIWISI는 개념, 텍스트 및 다이어그램의 모음으로만 요구사항을 탐색하는 데 따르는 어려움을 인정한다. 실무 사례 #11, “요구사항 모델을 작성한다”의 스트로맨 모델에서 보았듯이, 사람들은 새로운 것을 만들고 설명하는 것보다 눈앞에 놓인 것을 비평하는 것이 더 쉽다고 생각한다. (88쪽)

실무 사례 #14 일관된 방법으로 요구사항을 작성한다
‘요구사항 작성’이라는 문구를 볼 때마다 ‘요구사항 지식 표현’으로 바꾸어 생각하자. 자연어 텍스트는 사람들이 일반적으로 의사 소통하는 방식이기 때문에 소프트웨어 요구사항을 기록하는 데 가장 많이 사용되는 방법일 것이다. 하지만 시각적 모델(다이어그램), 테스트 코드, 설계 화면, 프로토타입, 의사 결정표, 수학적 표현 등 다양한 대안이 있다. 텍스트도 서술 단락, 글머리 기호 목록, 계층적으로 번호가 매겨진 문장, 표, 반복적인 텍스트를 피하는 구조화된 목록 등 다양한 형태를 취할 수 있다(Wiegers 2006). (104쪽)

실무 사례 #16 비즈니스 규칙을 식별하고 문서화한다
필자의 친구 제레미는 지역 혈액은행 웹사이트를 방문하여 당일 헌혈을 예약했다. 그러나 제레미가 혈액은행에 도착했을 때, 웹사이트에서는 당일 예약이 가능했지만 정작 혈액은행에서 당일 예약은 받지 않는다고 직원이 말했다. 그는 짜증이 났다.
제레미의 경험은 소프트웨어가 정해진 규칙을 제대로 시행하지 않거나 준수하지 않을 때 발생할 수 있는 문제를 잘 보여준다. 혈액은행에는 당일 예약 불가라는 정책이 있었지만, 예약 웹사이트의 설계자가 소프트웨어에서 이 정책을 준수하도록 만들지 않았다. 따라서 혈액은행 직원이 수동으로(그리고 불편하게) 정책을 시행해야 했다. (116쪽)