음성 검색
QR/바코드 검색
품목정보
| 발행일 | 2024년 03월 06일 |
|---|---|
| 쪽수, 무게, 크기 | 192쪽 | 188*245*12mm |
| ISBN13 | 9791192987699 |
소프트웨어 요구사항의 정수
: 20개의 실무 사례로 알려주는 요구사항 개발의 핵심 지식과 실전 경험
칼 위거스,캔디스 호캔슨 저 / 심재철 역
|
제이펍
|
2024년 03월 06일
저자/출판사 더보기/감추기
- 컴퓨터 공학 top100 1주
eBook이 출간되면 알려드립니다.
eBook 출간 알림 신청
분철서비스 시작 시 알려드립니다.
분철서비스 알림신청
- 원서이동
- 이미 소장하고 있다면 판매해 보세요! 이 상품 팔기 매입가 3,300원 더보기/감추기
- 국내배송만 가능
- 최저가 보상
- 문화비소득공제 신청가능
.jpg)
관련분류
카드 뉴스로 보는 책
책소개 책소개 보이기/감추기
상품 이미지를 확대해서 볼 수 있습니다.
원본 이미지
목차 목차 보이기/감추기
상세 이미지 상세 이미지 보이기/감추기
상품 이미지를 확대해서 볼 수 있습니다.
원본 이미지
저자 소개 (3명)
책 속으로 책속으로 보이기/감추기
실무 사례 #11 요구사항 모델을 작성한다
요구사항 지식을 표현하는 데 텍스트가 유일한 방법은 아니며, 때로는 최선의 방법도 아니다. 무수한 세부 사항 속에서 길을 잃고 큰 그림을 놓치거나 오류를 간과하기 쉽다. 시각적 요구사항 모델인 다이어그램은 문서화된 해결책 요구사항과는 다른 관점에서 요구사항 정보를 살펴볼 수 있는 좋은 방법을 제공한다. 강력한 요구사항 모델들을 만들면 BA가 상위 수준의 정보를 빠르게 반복 처리할 수 있으므로 보다 정확한 세부 요구사항으로 이어지는 통찰력을 부여해준다. 또한 현재 현실을 반영하기 위해 제품이 변경되면 모델을 쉽게 업데이트할 수 있으며, 이는 반복적인 프로젝트에서 특히 유용하다. 요구사항 모델링에 대한 숙련도는 필수적인 BA 기술이다(Wiegers, n.d.). 모델은 여러 가지 방법으로 요구사항 분석을 지원한다.
--- p.81
실무 사례 #12 프로토타입을 만들고 평가한다
이상적으로는 비즈니스 분석가가 사용자에게 필요한 것이 무엇인지 간단히 물어본 다음 요구사항 명세에 답변을 기록할 수 있다. 하지만 현실에서는 사용자가 “필요한 것이 무엇인지 말할 수는 없지만, 직접 보면 알 수 있을 겁니다I’ll know it when I see it, IKIWISI”라고 대답할 가능성이 더 높다. 두문자어인 IKIWISI는 개념, 텍스트 및 다이어그램의 모음으로만 요구사항을 탐색하는 데 따르는 어려움을 인정한다. 실무 사례 #11, “요구사항 모델을 작성한다”의 스트로맨 모델에서 보았듯이, 사람들은 새로운 것을 만들고 설명하는 것보다 눈앞에 놓인 것을 비평하는 것이 더 쉽다고 생각한다.
--- p.88
실무 사례 #14 일관된 방법으로 요구사항을 작성한다
‘요구사항 작성’이라는 문구를 볼 때마다 ‘요구사항 지식 표현’으로 바꾸어 생각하자. 자연어 텍스트는 사람들이 일반적으로 의사 소통하는 방식이기 때문에 소프트웨어 요구사항을 기록하는 데 가장 많이 사용되는 방법일 것이다. 하지만 시각적 모델(다이어그램), 테스트 코드, 설계 화면, 프로토타입, 의사 결정표, 수학적 표현 등 다양한 대안이 있다. 텍스트도 서술 단락, 글머리 기호 목록, 계층적으로 번호가 매겨진 문장, 표, 반복적인 텍스트를 피하는 구조화된 목록 등 다양한 형태를 취할 수 있다(Wiegers 2006).
--- p.104
실무 사례 #16 비즈니스 규칙을 식별하고 문서화한다
필자의 친구 제레미는 지역 혈액은행 웹사이트를 방문하여 당일 헌혈을 예약했다. 그러나 제레미가 혈액은행에 도착했을 때, 웹사이트에서는 당일 예약이 가능했지만 정작 혈액은행에서 당일 예약은 받지 않는다고 직원이 말했다. 그는 짜증이 났다. 제레미의 경험은 소프트웨어가 정해진 규칙을 제대로 시행하지 않거나 준수하지 않을 때 발생할 수 있는 문제를 잘 보여준다. 혈액은행에는 당일 예약 불가라는 정책이 있었지만, 예약 웹사이트의 설계자가 소프트웨어에서 이 정책을 준수하도록 만들지 않았다. 따라서 혈액은행 직원이 수동으로(그리고 불편하게) 정책을 시행해야 했다.
요구사항 지식을 표현하는 데 텍스트가 유일한 방법은 아니며, 때로는 최선의 방법도 아니다. 무수한 세부 사항 속에서 길을 잃고 큰 그림을 놓치거나 오류를 간과하기 쉽다. 시각적 요구사항 모델인 다이어그램은 문서화된 해결책 요구사항과는 다른 관점에서 요구사항 정보를 살펴볼 수 있는 좋은 방법을 제공한다. 강력한 요구사항 모델들을 만들면 BA가 상위 수준의 정보를 빠르게 반복 처리할 수 있으므로 보다 정확한 세부 요구사항으로 이어지는 통찰력을 부여해준다. 또한 현재 현실을 반영하기 위해 제품이 변경되면 모델을 쉽게 업데이트할 수 있으며, 이는 반복적인 프로젝트에서 특히 유용하다. 요구사항 모델링에 대한 숙련도는 필수적인 BA 기술이다(Wiegers, n.d.). 모델은 여러 가지 방법으로 요구사항 분석을 지원한다.
--- p.81
실무 사례 #12 프로토타입을 만들고 평가한다
이상적으로는 비즈니스 분석가가 사용자에게 필요한 것이 무엇인지 간단히 물어본 다음 요구사항 명세에 답변을 기록할 수 있다. 하지만 현실에서는 사용자가 “필요한 것이 무엇인지 말할 수는 없지만, 직접 보면 알 수 있을 겁니다I’ll know it when I see it, IKIWISI”라고 대답할 가능성이 더 높다. 두문자어인 IKIWISI는 개념, 텍스트 및 다이어그램의 모음으로만 요구사항을 탐색하는 데 따르는 어려움을 인정한다. 실무 사례 #11, “요구사항 모델을 작성한다”의 스트로맨 모델에서 보았듯이, 사람들은 새로운 것을 만들고 설명하는 것보다 눈앞에 놓인 것을 비평하는 것이 더 쉽다고 생각한다.
--- p.88
실무 사례 #14 일관된 방법으로 요구사항을 작성한다
‘요구사항 작성’이라는 문구를 볼 때마다 ‘요구사항 지식 표현’으로 바꾸어 생각하자. 자연어 텍스트는 사람들이 일반적으로 의사 소통하는 방식이기 때문에 소프트웨어 요구사항을 기록하는 데 가장 많이 사용되는 방법일 것이다. 하지만 시각적 모델(다이어그램), 테스트 코드, 설계 화면, 프로토타입, 의사 결정표, 수학적 표현 등 다양한 대안이 있다. 텍스트도 서술 단락, 글머리 기호 목록, 계층적으로 번호가 매겨진 문장, 표, 반복적인 텍스트를 피하는 구조화된 목록 등 다양한 형태를 취할 수 있다(Wiegers 2006).
--- p.104
실무 사례 #16 비즈니스 규칙을 식별하고 문서화한다
필자의 친구 제레미는 지역 혈액은행 웹사이트를 방문하여 당일 헌혈을 예약했다. 그러나 제레미가 혈액은행에 도착했을 때, 웹사이트에서는 당일 예약이 가능했지만 정작 혈액은행에서 당일 예약은 받지 않는다고 직원이 말했다. 그는 짜증이 났다. 제레미의 경험은 소프트웨어가 정해진 규칙을 제대로 시행하지 않거나 준수하지 않을 때 발생할 수 있는 문제를 잘 보여준다. 혈액은행에는 당일 예약 불가라는 정책이 있었지만, 예약 웹사이트의 설계자가 소프트웨어에서 이 정책을 준수하도록 만들지 않았다. 따라서 혈액은행 직원이 수동으로(그리고 불편하게) 정책을 시행해야 했다.
--- p.116
출판사 리뷰 출판사 리뷰 보이기/감추기
추천평 추천평 보이기/감추기
다이아몬드는 엄청난 양의 탄소 원자가 압축될 때 만들어지며, 압축이 결정화되어 다이아몬드를 형성한다. 칼과 캔디스도 이와 비슷한 일을 해냈는데, 방대한 요구사항 지식을 ‘핵심 실무 사례’라고 부르는 20가지 보석으로 압축했다. 이러한 실무 사례는 모든 이에게 사용을 권장할 만큼 매우 유용하다.
- James Robertson (《Mastering the Requirements Process》의 저자)
요구사항 공학 분야에서 최근 10년간 가장 많이 판매된 10종을 읽어보았는데, 이 한 권의 책에는 그 10종의 책을 합친 것보다 더 유용한 정보가 간결하게 담겨 있다. 그때 ‘이 책을 참고했더라면 좋았을 텐데!’ 하는 아쉬움이 남는다.
- Mike Cohn (《사용자 스토리》의 저자이자 Scrum Alliance 공동 창립자)
이 책은 주요 비즈니스 분석의 실무 사례에 대해 접근하기 쉽고, 명확하게 작성되어, 잘 정리된 내용을 원하는 초보 및 숙련된 비즈니스 분석가 모두에게 매우 유용한 자원이다. 칼과 캔디스는 비즈니스 분석 프로세스에 통합하여 더 효과적으로 만들 수 있는 간단한 실무 사례들로 복잡한 기능을 분류하는 데 탁월한 능력을 발휘했다.
- Laura Brandenburg (《How to Start a Business Analyst Career》의 저자)
이 책은 실용적인 조언과 훌륭한 예시, 그리고 소프트웨어 제품을 구축하는 사람들이 현실에서 직면하는 어려운 질문에 대한 답변으로 가득 차서 유용하고 접근하기 쉬우며 명료하다. 어떤 역할로든 소프트웨어 구축에 관여하는 사람이라면, 이 책을 통해 제품이 고객의 요구를 충족하고 진정한 가치를 제공할 수 있도록 하는 방법에 대한 지침을 얻을 수 있을 것이다.
- Shane Hastie (SoftEd의 글로벌 딜리버리 책임자이자 InfoQ.com의 ‘문화 및 방법’ 수석 편집자)
칼과 캔디스는 전통적인 BA 접근 방식과 애자일 소프트웨어 개발자를 위해 사용자 스토리를 정의하는 BA 방식 모두에게 적용할 수 있는 많은 실무 사례로 이 책을 ‘애자일’하게 만들었다. 《소프트웨어 요구사항의 정수》는 칼이 수년 동안 우리에게 제공한 모든 훌륭한 조언과 충고를 이 한 권의 책에 요약해 놓았다. 내가 이 책을 썼더라면 좋았을 텐데…
- Steve Blais (《Business Analysis: Best Practices for Success》의 저자이자 《Business Analysis for Practitioners》의 공동 저자)
회원리뷰 (5건) 회원리뷰 이동
한줄평 (0건) 한줄평 이동
첫번째 한줄평을 남겨주세요.
배송/반품/교환 안내
배송 안내
| 배송 구분 |
예스24 배송
|
|---|---|
| 포장 안내 |
안전하고 정확한 포장을 위해 CCTV를 설치하여 운영하고 있습니다. 고객님께 배송되는 모든 상품을 CCTV로 녹화하고 있으며, 철저한 모니터링을 통해 작업 과정에 문제가 없도록 최선을 다 하겠습니다.
목적 : 안전한 포장 관리 |
반품/교환 안내
상품 설명에 반품/교환과 관련한 안내가 있는경우 아래 내용보다 우선합니다. (업체 사정에 따라 달라질 수 있습니다)
| 반품/교환 방법 |
|
|---|---|
| 반품/교환 가능기간 |
|
| 반품/교환 비용 |
|
| 반품/교환 불가사유 |
|
| 소비자 피해보상 |
|
| 환불 지연에 따른 배상 |
|
.jpg)
