이 책은 한 번 읽고 덮어둘 성격의 책이 아닙니다. 나름대로 책 꽂이에서 멋진 디자인을 뽐낼 수도 있겠지만, 매 프로젝트마다 순간순간 펼쳐볼 수 있도록 곁에 두셔야할 책입니다.
대학때 사부님께서는 개발자들이 요구사항은 하늘에서 뚝 떨어지는 것으로 생각하는 경향이 많다는 말씀을 늘 하셨습니다. 즉, 누군가 요구사항을 만들것이고 개발자들은 그 요구사항대로 구현하기만 하면 된다는 수동적인 생각을 가지고 있다는 것이지요.
그런데 한편 고객들은 어떤가요? 프로젝트를 발추하면서 수주측이 다 알아서 해줄 것으로 믿고(또는 당연히 그정도 일은 해야 한다는 것으로 생각하고) 수주측이 요구사항에 대해 질문이라도 할라치면, 왜 업무에 방해를 하는가. 혹은 차라리 내 두뇌를 스캐닝 해갔으면 좋겠다는 한탄을 늘어놓게 됩니다.
이런 상황속에서는 당연히 프로젝트가 실패하게 될 수 밖에 없겠죠. 누구의 잘못인가요? 고객과 개발자 모두의 잘못이지요. 고객은 프로젝트를 추진하면서 자신이 원하는 결과물을 얻기 위해 최선을 다하지 않았고, 개발자는 할 일만 하면 된다는 식의 수동적이고 방어적인 자세를 고수함으로써 고객이 원하는 것이 무엇인지는 신경을 쓰지 않았기 때문입니다.
책에서도 언급되어 있지만, 여러분이 고가의 디지털 카메라, 홈 시어터, 차, 집을 산다고 해봅시다. 얼마나 꼼꼼하게 따져보고 주변에 물어보나요? 얼마나 사기를 주저하게 되나요? 그런데 프로젝트가 일이십만원 하는 것도 아니고.. 적어도 그 정도의 노력은 기울여야 하지 않을까요? 뭐 그거야 회사 돈이니까.. 한다고 칩시다. 구축된 시스템이 자신들의 업무를 가중시키거나 오히려 불편함을 초래할 수도 있는데도 그렇게 두손 두발 다 놓고 있으실 건가요?
그리고 개발자 여러분들도 정말 죽어라 납기일에 맞춰 만든 시스템이 "어.. 우리가 원했던 시스템이 아니네?" 하면서 변경요청을 받거나, 시스템이 사용조차 되지 않는다면 얼마나 허탈하겠습니까? 고객과 프로젝트 수주자는 경쟁관계이거나 원수가 아니라 상호 보완적이고 협력관계라는 사실을 잊지 마십시오.
본문에서 Frederick Brooks의 "소프트웨어 시스템을 구축하는데 있어서 가장 어려운 한 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다"라고 했습니다. 요구사항을 개발하고 관리하는 것이 중요하지만 얼마나 어려운지를 말해주고 있지요. 저자는 이에 대해 "요구사항을 개발하고 관리하는 것은 매우 힘든 일이며, 지름길도 마술도 존재하지 않는다. 그렇지만 너무나도 많은 조직들이 같은 문제로 고생을 하고 있기 때문에, 다양한 상황에 적용할 수 있는 공통 기법을 찾을 수 있다."고 말합니다.
대부분의 소프트웨어 공학관련 책들이 살짝 언급만 하고 넘어가서 모호하기만 했던 요구사항 공학에 대해서, 이 책은 실증적인 사례와 Best Practice들을 설명하고 있습니다. 요구사항에 대한 갈증을 속 시원하게 풀어주는 오아시스와 같은 책이랄까요? 여러분들도 저와 같은 느낌을 받으실 수 있을 것입니다. 정말 멋진 책이군요.
이 책을 읽으신 후 적용 영역을 넓혀서 여자친구, 부모님의 요구사항은 무엇인지, 인생이라는 본인의 장기 프로젝트 기간동안 달성해야할 요구사항이 무엇인지에 대해서도 접목시켜 보시는 것은 어떨까요?
==============================================
이 책의 아쉬운점
1) 용어대역표가 없습니다.
번역서의 용어사전과도 같은 용어대역표가 이 책에는 없더군요. 인포북에서와 같이 대역표가 있었더라면, 번역서의 모호한 부분에 대하여 원문의 내용을 짐작할 수 있었을텐데 하는 아쉬움이 남습니다.
2) 참고문헌이 없습니다.
본문에서는 깊게 다룰 수 없는 주제에 대해서는 다른 저자의 논문이나 책을 언급하고 있습니다만, 원서의 Index 바로 앞에 있는 Reference 절이 빠져있어서 제 개인적으로는 매우 답답했습니다.
3) 아쉽게도 일부 번역상 용어의 일반성, 일관성이 꼼꼼하게 지켜지지 못했습니다.
요구사항 공학(Software Requirement Engineering)에서 강조하는, 분명하고 일관된 용어사용이 아쉽게도 이 책 내에서 잘 지켜지지 않고 있습니다.
- Use Case : "유스 케이스" (간혹 사용자 케이스, 사용 케이스로 번역되었죠)
- Test Case: "테스트 케이스" (테스크 케이스라고 되어있는 부분이 꽤 많습니다.)
- Chater : "권리장전" (차터와 권리장전이 혼용되고 있습니다.)
- TBD : "이후결정" (미정(p.39)과 이후결정(p.51)이 혼용되고 있습니다.)
- Function Point : "기능점수" (P.494에서는 기능점수, P.180에서는 기능포인트)
[개인적 선호용어]
- Object : "객체"로 번역하는 것이 일반화 되어있는데 "개체"로 하셨더군요.
- Actor : "액터"로 번역하는 것이 일반화 되어있는데 "담당자"로 하셨더군요.
- Baseline : "베이스라인" ('기본내용'으로 번역하셔서 감이 잘 안오더군요.)
- Finite State Machine: "유한상태기계" ('한정적 상태 시스템'으로 번역하셨더군요.)
4) 개인적으로 어색한 문장이나 오탈자
- P.58의 "지식" 영역의 두 번째 블릿을 이렇게 변경해 보았습니다.
==> 요구사항 공학에 대하여 사용자 대표와 매니저들을 교육
- P.113의 "주의!" 부분을 이렇게 수정해 보았습니다.
==> 실제 시스템의 사용자들에게 질문하지도 않고 소프트웨어 개발자나 사용자 관리자가 요구를 이미 잘 알고 있다고 하는 것에 주의한다.
- P.125의 "기본 규칙을 정한다"의 다섯번째 블릿을 이렇게 수정해 보았습니다.
==> 개인적인 의견이 아닌 문제/이슈에 대한 커멘트와 비판에 초점을 맞춘다.
- P.144의 [그림 8-3]의 <포함>은 UML 표기법에 따라 "<<포함>>" 이나 "<< include >>" 가 나았을 것 같습니다.
- P.169의 [표9-1] 바로 밑에 단락 밑에서 네번째줄 맨 오른쪽 "추리 지식"
==> P.168에서는 inferred knowledge를 "추측 지식"으로 번역하셨는데, 여기서는 "추리 지식" 으로 번역을 하셨더군요.
- P.175의 중간 세번째 블릿
==> "수학적으로 정확한 정규 논리 언어를 사용하여 요구사항을 정의하는 정규 명세(formal specification) 기법"
- P.176의 밑에서 세번째 블릿 오타
==> 고육자료 -> 교육자료
- P.177의 두번째 블릿: fully justified에 대한 오역
==> "텍스트를 완성하지 말고" -> "텍스트를 양쪽정렬하지 말고"
- P.215의 "준비 요청자", "지연 요청자"
* "준비 요청자" ==> "준비중 요청자"
: '준비중'만 bold 이고, 요청자는 일반 폰트여야 합니다. 편집 오류인 듯
* "지연 요청자"
: '지연'만 bold 이고, 요청자는 일반 폰트여야 합니다. 편집 오류인 듯
- P.215의 [그림 11-4] "주문"에서 "주문 대기" 상태전이에서 오타
==> "벤저"는 "벤더"가 되어야 하겠죠.
- P.225의 "마지막으로" 절의 두 번째 문장을 아래와 같이 수정해 보았습니다.
==> "이 모델들이 제공하는 관점이 중복되기 때문에 프로젝트에 대하여 모든 종류의 다이어그램을 만들 필요는 없다."
- P.239의 "주의!" 부분의 두 번째 문장을 아래와 같이 정정합니다. (오타인듯)
==> "검증이 불가능한 품질 특성은 검증이 불가능한 기능 요구사항이나 마찬가지다."
- P.295의 "유지보수 프로젝트의 요구하항" 절의 두번째 문장을 아래와 같이 수정해 보았습니다.
==> "연속 개발(ongoing development)이라고 부르는 유지보수는, 소프트웨어 기업의 자원 대부분을 소비하는 경우가 많다."
- P.297의 세번째 블릿
==> "현재의 시스템 테스트들이" -> "현재의 시스템 테스트 집합으로"
- P.318의 "요구사항에서 테스트로" 윗 문단의 중간부분에서 오타
==> "이런 문제가 많이 만나게 되면," -> "이런 문제를 많이 만나게 되면,"
- P.320의 두 번째 문단의 세번째 줄 오른편에서 오타
==> "수준이 이난 소프트웨어" -> "수준이 아닌 소프트웨어"
- P.342의 두 번째 문단의 네번째 줄 왼편에서 오타
==> "이후 버전에서 그 기근을" -> "이후 버전에서 그 기능을"
- P.345의 밑에서 두 번째 줄 오른쪽
==> "1.3절의 문서를 이해" -> "1.3절에는 문서를 이해"
- P.394의 [그림 22-1]의 오타
==> "사용자 문서 프로세서" -> "사용자 문서 프로세스"
- P.407 의 [그림 22-6] 윗 단락 세 번째 줄
==> "[그림 22-8]에 설명된 절차들은" ->"[그림 22-6]에 설명된 절차들은"
- P.465의 첫 번째 문장에서 오타
==> "커피주문 시스템" -> "카페주문 시스템"
: 다른 곳에서는 카페주문 시스템으로 하셨는데... 개인적으로는 "카페테리아" 가 끌리는군요.
- P.493의 밑에서 두 번째 용어
==> "관계 포함" -> "포함 관계"
: 뒤에 '확장 관계'도 있던데.. 왜 순서가 뒤바뀌었는지 모르겠네요. ^^
5) 잘못된 그림 (p.241의 [그림 12-1])
텍스트로 그림을 그렸더니 깨지네요..
http://wgshim.dreambear.net/softreq/fig12-1.txt 에서 보시면 되겠습니다.
6) 확인을 해봐야 할 부분들
- P.374 의 밑에서 두 번째 줄
==> "~에서 추적한다" -> "~에서 추적된다"
- P.382 의 첫 번째 줄
==> "비전과 변경을 관리" -> "버전과 변경을 관리"
- P.419 의 [그림 23-3]의 "완화계획"의 세번째 항목
==> "인간요소 컨설턴트"의 의미??
|
