엔지니어링 요구 사항 관리 계획 수립

어떤 프로젝트를 시작할 때 요구사항을 식별하고 설정하는 것은 성공을 달성하기 위해 매우 중요합니다. 이 글은 간단한 방법으로, 몇 가지 기본 개념과 Altium 365 Requirements & Systems Portal의 사용을 통해 엔지니어링 프로젝트에서 요구사항 관리 계획을 만드는 방법을 소개하고자 합니다.

이 블로그는 엔지니어, 전문가, 프로젝트 매니저, 제품 매니저 및 요구사항 관리 계획을 만드는 방법을 이해해야 하는 모든 사람을 대상으로 합니다.

요구사항이란 무엇인가?

당연한 것 같지만 '요구사항이란 무엇인가?'라는 문제에 대해 생각해 보는 것이 가치가 있습니다. 사전에 따르면 요구사항은 '무엇인가를 위한 필요한 상황이나 조건'이라고 정의됩니다. 엔지니어링 세계에서 요구사항은 사용자나 클라이언트와 프로젝트의 개발자들 사이의 의사소통 방법입니다. 특히 대규모 프로젝트에서는 사용자가 개발자에게 자신이 원하는 것을 알릴 수 있는 몇 안 되는 방법 중 하나입니다.

자동차 프로젝트에서의 요구사항 예:

'사용자는 크루즈 컨트롤을 통해 사전에 정의된 속도로 자동으로 이동할 수 있어야 합니다.'

요구사항이 왜 중요한가?

다음과 같이 말해집니다: "요구 사항 정의 및 관리가 부실하면 막대한 비용을 초래하고 프로젝트 실행에 실패할 수 있습니다."

요구 사항의 정의는 일반적으로 고객과 공급업체 간 계약의 기초를 형성할 정도로 중요합니다. 요구 사항에 정의된 내용은 프로젝트에서 고려되어야 하며, 고객이 요구할 수도 있습니다. 그러나, 요구 사항 정의에 나타나지 않은 것은 프로젝트의 인도 단계에서 요구되어서는 안 됩니다.

따라서, 우리가 요구 사항을 작성하는 책임이 있다면 다음을 수행해야 합니다:

• 고객의 정확한 필요사항을 파악합니다.
• 명확한 구조와 잘 조직된 요구 사항을 포함한 문서를 작성합니다.
• 양측이 작성한 이해관계(계약)를 확인하기 위해 고객과 회의를 설정합니다.
• 프로젝트 진행 과정에서 채택된 해결책이 요구 사항에 충실한지 확인합니다.
• 요구 사항의 준수 여부를 검증하고 테스트합니다.

이러한 일련의 조치는 요구 사항 관리 계획으로 알려져 있습니다. 프로젝트의 생애를 통해 요구 사항을 식별, 정의, 추적하는 관리자 또는 관리 팀이 조직에 있어야 한다는 것이 매우 중요합니다.

요구 사항은 어떻게 작성되어야 하나요?

요구사항을 작성하는 것은 보이는 것처럼 간단하고 사소한 일이 아닙니다. 특정 기준을 충족해야 하는 문서입니다. 따라서 요구사항은 다음과 같아야 합니다:

• 명확하고, 정확하며, 구체적이어야 합니다: 필요한 것을 명확하고 정확하게 설명해야 합니다.
• 간결해야 합니다: 가능한 한 적은 단어를 사용해야 합니다.
• 단순한 언어를 사용해야 합니다: 기술 용어나 복잡한 단어로 독자를 혼란스럽게 해서는 안 됩니다.

잘 작성된 요구사항의 예:

• 모든 구성 요소(SMD 및 스루홀)는 TOP 면에 배치되어야 합니다.

잘못 작성된 요구사항의 예:

• SMD 구성 요소는 모두 같은 쪽에 배치되어야 하며, 스루홀 구성 요소의 솔더가 SMD 구성 요소의 솔더와 반대쪽에 있도록 해야 합니다.

위의 예에서, 잘 작성된 요구사항은 간결하며 필요한 것을 모호함 없이 완벽하게 정의하는 반면, 잘못 작성된 요구사항은 너무 많은 텍스트를 포함하고 있어 아무런 기여를 하지 않으며 독자를 혼란스럽게 하고 정확하지 않습니다(구성 요소가 배치될 쪽을 정의하지 않음).

요구사항은 항상 의무적이므로, 'shall'을 사용하여 작성해야 합니다. 요구사항이 선호사항이나 희망사항(의무적이지 않은 경우)일 때는 'should'를 사용하여 정의할 수 있으며, 제안이나 허가가 주어질 때는 'may'를 사용할 수 있습니다.

요구사항을 정의하는 기본 규칙

위의 내용 외에도, 요구사항을 정의할 때 몇 가지 기본 규칙을 따라야 합니다:

• 고유 ID를 가져야 합니다.
• 추가 정보 없이도 이해될 수 있어야 합니다.
• 다른 요구사항과 일관성이 있어야 합니다.
• 항상 최신 상태여야 합니다(버전 관리).
• 실현 가능해야 합니다(불가능한 요구사항은 피하세요).
• 검사, 시연, 또는 테스팅을 통해 구현이 검증되어야 합니다.

요구사항 식별

정의된 각 요구사항은 요구사항 정의 및 검토 시, 그리고 프로젝트 실행 단계에서 언제든지 참조될 수 있도록 고유 ID를 가져야 합니다. 요구사항 식별의 예는 Altium 365 요구사항 및 시스템 포털을 사용하여 보여집니다.

어떤 유형의 요구사항이 있으며, 어떻게 분류됩니까?

주로 두 가지 유형의 요구사항이 있습니다:

• 기능 요구 사항: 이것은 시스템의 기능을 정의합니다.
• 비기능 요구 사항: 이것은 해결책에 대한 제약이나 한계를 부과합니다(환경적, 신뢰성, 전자기 호환성, 안전성, 적용 규정, 비용 요구 사항, 시간 제한 등).

이러한 기능적 및 비기능적 요구 사항의 조합은 시스템 사양으로 알려져 있습니다. 시스템 사양에서는 요구 사항을 다음 수준에 따라 그룹화합니다:

• 초기 또는 고객 요구 사항
• 시스템 요구 사항
• 하위 시스템 요구 사항

초기 또는 고객 요구 사항은 프로젝트가 시작되기 전에 고객이나 사용자가 직접 제공하는 것입니다. 이것은 고객의 필요를 포착하기 때문에 중요하며, 우리의 요구 사항 행렬을 생성하기 위한 출발점으로 작용합니다. 이후 시스템 사양은 프로젝트의 각 부분에 해당하는 세부 사항 수준에 따라 요구 사항을 조직합니다. 이런 방식으로, 우리는 시스템 요구 사항을 가지고 있으며, 이것은 전체 시스템에 적용되고, 하위 시스템 요구 사항은 시스템의 특정 부분에만 적용됩니다. 예를 들어 설명해 보겠습니다.

새로운 스마트워치를 개발하는 프로젝트를 진행한다고 가정해 봅시다. 따라서 시스템 요구사항은 세트에 적용되는 것들입니다(아래 예시 참조):

• REQ-01: 성인 사용자를 위해 설계되어야 합니다.
• REQ-02: 모든 정보를 화면에 표시해야 합니다.
• REQ-03: 충전이 가능해야 합니다.
• REQ-04: 사용자가 메뉴를 탐색할 수 있는 버튼 또는 다른 메커니즘이 있어야 합니다.

시스템 요구사항이 정의되면, 나머지 요구사항은 다른 하위 시스템으로 나뉩니다.

스마트워치 개발 프로젝트의 예를 따르면, 하위 시스템의 예는 다음과 같습니다:

• 하위 시스템 1 – 스트랩
• 하위 시스템 2 – 디스플레이
• 하위 시스템 3 – 전원
• 하위 시스템 4 – 통신
• 하위 시스템 5 – 사용자 인터페이스

따라서 하위 시스템 요구사항의 정의는 다음과 같을 수 있습니다:

• STRAP-01: 재활용 가능한 재료를 사용해야 합니다.
• STRAP-02: 자석으로 고정될 수 있어야 합니다.
• DISPLAY-01: 디스플레이는 2인치여야 합니다.
• DISPLAY-02: 해상도는 368 x 448 픽셀이어야 합니다.
• POWER-01: 충전식 배터리로 작동해야 합니다.
• POWER-02: 배터리 수명은 최소 48시간이어야 합니다.
• COMMS-01: 블루투스 통신이 가능해야 합니다.
• COMMS-02: Wi-Fi 통신이 가능해야 합니다.
• UI-01: 메뉴 탐색을 위한 다이얼 형태의 측면 버튼이 있어야 합니다.

이러한 구조화된 요구사항 조직은 정의, 추적 및 관리를 더 쉽게 할 수 있게 합니다. 

요구사항 추적성

요구사항 관리 계획에서 요구사항 추적성은 필수적입니다; 이는 프로젝트 전반에 걸쳐 요구사항 구현의 진화를 추적하거나 관찰하는 것을 의미합니다.

스마트워치 프로젝트 예를 계속해서, 제품 스키마가 설계되면, 설계된 솔루션이 정의된 요구사항을 충족하는지 확인하기 위해 엔지니어와 관리자는 다음 단계로 넘어가기 전에 필요한 만큼 많은 회의를 개최해야 합니다. 이 경우, PCB 레이아웃입니다.

요구 사항 및 시스템 포털은 Altium 365에 직접 정의된 요구 사항의 가시성을 제공함으로써 이 작업을 지원합니다. 이는 이제 관리자와 엔지니어가 웹 브라우저를 통해 실시간으로 디자인에서 요구 사항을 추적할 수 있게 되었음을 의미하며, 이를 통해 팀원에게 작업을 할당하고, 디자인 엔지니어에게 요구 사항 변경 사항의 실시간 가시성을 제공하며, 전통적인 디자인 및 검토 패러다임을 완전히 변화시킬 수 있습니다.

요구 사항은 어떻게 관리되나요?

요구 사항을 관리하는 방법은 여러 가지가 있습니다. 재정적 자원이 적은 회사와 독립 전문가들은 종종 버전 관리 스프레드시트와 같은 간단하고 저렴한 도구를 사용하는 반면, 대규모 회사들은 DOORS, Valispace, Confluence, ReqView 등과 같은 요구 사항 관리를 위한 전문 소프트웨어를 일반적으로 사용합니다. Altium은 Valispace를 인수하고 이제 요구 사항 및 시스템 포털을 통해 Altium 365 생태계에 요구 사항 관리 도구를 통합합니다.

요구 사항 관리 계획 절차

이전 섹션을 바탕으로, 요구사항 관리 계획을 프로젝트 실행 전반에 걸쳐, 개념부터 상용화에 이르기까지 이해관계자의 요구사항을 정의, 관리, 검증, 확인하는 일련의 조치로 정의할 수 있습니다. 다음 이미지는 표준 요구사항 관리 계획의 플로우차트를 보여줍니다.

결론

요구사항 관리 계획의 중요성

모든 엔지니어링 프로젝트는 개발 팀이 고객의 요구와 모든 시스템 및 하위 시스템 요구사항을 완전히 이해하도록 보장하는 요구사항 관리 계획을 가져야 합니다.

요구사항을 올바르게 작성, 정의, 식별하는 방법 알기

요구사항을 작성하고 정의하기 위한 기본 규칙을 따라야 합니다. 마찬가지로, 존재하는 요구사항의 유형을 이해하고 올바르게 분류하는 방법, 그리고 요구사항 추적성이 무엇인지 이해하는 것이 중요합니다.

요구사항 추적성

요구사항은 충족되기 위해 작성되었으므로, 프로젝트 실행 중에 이를 관찰하고 추적하는 것이 매우 중요합니다. 왜냐하면 편차나 불일치가 더 일찍 감지될수록 프로젝트에 미치는 영향이 더 적기 때문입니다.

적절한 소프트웨어 사용하기

요구 사항 및 시스템 포털을 사용하여 Altium 365와 함께 그 잠재력을 극대화하세요. 이를 통해 요구 사항 공학과 개발 공학 간의 상호 작용이 훨씬 더 긴밀해져 프로젝트의 편차 가능성이 줄어들고 개발 시간이 단축됩니다.

오늘 modern하고 AI 기반의 요구 사항 관리를 시작하세요!