1부 소프트웨어 스펙이란?
1장 소프트웨어 스펙의 개요
1.1 소프트웨어 프로젝트 실패의 원인
1.2 스펙에 대한 오해
1.3 스펙의 역할
1.4 스펙을 제대로 작성하지 않으면
1.5 스펙과 프로젝트의 성공
2장 SRS
2.1 SRS란 무엇인가?
2.2 어떻게 소프트웨어를 빠르게 개발할 것인가?
2.3 스펙 문서의 유형
2.4 요구사항과 스펙의 차이
2.5 스펙 문서에 대한 착각
2.6 스펙인 것과 스펙이 아닌 것
2.7 스펙과 프로젝트 일정의 관계
2.8 스펙과 설계의 구분
3장 스펙 작성의 현주소, 현실과 관행
3.1 현재의 관행과 문제점
3.2 스펙에 대한 잘못된 통념
3.3 부실한 스펙 후 설계는 사상누각
3.4 시간만 있으면 누구나 스펙을 쓸 수 있는가?
3.5 소프트웨어 공학, 약인가? 독인가?
4장 사례 연구
4.1 A사의 해외 프로젝트_부실한 분석에 의한 계약
4.2 B사의 부품 교체_허술한 변경 관리
4.3 C사의 갑을 관계_고객의 의무 소홀
4.4 D사의 SI 수행_분석 역량 부족
4.5 E사의 소프트웨어 개발_있는 것은 소스코드뿐
4.6 F사의 공공 프로젝트_과도한 산출물
4.7 해외 사례_초기 분석 부실
5장 기업 문화
5.1 스펙과 기업 문화
5.2 잘 작성한 스펙의 혜택
5.3 좋은 관행 만들기
5.4 전사 아키텍처 전략을 선도하는 기술위원회
5.5 사수/부사수 시스템 탈피 방법
5.6 스펙을 제대로 작성하려면
6장 프로세스
6.1 소프트웨어 프로젝트의 개발 단계
6.2 스펙 작성 프로세스
6.3 SRS 관점으로 바라본 방법론 비교
6.4 스펙 작성에 시간을 얼마나 할애해야 하는가?
6.5 스펙은 얼마나 자세히 적어야 하는가?
6.6 스펙 리뷰
6.7 코드 리뷰보다는 설계 리뷰, 설계 리뷰보다는 스펙 리뷰
6.8 스펙과 베이스라인
6.9 스펙 변경 프로세스
6.10 종결된 프로젝트의 스펙, 업데이트할 것인가?
6.11 종
