통합 차량 관제 시스템 용어 사전
설계 원칙

아키텍처 제약 요구사항

구조 자체가 안전 요구사항이 되는 경우. SR 이 내부 구조를 언급하는 예외를 만든다.

§9 는 "Controller 간 내부 명령 전달, 상태 교환, 세부 중재 및 실행 메커니즘은 SysRS 또는 설계 문서에서 정의한다"고 못 박는다. 그런데 §6.2.5 는 내부 구조를 언급한다.

"윈도우 제어 관련 통신 오류가 발생하더라도 로컬 윈도우 제어기에서 수행하는 Anti-pinch 보호 기능을 유지해야 한다."

왜 예외가 허용되나

**"통신이 끊겨도 Anti-pinch 가 동작한다"는 관찰 가능한 결과인데, 그 결과를 보장하는 유일한 방법이 "로컬에서 수행"**이기 때문이다. 구조가 곧 요구사항이 된다.

이런 걸 아키텍처 제약 요구사항(architectural constraint)이라 부르고, SR 에 들어가는 것이 정당하다.

코드에서 검증 가능한 형태가 된다

/* app/window/safety.c — 의존성을 의도적으로 최소화 */
#include "drv/hbridge.h"
#include "app/window/position.h"
/* com/ · svc/req 를 include 하지 않는다 — 통신 없이 동작해야 한다 */

#include 목록 자체가 요구사항 준수의 증거가 된다. 코드 리뷰에서 safety.ccom/ 헤더가 추가되면 즉시 반려할 수 있다.

남용하면 안 된다

이런 예외는 안전상 필요할 때만 쓴다. 남용하면 SR 이 설계서가 되어, 구현 방식을 바꿀 때마다 요구사항을 고쳐야 한다.

함께 보면 좋은 용어

노트에서 맥락과 함께 보기 — 요구사항 관리 — SR 작성 원칙·TBD 32건·리뷰 결과