NASA가 요구사항에 쓰지 말라고 정해 둔 단어 13개

 

미국 항공우주국은 요구사항에 쓰면 안 되는 단어를 목록으로 만들어 뒀습니다.

미국 항공우주국의 시스템 엔지니어링 핸드북에는 좋은 요구사항 쓰는 법이 부록으로 붙어 있습니다. 그 안에서 제일 실용적인 건 원칙이 아니라 목록입니다. 쓰지 말라고 이름을 하나하나 적어 둔 단어들이요.

 

목록 전문

flexible, easy, sufficient, safe, ad hoc, adequate, accommodate, user-friendly, usable, when required, if required, appropriate, fast, portable, light-weight, small, large, maximize, minimize, robust, quickly, easily, clearly.

여기에 "ly"나 "ize"로 끝나는 말은 일단 의심하라는 단서가 붙습니다. 그리고 별도로 모호한 표현 목록이 하나 더 있어요. this, these, as appropriate, etc., and/or, but not limited to.

우리말 문서에서 이 목록에 걸리는 표현은 이런 것들입니다. 유연하게, 쉽게, 충분히, 안전하게, 적절히, 사용자 친화적으로, 필요시, 빠르게, 가볍게, 최대한, 최소화, 안정적으로, 신속히, 명확히, 기타 등등, 그리고 "등".

 

왜 하필 이 단어들인가

공통점 하나뿐입니다. 검수 자리에서 판정이 안 됩니다.

"필요시 관리자에게 알린다"를 예로 들어 보죠. 개발이 끝나고 확인할 때, 알림이 안 왔는데 만든 쪽은 필요한 상황이 아니었다고 하고 시킨 쪽은 필요한 상황이었다고 합니다. 둘 다 같은 문장을 근거로 듭니다. 문장이 판정을 못 하게 쓰여 있으니 판정은 문서가 아니라 사람이 하게 되고, 그러면 목소리 큰 쪽이 이깁니다.

반대로 "결제가 3회 연속 실패하면 관리자 이메일로 알린다"는 다툴 것이 없습니다. 세 번 실패시켜 보면 끝납니다. 같은 요구인데 한쪽은 회의가 필요하고 한쪽은 5분이면 됩니다.

 

"등"이 제일 위험합니다

한국어 요구사항 문서에서 가장 자주 보이는 글자입니다. "회원 정보, 결제 내역 등을 조회할 수 있다."

이 한 글자가 하는 일은 범위를 열어 두는 것입니다. 쓰는 사람은 빠뜨린 게 있을까 봐 안전장치로 붙이는데, 읽는 사람 입장에서는 무엇이 더 있는지 알 수 없는 문장이 됩니다. 그리고 그 "등"은 개발이 끝난 뒤에 채워집니다. 대개 무료로요.

나사 목록의 "but not limited to"가 정확히 같은 물건입니다. 영어권에서도 같은 이유로 금지어입니다.

 

조동사 셋을 갈라 두는 것도 같은 이야기입니다

같은 문서에 shall, will, should를 갈라 놓은 대목이 있습니다. shall은 요구사항, will은 사실이나 목적 서술, should는 목표입니다.

우리말에는 이 구분이 아예 없어서 더 위험해요. "제공한다", "제공할 예정이다", "제공하면 좋다"가 한 표 안에 나란히 들어가는데, 검수할 때 이 셋의 무게가 같지 않습니다. 그런데 문서에는 같은 무게로 적혀 있죠.

 

고칠 때 순서

이미 쓴 문서를 다 뜯어고칠 필요는 없습니다. 위 목록을 그대로 놓고 검색 한 번 돌려서, 걸리는 줄만 숫자나 판정 방법으로 바꿔 보세요. 대개 문서 전체의 10%도 안 됩니다. 그런데 나중에 분쟁이 나는 줄은 거의 그 10% 안에 있습니다.

바꿀 때 요령이 하나 있습니다. "어떻게 확인할 겁니까"를 소리 내어 물어보고, 대답이 안 나오면 그 줄이 걸린 겁니다. 대답이 "보면 압니다"여도 걸린 겁니다.

이 목록 말고도 요구사항 한 줄을 재는 자가 두 개 더 있습니다. 규모를 셀 수 있는지, 그리고 조건이 문장 앞에 나오는지. 세 자를 한 문장에 차례로 대 보는 방법은 원문에 정리해 뒀습니다.