기능적 요구 사항과 비 기능적 요구 사항을 구분하는 이유는 무엇입니까?

나는 둘 사이의 차이점을 이해하지만 동료들로부터 라벨링 요구 사항이 기능적 또는 비 기능적 (또는 과도기적)이라는 이점에 대해 의문을 갖습니다. 왜 그렇게 귀찮게합니까? 그는 이틀 동안 한 프로젝트에 대한 요구 사항 목록을 검토하는 데 시간을 보냈으며 결과는 "모든 것을 다"라는 칙령으로 다른 사업체에 문서를 제출하는 것이기 때문에 아무런 이점도 얻지 못했습니다.

내가 두려워하는 것은 요구 사항이 하나의 문서에 모여 있다는 것입니다. 나는 실용적으로 그 이점을 설명하려고했지만 팔 수 없었다. 기능적 요구 사항과 기능적 요구 사항을 문서화하는 이점을 어떻게 판매합니까?

요구 사항을 명시 적으로 분리하면 올바른 시스템을보다 쉽게 ​​설계 할 수 있습니다.

비 기능적 요구 사항 (개념 / 용어 품질 특성 선호-기능적 / 기능적 이외의 새로운 통찰력을 제공해야 함)을 사용하면 기능보다는 소프트웨어 의 속성 에 더 관심 이 있습니다. 즉 어떻게 시스템이 어떤 기능을 단순히 수행하는 어떤 시스템이 수행합니다. 품질 요구 사항은 기능적 요구 사항이 수행하지 않는 방식으로 시스템 아키텍처에 상당한 영향을 미치므로 이러한 이유로 요구 사항이 다르게 처리되어야합니다.

품질 속성을 기능 요구 사항과 분리하면 다양한 요구 사항을 다른 방식으로 분석, 지정 및 우선 순위 지정할 수 있습니다. 예를 들어, 품질 속성은 일반적으로 품질 속성 시나리오 를 사용하여 지정 되지만 기능적 요구 사항은 스토리, 유스 케이스, should statement 또는 기타 여러 형식의 형식을 취할 수 있습니다. 내가 작업 한 대부분의 시스템에는 12 가지 미만의 품질 특성과 더 많은 기능 요구 사항이있었습니다.

실제로 다른 종류의 요구 사항- 기술 제약 조건을 소개 합니다. 다시 한 번, 요구 사항을이 세 가지 버킷으로 명시 적으로 분리하면 시스템을 구축하는 동안 올바른 균형을 유지하는 방법에 대한 힌트를 얻을 수 있습니다. 기능적 요구 사항은 종종 협상 가능하며, 품질 특성은 아키텍처 및 선택한 구조에 큰 영향을 미치며 기술적 인 제약은 협상 할 수 없습니다.

이것이 우리 팀이라면 아키텍처에서 중요한 것을 놓치지 않도록 요구 사항에 유형별로 명확하게 주석을 달아야한다고 말하고 싶습니다. 기능뿐만 아니라 아키텍처 드라이버에 대해서도 생각해보십시오.

소프트웨어 집중 시스템 설계의 Anthony Lattanze : 실무자 안내서 는 아키텍처 드라이버에 대한 실질적인 개요와 여기에서 요약 한 것보다 훨씬 포괄적으로 다루어야하는 이유를 설명합니다.

모든 요구 사항이 동일한 우선 순위 / 무게 (특히 "필수") 인 경우 기능적 요구 사항과 비 기능적 요구 사항을 분리하는 것보다 더 걱정해야 할 것입니다.

그럼에도 불구하고 두 가지 요구 사항 범주를 분리해야하는 몇 가지 이유가 있습니다.

구현에 대한 책임 나는 많은 비 기능적 요구 사항, 특히 성능에 중점을 둔 요구 사항이 개발자에게 적당히 적용된다는 것을 알았습니다. 설계는 확장 성과 속도를 지원할 수 있지만 (특정 코드 섹션을 조정할 수 있음) 일반적으로 성능 요구 사항을 충족 할 수있는 것은 아키텍처에 따라 다르며 종종 하드웨어 구성 시간에 달려 있습니다.

테스트 책임 사용자, QA 팀은 보안, 내결함성, 안전 및 신뢰성 요구 사항을 충족시키는 데 얼마나 능숙합니까?

스스로 반복하지 마십시오 문서는 코드와 동일한 DRY 원칙을 따라야합니다. 공통 UI 스타일 요구 사항은 함께 그룹화되어야합니다. 요구 사항을 담당하는 사람이 실제로 원하는 경우 기능 요구 사항에서 비 기능적 요구 사항 (개별 또는 그룹)을 참조 할 수 있습니다.

버전 관리 "표준"이 많은 회사 환경에있는 경우 버전을 지정할 수있는 특정 UI 또는 보안 (몇 가지 이름을 지정하기 위해) 요구 사항 문서를 작성할 수 있습니다. 이렇게하면 응용 프로그램 별 요구 사항 (주로 기능적 요구 사항)을 작성할 수 있습니다. "응용 프로그램은 XYZ-Company-SecReq-DocumnentNamingStandard.docx에 정의 된 보안 요구 사항의 V2.3을 준수해야합니다."

기능적 요구 사항과 비 기능적 요구 사항을 구분하는 이유는 무엇입니까?

차별화의 한 가지 이유는 두 유형 사이의 추상화 수준입니다. 작동하지 않는 요구 사항은 시스템 수준이며 시스템 전체의 작동 방식을 말합니다. 기능 요구 사항은 특정 기능과 클라이언트에 제공해야하는 기능을 나타냅니다.

비 기능적 요구 사항은 시스템을 제한하는 반면, 기능적 요구 사항은 시스템이 수행해야하는 작업을 말합니다. 비 기능 요구 사항은 기능 요구 사항을 설계하고 나중에 구현하는 방법에 대한 제한 사항을 제공합니다. 그것들을 분리함으로써, 제약 및 한계로부터 특징을 명확하게 식별하는 것이 가능해진다.

내가 두려워하는 것은 요구 사항이 하나의 문서에 모여 있다는 것입니다. 나는 실용적으로 그 이점을 설명하려고했지만 팔 수 없었다. 기능적 요구 사항과 기능적 요구 사항을 문서화하는 이점을 어떻게 판매합니까?

내 경험상, 기능적 및 비 기능적 요구 사항은 실제로 동일한 문서로 그룹화되거나 동일한 시스템에서 추적됩니다. 그러나, 그들은 문서의 각기 다른 개별 섹션과 각 섹션을 충족시키는 성공 기준을 제공받습니다.

일반적으로 팀은 요구 사항을 충족시키는 데 도움이되는 요구 사항을 분류합니다. 아키텍처 요구 사항을 구체적으로 요구하는 요구 사항이있는 경우 아키텍처 요구 사항을 "아키텍처"요구 사항이라고하면 팀이 아키텍처 작업을 수행하는 데 도움이됩니다.

모든 요구 사항에 대한 큰 단일 문서가 반드시 나쁜 것은 아닙니다 ... 검토하는 데 2 ​​일이 걸리는 것도 나쁘지 않습니다. 문제는 일반적으로 한 사람이 요구 사항을 검토 한 후 이해하기는하지만 다른 사람이 동일한 작업을 수행하는 것은 쉽지 않다는 것입니다. 프로젝트에 참여하는 다른 사람들을 도울 메타 데이터로 레이블 요구 사항을 시작하는 것이 큰 도움이 될 수 있습니다.

아마도 그것을 추상화 문제로 묘사하려고 시도하십시오. 레거시 코드 기반으로 작업해야하는 경우 기존 코드를 모두 읽은 후 작동하지 않습니다. 코드 구조에 따라 도움이됩니다. 요구 사항에 일부 구조가 있으면 같은 방식으로 도움이됩니다.

분리에는 여러 가지 이점이 있습니다.

1. 테스트 시간 절약 (기능 요구 사항 만 테스트)
2. 향후 요구 사항 변경에 대한 시간을 절약합니다 (즉, 비 기능적 요구 사항은 검토 / 승인 / 구현 / 테스트에 더 적은 시간이 소요됨)
3. 규제 (예 : FDA 등) 세계에서 비 기능 요구 사항은 기능 요구 사항에 필요한 서류 양의 1/10을 요구합니다.
4. 팀에게 선임 (기능) 팀과 비 기능 (팀) 팀 구성원 간의 작업을 나눌 수있는 기능을 제공합니다.

나는 계속할 수 ...

표면적으로 이틀은 오랜 시간이 걸리는 것 같습니다. 장기적으로는 몇 주 또는 몇 달의 미래 작업을 절약 할 수 있습니다.