R&D 과제의 기술문서 폴더가 커질수록 문제는 문서가 없어서 생기지 않습니다. 오히려 문서는 많은데 서로 연결되지 않아서 생깁니다. 요구사항 명세서는 최신이라고 적혀 있지만 어떤 시험성적서가 그 요구사항을 검증했는지 알 수 없고, 시험성적서에는 합격이라고 적혀 있지만 어떤 설계 변경 이후에 다시 수행한 시험인지 표시되지 않습니다. 변경 이력표에는 날짜와 승인자가 있지만 그 변경이 어느 요구사항과 어느 시험 결과를 흔들었는지 보이지 않습니다. 이 상태에서는 최종 보고서, 기술 파일, 인증 검토, 내부 품질 리뷰가 시작될 때마다 같은 질문을 다시 받습니다. "이 결과가 어떤 요구사항의 증거인가요?", "변경 후 재시험했나요?", "이 시험성적서는 폐기된 설계 기준으로 만든 것 아닌가요?"
R&D 기술문서 인덱스 체크리스트의 목적은 파일을 예쁘게 정리하는 것이 아닙니다. 요구사항, 설계 산출물, 시험성적서, 변경 이력, 승인 기록을 하나의 색인으로 연결해 나중에 검토자가 같은 경로를 따라 확인할 수 있게 만드는 것입니다. ISO/IEC/IEEE 29148은 요구사항 공학에서 요구사항 관련 정보 항목과 그 내용을 다루는 표준으로 소개되고, NASA 요구사항 작성 지침은 좋은 요구사항이 명확하고 단일하며 검증 가능해야 한다고 안내합니다[S1][S3]. FDA 설계관리 교육자료는 설계 출력이 설계 입력에 맞는지 평가할 수 있는 기준과 설계 검증의 객관적 증거를 강조하고, DoD 시스템공학 가이드는 요구사항별 검증 방법 식별과 양방향 추적을 반복해서 다룹니다[S5][S6]. 이 근거를 R&D 문서관리 관점으로 옮기면 결론은 단순합니다. 인덱스는 문서 목록이 아니라 "왜 이 문서가 여기에 있고, 무엇을 증명하며, 변경되면 무엇을 다시 봐야 하는가"를 보여주는 연결표여야 합니다.
빠른 결론
R&D 기술문서 인덱스는 최소한 요구사항 ID, 문서 ID, 문서 유형, 최신 버전, 검증 방법, 시험성적서 ID, 합격 기준, 변경 이력 ID, 영향 범위, 승인 상태를 같은 행 또는 같은 연결 구조에서 보여줘야 합니다. 폴더명과 파일명만으로는 충분하지 않습니다. 검토자가 요구사항 하나를 선택했을 때 관련 설계 문서, 시험성적서, 변경 승인, 재시험 필요 여부까지 역추적할 수 있어야 합니다.
기술문서 인덱스는 파일 목록이 아니라 검증 경로입니다
많은 팀이 기술문서 인덱스를 처음 만들 때 엑셀 한 장에 파일명, 작성자, 날짜, 버전만 적습니다. 이 방식은 파일을 찾는 데는 도움이 되지만 검증에는 부족합니다. R&D 문서에서 중요한 질문은 "파일이 어디 있는가"가 아니라 "이 파일이 어떤 판단을 뒷받침하는가"입니다. 요구사항 명세서가 있으면 그 요구사항을 만족했다는 시험성적서가 있어야 하고, 시험성적서가 있으면 시험 조건과 합격 기준이 요구사항과 맞아야 합니다. 변경 이력이 있으면 변경 전후로 영향을 받는 요구사항과 시험이 표시되어야 합니다.
NASA의 요구사항 검토 체크리스트는 요구사항이 고유하게 참조될 수 있어야 하며 상위 요구사항이나 범위와 양방향으로 추적 가능해야 한다고 봅니다[S1]. 이 원칙을 기술문서 인덱스에 적용하면 모든 핵심 문서에는 독립적인 문서 ID가 필요합니다. REQ-014, TEST-014-02, CR-2026-07-03-01처럼 사람이 읽을 수 있고 중복되지 않는 ID를 부여해야 합니다. 파일명은 바뀔 수 있지만 ID는 바뀌면 안 됩니다. 파일명이 시험성적서_최종_수정본2.xlsx라면 검토자는 최신성을 판단할 수 없습니다. 반면 TEST-014-02_센서정확도_설계변경CR-08후_재시험.pdf처럼 요구사항과 변경 이력을 포함하면 파일명만 보아도 연결 경로가 보입니다.
첫 번째 체크포인트는 인덱스의 행 단위를 정하는 것입니다. 문서 하나가 한 행인지, 요구사항 하나가 한 행인지, 시험 하나가 한 행인지 결정해야 합니다. 요구사항 추적이 핵심이라면 요구사항 ID를 기준 행으로 잡는 편이 좋습니다. 요구사항 하나에 설계 문서, 시험성적서, 변경 이력을 여러 칸으로 연결하면 빠르게 누락을 찾을 수 있습니다. 반대로 문서 제출 목록이 핵심이라면 문서 ID를 기준 행으로 잡고 관련 요구사항과 검증 결과를 연결합니다. 어느 쪽을 선택해도 괜찮지만, 한 인덱스 안에서 기준을 계속 바꾸면 안 됩니다.
| 인덱스 방식 | 기준 행 | 적합한 상황 | 빠지기 쉬운 정보 |
|---|---|---|---|
| 요구사항 기준 | 요구사항 ID | 요구사항별 시험 증거와 변경 영향을 확인해야 할 때 | 문서 제출 상태, 원본 파일 위치 |
| 문서 기준 | 문서 ID | 기술 파일 제출 목록과 승인 상태가 중요할 때 | 요구사항별 검증 누락 |
| 시험 기준 | 시험 항목 또는 시험성적서 ID | 시험 재수행, 합격 기준, 시험 조건 관리가 중요할 때 | 상위 요구사항과 변경 사유 |
| 변경 기준 | 변경요청 ID | 변경 영향 분석과 재시험 판단이 중요할 때 | 변경 전 이미 유효했던 증거 |
요구사항 ID는 시험성적서와 변경 이력을 묶는 첫 번째 키입니다
요구사항 ID가 약하면 인덱스 전체가 약해집니다. "사용자는 결과를 조회할 수 있어야 한다" 같은 문장은 기능 방향을 말하지만 시험성적서와 연결하기 어렵습니다. 어떤 사용자, 어떤 결과, 어떤 조건, 어떤 응답 시간, 어떤 예외 상태를 말하는지 알 수 없기 때문입니다. NASA 지침은 요구사항이 모호한 표현을 피하고 단일 생각을 담아야 하며 시험, 시연, 검사, 분석 등으로 만족 여부를 보일 수 있어야 한다고 설명합니다[S1]. 따라서 인덱스에 올릴 요구사항은 먼저 검증 가능한 문장으로 다듬어야 합니다.
예를 들어 REQ-021: 시스템은 분석 결과를 조회할 수 있어야 한다는 인덱스 키로 약합니다. 이를 REQ-021: 승인된 연구자는 과제 ID와 시료 ID로 분석 결과를 조회할 수 있어야 하며, 조회 결과에는 측정값, 단위, 장비 ID, 측정 시각, 결과 상태가 표시되어야 한다로 바꾸면 시험 항목이 생깁니다. 여기에 성능 요구사항 REQ-021-P1: 10만 건 이하 데이터 조건에서 p95 응답 시간은 3초 이내여야 한다를 분리하면 시험성적서에는 기능 시험과 성능 시험을 따로 연결할 수 있습니다. 변경 이력도 더 분명해집니다. 장비 ID 표시 방식이 바뀌면 REQ-021이 영향받고, 응답 시간 기준이 바뀌면 REQ-021-P1이 영향받습니다.
인덱스에서 요구사항 ID는 다음 문서와 연결되어야 합니다. 첫째, 요구사항의 출처입니다. 사용자 인터뷰, 과제 제안서, 규격, 내부 품질 기준, 법규 요구, 계약 조건 중 어디에서 온 요구사항인지 적습니다. 둘째, 설계 산출물입니다. 요구사항을 만족시키기 위해 작성된 화면 설계, 알고리즘 설명, 회로 설계, 인터페이스 명세, 데이터 모델을 연결합니다. 셋째, 검증 산출물입니다. 시험 계획서, 시험성적서, 분석 보고서, 검사 기록, 시연 결과를 연결합니다. 넷째, 변경 이력입니다. 요구사항 문장이나 합격 기준이 바뀌었는지, 설계만 바뀌었는지, 시험 조건이 바뀌었는지 표시합니다.
| 필드 | 필수 여부 | 작성 예시 | 검토자가 확인하는 질문 |
|---|---|---|---|
| requirement_id | 필수 | REQ-021 | 요구사항을 고유하게 찾을 수 있는가 |
| requirement_statement | 필수 | 승인된 연구자는 과제 ID와 시료 ID로 분석 결과를 조회할 수 있어야 한다 | 시험 가능한 문장인가 |
| source_id | 권장 | VOC-03, SPEC-02, REG-01 | 왜 필요한 요구사항인가 |
| design_doc_id | 필수 | DES-021, API-021 | 어떤 설계가 이 요구사항을 구현하는가 |
| verification_method | 필수 | test, analysis, inspection, demonstration | 어떻게 검증하는가 |
| test_report_id | 필수 | TR-021-01 | 어떤 시험성적서가 증거인가 |
| change_request_id | 조건부 필수 | CR-08 | 어떤 변경이 영향을 주었는가 |
시험성적서는 합격 표시보다 요구사항-조건-결과 연결이 중요합니다
시험성적서가 인덱스에 연결될 때 가장 흔한 실패는 "합격"만 적는 것입니다. 합격이라는 단어는 결과 요약일 뿐입니다. 검토자가 알고 싶은 것은 어떤 요구사항을 어떤 조건에서 어떤 방법으로 검증했고, 어떤 기준으로 합격을 판단했는지입니다. FDA 설계관리 교육자료는 설계 출력이 설계 입력에 적합한지 평가할 수 있도록 문서화하고, 설계 검증은 설계 출력이 설계 입력을 충족한다는 객관적 증거라고 설명합니다[S5]. R&D 일반 문서에서도 이 구조는 그대로 유효합니다. 시험성적서는 요구사항의 객관적 증거가 되어야 하며, 인덱스는 그 증거의 위치와 적용 범위를 알려줘야 합니다.
시험성적서 ID는 단독으로 존재하지 않아야 합니다. TR-021-01이 있다면 인덱스에는 REQ-021, 시험 방법, 시험 환경, 시험 일자, 시험자, 장비 ID, 시료 ID, 합격 기준, 결과 요약, 원본 파일 위치가 함께 있어야 합니다. 특히 변경 후 재시험이 필요한 프로젝트라면 시험성적서의 유효 버전을 표시해야 합니다. TR-021-01은 변경 전 설계 기준에서 수행한 시험이고, TR-021-02는 CR-08 이후 재시험이라면 두 문서를 모두 보관하되 현재 유효 증거는 TR-021-02라고 표시해야 합니다. 이전 시험성적서를 삭제하지 않는 이유는 변경 판단의 흐름을 보존하기 위해서입니다.
DoD 시스템공학 가이드는 검토 단계에서 모든 요구사항에 검증 방법이 식별되어야 한다고 설명하고, 기능 기준선이 요구사항과 검증 내용을 포함한다고 안내합니다[S6]. 인덱스에 적용하면 각 시험성적서 행에는 최소한 검증 방법과 연결 요구사항이 있어야 합니다. 시험 보고서 파일이 있어도 요구사항 ID가 비어 있으면 그 파일은 제출 자료일 수는 있어도 추적 가능한 증거는 아닙니다. 반대로 요구사항 ID는 있는데 시험 조건이 비어 있으면 같은 시험을 재현하거나 변경 후 재시험 범위를 정하기 어렵습니다.
시험성적서 연결 체크
- 시험성적서 ID가 요구사항 ID와 직접 연결되어 있는가?
- 시험 방법이 test, analysis, inspection, demonstration 중 하나로 표시되어 있는가?
- 합격 기준이 수치, 상태, 산출물, 허용 오차 중 하나로 읽히는가?
- 시험 환경, 장비, 시료, 데이터셋, 소프트웨어 버전이 기록되어 있는가?
- 변경 후 재시험인지, 최초 시험인지, 참고용 이전 시험인지 구분되어 있는가?
- 시험성적서 원본 파일과 인덱스의 요약 값이 서로 맞는가?
변경 이력은 문서 버전표가 아니라 영향 분석표여야 합니다
변경 이력을 단순히 날짜, 작성자, 변경 내용으로만 적으면 나중에 재시험 범위를 판단할 수 없습니다. "분석 결과 화면 수정"이라는 변경 내용은 너무 넓습니다. 어떤 요구사항이 바뀌었는지, 어떤 설계 문서가 바뀌었는지, 어떤 시험성적서를 새로 만들었는지, 기존 시험성적서를 계속 유효하게 볼 수 있는지 표시해야 합니다. NIST SSDF는 소스 코드와 구성 정보에 대한 변경을 계정 책임성과 함께 추적하는 예를 제시하고, 설계 결정과 위험 대응 기록을 필요에 따라 갱신하는 실무를 다룹니다[S7]. 소프트웨어 보안 문맥의 지침이지만, 변경 이력을 책임성과 증거 갱신으로 다루는 관점은 R&D 기술문서 인덱스에도 잘 맞습니다.
변경 이력 ID는 요구사항 ID와 시험성적서 ID 사이의 다리입니다. 예를 들어 CR-08이 "장비 ID 표시 형식 변경"이라면 영향받는 요구사항은 REQ-021, 설계 문서는 API-021, 시험성적서는 TR-021-02가 됩니다. 이때 TR-021-01은 폐기하지 않고 superseded_by: TR-021-02로 표시합니다. 변경 사유가 사용자 혼동 해소라면 출처는 사용자 피드백 문서가 될 수 있고, 변경 사유가 외부 규격 변경이라면 규격 문서가 출처가 됩니다. 중요한 것은 변경 내용만 쓰는 것이 아니라 변경의 근거와 영향 범위를 함께 쓰는 것입니다.
ISO의 문서화 정보 지침은 문서화 정보가 메시지 전달, 수행 증거, 지식 공유에 쓰일 수 있고, 조직은 프로세스 운영과 효과성을 입증할 만큼의 문서화 정보를 결정할 수 있다고 설명합니다[S8]. 이 말은 모든 변경에 과도한 양식이 필요하다는 뜻이 아닙니다. 작은 오탈자 수정과 합격 기준 변경을 같은 무게로 다루면 문서관리가 무거워집니다. 대신 변경 등급을 둡니다. 문장 표현만 바꾼 변경은 minor, 요구사항 의미나 합격 기준을 바꾼 변경은 major, 시험 결과의 유효성을 흔드는 변경은 verification-impact처럼 구분합니다. 이 등급이 있어야 검토자는 재시험이 필요한 변경과 기록만 남기면 되는 변경을 빠르게 가릅니다.
| 변경 필드 | 작성 예시 | 인덱스에서 하는 역할 |
|---|---|---|
| change_request_id | CR-08 | 변경을 고유하게 참조합니다 |
| change_type | requirement, design, test, document-only | 변경 성격을 구분합니다 |
| impacted_requirement_ids | REQ-021, REQ-021-P1 | 영향받는 요구사항을 찾습니다 |
| impacted_test_report_ids | TR-021-01, TR-021-02 | 이전 증거와 새 증거를 비교합니다 |
| retest_required | yes, no, partial | 재시험 판단을 남깁니다 |
| approval_record_id | APR-08 | 누가 어떤 근거로 승인했는지 연결합니다 |
| effective_version | v1.3 | 현재 유효한 문서 버전을 표시합니다 |
인덱스 필드는 최소 10개에서 시작하고, 부족하면 늘립니다
처음부터 완벽한 PLM이나 QMS 도구를 만들 필요는 없습니다. 작은 R&D 팀이라면 스프레드시트 하나로도 충분히 시작할 수 있습니다. 다만 필드가 너무 적으면 나중에 다시 만들게 됩니다. 최소 필드는 요구사항, 문서, 시험, 변경, 승인, 위치를 모두 포함해야 합니다. 이 6개 축이 있어야 요구사항에서 시험성적서로, 시험성적서에서 변경 이력으로, 변경 이력에서 승인 근거로 이동할 수 있습니다.
필드 설계에서 중요한 원칙은 자유 텍스트와 선택값을 분리하는 것입니다. verification_method처럼 반복해서 쓰는 항목은 선택값으로 관리합니다. test, analysis, inspection, demonstration처럼 표준화하면 필터링이 쉬워집니다. 반대로 변경 사유처럼 맥락이 필요한 항목은 자유 텍스트가 필요합니다. 모든 것을 자유 텍스트로 만들면 검색이 어렵고, 모든 것을 선택값으로 만들면 실제 변경 사유를 설명하기 어렵습니다.
| 필드명 | 필수 | 예시 | 작성 기준 |
|---|---|---|---|
| requirement_id | 예 | REQ-021 | 요구사항별 고유 ID |
| document_id | 예 | DES-021, TR-021-02 | 문서별 고유 ID |
| document_type | 예 | requirement, design, test_report, change_record | 문서 유형 선택값 |
| version | 예 | v1.3 | 승인된 최신 버전 |
| status | 예 | draft, review, approved, superseded | 문서 상태 |
| verification_method | 조건부 | test | 요구사항 또는 시험 문서에 필수 |
| acceptance_criteria | 조건부 | p95 3초 이내 | 시험 가능 기준 |
| source_or_parent | 권장 | VOC-03, SPEC-02 | 요구사항의 출처 또는 상위 요구 |
| change_request_id | 조건부 | CR-08 | 변경 영향이 있으면 필수 |
| approval_record_id | 조건부 | APR-08 | 승인 필요한 문서에 필수 |
| file_location | 예 | /technical-file/test/TR-021-02.pdf | 원본 위치 |
| retention_note | 권장 | 최종보고 후 5년 보관 | 보관 기준 |
이 필드들은 문서관리 담당자만을 위한 것이 아닙니다. 개발자는 어떤 설계 문서가 최신인지 확인하고, 시험 담당자는 어떤 요구사항을 시험해야 하는지 찾고, PM은 변경 후 재시험 범위를 판단하며, 검토자는 최종 보고서의 증거 사슬을 확인합니다. 따라서 필드명은 조직 내부에서 합의한 언어로 고정해야 합니다. 같은 의미를 test result, 시험결과, 성적서, 검증자료처럼 섞어 쓰면 인덱스가 커질수록 검색 정확도가 떨어집니다.
요구사항-시험성적서-변경 이력을 한 줄로 읽는 매트릭스 예시
인덱스가 제대로 작동하는지 확인하는 가장 빠른 방법은 요구사항 하나를 골라 한 줄로 읽어보는 것입니다. "REQ-021은 VOC-03에서 왔고, DES-021과 API-021로 설계되었으며, TR-021-02에서 CR-08 이후 재시험되어 합격했고, APR-08로 승인되었다." 이 문장이 자연스럽게 만들어지면 인덱스가 일하고 있는 것입니다. 반대로 "REQ-021은 있는데 시험성적서가 어디 있는지 모르고, 변경 기록은 있지만 재시험 여부를 모른다"면 파일은 있어도 추적성은 없습니다.
NASA 시스템공학 핸드북 부록은 양방향 추적성을 특정 요구사항이나 기대를 상위 요구사항과 하위 요구사항으로 추적할 수 있는 능력으로 설명합니다[S2]. R&D 인덱스에서는 여기에 시험성적서와 변경 이력이 추가됩니다. 상위 요구사항과 하위 요구사항만 연결하면 설계 구조는 보이지만, 실제 검증 증거는 보이지 않을 수 있습니다. 따라서 기술문서 인덱스에는 요구사항 계층, 검증 산출물, 변경 기록이 모두 들어가야 합니다.
| requirement_id | design_doc_id | verification_method | test_report_id | change_request_id | current_evidence | review_question |
|---|---|---|---|---|---|---|
| REQ-021 | DES-021, API-021 | test | TR-021-02 | CR-08 | valid | 변경 후 재시험 결과가 최신인가 |
| REQ-021-P1 | PERF-021 | test, analysis | TR-021-P1-01 | 없음 | valid | 성능 시험 조건이 운영 조건과 맞는가 |
| REQ-034 | UI-034 | inspection, demonstration | DEMO-034-01 | CR-11 | partial | 화면 변경 후 시연 기록이 다시 필요한가 |
| REQ-040 | SEC-040 | analysis, test | TR-040-03 | CR-12 | pending | 권한 변경 후 접근 로그 시험이 끝났는가 |
이 표에서 핵심은 current_evidence입니다. 모든 시험성적서가 현재 증거는 아닙니다. 어떤 문서는 이전 설계를 설명하는 이력이고, 어떤 문서는 변경 전 참고 자료이며, 어떤 문서는 아직 승인되지 않은 초안입니다. 인덱스는 이 차이를 드러내야 합니다. 특히 최종 기술 파일을 만들 때는 valid 증거만 제출 자료로 묶고, superseded 문서는 변경 이력의 근거로 남기는 방식이 안전합니다.
폴더 구조와 파일명은 인덱스 규칙을 따라야 합니다
인덱스가 좋아도 폴더와 파일명이 무질서하면 현장에서 쓰기 어렵습니다. 폴더는 문서 유형 기준으로 나누되, 파일명에는 문서 ID와 핵심 연결 키를 넣습니다. 예를 들어 요구사항 문서는 /01_requirements/REQ-index.xlsx, 설계 문서는 /02_design/DES-021_API-result-view_v1.3.pdf, 시험성적서는 /03_verification/TR-021-02_REQ-021_CR-08.pdf, 변경 이력은 /04_change/CR-08_result-field-format-change.pdf처럼 관리할 수 있습니다. 중요한 것은 파일명이 인덱스의 문서 ID와 맞아야 한다는 점입니다.
파일명에 너무 많은 정보를 넣을 필요는 없습니다. 모든 필드는 인덱스에 있고, 파일명은 사람이 찾을 수 있는 최소 정보만 담으면 됩니다. 권장 조합은 문서ID_대상요구사항_핵심주제_버전입니다. 시험성적서라면 변경 후 재시험 여부가 중요하므로 CR-ID를 추가합니다. 승인본과 초안이 함께 있을 때는 파일명보다 인덱스의 status를 우선합니다. 파일명에 final이 있어도 인덱스 상태가 superseded라면 최신 증거가 아닙니다.
위험한 파일명 신호
최종,진짜최종,수정본,최종_수정처럼 버전 판단을 사람 기억에 맡기는 이름
- 요구사항 ID나 시험성적서 ID 없이 날짜와 제목만 있는 파일명
- 변경 후 재시험 자료인데 변경요청 ID가 없는 시험성적서
- 승인본과 초안이 같은 폴더에 있지만 상태값이 없는 문서
- 원본 PDF, 편집 파일, 캡처 이미지가 같은 문서 ID 없이 흩어진 구조
제출 전 30분 체크리스트: 누락은 링크가 끊긴 곳에서 나옵니다
기술문서 인덱스를 제출 전 검토할 때는 모든 문서를 다 읽기보다 연결이 끊긴 곳을 찾는 편이 빠릅니다. 요구사항 ID가 있는데 시험성적서 ID가 없으면 검증 누락입니다. 시험성적서 ID가 있는데 합격 기준이 없으면 결과 판단 누락입니다. 변경 이력 ID가 있는데 영향받는 요구사항이 없으면 변경 영향 분석 누락입니다. 승인 기록이 있는데 승인 대상 버전이 없으면 승인 근거 누락입니다. 이런 누락은 문서 품질보다 색인 구조에서 먼저 드러납니다.
다음 순서로 30분만 점검해도 큰 결함을 찾을 수 있습니다. 먼저 요구사항 ID 열을 필터링해 빈 값과 중복 값을 찾습니다. 둘째, 모든 approved 문서가 파일 위치와 버전을 갖고 있는지 봅니다. 셋째, 요구사항별 verification_method와 test_report_id가 비어 있는 행을 찾습니다. 넷째, change_request_id가 있는 행에서 retest_required와 impacted_test_report_ids를 확인합니다. 다섯째, superseded 문서가 현재 증거로 잘못 표시되어 있지 않은지 봅니다.
최종 인덱스 체크리스트
- 모든 요구사항에 고유한 requirement_id가 있는가?
- 요구사항 문장이 시험, 분석, 검사, 시연 중 하나로 검증 가능한가?
- 각 요구사항에 관련 설계 문서와 시험성적서가 연결되어 있는가?
- 시험성적서에는 시험 조건, 합격 기준, 결과 요약, 원본 위치가 있는가?
- 변경 이력은 변경 내용뿐 아니라 영향받는 요구사항과 시험성적서를 표시하는가?
- 변경 후 재시험 필요 여부와 실제 재시험 문서가 맞는가?
- 승인 기록은 승인 대상 문서 ID와 버전을 명확히 가리키는가?
- 폐기된 문서와 현재 유효 증거가 상태값으로 구분되는가?
- 파일명, 폴더 경로, 인덱스의 문서 ID가 서로 일치하는가?
- 검토자가 요구사항 하나에서 시험성적서와 변경 이력까지 역추적할 수 있는가?
인덱스가 정리되면 다음 단계는 문서 자체의 품질을 올리는 것입니다. 요구사항 문장이 아직 모호하다면 R&D 사용자 요구사항 명세 체크리스트에서 기능, 성능, 제약조건을 먼저 분리합니다. 요구사항과 시험 증거를 더 촘촘히 묶어야 한다면 R&D evidence traceability matrix checklist로 확장합니다. 사용자 시험이나 사용성 증거가 핵심이면 R&D 사용자 테스트 사용성 증거 체크리스트를 별도로 둡니다. 데이터 보관, 접근권한, 원자료 관리가 약하다면 R&D 데이터 관리계획 체크리스트에서 데이터 축을 분리해 관리하는 편이 좋습니다.
R&D 기술문서 인덱스의 성패는 문서 수가 아니라 질문에 답하는 속도로 드러납니다. 요구사항 하나를 골랐을 때 어느 시험성적서가 증거인지, 어떤 변경 이후 다시 시험했는지, 누가 어떤 버전을 승인했는지 바로 보이면 인덱스는 충분히 일하고 있습니다. 반대로 파일은 많지만 연결 경로가 보이지 않으면 최종 검토 때마다 같은 설명을 반복하게 됩니다. 인덱스는 문서의 목차가 아니라 요구사항, 시험성적서, 변경 이력을 잇는 검증 지도입니다.
R&D 기술문서 인덱스 체크리스트 참고 출처
- [S1] NASA, Appendix C: How to Write a Good Requirement
- [S2] NASA, System Engineering Handbook: Appendix
- [S3] ISO, ISO/IEC/IEEE 29148:2018 Requirements engineering
- [S4] IEEE SA, IEEE/ISO/IEC 29148-2018
- [S5] FDA, Design Controls training material
- [S6] U.S. DoD OUSD(R&E), Systems Engineering Guidebook
- [S7] NIST SP 800-218, Secure Software Development Framework
- [S8] ISO, Guidance on the requirements for Documented Information of ISO 9001:2015