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

어떤 프로젝트의 시작점에서 요구사항을 식별하고 설정하는 것은 성공을 달성하기 위해 매우 중요합니다. 이 글은 간단한 방식으로, 몇 가지 기본 개념과 Altium Develop 요구사항 및 시스템 능력을 사용하여 엔지니어링 프로젝트에서 요구사항 관리 계획을 만드는 방법을 소개하고자 합니다.

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

더 읽어보기: 현대 전자 하드웨어 팀을 위한 요구사항 관리 가이드

핵심 요약

• 명확하고 잘 작성된 요구사항은 고객과 개발자 사이의 계약을 형성하고 전체 프로젝트를 안내합니다.
• 요구사항은 기능적 대 비기능적으로 구분되며 고객, 시스템, 하위 시스템 수준으로 구조화되어 정의, 추적 및 관리를 단순화합니다.
• 요구사항 관리 계획은 요구사항이 프로젝트 전반에 걸쳐 어떻게 캡처, 관리, 검증, 확인 및 추적되는지 정의하여 이탈이 조기에 발견되고 최소한의 영향으로 처리될 수 있도록 합니다.
• Altium Develop 요구사항 및 시스템 능력은 실시간 추적성, 코멘트 및 작업 할당을 통해 요구사항을 엔지니어링 워크플로우에 통합하여 협업을 강화하고 프로젝트 위험 및 시간을 줄입니다.

요구사항이란 무엇인가?

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

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

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

요구사항이 왜 그렇게 중요한가요?

다음과 같이 말합니다: "요구사항의 정의와 관리가 부실하면 엄청난 비용을 초래하고 프로젝트 실행에 실패할 수 있습니다."

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

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

• 고객의 정확한 필요사항을 파악합니다.
• 명확한 구조와 잘 조직된 요구사항을 가진 문서를 작성하세요.
• 양측이 서면으로 관심사를 확인할 수 있도록 고객과 회의를 설정하세요.
• 프로젝트가 진행됨에 따라 채택된 해결책이 요구사항에 충실한지 확인하세요.
• 요구사항 준수 여부를 검증하고 테스트하세요.

이러한 일련의 조치들은 요구사항 관리 계획으로 알려져 있습니다. 프로젝트의 생명 주기를 통해 요구사항을 식별, 정의, 추적하는 관리자나 관리 팀이 조직 내에 있어야 합니다.

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

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

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

잘 작성된 요구사항의 예:

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

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

• SMD 부품은 모두 같은 쪽에 배치되어야 하며, 스루홀(thru-hole) 부품의 솔더는 SMD 부품의 솔더와 반대쪽에 있어야 합니다.

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

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

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

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

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

요구사항 식별

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

어떤 유형의 요구사항이 존재하며, 이들은 어떻게 분류되나요?

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

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

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

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

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

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

• 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의 요구사항 및 시스템 기능 개발은 이 작업을 지원합니다. 이는 관리자와 엔지니어가 Altium에서 직접 정의된 요구사항의 가시성을 제공하기 때문입니다. 이는 관리자와 엔지니어가 이제 웹 브라우저를 통해 실시간으로 디자인에서 요구사항을 추적할 수 있게 하며, 팀원에게 작업을 할당하고, 디자인 엔지니어에게 요구사항 변경사항의 실시간 가시성을 제공하여, 전통적인 디자인 및 검토 패러다임을 완전히 변화시키게 합니다.

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

요구사항을 관리하는 방법은 여러 가지가 있습니다. 재정적 자원이 적은 회사와 독립 전문가들은 종종 버전 관리 스프레드시트와 같은 간단하고 저렴한 도구를 사용하는 반면, 큰 회사들은 DOORS, Valispace, Confluence, ReqView 등과 같은 요구사항 관리를 위한 전문 소프트웨어를 주로 사용합니다.

요구사항 관리 계획 절차

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

결론

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

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

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

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

요구사항 추적성

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

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

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

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