모든 사람 들 이 명세서 작업 을 해야 한다고 생각 은 하 지만 , 아무 도 명세서 작업 을 하 지 않 습니다 . 왜 명세서 작업 을 하 지 않 을까요 ? 명세서 작업 단계 를 건너뛰 면 시간 을 절약 할 수 있 다고 말 합니다 . 이런 사람 들 은 명세서 작성 작업 이 NASA 에서 우주 왕 복선 을 만드 는 공학 도 나 큰 규모 의 보험 회사 직원 에게 나 필요 한 사치 쯤 으로 치부 합니다 . 명세서 작업 을 하 지 않 는 관례 는 소프트웨어 프로젝트 에서 가장 크 고 불 필요 한 위험 요인 을 짊어지 는 행동 입니다 . 이 는 등 에 옷가지 만 을 걸친 다음 에 날기 를 기대 하 며 모하비 사막 을 건너 려고 출발 하 는 것 만큼 이나 바보 스럽 습니다 . 명세서 작업 을 생략 하 고 바로 코드 작성 으로 뛰어드 는 프로그래머 나 소프트웨어 개발자 는 스스로 를 허리춤 에서 순식간 에 총 을 뽑 는 멋진 총잡이 라고 생각 하 는 경향 이 있 습니다 . 하지만 결코 그렇 지 않 으며 , 이런 개발자 일수록 놀라 자빠질 정도 로 생산 성 이 낮 습니다 . 즉 , 형편 없 는 코드 를 작성 하 거나 조잡 한 소프트웨어 를 양산 하 며 , 결국 전혀 쓸데없 느 ㄴ 거대 한 위험 을 자초 해 프로젝트 를 위협 합니다 . 기능 명세 - FUNCTIONAL SPECIFICATION 완전히 사용 자 관점 에서 제품 이 어떻게 동작 할지 를 기술 합니다 . 어떻게 구현 했 는지 는 신경 도 쓰 지 않 습니다 . 기능 에 대해 이야기 하 고 , 화면 , 메뉴 , 대화 상자 와 같 은 사용 자 인터페이스 부품 을 명세 합니다 . 기술 명세 - TECHNICAL SPECIFICATION 프로그램 내부 구현 을 기술 합니다 . 자료 구조 와 관계 형 데이터베이스 모델 과 프로그래밍 언어 , 도구 , 알고리즘 선택 과 같 은 항목 을 다룹니다 . * 좋 은 기능 명세 에 대한 아이디어 ! 1 . 면책 조항 방어 적 인 내용 " 이 명세 는 완벽 하 지 않 습니다 . " 시간 이 흘러 명세 가 완벽 하 게 되 면 다음 과 같이 면책 조항 을 바꿀 수 있 다 . " 제 가 알 기 로 는 이 명세 는 거의 완벽 합니다 . 하지만 무언가 빠뜨렸 을 경우 에 는 제게 말씀 해 주 세요 " 2 . 저자 명세 는 1 명 이 전담 해서 작성 해야 만 합니다 . 큰 제품 일 경우 라면 , 여러 부문 으로 쪼갠 다음 에 각각 을 개인 에게 할당 해서 독자 적 으로 명세 하 게 합니다 . 어떤 회사 는 명세 에 이름 을 넣 어서 개인 의 공로 를 인정 하 는 관례 를 이기 적 인 행동 이나 팀워크 를 해치 는 일 이 라고 생각 합니다 . 하지만 이 는 허튼 소리 입니다 . 사람 들 은 자신 이 명세 한 사항 에 대해 책임감 과 소유 의식 을 느껴야 합니다 . 명세 에서 무언가 잘못 되 면 , 이 를 수정 할 책임 이 있 는 명세서 소유자 를 지정 해야 하 며 이 사람 이름 이 바로 명세서 에 찍혀 있 어야 합니다 . 3 . 시나리오 생생 하 고 현실 적 인 시나리오 를 만들 수록 , 실 사용자 나 가상 으로 창조 한 사용 자 모두 를 위한 제품 을 더 잘 만들 수 있 습니다 . 4 . 회피 목표 팀 단위 로 제품 을 만들 때 없 으면 못 살 겠 다는 이유 만 으로 실제 든 상상 이 든 간 에 각자 좋 아 하 는 상큼 한 기능 을 넣 으려는 경향 이 있 습니다 . 이렇게 불 필요 한 기능 을 쳐 내 는 가장 좋 은 방법 으로 명세 에 회피 목표 항목 을 추가 합니다 . 5 . 개괄 개괄 은 명세 를 위한 목차 와 유사 합니다 . 개괄 은 간단 한 흐름 도 이거 나 광범위 한 아키 텍 쳐 관점 에서 본 토론 일 수 도 있 습니다 . 모든 사람 이 숲 을 보 기 위해 목차 를 읽 습니다 . 이렇게 해야 나무 도 의미 가 있 을 것 입니다 . 6 . 세부 사항 웹 타입 서비스 를 설계 할 때 세부 사항 을 정리 하 는 좋 은 방법 은 , 모든 가능 한 화면 에 기준 이 되 는 이름 을 붙인 다음 , 너무나 도 자세 해 못 견딜 만큼 따분 한 세부 사항 을 매 화면 마다 기술 하 는 장 을 제공 하 는 겁니다 . 세부 사항 은 기능 명세 에서 가장 중요 한 핵심 입니다 . 7 . 미해결 문제 명세 첫 버전 에 미해결 문제 를 남겨 놓 아도 나쁘 지 않 습니다 . 문제점 을 쉽 게 찾 을 수 있 도록 특별 한 스타일 을 적용 해서 표시 를 하 고 , 적당 한 대안 이 있 으면 이 를 논의 합니다 . 프로그래머 가 작업 을 시작 할 무렵 에 이런 모든 미해결 사항 들 을 짚 어 놔야 합니다 . 단순히 프로그래머 가 모든 쉬운 작업 부터 시작 하 도록 내 버려 두 고 , 나중 에 미 해결 문제 를 푸 는 방법 이 옳 다고 생각 할지 도 모르 겠 습니다 . 하지만 , 이 는 잘못 된 생각 입니다 . 프로그래머 가 코드 를 구현 하 려고 시도 할 무렵 에 나타나 는 새로운 문제점 과 씨름 하 는 과정 에서 또 다른 문제점 이 나타날 것 이 며 , 당신 이 미리 알 고 있 었 으며 , 예전 에 끝 냇 어야 하 는 미해결 문제 역시 그대로 남 아 있 을 것 입니다 . 설상 가상 으로 난이 도 높 은 문제 를 해결 하 는 과정 이 코드 를 작성 하 는 방법 에 도 상당 한 영향 을 미칠지 도 모르 겠 습니다 . 8 . 방주 ( SIDE NOTE ) 명세 를 작성 하 는 동안 에 프로그래머 , 테스터 , 마케팅 팀원 , 기술 집 필가 와 같 은 다양 한 청중 이 있 음 을 기억 해야 합니다 . 명세 를 작성 할 때 단지 특정 그룹 에 만 유용 한 활자 화 한 사실 을 고려 하 면 좋 겠 습니다 . 예 를 들 어 프로그래머 를 위해 기술 적 으로 유용 한 몇 가지 세부 사항 을 기술 하 는 메시지 를 ' 기술 노트 ' 항목 으로 구분 해서 기록 할 수 있 습니다 . 마케팅 팀원 은 이런 메시지 를 무시 하 지만 프로그래머 는 이런 메시지 를 탐독 합니다 . 9 . 명세 는 지속 적 으로 개정 해야 합니다 . 주기 적 으로 개정 하 여 현실 을 반영 합니다 . 명세 는 항상 제품 이 동작 하 는 원리 를 최대 로 반영 하 는 그림자 입니다 . 명세 는 단지 제품 이 코드 완료시 점 에서 굳어질 따름 입니다 . * 명세서 작성 팁 1 . 재미있 게 씁시다 . 여러분 이 작성 한 명세 가 유쾌 하 며 재미있 고 읽 기 쉽 다는 이유 로 당신 을 얕보 는 회사 에 근무 한다면 , 어서 다른 회사 를 찾 는 게 낫 습니다 . 2 . 명세 를 쓰 는 작업 은 머리 가 돌아가 도록 코드 를 쓰 는 작업 과 유사 하 다 . 문서 를 소개 하 려는 대상 층 을 감안 하 고 , 단계 마다 그 사람 이 무엇 을 이해 하 길 바라 는지 먼저 상각 해 보 세요 . 문장 마다 독자 가 내용 을 깊이 이해 했 을지 , 문맥 의 의미 는 파악 했 는지 스스로 되물 어 보 십시오 . 그래야 명세 를 읽 는 높 으신 분 께서 수많 은 기술 용어 에 압도 당해 처음 부터 문서 읽 기 를 포기 하 거나 멈추 지 않 게 될 겁니다 . 3 . 최대한 단순 하 게 작성 하 라 . 쉬운 문장 으로 작성 하 는 방식 은 왠지 프로 답 지 않 다는 생각 에 , 형식 적 이 며 현학 적 인 언어 를 남발 하 지 는 마세요 . 가능 한 가장 쉬운 언어 를 사용 해야 합니다 . 실제 화면 보다 명세서 를 더 효과 적 으로 개선 하 는 방법 은 없 습니다 . 그림 은 천 마디 말 보다 낫 습니다 . 4 . 여러 차례 에 걸쳐 검토 하 고 다시 읽 어라 . 5 . 표준 양식 은 해 롭 다고 간주 한다 . 모든 명세 는 일정 한 형식 을 갖춰야 한다 라는 생각 은 버리 십시오 . - 출처 - 조엘 온 소프트웨어 - 출처 : https : / / elky . tistory . com / 598 [ 엘키 의 주절 주절 ] 공유 하 기 글 요소