150. SRS의 품질 특성 - 정확성, 명확성, 완전성, 일관성, 수정 용이성, 추적 가능성

핵심 인사이트 (3줄 요약)

본질: 요구사항 명세서(SRS)의 품질 특성은 IEEE 830 표준에서 정의한, 산문형(자연어) 요구사항 문장이 개발과 테스트의 기준이 되는 '엔지니어링 잣대'로 기능하기 위한 절대적 채점 기준(Criteria)이다.

가치: "정확하고 명확하며 빠짐없이 완전해야 하고(내용적 무결성), 앞뒤가 일관되어 모순이 없어야 하며(논리적 무결성), QA가 테스트로 O/X 채점(검증 가능성)하고 소스코드까지 꼬리표가 이어져야(추적 가능성)" 프로젝트의 폭망을 막을 수 있다.

융합: 이 6가지 철칙은 현대 애자일(Agile) 생태계에서도 죽지 않고, 유저 스토리(User Story)가 스프린트 개발에 착수되기 위해 통과해야 하는 **DoR (Definition of Ready)**과 BDD(Given-When-Then) 자동화 테스트 시나리오 검증 뼈대로 완벽하게 융합되어 살아 숨 쉰다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 소프트웨어 요구사항 명세서(SRS, Software Requirements Specification) 품질 특성이란, 기획자나 비즈니스 분석가(BA)가 작성한 요구사항 문서가 다음 단계인 설계(Design)와 코딩(Implementation) 단계로 무사히 넘어가기 위해 만족해야 하는 정성적/정량적 허들(Hurdle)이다.
필요성: 프로젝트 실패의 70%는 코더의 코딩 실력 부족이 아니라, "무엇을 만들어야 하는지"를 적어둔 명세서가 개판이라서 발생한다. "화면이 예쁘게 빨리 떴으면 좋겠어요"라고 적힌 문서를 보고 디자이너, 백엔드 개발자, DB 튜너는 각자 상상력을 발휘해 전혀 다른 성을 짓기 시작한다. 결국 완성 날 고객은 인수를 거부하고 막대한 재작업(Rework) 비용이 터진다. 자연어의 파멸적 모호함을 수학적 공리 수준으로 통제할 강력한 '문장 감수 기준'이 필요했다.
💡 비유: 건축 도면을 그릴 때 "창문을 크게 뚫고, 대충 따뜻하게 지어줘"라고 적으면 목수는 자기 맘대로 집을 짓다가 겨울에 얼어 죽는 집을 만듭니다. 좋은 도면(SRS)은 "창문 가로 1.5m x 세로 2m, 2중 진공 유리, 실내 온도 24도 유지"라고 적어두어, 목수(개발자)가 딴생각을 못 하게 하고 나중에 감리사(테스터)가 줄자를 들고 와서 합격/불합격(검증)을 도장 찍을 수 있게 만드는 **'완벽한 설계 헌법'**입니다.
등장 배경:
1. 폭포수 모델의 딜레마: 요구사항이 확정(Baseline)되어야 코딩을 시작할 수 있는 구조에서, 기준선이 흔들리면 하위 산출물이 모래성처럼 붕괴했다.
2. IEEE Std 830-1998 제정: 전 세계 시스템 공학의 바이블 격인 이 표준에서 "좋은 명세서란 이런 조건을 갖춰야 한다"며 특성들을 수학 공리처럼 박아 넣었다.
3. QA(품질 보증)의 독립: 개발자와 독립된 테스터 집단이 소프트웨어를 검증하려면 소스코드가 아닌 '절대적 기준 문서'가 필요했고, 검증이 불가능한 문장은 명세서에서 즉시 퇴출당했다.

┌─────────────────────────────────────────────────────────────┐
│          SRS 6대 품질 특성 위반 시 발생하는 재앙 시나리오              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ 1️⃣ 정확성 (Correctness) 위반                                  │
│ ➔ 고객은 '신용카드'를 원했는데 '현금결제'로 명세됨 ➔ 오픈 날 소송 터짐 💥  │
│                                                             │
│ 2️⃣ 명확성 (Unambiguous) 위반                                  │
│ ➔ "가급적 빨리 갱신한다" ➔ A개발자 1초, B개발자 10초로 제각각 짬 💥  │
│                                                             │
│ 3️⃣ 완전성 (Completeness) 위반                                 │
│ ➔ "성공 시 포인트 100원 지급" (실패 시 로직이 빵꾸남) ➔ 서버 무한 대기 💥│
│                                                             │
│ 4️⃣ 일관성 (Consistency) 위반                                  │
│ ➔ 10페이지엔 "비밀번호 8자리", 50페이지엔 "10자리" ➔ 개발자 정신 분열 💥 │
│                                                             │
│ 5️⃣ 검증 가능성 (Verifiability) 위반                             │
│ ➔ "초보자도 쓰기 쉬워야 함" ➔ QA 테스터가 O/X 채점 불가로 테스트 포기 💥 │
│                                                             │
│ 6️⃣ 추적 가능성 (Traceability) 위반                             │
│ ➔ 법이 바뀌어서 결제 로직 고쳐야 하는데, 명세서 1만 페이지 중 어딨는지     │
│    아이디(ID) 꼬리표가 없어서 못 찾음 ➔ 유지보수 파산 💥               │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 단순히 시험용 암기 단어가 아니라, 실무에서 아키텍트와 프로젝트 매니저(PM)가 리뷰 회의 때 눈에 불을 켜고 잡아내야 하는 결함(Defect)의 핵심 기준들이다. 위 6가지 중 하나라도 구멍이 뚫린 문장이 개발자에게 넘어가는 순간, 그 문장은 런타임 버그(Bug)가 되어 서버를 터뜨리거나 고객의 분노로 돌아온다. 가장 훌륭한 아키텍트는 아키텍처를 잘 그리는 사람이 아니라, 기획자가 가져온 저 쓰레기 문장들을 쳐내고 다시 쓰게 만드는 '검문소의 수문장'이다.

📢 섹션 요약 비유: 이 6가지 규칙은 **'외계인에게 라면 끓이는 법 설명하기'**와 같습니다. 대충 적으면 냄비째 씹어먹을 수 있으니, "어떤 라면인지(정확), 물 500ml(명확), 스프와 면을 순서대로(완전), 앞뒤 말이 안 바뀌게(일관), 완성 후 나트륨 농도 측정(검증), 요리 과정 비디오 녹화(추적)"까지 완벽하게 통제해야 살 수 있습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 정확성 (Correctness)

개념: 명세서에 기술된 내용이 고객이 실제로 원했던(의도한) 바를 100% 반영하고 있는가?
검증 방안: 기계나 테스트가 증명할 수 없다. 오직 도메인 지식을 가진 **고객(현업)과의 집요한 인터뷰, 프로토타이핑(화면 목업), 그리고 최종 서명(Sign-off/Baseline)**을 통해서만 담보된다.
함정: 명확하고 완벽하게 쓰였더라도 고객이 원하지 않은 기능이라면 정확성은 0점이다.

2. 명확성 (Unambiguous)

개념: 어느 누가(개발자, 테스터, 고객) 읽더라도 오직 1가지 의미로만 해석되어야 한다. 자연어의 다의성(중의적 표현)을 원천 차단해야 한다.
해결 아키텍처: "가급적, 빠르게, 유연한" 같은 형용사/부사를 삭제하고 정량적 수치(예: 3초 이내)를 박아 넣어야 한다. 복잡한 문장은 줄글을 버리고 의사결정표(Decision Table), 상태 전이도(State Diagram), 수식 등의 반정형/정형 명세 툴로 뜯어고쳐야 한다.

3. 완전성 (Completeness)

개념: 시스템이 마주칠 수 있는 '모든' 경우의 수와 상황에 대한 대처법이 빵꾸 없이 꽉 채워져 있어야 한다. (TBD - To Be Determined 삭제).
해결 아키텍처: 해피 패스(Happy Path, 정상 동작)만 적는 주니어 기획자의 문서를 찢고, 예외 상황(서버 다운 시 롤백), 한계 용량(입력창 500자 초과 시 에러 메시지) 등 **대안 흐름(Alternative Flow)과 예외 흐름(Exception Flow)**을 유스케이스 명세서에 100% 매워 넣어야 한다.

4. 일관성 (Consistency)

개념: 수백 페이지에 달하는 거대 명세서 문서 내에서, A라는 조건과 B라는 조건이 서로 모순(Conflict)되거나 충돌해서는 안 된다.
해결 아키텍처: 용어의 파편화를 막기 위해 반드시 '자료 사전(Data Dictionary)' 또는 '용어집(Glossary)'을 프로젝트 0순위로 세팅하여 "고객 = 유저 = 회원"처럼 헷갈리는 명사들을 하나로 통제(SSOT)해야 모순이 발생하지 않는다.

5. 검증 가능성 (Verifiability)

개념: 요구사항을 보고 테스터(QA)가 "이게 성공(Pass)인지 실패(Fail)인지 O/X 로 채점할 수 있는가?"
해결 아키텍처: 테스트 케이스(TC)를 뽑아낼 수 없으면 명세가 아니다. "시스템 성능이 좋아야 한다"는 채점 불가다. "동시 접속자 10,000명 부하 테스트 시(JMeter), 99%의 요청이 200ms 이내에 HTTP 200 OK를 반환해야 한다"처럼 철저한 계량화와 테스트 방법론이 문장 내에 융합되어 있어야 한다.

6. 추적 가능성 (Traceability)

개념: 이 요구사항이 대체 어디서(누구의 아이디어로) 튀어나왔고, 미래에 어떤 설계도와 소스코드로 변환되었는지 앞뒤로 꼬리표를 묶어 역추적이 가능해야 한다.
해결 아키텍처: 문서에 단순히 글을 적는 것이 아니라, REQ-PAY-001 같은 고유 식별자(ID)를 모든 문단에 매핑하고, 이를 바탕으로 엑셀표인 **RTM (Requirements Traceability Matrix)**을 구축하여 Git 커밋 번호와 TC 번호를 거미줄처럼 이어 묶는 전사 형상 관리(SCM) 융합이 필수다.

Ⅲ. 융합 비교 및 다각도 분석

딜레마: 명확성(Unambiguous) vs 작성 비용(Cost)의 치열한 줄다리기

명확성과 완전성을 100% 수학적으로 달성하는 방법이 있다. 바로 Z-언어나 VDM 같은 **정형 명세(Formal Specification)**를 쓰는 것이다.

요구사항 작성 방식	명확성 / 완전성 보장 레벨	작성 비용 (시간/돈)	아키텍처적 선택 기준
자연어 (산문형 워드)	매우 낮음 (해석의 충돌 잦음)	매우 낮음 (금방 씀)	1달짜리 쇼핑몰 이벤트 페이지
반정형 (UML, 의사결정표)	높음 (실무적 스윗스팟)	중간 (표와 그림 규격화)	90% 이상의 금융, 엔터프라이즈 시스템 표준
정형 (수학적 논리식 Z)	완벽함 (100% 버그 증명)	천문학적 (수학자 필요)	우주선 궤도 수정 커널, 원자력 발전소 제어 모듈

과목 융합 관점: 소프트웨어 공학의 영원한 진리는 "은통알은 없다(No Silver Bullet)"다. 모든 문서의 완전성을 100% 맞추려고 1년 내내 명세서만 고치고 있으면 회사는 망한다(분석 마비, Analysis Paralysis). 따라서 생명이나 수백억 돈이 오가는 결제 트랜잭션 모듈(Core Domain)에 대해서는 수학적 의사결정표로 명확성을 한계까지 끌어올리고, 중요도가 낮은 마이페이지 UI 색상(Sub Domain)에 대해서는 자연어(비정형)와 프로토타이핑(그림)으로 퉁치고 빨리 넘어가는 Risk-based(위험 기반) 아키텍처 설계 완급 조절이 시니어의 필수 덕목이다.

📢 섹션 요약 비유: 동네 냇가를 건널 징검다리를 놓을 때(일반 시스템) 수백 장의 강철 강도 테스트 도면(정형 명세)을 그리는 건 바보짓입니다. 하지만 인천대교를 놓을 때(생명 직결 시스템) 대충 스케치북에 "튼튼하게"라고 적고(자연어) 시멘트를 붓는 건 살인행위입니다. 아키텍트는 다리의 크기에 맞춰 도면의 깐깐함을 융합 조절해야 합니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 완전성(Completeness) 누락으로 인한 락(Lock) 무한 대기 장애: "결제 시 사용자의 포인트를 깎고 결제를 승인한다." 기획자가 쓴 요구사항이다. 주니어 개발자가 이대로 짰다. 블랙프라이데이 날, 포인트 서버 DB가 10초간 다운되었다. 포인트 차감 응답이 오지 않자 결제 서버의 모든 쓰레드(Thread)가 타임아웃 룰셋이 없어 영원히 멈춰(Hang) 섰고, 전체 시스템이 마비되었다.
- 판단: 완전성 원칙의 치명적 위반이다. 요구사항 명세서에는 해피 패스(정상 결제)뿐만 아니라, **"타 시스템 연동 시 3초 이내 응답이 없으면 결제를 롤백하고 고객에게 '지연 에러'를 반환한다"**라는 예외 처리(Exception Handling) 로직이 반드시 100% 명시되어야 했다. 문서의 빵꾸는 곧장 시스템 병목과 마비로 직결된다.
시나리오 — 검증 불가(Unverifiable) 요구사항의 인수 테스트 파국: 공공기관 포털 SI 프로젝트 완료 후, 마지막 인수 테스트(UAT) 날짜가 다가왔다. 요구사항 ID REQ-UI-10에 "시스템은 노약자도 쉽게 사용할 수 있는 직관적인 UI를 제공해야 한다"라고 적혀 있었다. 감리단과 검수자가 "글씨가 작아서 노인이 보기 힘드네. 불합격. 잔금 10억 지급 보류!"를 때렸다. 개발사는 "폰트 크기 12px이면 충분히 큽니다"라고 항변했지만 싸움만 날 뿐이었다.
- 판단: 형용사와 부사가 섞인 최악의 안티패턴 문장이다. 이 문장은 애초에 베이스라인(Baseline) 도장을 찍기 전 리뷰 단계에서 아키텍트에 의해 **"웹 접근성 지침(WCAG) AA 등급을 통과하는 색상 대비율(4.5:1 이상)과 글꼴 확대 기능을 제공해야 한다"**라고 채점 가능한 0/1 수치 잣대로 변환(검증 가능성 확보)되었어야만 했다. 명세서에 감정이 들어가면 돈을 떼인다.

  ┌─────────────────────────────────────────────────────────────┐
  │        실무 아키텍처: BDD (행동 주도 개발)로 6대 품질 특성을 100% 달성하기   │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [ ❌ 기획자의 애매한 텍스트 (모호성 덩어리) ]                         │
  │ "장바구니에 5만 원 이상 담으면 배송비 빼주세요."                        │
  │ 💥 완전성 위반: 5만 원 딱 맞을 때는? 쿠폰 써서 4만 9천 원이 되면?       │
  │                                                             │
  │        ======= [ BDD 기반의 Gherkin 문법으로 정제 ] ========      │
  │                                                             │
  │ [ ✅ 개발자와 QA가 함께 재작성한 무결점 실행 가능 명세 (Executable) ]   │
  │                                                             │
  │ Feature: 무료 배송 판정 로직 (REQ-DEL-001) ◀─ (추적 가능성 🔗)    │
  │                                                             │
  │   Scenario: 총 결제 예정액이 5만 원 '이상'일 때 무료 배송 적용        │
  │     Given 고객 장바구니 상품 총액이 60,000원이다.                     │
  │     And   고객이 15,000원짜리 할인 쿠폰을 적용했다. (완전성 🛡️)         │
  │                                                             │
  │     When  결제 금액 계산 로직이 실행될 때,                         │
  │                                                             │
  │     Then  최종 배송비는 0원으로 계산되어야 한다. (명확성 🔍)           │
  │     And   총 결제 청구액은 45,000원이어야 한다. (검증 가능성 ✅)       │
  │                                                             │
  │ 🌟 실무 효과: 이 Gherkin 텍스트 문서 자체가 곧바로 JUnit 테스트 코드로   │
  │ 자동 변환되어 CI/CD 빌드 시 기계가 돌려가며 O/X를 채점한다. 자연어가 코드와│
  │ 동기화되는 기적(Single Source of Truth)이 애자일 환경에서 완성된다!   │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] IEEE 830의 6대 품질 특성은 90년대 워드 문서(Word) 시대의 유물로 여겨질 뻔했으나, 현대 애자일(Agile) 환경에서 **BDD (Behavior-Driven Development)**를 만나 화려하게 부활했다. Gherkin(Given-When-Then) 문법에 맞춰 글을 쓰다 보면 인간은 억지로라도 예외 상황(완전성)을 고민하게 되고, 구체적인 수치(검증 가능성)를 적어 넣을 수밖에 없는 논리적 족쇄에 갇히게 된다. 나아가 이 명세서가 곧바로 테스트 코드로 자동 연동되므로, "문서 따로, 코드 따로" 놀던 일관성(Consistency)과 추적성(Traceability)의 붕괴를 한 큐에 해결해 버리는 궁극의 모던 요구공학 파이프라인이다.

도입 체크리스트

기술적: 요구사항 명세서의 각 문장(티켓)이 Jira 같은 이슈 트래커 시스템에서 Git 브랜치, PR(Pull Request) 번호, 그리고 SonarQube/Jenkins의 빌드 배포 결과와 태깅되어 **완벽한 쌍방향 추적성(RTM)**을 자동화하고 있는가?
운영·보안적: 명확성과 완전성을 높이기 위해, 보안팀이 개입하여 모든 시스템 유스케이스에 짝을 이루는 **오용 케이스(Misuse Case / Abuse Case: 해커가 비정상적 입력을 넣었을 때의 방어 로직)**가 명세서의 대안 흐름(Alternative Flow)에 필수적으로 박혀 있는가?

안티패턴

구현 방식(How)을 명세(What)에 우겨넣는 월권행위: 요구사항 문서에 "데이터베이스는 Oracle 19c를 쓰고, 로그인 화면 비밀번호는 SHA-256으로 해싱해서 React 컴포넌트로 뿌려야 한다"라고 특정 기술 스택을 꽉 막히게 떡칠해 놓는 행위. 명세서는 철저하게 "무엇(What)을 해야 하는가"와 "응답 속도(비기능 제약)"만을 적어야 한다. 암호화를 어떻게 할지(How)는 명세가 끝난 뒤 아키텍트와 백엔드 개발자가 자유롭게 기술을 선택해야 할 설계(Design)의 영역이다.
📢 섹션 요약 비유: 명세서는 식당 손님이 "안 맵고 부드러운 오므라이스를 만들어 줘(What)"라고 적어내는 주문서입니다. 손님이 주문서에 "프라이팬을 10번 돌리고, 웍은 테팔 것을 쓰고 불은 가스레인지만 써(How)"라고 간섭하면 주방장(개발자)은 인덕션이라는 더 좋은 도구가 있어도 쓸 수가 없어 요리를 망치게 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	주먹구구식 텍스트 명세 관행	6대 품질 특성 강제화 (BDD 등)	개선 효과
정량	예외 로직 누락에 의한 배포 후 버그 속출	완전성과 검증성 확보로 설계 단계 버그 차단	프로덕션(운영) 단계의 치명적 런타임 버그 80% 사전 소멸
정량	요구사항 변경 시 영향도 파악 불가	RTM 맵핑으로 즉각적인 코드 연관성 추출	형상 변경 및 유지보수 시 영향도 분석 시간 90% 이상 단축
정성	개발자-기획자-테스터 간 끝없는 책임 전가	단일 진실 원천(SSOT)에 기반한 객관적 채점	부서 간 커뮤니케이션 낭비 제거 및 릴리즈 승인(Sign-off) 기간 단축

미래 전망

거대 언어 모델(LLM)에 의한 명세 리뷰 자동화: 앞으로의 기획자나 아키텍트는 6대 특성을 검증하느라 밤을 새울 필요가 없어진다. 장황하게 쓴 회의록을 ChatGPT 같은 AI에 던지며 "IEEE 830 품질 특성에 맞춰 모순이나 누락(예외 처리 빵꾸)을 찾아내고, Gherkin 테스트 시나리오로 변환해 줘"라고 시키면, AI가 사람의 언어에 숨겨진 맹점(모호성)을 1초 만에 짚어내고 100% 명확한 표(Table) 구조로 번역해 주는 'AI 기반 요구공학'이 폭발적으로 도입되고 있다.
애자일 DoR (Definition of Ready)과의 완벽한 융합: 무거운 폭포수 시대의 거대한 책자(SRS) 형태는 멸종하고 있다. 대신, 잘게 쪼개진 포스트잇(User Story) 하나하나가 개발자의 손으로 넘어가기 직전에 "이 티켓은 코딩을 시작해도 될 만큼 명확하고, 완전하며, 테스트 가능한가?"를 검문하는 **DoR (준비 완료 정의)**의 강력한 방어막으로 6대 품질 특성의 영혼이 스며들어 애자일 생태계를 견고하게 지탱하고 있다.

참고 표준

IEEE Std 830-1998: 소프트웨어 요구사항 명세서(SRS) 작성을 위한 가이드. 이 6가지 특성의 영원한 오리지널 글로벌 출처.
ISO/IEC/IEEE 29148:2018: 시스템 및 소프트웨어 공학 - 수명주기 프로세스 - 요구공학(Requirements Engineering) 최신 통합 국제 표준

"나쁜 명세서 위에 지은 좋은 시스템이란 존재하지 않는다." 수백 대의 클라우드 서버 클러스터링과 아무리 우아한 쿠버네티스(Kubernetes) 아키텍처를 갈아 넣더라도, 첫 단추인 '명세서의 모호함'을 제거하지 못하면 우리는 단지 '고객이 원하지 않는 쓰레기를 전 세계에서 가장 빠르고 튼튼하게 서비스'하는 코미디를 찍게 될 뿐이다. 정확하고(Correct), 명확하며(Unambiguous), 추적 가능한(Traceable) 단단한 명세 문장 한 줄을 깎아내는 치열한 고통이야말로, 소프트웨어 엔지니어가 타이핑(Coding) 노가다꾼에서 진정한 아키텍트로 도약하기 위해 반드시 통과해야 하는 위대한 인문학적 수련이다.

📢 섹션 요약 비유: 이 6대 품질 특성은 사막을 건너는 지도(명세서)를 검사하는 '6개의 돋보기'입니다. 방향이 맞는지(정확), 글씨가 안 번졌는지(명확), 중간에 지워진 길은 없는지(완전) 돋보기로 미리 완벽히 검사해 두어야, 나중에 목마른 사막 한가운데서 개발자 100명이 길을 잃고 떼죽음을 당하는 비극(프로젝트 실패)을 막아낼 수 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
소프트웨어 요구사항 명세서 (SRS)	이 6가지 깐깐한 품질 잣대를 무사히 통과한 문장들만이 모여서 만들어지는, 소프트웨어 개발의 헌법이자 최종 계약 문서다.
요구사항 추적성 매트릭스 (RTM)	6대 특성 중 '추적 가능성'을 실물 엑셀표나 지라(Jira) 티켓 번호 엮기로 구현하여, 설계/코드/테스트까지 유령처럼 따라다니는 거미줄이다.
BDD (행동 주도 개발)	모호한 비정형 자연어를 기계가 읽어낼 수 있는 `Given-When-Then` 텍스트 블록으로 강제하여, '명확성'과 '검증 가능성'을 극강으로 끌어올린 현대의 융합 툴이다.
비기능 요구사항 (Non-Functional)	성능이나 가용성 같은 추상적인 개념을 다루므로, "성능이 좋아야 한다"는 최악의 모호성을 타파하고 "1초 이내 99% 응답"으로 정량화(검증 가능성)해야 하는 최우선 튜닝 대상이다.
블랙박스 테스트 (Black-box Testing)	소스 코드를 안 보고, 오직 100% 명확하고 완전하게 작성된 SRS 명세서 텍스트의 조건(입력)과 결과(출력)만 보고 채점표(TC)를 뽑아내는 테스트 기법이다.

👶 어린이를 위한 3줄 비유 설명

친구한테 "멋진 장난감을 만들어줘!"라고 대충 말하면(비정형 명세), 내 맘에 쏙 드는 걸 받기가 너무 힘들고 나중에 싸우게 돼요.
그래서 장난감 공장에 주문서를 넣을 땐 6가지 규칙을 꼭 지켜야 해요! "진짜 내가 원하는 차 모양인지(정확), 바퀴는 딱 4개인지(명확/완전), 앞엔 4개라 적고 뒤엔 6개라 적지 않았는지(일관)" 말이죠.
그리고 나중에 다 만들어졌을 때 자로 길이를 재서 통과/실패를 채점할 수 있게(검증) 정확한 숫자로 꼼꼼히 적어야만, 바보 기계도 완벽한 장난감을 뚝딱 만들어 낼 수 있답니다!