R&D 사용자 요구사항 명세 체크리스트: 기능, 성능, 제약조건을 검증 가능한 문장으로 쓰는 법

R&D 과제에서 사용자 요구사항 명세가 흔들리는 순간은 대개 초안이 비어 있을 때가 아닙니다. 오히려 “로그인 기능 제공”, “빠른 응답”, “사용하기 쉬운 화면”, “보안 강화”, “외부 시스템 연동”처럼 그럴듯한 문장이 이미 적혀 있을 때 문제가 시작됩니다. 이런 문장은 회의에서는 합의처럼 보이지만, 설계 리뷰나 시험 계획 단계에서는 누가 어떤 조건에서 무엇을 검증해야 하는지 분명하지 않습니다. 개발자는 구현 범위를 넓게 해석하고, 시험 담당자는 합격 기준을 새로 만들어야 하며, PM은 일정 지연이 기능 추가 때문인지 요구사항 해석 차이 때문인지 설명하기 어렵습니다.

이 글의 목표는 R&D 사용자 요구사항 명세를 예쁘게 쓰는 법이 아닙니다. 기능, 성능, 제약조건을 검증 가능한 문장으로 바꾸는 최소 점검 기준을 제공하는 것입니다. NASA의 요구사항 작성 지침은 좋은 요구사항이 명확하고 단순하며, 한 문장에 하나의 생각만 담고, 검증 기준을 세울 수 있어야 한다고 설명합니다[S1]. NASA의 시스템공학 절차는 이해관계자 기대를 정량적이고 측정 가능한 기술 요구사항으로 변환하는 흐름을 둡니다[S2]. IEEE/ISO/IEC 29148은 시스템과 소프트웨어 요구사항 공학 전 과정에서 요구사항 산출물과 정보 항목을 다루는 표준입니다[S3][S4]. 따라서 R&D 명세 초안의 첫 기준은 “그럴듯한가”가 아니라 “검증자가 같은 의미로 읽고 시험, 분석, 검사, 시연 중 하나로 확인할 수 있는가”입니다.

빠른 결론

R&D 사용자 요구사항 명세는 “사용자가 원한다”에서 끝나면 안 됩니다. 좋은 요구사항 문장은 조건, 대상, 동작, 측정 항목, 합격 기준, 검증 방법, 출처를 함께 남깁니다. 기능 요구사항은 사용자의 과업과 시스템 반응을 분리해 쓰고, 성능 요구사항은 빠르다·안정적이다 같은 형용사를 수치와 조건으로 바꾸며, 제약조건은 설계 해법을 강제하는 문장과 반드시 지켜야 하는 경계를 구분해야 합니다.

사용자 요구사항 명세는 기능 목록이 아니라 검증 가능한 약속입니다

사용자 요구사항을 처음 쓸 때 가장 쉬운 방식은 화면이나 메뉴 목록을 나열하는 것입니다. 그러나 기능 목록은 “무엇이 있으면 좋겠다”를 보여줄 뿐, “언제 합격이라고 볼 것인가”를 보장하지 않습니다. 예를 들어 “사용자는 실험 데이터를 조회할 수 있어야 한다”는 문장은 기능 방향은 맞지만 부족합니다. 어떤 사용자인지, 어떤 데이터인지, 조회 조건은 무엇인지, 응답 결과가 어떻게 보여야 하는지, 권한이 없는 경우 어떻게 처리해야 하는지, 검증 방법이 무엇인지가 빠져 있습니다.

검증 가능한 요구사항은 약속의 단위를 작게 만듭니다. “연구자는 승인된 프로젝트의 센서 원시 데이터를 기간, 장비 ID, 시료 ID 조건으로 검색할 수 있어야 한다”까지 쓰면 기능의 주체와 대상이 보입니다. 여기에 “검색 결과는 데이터셋 ID, 수집 시각, 장비 ID, 파일 상태를 표시해야 한다”를 더하면 시스템 반응이 분리됩니다. 마지막으로 “시험 데이터 10만 건 기준, 기간 조건 검색 결과 첫 화면은 3초 이내에 표시되어야 한다”처럼 조건과 성능 기준을 붙이면 검증자가 실제 시험 항목을 만들 수 있습니다.

NASA의 요구사항 검증 체크리스트는 요구사항이 명확하고 모호하지 않은지, “적절한 경우”, “기타”, “and/or”처럼 해석을 흔드는 표현이 없는지 확인하라고 안내합니다[S1]. 이 기준을 R&D 명세에 적용하면 초안 리뷰의 질문이 달라집니다. “이 기능이 필요한가”에서 멈추지 않고 “이 문장을 다른 팀이 읽어도 같은 시험을 만들 수 있는가”로 넘어가야 합니다. 사용자 요구사항 명세는 회의록이 아니라 이후 설계, 구현, 시험, 변경관리의 기준선이기 때문입니다.

초안 표현	검증 가능한 문장으로 바꿀 때 묻는 질문	보강 예시
사용하기 쉬워야 한다	누구의 어떤 과업이 쉬워져야 하는가	신규 연구자는 시료 등록 화면에서 필수 6개 항목을 5분 이내에 입력 완료할 수 있어야 한다
빠르게 처리한다	어떤 조건에서 어느 지표가 얼마나 빨라야 하는가	1만 건 이하 조회 요청의 95%는 서버 응답 시간 2초 이내여야 한다
보안을 강화한다	어떤 자산, 위협, 접근 조건을 제한하는가	외부 협력사는 승인된 과제 폴더의 읽기 권한만 가져야 하며 다운로드 로그가 남아야 한다
연동을 지원한다	어떤 시스템과 어떤 데이터가 어떤 방식으로 이동하는가	LIMS는 장비 ID, 시료 ID, 측정값, 단위, 수집 시각을 CSV 또는 API로 내보낼 수 있어야 한다

기능 요구사항은 사용자 행동과 시스템 반응을 한 문장에 섞지 않습니다

기능 요구사항은 “시스템이 무엇을 해야 하는가”를 다룹니다. 하지만 R&D 현장에서는 사용자 행동, 시스템 기능, 운영 절차, 담당자 업무가 한 문장에 섞이는 경우가 많습니다. “담당자는 실험 후 결과를 확인하고 오류가 있으면 수정하여 보고서를 제출한다”는 문장은 업무 절차에 가깝습니다. 요구사항으로 바꾸려면 시스템 책임을 분리해야 합니다. 예를 들어 “시스템은 실험 결과 레코드의 측정값, 단위, 장비 ID, 시료 ID, 수집 시각을 표시해야 한다”와 “시스템은 수정 전 값, 수정 후 값, 수정자, 수정 사유, 수정 시각을 이력으로 저장해야 한다”처럼 나눕니다.

기능 요구사항은 보통 사용자 역할, 조건, 대상 데이터, 시스템 동작, 예외 반응으로 정리합니다. 사용자 역할은 “사용자”보다 좁아야 합니다. 연구책임자, 실험 담당자, 품질 검토자, 외부 협력사, 장비 관리자처럼 권한과 책임이 다른 집단을 분리합니다. 조건은 기능이 언제 적용되는지 보여줍니다. “승인된 과제에서”, “검토 상태가 반려인 경우”, “장비 연결이 끊어진 경우”, “동일 시료 ID가 이미 존재하는 경우”처럼 쓰면 기능 범위가 줄어듭니다.

시스템 반응은 관찰 가능해야 합니다. “안내한다”보다 “오류 코드와 수정 가능한 항목명을 표시한다”가 낫습니다. “관리한다”보다 “생성, 조회, 수정, 삭제 권한을 역할별로 제한한다”가 낫습니다. “자동화한다”보다 “측정 파일 업로드 후 1분 이내에 파일명, 해시값, 업로드 사용자, 업로드 시각을 기록한다”가 낫습니다. NASA 지침은 요구사항이 한 주어와 한 술어를 가져야 하고, 한 문장에 여러 요구사항을 넣지 말라고 봅니다[S1]. 그래서 기능 요구사항은 길게 쓰는 것이 아니라 작게 쪼개야 합니다.

기능 요구사항 문장 골격

역할: 누가 이 기능을 쓰는가. 예: 실험 담당자, 검토자, 외부 협력사

조건: 어떤 상태에서 기능이 적용되는가. 예: 과제 승인 후, 반려 상태, 네트워크 장애 시

대상: 어떤 데이터나 물리 대상을 다루는가. 예: 시료 ID, 장비 로그, 시험 결과 파일

동작: 시스템이 수행할 관찰 가능한 행동은 무엇인가. 예: 표시, 저장, 차단, 전송, 기록

예외: 실패하거나 권한이 없을 때 무엇을 보여주고 무엇을 남기는가

기능 요구사항을 쓸 때 구현 방법을 너무 빨리 고정하는 것도 위험합니다. NASA는 요구사항이 필요한 것을 말해야지 제공 방법을 말하지 않아야 한다고 안내합니다[S1]. “React 기반 대시보드로 표시한다”는 개발 선택일 수 있습니다. 명세 단계에서는 “측정 결과 목록은 결과 ID, 시료 ID, 상태, 마지막 수정 시각을 한 화면에서 비교할 수 있어야 한다”가 더 안전합니다. 특정 기술을 반드시 써야 하는 이유가 있다면 기능 요구사항이 아니라 제약조건이나 인터페이스 요구사항으로 따로 기록합니다.

성능 요구사항은 형용사를 조건, 지표, 기준값으로 바꿔야 합니다

성능 요구사항에서 가장 흔한 실패 문장은 “빠르게”, “안정적으로”, “정확하게”, “대량 처리 가능”, “실시간”, “고가용성”입니다. 이런 단어는 방향은 말하지만 시험 기준을 만들지 못합니다. 성능 요구사항은 항상 조건, 측정 지표, 기준값, 표본 또는 분위수, 측정 방법을 가져야 합니다. “빠른 검색”은 “검색 대상 10만 건, 동시 사용자 20명, 기간 조건 포함, 서버 응답 시간 p95 2초 이내”처럼 바뀌어야 합니다.

성능 기준에는 사용 맥락이 필요합니다. 연구 데이터 플랫폼이라면 데이터 건수, 파일 크기, 동시 사용자 수, 네트워크 조건, 장비 연결 상태, 데이터 보존 기간이 성능 조건이 됩니다. 장비 제어 소프트웨어라면 샘플링 주기, 제어 지연, 허용 오차, 장애 감지 시간, 재시도 횟수가 조건이 됩니다. 사용자 인터페이스라면 첫 화면 표시 시간, 오류 메시지 표시 시간, 필수 과업 완료 시간, 입력 검증 지연이 조건이 됩니다. NASA의 체크리스트도 성능 요구사항에서 타이밍, 처리량, 저장 크기, 지연, 정확도, 정밀도 같은 사양과 여유가 빠졌는지 확인하라고 봅니다[S1].

성능 요구사항은 합격 기준이 지나치게 엄격해도 문제가 됩니다. “모든 요청은 1초 이내”라고 쓰면 보기에는 명확하지만 현실과 비용을 무시할 수 있습니다. NASA 지침은 허용 오차가 지나치게 빡빡한지, 두 배나 세 배로 완화했을 때 어떤 일이 생기는지 물어보라고 합니다[S1]. R&D 초안에서는 “사용자 업무에 영향을 주는 지연 기준”과 “기술적으로 보기 좋은 목표”를 구분해야 합니다. 예를 들어 실험 로그 저장은 지연이 치명적일 수 있지만, 월간 통계 리포트 생성은 몇 분이 걸려도 업무상 문제가 없을 수 있습니다.

모호한 성능 표현	검증 가능한 성능 요구사항 요소	예시 문장
실시간 모니터링	갱신 주기, 허용 지연, 누락 처리	장비 상태 화면은 정상 네트워크 조건에서 5초 주기로 온도, 압력, 오류 상태를 갱신해야 한다
대량 데이터 처리	데이터 크기, 동시성, 처리 시간	1GB 이하 CSV 파일은 업로드 완료 후 10분 이내에 행 수, 오류 행 수, 검증 결과를 생성해야 한다
안정적인 서비스	가용성 기간, 장애 감지, 복구 목표	업무 시간 기준 월간 서비스 가용성은 99.5% 이상이어야 하며 장애 감지는 3분 이내에 기록되어야 한다
정확한 분석	기준 데이터, 허용 오차, 비교 방법	기준 시료 30개에 대한 농도 계산 결과는 기준값 대비 ±2% 이내여야 한다

성능 요구사항은 기능 요구사항과 연결되어야 합니다. 검색 기능이 있으면 검색 성능이 필요할 수 있고, 업로드 기능이 있으면 파일 크기와 처리 시간이 필요할 수 있습니다. 반대로 모든 기능에 성능 수치를 붙일 필요는 없습니다. 측정하지 않을 성능 요구사항은 나중에 시험 항목만 늘립니다. 중요한 것은 “측정할 수 있는 것만 쓴다”가 아니라 “사용자 결과에 영향을 주는 것을 측정 가능하게 쓴다”입니다.

제약조건은 설계 지시와 반드시 지켜야 할 경계를 분리합니다

제약조건은 기능이나 성능처럼 “무엇을 한다”보다 “어떤 범위 안에서 해야 한다”를 다룹니다. 법규, 표준, 운영 환경, 보안 정책, 장비 규격, 데이터 보존 기간, 외부 인터페이스, 예산 또는 일정 경계가 여기에 들어갑니다. 문제는 제약조건이라는 이름으로 설계 해법을 미리 박아 넣는 경우입니다. “PostgreSQL을 사용해야 한다”, “모든 화면은 모바일 앱으로 만들어야 한다”, “AI 모델을 반드시 사용해야 한다”는 문장은 실제 제약일 수도 있지만, 단순 선호일 수도 있습니다. 선호를 제약조건으로 쓰면 대안 검토가 사라집니다.

제약조건은 근거와 영향 범위를 함께 적어야 합니다. “기관 보안정책에 따라 외부 협력사는 VPN 접속 후 승인된 과제 폴더만 접근할 수 있어야 한다”처럼 근거가 있으면 설계자가 선택지를 좁힐 수 있습니다. “장비 제조사 SDK가 Windows 11에서만 제공되므로 장비 제어 모듈은 Windows 11 환경에서 실행되어야 한다”처럼 이유가 분명하면 운영 환경 제약이 됩니다. 반면 “관리자가 편하므로 엑셀로 한다”는 요구사항이 아니라 구현 선호나 운영 제안입니다.

FDA의 설계 입력 교육 자료는 설계 입력이 사용자 요구와 의도된 사용을 측정 가능한 말로 다뤄야 하며, 불완전하거나 모호하거나 충돌하는 요구사항을 처리해야 한다고 설명합니다[S7]. 이 원칙은 의료기기 밖의 일반 R&D에도 유용합니다. 제약조건은 다른 요구사항과 충돌할 때 특히 중요합니다. 예를 들어 “모든 데이터는 10년 보존”과 “개인정보는 목적 달성 후 파기”가 함께 있다면 둘 중 하나를 지우는 문제가 아니라 데이터 유형, 법적 근거, 비식별화, 접근 권한, 파기 예외를 분리해야 합니다.

제약조건으로 보류해야 하는 문장

근거 없이 특정 제품명, 프레임워크, 클라우드, DBMS를 고정한 문장

성능 목표와 비용 한계를 동시에 만족한다고 단정하지만 측정 조건이 없는 문장

보안, 개인정보, 인증, 표준을 언급하지만 적용 범위와 출처가 없는 문장

운영 절차와 시스템 요구사항이 섞여 담당자 행동을 제품 요구처럼 쓴 문장

“필요 시”, “가능한 한”, “최대한”, “동급 이상”처럼 합격 기준이 없는 문장

제약조건은 요구사항을 좁히는 장치이지 책임을 숨기는 장치가 아닙니다. “관련 법규 준수”라고만 쓰면 아무도 무엇을 확인해야 하는지 모릅니다. “개인정보가 포함된 원본 파일은 프로젝트 종료 후 30일 이내 삭제 또는 별도 승인 보존 상태로 전환되어야 하며, 전환 이력은 보존 사유와 승인자를 포함해야 한다”처럼 적용 대상과 기록 기준이 있어야 합니다. 보안 요구라면 자산, 접근 주체, 접근 조건, 로그, 보존 기간이 드러나야 합니다. 인터페이스 제약이라면 상대 시스템, 데이터 항목, 형식, 실패 처리, 버전 관리가 보여야 합니다.

검증 가능한 문장은 조건, 대상, 행동, 측정, 합격 기준으로 완성됩니다

R&D 요구사항 문장을 빠르게 고칠 때는 하나의 템플릿을 쓰면 좋습니다. “어떤 조건에서, 어떤 대상이, 어떤 행동을 해야 하며, 어떤 방법으로 측정했을 때, 어떤 기준이면 합격인가”입니다. 모든 문장이 이 순서를 그대로 따라야 하는 것은 아니지만, 빠진 요소를 찾기에는 충분합니다. NASA의 기술 요구사항 정의 프로세스는 이해관계자 기대를 고유하고 정량적이며 측정 가능한 기술 요구사항으로 변환한다고 설명합니다[S2]. 이 문장을 실무 언어로 바꾸면 “검증자가 시험표에 옮길 수 있는 문장”입니다.

좋은 요구사항은 검증 방법을 예상할 수 있습니다. 시험으로 확인할 것인지, 분석으로 확인할 것인지, 검사로 확인할 것인지, 시연으로 확인할 것인지가 보이면 문장이 강해집니다. 예를 들어 “시스템은 오류를 알려야 한다”는 약합니다. “시스템은 업로드 파일의 필수 컬럼이 누락된 경우 5초 이내에 누락 컬럼명, 행 번호, 수정 안내를 화면에 표시해야 한다. 검증은 누락 컬럼을 포함한 시험 파일 5개 업로드 시나리오로 수행한다”처럼 쓰면 시험 방법이 보입니다.

다음은 초안을 고치는 실제 예시입니다.

초안	문제	검증 가능한 문장
사용자는 데이터를 쉽게 찾을 수 있어야 한다	사용자, 데이터 범위, 쉬움의 기준이 없음	연구자는 승인된 과제의 실험 결과를 시료 ID, 장비 ID, 기간 조건으로 검색할 수 있어야 하며, 10만 건 데이터 기준 p95 응답 시간은 3초 이내여야 한다
시스템은 보안성이 높아야 한다	보안 대상과 검증 항목이 없음	외부 협력사 계정은 승인된 과제 폴더의 읽기 권한만 가져야 하며, 다운로드 시 계정 ID, 파일 ID, 시각, IP 주소가 로그에 기록되어야 한다
분석 결과는 정확해야 한다	기준 데이터와 허용 오차가 없음	표준 시료 30개에 대한 농도 계산 결과는 기준 장비 측정값 대비 ±2% 이내여야 하며, 검증 결과는 시료 ID별 차이율을 포함해야 한다
장애가 발생하면 복구한다	장애 종류와 복구 기준이 없음	장비 연결이 30초 이상 끊기면 시스템은 연결 끊김 상태를 표시하고, 재연결 후 누락 구간의 원시 로그 수집 여부를 사용자에게 표시해야 한다

IEEE/ISO/IEC 29148은 요구사항 공학 활동에서 요구사항 관련 정보 항목과 내용을 다루는 표준으로 소개됩니다[S3][S4]. 이 표준의 세부 조항을 그대로 복제하지 않아도, 초안 리뷰에서는 정보 항목 관점이 중요합니다. 요구사항 ID, 요구사항 문장, 출처, 상위 요구사항, 유형, 우선순위, 검증 방법, 합격 기준, 상태, 변경 이력을 같은 표에서 관리해야 합니다. 문장만 좋아도 출처와 검증 방법이 없으면 추적성이 약해집니다.

나쁜 요구사항을 찾는 R&D 사용자 요구사항 명세 체크리스트

요구사항 리뷰에서는 문장을 하나씩 읽으면서 “고쳐야 할 냄새”를 찾는 편이 빠릅니다. 첫 번째 냄새는 형용사입니다. 빠른, 쉬운, 안전한, 정확한, 유연한, 직관적인, 효율적인 같은 단어는 거의 항상 조건과 지표가 필요합니다. 두 번째 냄새는 묶음 동사입니다. 관리한다, 처리한다, 지원한다, 제공한다, 강화한다 같은 동사는 생성, 조회, 수정, 삭제, 표시, 전송, 차단, 기록, 계산처럼 관찰 가능한 행동으로 바꿔야 합니다.

세 번째 냄새는 책임 주체 혼합입니다. “연구자는 검토 후 시스템에 승인하고 담당자는 통보한다”처럼 사용자 행동과 시스템 행동이 섞이면 운영 절차와 제품 요구사항이 충돌합니다. 네 번째 냄새는 숨은 예외입니다. 권한 없음, 데이터 없음, 중복 입력, 파일 형식 오류, 네트워크 장애, 장비 미연결, 외부 API 실패 같은 상황이 빠져 있으면 성공 경로만 명세한 것입니다. 다섯 번째 냄새는 출처 없음입니다. “고객 요청”, “내부 규정”, “표준 준수”라고 쓰면서 구체 문서 ID와 조항, 회의록, 결정 기록이 없으면 변경관리 때 근거를 찾기 어렵습니다.

DoD 시스템공학 가이드북은 기술 요구사항, 시험과 평가 요구사항, 요구사항 검증 추적 데이터베이스, 최소 기술 요구사항, 기술 수용 기준 같은 항목을 획득 문서의 기술 내용과 연결해 설명합니다[S5]. 이 관점은 R&D 내부 프로젝트에도 그대로 적용할 수 있습니다. 요구사항 명세는 개발자에게만 주는 문서가 아니라, 검토자·시험자·구매 담당자·외부 협력사가 같은 기준을 보는 문서입니다. 그래서 각 요구사항은 시험 방법과 수용 기준으로 넘어갈 수 있어야 합니다.

다음 체크리스트에서 하나라도 “아니오”가 나오면 문장을 고쳐야 합니다.

요구사항 문장별 10개 점검

요구사항 ID가 있고 다른 문서에서 고유하게 참조할 수 있는가?

사용자 역할이나 시스템 대상이 너무 넓게 쓰이지 않았는가?

한 문장에 하나의 요구사항만 담겨 있는가?

“빠른”, “쉬운”, “적절한”, “필요 시” 같은 모호한 표현을 수치나 조건으로 바꿨는가?

기능, 성능, 제약조건, 운영 절차를 서로 다른 행으로 분리했는가?

요구사항의 출처가 회의록, 상위 요구사항, 규정, 표준, 사용자 조사 중 어디인지 기록했는가?

시험, 분석, 검사, 시연 중 어떤 방식으로 검증할지 정했는가?

합격 기준과 불합격 기준을 같은 사람이 다시 읽어도 판단할 수 있는가?

권한 없음, 데이터 없음, 중복, 장애, 외부 시스템 실패 같은 예외가 필요한 요구사항에 반영되었는가?

변경될 경우 영향을 받는 상위 요구사항, 시험 케이스, 산출물을 찾을 수 있는가?

이 체크리스트는 문장 품질만 보지 않습니다. 요구사항이 실제 R&D 운영에서 살아남을 수 있는지를 봅니다. 요구사항을 잘게 쪼갰는데도 검증 방법이 없으면 시험 단계에서 다시 흔들립니다. 검증 방법을 붙였지만 출처가 없으면 범위 조정 때 근거가 사라집니다. 출처가 있지만 합격 기준이 없으면 리뷰마다 해석이 달라집니다. 세 가지가 동시에 있어야 명세가 기준선 역할을 합니다.

변경과 추적성은 요구사항 명세의 마지막 열이 아니라 운영 규칙입니다

사용자 요구사항은 한 번에 완성되지 않습니다. 실험 조건이 바뀌고, 장비가 바뀌고, 외부 협력사의 권한 범위가 바뀌고, 법규나 기관 정책이 바뀔 수 있습니다. 따라서 요구사항 명세에는 변경 이력을 남길 구조가 있어야 합니다. DoDI 5000.88은 임무 능력에서 시스템 요구사항, 성능, 실행 지표까지 추적성을 제공하라고 설명합니다[S6]. R&D 프로젝트에서는 이를 “사용자 요구에서 기능·성능·제약조건, 시험 케이스, 결과 증거까지 끊기지 않게 연결한다”로 해석할 수 있습니다.

추적성은 복잡한 도구 이름이 아닙니다. 최소한 요구사항 ID, 상위 요구사항 또는 출처, 관련 설계 산출물, 관련 시험 케이스, 검증 상태, 이슈 링크, 변경 사유, 승인자를 한 표에서 볼 수 있으면 시작할 수 있습니다. 예를 들어 USR-023이 “외부 협력사 데이터 조회 권한”이라면 관련 설계 산출물은 권한 모델, API 명세, 화면 정책이 될 수 있습니다. 관련 시험 케이스는 권한 있음, 권한 없음, 만료 계정, 다운로드 제한, 로그 기록 검증으로 나뉠 수 있습니다. 변경 사유가 “협력사 범위 확대”라면 어떤 테스트가 다시 돌아야 하는지도 보여야 합니다.

추적성이 약한 명세는 변경 때 흔들립니다. “요구사항을 조금 수정했을 뿐”이라고 생각했는데 시험 케이스, 사용자 교육, 운영 정책, 개인정보 보존, 협력사 계약 범위가 모두 영향을 받을 수 있습니다. 그래서 요구사항 변경은 문장 수정이 아니라 영향 분석입니다. 영향이 작으면 변경 승인도 가볍게 끝날 수 있지만, 영향이 크면 상위 요구사항과 검증 기준을 다시 확인해야 합니다. FDA 설계 입력 자료도 불완전하거나 모호하거나 충돌하는 요구사항을 처리하고, 입력 요구사항을 문서화·검토·승인해야 한다는 점을 강조합니다[S7]. 규제 산업이 아니더라도 이 태도는 R&D 문서 품질에 유용합니다.

추적성 필드	남겨야 하는 내용	빠지면 생기는 문제
source_id	회의록, 사용자 조사, 상위 요구사항, 표준, 규정, 계약 조항	왜 필요한 요구사항인지 설명하기 어려움
parent_requirement	상위 목표 또는 사용자 니즈	기능이 과제 목표와 연결되는지 불명확
verification_method	시험, 분석, 검사, 시연	검증자가 합격 기준을 새로 만들어야 함
acceptance_criteria	수치, 상태, 산출물, 관찰 가능한 기준	완료와 미완료의 경계가 흐림
change_history	변경 전후 문장, 사유, 승인자, 영향받는 시험	변경 후 재검증 범위를 놓침

추적성은 문서를 무겁게 만들기 위한 것이 아닙니다. 오히려 회의 시간을 줄이기 위한 장치입니다. 요구사항 하나를 두고 “왜 넣었는가”, “무엇으로 검증하는가”, “변경되면 어디가 영향을 받는가”를 매번 다시 토론하지 않게 해 줍니다. 특히 R&D 프로젝트처럼 불확실성이 큰 환경에서는 요구사항이 바뀌지 않는 것이 아니라, 바뀐 사실과 이유가 남는 것이 더 중요합니다.

마지막 30분 점검: 기능, 성능, 제약조건을 같은 표에서 분리합니다

요구사항 명세를 제출하기 전에는 새 문장을 더 쓰기보다 기존 문장을 분리해야 합니다. 먼저 기능 요구사항만 필터링합니다. 각 기능이 사용자 역할, 조건, 대상, 시스템 동작, 예외 반응을 갖는지 봅니다. 다음으로 성능 요구사항만 따로 봅니다. 각 성능 문장이 데이터량, 사용자 수, 환경 조건, 측정 지표, 기준값, 측정 방법을 갖는지 확인합니다. 마지막으로 제약조건만 모읍니다. 각 제약이 법규, 표준, 운영 환경, 인터페이스, 보안 정책, 장비 한계, 계약 조건 중 어디에서 왔는지 근거를 붙입니다.

그다음 검증 열을 채웁니다. 각 요구사항 옆에 시험, 분석, 검사, 시연 중 하나를 적고, 합격 기준을 한 줄로 씁니다. 합격 기준을 못 쓰는 요구사항은 아직 요구사항이 아니라 기대나 방향입니다. 그 문장은 삭제하지 말고 “TBR” 또는 검토 필요 상태로 표시하고, 누가 언제 어떤 근거로 해결할지 남깁니다. NASA 지침도 TBD 값을 줄이고 TBR에는 근거, 해소 방법, 책임자, 기한을 남기는 편이 낫다고 안내합니다[S1].

마지막으로 같은 사이트의 다른 R&D 문서와 범위를 나눕니다. 요구사항 문장이 시험 증거와 연결되는 단계는 R&D evidence traceability matrix checklist에서 더 깊게 다루는 편이 맞습니다. 사용자 테스트와 사용성 관찰 증거는 R&D 사용자 테스트 사용성 증거 체크리스트로 분리합니다. 데이터 보존, 공유, 접근권한, 원자료 관리가 중심이면 R&D 데이터 관리계획 체크리스트를 봅니다. 중간 의사결정과 go/no-go 판단은 R&D 마일스톤 gate review 체크리스트가 더 맞습니다.

요구사항 명세의 품질은 문장 수가 아니라 검증 가능한 약속의 수로 결정됩니다. 기능은 사용자의 과업과 시스템 반응으로, 성능은 조건과 기준값으로, 제약조건은 근거와 경계로 써야 합니다. 제출 직전의 가장 좋은 질문은 하나입니다. “이 문장을 모르는 검증자가 읽어도 같은 시험과 같은 합격 기준을 만들 수 있는가?” 그 답이 아니오라면 아직 요구사항이 아니라 해석이 남아 있는 초안입니다.