프로젝트가 실패하지 않는 답은 소프트웨어 스펙 작성에 있다 소프트웨어 스펙(SRS)은 시작이고 기준이다. 스펙을 제대로 작성하는 것은 프로젝트의 성패를 가를 만큼 중요하다. 스펙을 잘 작성하기 위해서는 개발 문화, 관행, 습관, 프로세스, 원리, 원칙을 알고 접근해야 하며 실전을 통한 노하우 축적이 필요하다. 이 책은 저자들의 수많은 경험을 토대로 여러 유관 분야 이론을 망라하고 스펙 작성 요령을 제시한다. ‘스펙 작성’의 진짜 의미가 무엇인지 이 책을 통해 알아보길 바란다.
소프트웨어 컨설팅 회사인 ABC Tech의 대표이며 카이스트 겸직교수로 「소프트웨어 전문가 과정」을 맡고 있다. 경기고등학교, 서울대학교 공과대학을 졸업했고 미국 산호세 캘리포니아 주립대학에서 전산학 학사, 스탠포드대학에서 전산학 석사를 취득했다. 미국 실리콘밸리의 GE, Sun Microsystems 등에서 약 16년간 소프트웨어 실무경력을 쌓고 세계 150여 개 기업에 인터넷 통합 메시지 솔루션을 제공하는 '스탠포드 소프트웨어(Stanford Software Corp, USA)'를 설립, 제품을 개발하고 회사를 운영했다. 2000년 한국으로 돌아와 소프트웨어 분야 컨설턴트로, '안철수연구소'의 부사장 및 최고기술경영자(CTO)로 근무했다. 저서로 『대한민국에는 소프트웨어가 없다』, 『소프트웨어 개발의 모든 것』, 『글로벌 소프트웨어를 꿈꾸다』, 『글로벌 소프트웨어를 말하다, 지혜』를 집필하고 『세상을 바꾼 32개의 통찰』을 번역했으며, 소프트웨어 공학 블로그 ikwisdom.com을 운영한다.
1부 소프트웨어 스펙이란?1장 소프트웨어 스펙의 개요1.1 소프트웨어 프로젝트 실패의 원인 1.2 스펙에 대한 오해 1.3 스펙의 역할1.4 스펙을 제대로 작성하지 않으면1.5 스펙과 프로젝트의 성공2장 SRS2.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 종결된 프로젝트의 스펙 일부 삭제6.12 대형 프로젝트 분석의 협업7장 Who?7.1 스펙은 누가 쓰는가?7.2 분석 아키텍트의 역할7.3 분석 아키텍트의 자질7.4 소프트웨어 개발자는 글을 잘 써야 한다7.5 문서 작성 기술7.6 시뮬레이션 능력7.7 문제 해결 능력7.8 프로젝트 이해관계자8장 What?8.1 why, what, how8.2 목표와 범위 정의하기8.3 요구사항에 우선순위 부여하기8.4 외주 시 외주 업체에 전달할 문서는?8.5 스펙 체크리스트의 효용성9장 How?9.1 스펙의 재료9.2 스펙 가독성 높이기9.3 문장 바르게 쓰기9.4 스펙 작성 팁9.5 스펙 재사용하기9.6 소스코드로 스펙 작성하기9.7 유닛 테스트로 스펙 작성하기9.8 중복 최소화하기9.9 품질 특성 명시하기9.10 프로토타입 만들기9.11 스펙을 적기 위해서는 why를 알아야 한다9.12 훔쳐보기는 이제 그만9.13 인터페이스 개선하기9.14 인터페이스 정의하기10장 도구10.1 SRS 작성을 돕는 도구10.2 UI 작성 방법10.3 스펙 문서의 템플릿2부 SRS 작성법 1장 Introduction(개요)1.1 Purpose(목표)1.2 Product Scope(범위)1.3 Document Conventions(문서 규칙)1.4 Terms and Abbreviations(정의 및 약어)1.5 Related Documents(관련 문서)1.6 Intended Audience and Reading Suggestions(대상 및 읽는 방법)1.7 Project Output(프로젝트 산출물)2장 Overall Description(전체 설명)2.1 Product Perspective(제품 조망)2.2 Overall System Configuration(전체 시스템 구성)2.3 Overall Operation(전체 동작방식)2.4 Product Functions(제품 주요 기능)2.5 User Classes and Characteristics(사용자 계층과 특징)2.6 Assumptions and Dependencies(가정과 종속관계)2.7 Apportioning of Requirements(단계별 요구사항)2.8 Backward Compatibility(하위 호환성)3장 Environment(환경)3.1 Operating Environment(운영 환경)3.2 Product Installation and Configuration(제품 설치 및 설정)3.3 Distribution Environment(배포 환경)3.4 Development Environment(개발 환경)3.5 Test Environment(테스트 환경)3.6 Configuration Management(형상 관리)3.7 Bugtrack System(버그트래킹 시스템)4장 External Interface Requirements(외부 인터페이스 요구사항)4.1 System Interface(시스템 인터페이스)4.2 User Interface(사용자 인터페이스)4.3 Hardware Interface(하드웨어 인터페이스)4.4 Software Interface(소프트웨어 인터페이스)4.5 Communication Interface(통신 인터페이스)5장 Performance Requirements(성능 요구사항)5.1 Throughput(작업 처리량)5.2 Concurrent Session(동시 세션)5.3 Response Time(대응 시간)5.4 Performance Dependency(성능 종속관계)5.5 Other Performance Requirements(그 외 성능 요구사항)6장 Non-functional Requirements(비기능 요구사항)6.1 Safety(안전성 요구사항)6.2 Security(보안 요구사항)6.3 System Attributes(소프트웨어 시스템 특성)6.4 Logical Database Requirements(데이터베이스 요구사항)6.5 Business Rules(비즈니스 규칙)6.6 Design and Implementation Constraints(설계와 구현 제한사항)6.7 Memory Constraints(메모리 제한사항)6.8 Operations(운영 요구사항)6.9 Site Adaptation Requirements(사이트 적용 요구사항)6.10 Internationalization Requirements(다국어 지원 요구사항)6.11 Unicode Support(유니코드 지원)6.12 64bit Support(64비트 지원)6.13 Certification(제품 인증)7장 Functional Requirements(기능 요구사항)8장 Change Management Process(변경 관리 프로세스)9장 Document Approvals(최종 승인자)
