요구사항 없는 개발이 가능한 실무 상황

임베디드 소프트웨어 개발 현장에서는 요구사항 문서 없이 프로젝트가 시작되는 경우가 많습니다.

팀원끼리 구두로 “이렇게 하면 되겠지”라고 합의해서 개발을 진행하지만,

이 방식의 가장 큰 리스크는

새로운 인력이 투입될 때, 참고할 수 있는 공식 자료가 없다는 점입니다.

결국, 기존 개발자만 알던 ‘암묵적 기준’에 의존하게 되어

• 신규 인력은 코드만 보며 해석에 의존하게 되고
• 변경 요청, 유지보수, 인수인계 시 오해와 품질 저하가 반복됩니다.

[개발자A]: "이거 이렇게 해도 돼요?"
[개발자B]: "예전에 이렇게 했었어요"
[개발자C]: "아, 그건 OOO선임님만 알아요"
...
[신규 개발자]: "자료가 없어서 기존 코드만 봅니다..."

ASPICE 요구 시 필수 프로세스와 단계

ASPICE(Automotive SPICE)는 소프트웨어 개발을 구조적으로 관리하기 위한 표준입니다.

ASPICE의 소프트웨어 엔지니어링 영역(SWE.1~SWE.6)은 다음과 같이 단계별로 구성되어 있습니다.

업무를 진행하는 순서는 아래와 같습니다.

[SWE.1 요구분석]
	↓
[SWE.2 아키텍처]
	↓
[SWE.3 상세설계/구현]
	↓
[SWE.4 단위테스트]
	↓
[SWE.5 통합테스트]
	↓
[SWE.6 적합성테스트]

요구사항, 검증 가능성, 그리고 SWE.6에 대한 실무적 오해

실무에서 “요구사항 만들 때 적합성 테스트도 동시에 개발하라”는 말을 많이 듣습니다.

이건 “요구사항을 정의할 때, SWE.6(적합성 테스트)에서 이걸 실제로 어떻게 검증할 것인지까지 반드시 고려하라”는 의미입니다.

즉,

• 요구사항을 만들 때 “테스트 가능한 요구인지, 결과가 명확히 확인될 수 있는지”
  • (예: “자동 문은 3초 이내에 잠긴다”, “ABS는 오작동 시 1초 내 복구된다” 등)
• 이후 SWE.6 단계에서 이 요구사항을 바탕으로 구체적인 테스트케이스(Test Case)를 만들고
• 실제 테스트(검증) 실행 및 결과(테스트 리포트)는 개발/통합이 끝난 후에 수행합니다.

ISO 26262 기준에서의 요구사항, 설계, 테스트 연계

ISO 26262는 자동차 기능안전 표준입니다.

이 표준은 Safety Goal(안전 목표) → SW 요구사항 → 설계 → 구현(코드) → 테스트

모든 단계가 반드시 추적성(traceability) 있게 명확하게 연결되어 있어야 함을 요구합니다.

예를 들어

• Safety Goal이 실제 SW 요구사항에 어떻게 반영됐는지
• 그 요구사항이 설계/코드의 어떤 부분에 구현됐는지
• 이 기능이 어떤 테스트케이스에서 실제로 검증됐는지

문서와 도구(요구사항 관리툴, 설계 문서, 테스트 기록 등)로 추적할 수 있어야 합니다.

표준 요구와 실전 개발의 괴리

실제 프로젝트에서는

• 문서상 요구사항과 실제 구현 코드가 다르거나
• 테스트케이스가 요구사항을 반영하지 못하는 등 표준과 현실의 괴리가 자주 발생합니다.

특히, 문서화 없이 개발하면

누가 어떤 기준으로 개발했는지, 왜 변경됐는지,

어디서 오류가 생겼는지 아무도 설명할 수 없는 상황이 빈번합니다.

표준 문서화의 실질적 의미와 실무 대응 전략

문서화의 핵심 목적은

“누가 들어와도, 언제든 근거와 의도를 이해할 수 있게 만드는 것”입니다.

실무에서는

• 요구사항, 설계, 테스트의 핵심 근거와 의도를 문서로 남기고
• 변경 이력과 리뷰 기록을 협업툴/추적 매트릭스 등으로 관리해야 하며
• “문서가 목적이 아니라, 실제 지식과 품질의 기반”임을 모두가 이해하는 것이 필수입니다.