각 엔지니어링 프로세스 별 입력값, 기대값 비교

시스템 요구사양서, 시스템 아키텍처 설계서, 소프트웨어 요구사양서, 소프트웨어 아키텍처 설계서, 소프트웨어 상세 설계서의 테스트 케이스에 적힌 기대값이 어떻게 생겼는지 궁금해 비교해서 각 차이가 비교될 수 있도록 알려줘

 

 

각 문서의 테스트 케이스 기대값 비교

자동차 소프트웨어 개발(예: ASPICE, ISO 26262 준수)에서 V-Model 프로세스를 기반으로, 각 문서의 테스트 케이스는 개발 단계에 따라 수준이 다릅니다. 테스트 케이스의 "기대값(Expected Values/Results)"은 테스트 입력에 대한 예상 출력이나 상태를 의미하며, 문서의 추상화 수준(abstraction level)에 따라 고수준(what the system does)에서 저수준(how it does internally)으로 구체화됩니다. 이는 요구사항 추적성(traceability)을 보장하며, 검증(verification)과 유효성 검사(validation)를 위해 사용됩니다.

아래 테이블에서 각 문서를 비교합니다. 열은 문서 이름, 테스트 케이스 수준(예: 통합/단위), 기대값의 특징, 예시, 그리고 주요 차이점을 포함합니다. 이는 소프트웨어 공학 표준(예: ISO 26262 Part 6: 소프트웨어 개발, ASPICE SWE 프로세스)에서 유도된 일반적 패턴을 기반으로 합니다. 실제 프로젝트에서는 테일러링(조정)이 적용될 수 있습니다

 

.

추가 설명

• 공통 원칙: 모든 기대값은 요구사항 추적성(matrix)을 통해 상위 문서와 연결되어야 합니다(ISO 26262 Part 4/6, ASPICE SWE.3/4 요구). 기대값은 measurable(측정 가능)해야 하며, pass/fail 기준 포함. ASPICE에서는 프로세스 평가를 위해, ISO 26262에서는 ASIL 기반 안전 검증을 위해 사용.
• 차이의 근본 이유: 개발 단계 하향식(top-down). SRS는 "무엇(what)"을, 디자인 문서는 "어떻게(how)"를 다루며, 기대값의 세밀도가 증가합니다. 예를 들어, SRS 기대값은 사용자 시나리오 중심이지만, 상세 설계는 fault injection(결함 주입) 테스트처럼 내부 오류 처리까지 포함.
• 실제 적용 팁: 테스트 케이스는 IEEE 829 표준 형식(ID, 입력, 기대값, 실제값)으로 작성. LLM(예: ChatGPT) 도구로 자동 생성 가능하지만, 수동 검토 필수.