이미 소장하고 있다면 판매해 보세요.
|
제1부 필수 요구사항 개념
제1장 요구사항 공학 개요 "요구사항" 정의 여러 가지 종류의 요구사항 비즈니스 요구사항 사용자 요구사항 기능 요구사항 시스템 요구사항 비즈니스 규칙 품질 속성 외부 인터페이스 제약사항 요구사항 공학 활동 전망 제2장 소프트웨어 요구사항에 대한 일반적인 진리 요구사항 실체 요구사항 이해 관계자 요구사항 명세 제2부 요구사항의 관리적인 관점 제3장 보다 나은 요구사항의 비즈니스 가치 아픈 곳을 얘기하세요 보다 나은 요구사항의 효과 투자 투자에 대한 효과 경제학 관점의 논쟁 제4장 요구사항을 얻는데 소요되는 기간 업계에 대한 벤치마크 자신만의 경험 점증적 접근 방법 요구사항 유도 계획하기 제5장 요구사항에 근거한 평가 평가의 몇 가지 기본 원칙 평가 접근 방법 평가가 목적은 아니다 요구사항으로부터 평가하기 소프트웨어 규모 측정 스토리 점수 유스케이스 점수 테스트 가능한 요구사항 평가의 현실 제3부 고객과의 상호작용 제6장 온-사이트 고객의 허구 사용자 계층과 제품 챔피언 대리 사용자 자 여기를 주목하세요 제7장 심문이 아니라 질문이다 먼저, 이런 질문은 피하라 비즈니스 요구사항 유도를 위한 질문들 사용자 요구사항과 유스케이스 사용자 요구사항 유도를 위한 질문 격식에 구애받지 않는 질문들 왜 이유를 묻는가 제8장 한 사람의 시각으로는 충분하지 않다 요구사항 검토에 대한 개선 제4부 유스케이스(Use Case) 제9장 유스케이스와 시나리오 그리고 스토리 유스케이스 시나리오 사용자 스토리 제10장 액터와 사용자 제11장 유스케이스로는 충분하지 않을 때 유스케이스의 능력 프로젝트 타입 한계 이벤트 응답표 유스케이스가 기능 요구사항을 대체하지 않는다 유스케이스는 기능 요구사항을 드러낸다 제5부 요구사항 작성 제12장 연결 문서 제13장 얼마나 상세하게 기술해야 하는가 누가 요구사항을 만드는가 요구사항이 더 상세해야 하는 경우 상세한 요구사항이 덜 적합한 경우 함축된 요구사항 상세 요구사항 수준에 대한 샘플 제14장 중복할 것인가, 중복하지 않을 것인가 상호참조 하이퍼링크 추적성 링크 권고 제15장 요구사항 스타일의 요소 필자가 요구사항이라고 생각하는 것 시스템 관점 또는 사용 관점 부모 및 자식 요구사항 뭐라고요? 다시 한 번 얘기해주시겠어요 복잡한 로직(Logic) 부정적인 요구사항 생략 경계 모호한 어법 피하기 제16장 요구사항과 설계 사이의 퍼지 라인 솔루션 아이디어와 설계 제약 솔루션 길잡이 제6부 요구사항 프로세스 제17장 프로젝트 범위 정의 비전과 범위 컨텍스트 다이어그램 유스케이스 다이어그램 특징 수준 은밀한 범위 확장 관리 제18장 모래 위에 그은 선 요구사항 베이스라인 베이스라인 결정 시기 제19장 여섯 명의 장님과 요구사항 자연 언어의 한계 요구사항에 관한 몇 가지 다른 관점 관점을 왜 다각화하는가 적절한 관점의 선택 다양한 관점들의 조화 제7부 요구사항 관리 제20장 다중 릴리즈를 위한 요구사항 다루기 단일 요구사항 명세 다중 요구사항 명세서 요구사항 관리 도구 제21장 비즈니스 요구사항과 비즈니스 규칙 비즈니스 요구사항 비즈니스 규칙 비즈니스 규칙과 소프트웨어 요구사항 제22장 요구사항 측정 제품 규모 요구사항 품질 요구사항 상태 변경 요청 노력 제23장 요구사항 관리 도구의 이용 먼저 좋은 요구사항을 작성하라 문화의 변화를 예상하라 데이터베이스 중심인지, 문서 중심 도구인지를 선택하라 너무 많은 요구사항 종류나 속성들을 만들지 말라 도구 사용자를 훈련시켜라 책임을 할당하라 도구 기능에 대한 이점을 취하라 찾아보기 |
|
이 책은 이전에 한국에서 번역 출판된 [소프트웨어 요구사항 2판]의 내용을 현장에서 다룰 때 부딪히는 까다로운 문제에 대한 실용적인 접근론을 다룬 이 분야의 또 다른 역작이라고 할 수 있다. 이 책을 읽는 독자들은 직접 코딩을 하는 개발자이거나 아니면 PL이나 PM으로서 소프트웨어 개발의 최상위 수준의 문제를 다루는 역할을 하고 있을 것이다. 만일 독자가 소프트웨어 개발 프로젝트의 출발선상에 서있고 이전에 어떤 개발 경험에서 소프트웨어 요구사항에서 심각한 고민을 한 적이 있다면 이 책에서 다루는 내용의 많은 부분을 공감할 것이다. 나름대로 요구사항을 잘 도출하고 관리해왔다고 생각하였지만 소프트웨어 개발 중반에 끝도 없는 요구사항이 쏟아지고 처음의 요구사항이 은밀하게 변경되고 확장되는 경험을 하고 있는 독자라면 과연 어디서 문제 해결의 실마리를 찾을 것인가 고민할 때 이 책이 그 길잡이 역할을 해줄 수 있을 것이라고 생각한다.
물론 단지 이 책이 현재 부딪히고 있는 모든 문제를 해결해 주지는 못한다. 중요한 것은 경험이고 그 보다 중요한 것은 경험을 향후의 생산성으로 연결하는 능력일 것이다. 잘 정의된 요구사항은 프로젝트가 성공하는데 있어서 필수 불가결한 사전 조건이다. 자금력이 항상 풍부하고 기간이 아주 넉넉한 프로젝트는 거의 없다. 실제 프로젝트가 시작되면 관리자는 일정과 비용이라는 양날의 칼을 들고 개발자와 분석가 그리고 테스터를 압박하기 시작하고 요구사항이 변경되거나 추가될 때 일정과 비용에 영향을 끼치지 않도록 사람이라는 자원을 가혹하게 사용하기 시작한다. 개발 방법론은 이상적이나 현실은 그렇지 않은 참담한 현실을 접한 개발자들은 의욕을 상실하고 점점 잘 실행되는(?) 소프트웨어만을 개발의 최종목표로 삼기 시작한다. 이제 여러분의 프로젝트 관리자는 그냥 그럭저럭 실행되는 소프트웨어를 납품하고 프로젝트는 성공적으로 종료될 것이다. 그 소프트웨어를 받아든 사용자는 기대감으로 이 소프트웨어를 사용하기 시작하고 이내 소프트웨어의 독선에 치를 떨게 될 것이다. 사용자를 무시하지 말고 사용자에 기만당하지 않으려면 여러분이 요구사항 개발 단계를 더 주의 깊게 살펴보아야 하고 관리자에게 그 시기가 얼마나 중요한지를 설득해야 한다. 눈앞에 보이는 이익을 쫓아 조금 후 닥칠 재난을 간과하지 않아야 하겠다. 이전에 [소프트웨어 요구사항 2판]을 읽고 현실에서 부딪히는 많은 문제들을 고민하였는데 이 책을 번역하면서 나의 그런 고민들을 간파한 저자의 뛰어난 통찰력에 다시 한 번 놀라게 되었다. 아무쪼록 이 책을 읽는 독자들이 소프트웨어 개발에서 요구사항과 관련한 문제의 실마리를 얻기 바란다. --- 역자 |