스펙에 있어서는 안될 표현들
2011/06/20 19:06 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
필자는 여러 개발자들이 작성해 놓은 스펙문서를 볼 기회가 많다. 대부분 99.9% 스펙이라고 하기에는 내용적으로 부족하고 리뷰도 부족한 문서들이지만 우선 각 문장을 하나씩 보다라도 고쳐할 부분이 매우 많다.
스펙(SRS)은 작성을 하고나면 이를 토대로 비즈니스도 하고 설계/구현도 하고 테스트팀은 테스트를 준비한다. 따라서 각 내용은 매우 정확하게 적어야 하며 두루뭉실하게 적으면 안된다. 하지만 정확한 표현을 하는 습관을 가지고 있지 않은 거의 대부분의 개발자들은 무심코 대충 작성을 하게 된다. 이는 수많은 오해를 유발해서 재작업과 품질 저하를 초래한다.
사실 원칙은 간단하다. 오해를 불러일으키지 않게 정확하게 작성해야 하고 범위를 구체적으로 명시해야 한다. 또한 정량적인 테스트가 가능하도록 설명해야 한다. 비즈니스 관련된 부분은 예외이다.
그럼 스펙을 작성할 때 피해야 할 표현들에는 어떤 것이 있나 알아보자.
SMTP를 지원해야 하다.
지원한다는 말은 대단히 모호한 표현이다. 지원해야 하는 범위를 아주 구체적으로 기술해야 한다.
1~5의 값을 가진다.
1,2,3,4,5인지? 1,3,5인지? 1~5의 float값인지? 그 정밀도와 가질 수 있는 값을 정확하게 기술해야 한다.
데이터를 효율적으로 저장해야 한다.
효율적이라는 표현은 모호한 단어로서 피해야 한다. 메모리나 CPU 자원 대비 효율적인지, Storage 용량을 적게 차지해야 하는지, 성능이 중요한지 구체적으로 적어야 한다. 또한 정확하게 요구되는 수준을 수치로 표시하는 것이 좋다.
사과, 배, 복숭아 등등을 지원해야 한다.
등등은 사용해서는 안된다. 지원해야 하는 모든 항목을 다 나열해야 한다.
기존의 값과 동일하다.
기존이 무엇인지 구체적으로 명시를 하고 해당 문서가 있으면 Link를 걸어줘야 한다.
충분한 메모리를 할당해야 한다.
충분하다는 것이 정확하게 얼마인지를 명시해야 한다.
사용자에게 친숙한 화면을 제공해야 한다.
어떠한 사용자가 친숙함을 느끼기 위해서 제공해야 하는 정확한 요구를 구체적으로 설명해야 한다.
일반적인 조건을 모두 만족해야 한다.
일반적인 조건을 구체적으로 기술해야 한다. 또한 일반적이지 않은 상황에서 시스템이 어떻게 되는지도 설명이 되어야 한다.
필요한 경우 메모리를 추가로 할당한다.
필요한 경우를 정확하게 판단할 수 있는 조건을 구체적으로 설명해야 한다. 수치가 나오면 좋다.
이외에도 수많은 표현들이 있다. 개발자라면 적어도 개발문서에서 이런 표현들이 나오지 않도록 항상 조심하는 습관을 갖는 것이 좋겠다. 이것도 하루아침에 이뤄지지 않는다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by churl
RSS Feed
필자는 여러 개발자들이 작성해 놓은 스펙문서를 볼 기회가 많다. 대부분 99.9% 스펙이라고 하기에는 내용적으로 부족하고 리뷰도 부족한 문서들이지만 우선 각 문장을 하나씩 보다라도 고쳐할 부분이 매우 많다.
스펙(SRS)은 작성을 하고나면 이를 토대로 비즈니스도 하고 설계/구현도 하고 테스트팀은 테스트를 준비한다. 따라서 각 내용은 매우 정확하게 적어야 하며 두루뭉실하게 적으면 안된다. 하지만 정확한 표현을 하는 습관을 가지고 있지 않은 거의 대부분의 개발자들은 무심코 대충 작성을 하게 된다. 이는 수많은 오해를 유발해서 재작업과 품질 저하를 초래한다.
사실 원칙은 간단하다. 오해를 불러일으키지 않게 정확하게 작성해야 하고 범위를 구체적으로 명시해야 한다. 또한 정량적인 테스트가 가능하도록 설명해야 한다. 비즈니스 관련된 부분은 예외이다.
그럼 스펙을 작성할 때 피해야 할 표현들에는 어떤 것이 있나 알아보자.
SMTP를 지원해야 하다.
지원한다는 말은 대단히 모호한 표현이다. 지원해야 하는 범위를 아주 구체적으로 기술해야 한다.
1~5의 값을 가진다.
1,2,3,4,5인지? 1,3,5인지? 1~5의 float값인지? 그 정밀도와 가질 수 있는 값을 정확하게 기술해야 한다.
데이터를 효율적으로 저장해야 한다.
효율적이라는 표현은 모호한 단어로서 피해야 한다. 메모리나 CPU 자원 대비 효율적인지, Storage 용량을 적게 차지해야 하는지, 성능이 중요한지 구체적으로 적어야 한다. 또한 정확하게 요구되는 수준을 수치로 표시하는 것이 좋다.
사과, 배, 복숭아 등등을 지원해야 한다.
등등은 사용해서는 안된다. 지원해야 하는 모든 항목을 다 나열해야 한다.
기존의 값과 동일하다.
기존이 무엇인지 구체적으로 명시를 하고 해당 문서가 있으면 Link를 걸어줘야 한다.
충분한 메모리를 할당해야 한다.
충분하다는 것이 정확하게 얼마인지를 명시해야 한다.
사용자에게 친숙한 화면을 제공해야 한다.
어떠한 사용자가 친숙함을 느끼기 위해서 제공해야 하는 정확한 요구를 구체적으로 설명해야 한다.
일반적인 조건을 모두 만족해야 한다.
일반적인 조건을 구체적으로 기술해야 한다. 또한 일반적이지 않은 상황에서 시스템이 어떻게 되는지도 설명이 되어야 한다.
필요한 경우 메모리를 추가로 할당한다.
필요한 경우를 정확하게 판단할 수 있는 조건을 구체적으로 설명해야 한다. 수치가 나오면 좋다.
이외에도 수많은 표현들이 있다. 개발자라면 적어도 개발문서에서 이런 표현들이 나오지 않도록 항상 조심하는 습관을 갖는 것이 좋겠다. 이것도 하루아침에 이뤄지지 않는다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by churl
'프로젝트 > 요구사항분석' 카테고리의 다른 글
| 프로토타입을 재활용하면 될까? 안될까? (5) | 2011/11/14 |
|---|---|
| 프로토타입이란? (8) | 2011/11/03 |
| 스펙에 있어서는 안될 표현들 (8) | 2011/06/20 |
| 개발문서를 만들기는 했는데 업데이트가 안되는 이유 (16) | 2010/03/24 |
| SRS에 대한 인식의 변화 (10) | 2009/11/13 |
| 이건 기능이 아닌데 (4) | 2009/08/03 |
Trackback Address: http://allofsoftware.net/trackback/225
모호한 표현을 피하고 구체적으로 기술해야 된다가 핵심이군요. 두 번 물어보게 만들지 않게 한다도 통하는 말일듯 해요.
안녕하세요. M님
습관이 중요합니다.
글 내용에도 있지만, Business Logic에 해당하는 부분은 열외이기는 하지만, 기술적인 부분과 섞여 있을 때가 난감합니다. 보통의 경우 SRS를 확정지으려고 하지 않고, 자꾸 뒤로 미루는 경우가 많거든요.
개발자들도, 실제 개발에 쓰는 용어와 고객과의 대화시에 쓰는 용어를 구별해서 썼으면 좋겠는데... 개발할 때 두리뭉실 하는 경우가 많네요. 이러면 안되는데...
또한가지 개발자들이 자주 놓치는 부분이 "단위" 표기 입니다. 시간인지 분인지, Kg인지 g 인지 등등 이 점이 굉장히 중요하다고 생각하는데, 의외로 많이들 놓치더군요.
디밥님 안녕하세요.
개발자들은 결정을 하지 않고 자꾸 뒤로 미루려는 성향이 있습니다. 하지만 뒤로 미룰수록 더 복잡하고 비용이 많이 들기 때문에 미리 결정할 수 있는 것들은 최대한 빨리 결정해서 확정을 하는 것이 중요합니다.
좋은 의견 감사합니다.
개발용 문서를 보면 확실이
이전 버전과 동일 이라는 말 만큼 짜증나는 문장도 없는것 같아요 ㅋ
비밀댓글입니다
스펙을 주고 외주개발한다는 가정하에 작성하는 것이 좋습니다.
그리고 문서든 코드이든 Review를 하는 것이 가장 좋습니다.
Review는 SE 분야에서 연구자와 실무자가 모두 품질 향상에 도움이 된다고 인정한 유일한 툴입니다.
정도유님 안녕하세요.
이말을 제대로 이해하고 있는 개발자나 경영자는 정말로 만나보고 어렵습니다. ^^