요구사항 관리에서 얻은 교훈: S-80 잠수함 프로그램

S-80 잠수함 프로그램은 하드웨어 제품 개발 프로젝트에서 요구사항, 제약 조건, 설계 변경, 검증 점검이 왜 서로 연결된 상태를 유지해야 하는지를 보여줍니다.

하드웨어 제품 개발에서는 하나의 설계 변경이 당장의 문제를 해결하는 동시에 시스템의 다른 부분에서 새로운 문제를 야기할 수 있습니다. 그렇기 때문에 요구사항 관리는 단순히 제품이 무엇을 해야 하는지를 정의하는 데 그치지 않고, 설계가 발전하는 과정에서 관련 제약 조건, 설계 결정, 검증 점검을 계속 보이도록 유지하는 일까지 포함합니다.

스페인의 S-80 잠수함 프로그램은 이 패턴을 분명하게 보여줍니다. 개발 과정에서 이 프로그램은 중량과 부력에 관한 중대한 문제에 직면했습니다. 재설계는 그 문제를 해결하는 데 도움이 되었지만, 업데이트된 선체 치수는 새로운 현실적 문제를 낳았습니다. 잠수함이 원래 사용하도록 계획된 항구에 비해 너무 길어진 것입니다.

여기에는 잠수함이든 전자 기기든 하드웨어 제품을 개발하는 모든 팀에 적용할 수 있는 교훈이 있습니다. 요구사항, 제약 조건, 설계 변경, 검증 점검이 서로 분리되어 있으면, 변경이 다른 무엇에 영향을 미칠 수 있는지 팀이 파악하기 어려워집니다.

핵심 요점

• 요구사항 충돌은 중요한 제약 조건이 설계 변경을 검토하는 워크플로우 밖에 있을 때 자주 드러납니다.
• 팀은 요구사항을 연결함으로써 그것이 영향을 미치는 제약 조건, 설계 결정, 검증 점검과 연계해 이러한 위험을 줄일 수 있습니다.
• 연결된 요구사항 워크플로우를 사용하면 무엇이 변경되었고, 무엇에 영향을 미치며, 어떤 항목을 검토해야 하는지 재작업 비용이 커지기 전에 더 쉽게 파악할 수 있습니다.

S-80 프로그램에서 실제로 일어난 일

스페인은 새로운 잠수함급을 개발하기 위해 S-80 프로그램을 시작했습니다. 개발 도중 이 프로그램은 심각한 중량 및 부력 문제에 직면했습니다. 함정의 무게가 계획보다 무거워지면서, 잠항 후 안정적으로 수면 위로 부상할 수 있을 만큼 충분한 부력 여유를 확보했는지에 대한 우려가 제기되었습니다.

이 문제를 해결하기 위해 설계가 수정되었습니다. 핵심 변경 사항 중 하나는 선체를 더 길게 만드는 것이었고, 이는 필요한 부력 여유를 회복하는 데 도움이 되었습니다. 하지만 이 수정은 함정의 물리적 치수도 바꾸었습니다. 이후 업데이트된 잠수함은 운용될 인프라와의 적합성 검토를 받아야 했고, 그 검토 결과 현실적인 문제가 드러났습니다. 더 이상 해당 항구에 들어갈 수 없게 된 것입니다.

이 인프라 문제는 이미 대규모 재설계가 필요했던 프로그램에 또 하나의 작업 부담을 더했습니다. 결국 이 프로그램은 원래 예상보다 더 복잡해지고, 더 오랜 시간이 걸렸으며, 더 많은 비용이 들게 되었습니다.

이 사례는 모든 재설계가 결국 한 가지 질문을 더 남긴다는 점을 일깨워 줍니다. 이제 또 무엇을 확인해야 하는가?

하드웨어 팀이 S-80 사례에서 배울 수 있는 점

대부분의 하드웨어 팀은 잠수함 프로그램보다 훨씬 작은 규모로 일하지만, 동일한 패턴은 일상적인 제품 개발에서도 나타날 수 있습니다. 하나의 설계 변경이 팀이 현재 해결하려는 문제를 넘어 크기, 규정 준수 요구사항, 인터페이스 제약 조건에 영향을 줄 수 있기 때문입니다.

이러한 제약 조건을 아는 것만으로는 충분하지 않습니다. 바로 이 지점에서 요구사항 관리가 중요합니다. 요구사항 관리는 설계가 발전하는 동안 이러한 요소들을 계속 보이게 하고, 서로 연결하며, 검토 가능하게 유지하도록 돕습니다. 하드웨어 팀에게 이는 다음과 같은 세 가지 실질적인 습관으로 요약됩니다.

중요한 제약 조건을 눈에 보이게 유지하기

중요한 제약 조건은 회의 메모, 스프레드시트, 또는 누군가의 기억 속에만 존재해서는 안 됩니다. 이러한 조건은 명확하게 문서화되어야 하며, 가능하다면 설계가 변경될 때 팀이 확인할 수 있도록 측정 가능한 형태로 작성되어야 합니다.

요구사항을 설계 결정과 연결하기

요구사항은 그것이 영향을 미치는 시스템 영역, 블록, 설계 객체 또는 엔지니어링 활동과 연결될 때 더 큰 가치를 가집니다. 이러한 연결은 엔지니어가 특정 설계 결정이 왜 중요한지, 어떤 요구사항을 뒷받침하는지, 그리고 설계가 바뀔 때 또 무엇이 영향을 받을 수 있는지를 파악하는 데 도움이 됩니다.

변경 영향 검토를 위해 추적성을 활용하기

추적성은 팀이 하나의 실질적인 질문에 답할 수 있도록 돕습니다. 이 변경은 또 무엇에 영향을 미치는가? 요구사항이 설계 결정, 제약 조건, 검증 점검, 증빙 자료와 계속 연결되어 있으면, 팀은 무엇이 변경되었는지, 무엇이 여전히 충족되고 있는지, 그리고 재작업 비용이 커지기 전에 무엇을 검토해야 하는지를 파악할 수 있습니다.

연결된 요구사항 워크플로우가 도움이 되는 방식

하드웨어 팀에는 요구사항 텍스트를 저장하는 장소 그 이상이 필요합니다. 문서와 스프레드시트로도 요구사항을 기록할 수는 있지만, 프로젝트 복잡성이 증가하고 각 요구사항이 엔지니어링 체인 전반에서 계속 연결되어야 할수록 관리가 어려워집니다.

Altium Requirements Portal은 하나의 공유 환경에서 요구사항, 추적성, 담당자, 검증을 관리함으로써 이러한 워크플로우를 지원하도록 설계되었습니다. 요구사항을 고립된 텍스트로 취급하는 대신, 팀은 무엇이 변경되었는지, 그것이 무엇에 영향을 미치는지, 다음 단계를 누가 담당하는지, 그리고 해당 요구사항을 어떻게 검증할 것인지를 확인할 수 있습니다.

당신의 프로젝트에서 "잠수함"은 무엇인가요?

모든 하드웨어 개발 프로젝트에는 설계가 빠르게 진행될 때 놓치기 쉬운 제약 조건이 있습니다. 그것은 기계적, 전기적, 규제적, 운영상, 또는 프로세스 관련 제약일 수 있습니다. 위험은 팀에 지식이 없다는 데 있는 것이 아니라, 설계가 변경될 때 중요한 지식이 항상 문서화되고, 연결되고, 검토되는 것은 아니라는 데 있습니다.

이 점이 바로 S-80 사례를 그 규모를 넘어 유용하게 만드는 이유입니다. 엔지니어링 의도, 설계 결정, 증빙 자료가 시간의 흐름 속에서 서로 연결된 상태로 유지되지 않으면, 같은 패턴이 일상적인 제품 개발에서도 나타날 수 있습니다.

팀 전체가 접근할 수 있는 요구사항 관리 도구로 변경 영향 추적을 더 쉽게 만드세요.

Requirements Portal 시작하기 →

자주 묻는 질문

하드웨어 프로젝트에서 요구사항 관리 문제가 발생하는 원인은 무엇인가요?

요구사항 관리 문제는 요구사항이 그것이 영향을 미치는 설계 작업, 제약 조건, 검증 점검과 연결되어 있지 않을 때 자주 발생합니다. 요구사항 자체는 존재할 수 있지만, 팀이 그것이 무엇과 연결되는지 볼 수 없다면 설계 변경 시 중요한 영향을 놓칠 수 있습니다.

왜 스프레드시트는 요구사항 관리에 점점 어려워지나요?

스프레드시트는 요구사항 텍스트를 기록할 수는 있지만, 프로젝트 복잡성이 증가할수록 관리가 어려워집니다. 팀에는 엔지니어링 체인 전반에 걸쳐 요구사항을 설계 작업, 변경 이력, 검증 상태, 증빙 자료와 연결해 유지할 수 있는 방법이 필요합니다.

추적성은 어떻게 후기 단계의 재작업을 줄이는 데 도움이 되나요?

추적성은 팀이 하나의 실질적인 질문에 답하도록 돕습니다. 이 변경은 또 무엇에 영향을 미치는가? 요구사항을 설계 결정, 제약 조건, 검증 점검, 증빙 자료와 연결하면, 팀은 재작업 비용이 커지기 전에 무엇을 검토해야 하는지 파악할 수 있습니다.