features functional requirements
이 자습서에서는 유형, 기능, 기능적 요구 사항과 비 기능적 요구 사항의 비교 및 비즈니스 요구 사항과 기능적 요구 사항을 예제로 설명합니다.
기능 요구 사항은 소프트웨어 시스템이 수행해야하는 작업을 정의합니다. 소프트웨어 시스템 또는 해당 모듈의 기능을 정의합니다. 기능은 시스템의 출력에 대한 테스트중인 시스템에 대한 입력 세트로 측정됩니다.
시스템의 기능 요구 사항 구현은 시스템 설계 단계에서 계획되는 반면 비 기능 요구 사항의 경우 시스템 아키텍처 문서에서 계획됩니다. 기능 요구 사항은 비 기능 요구 사항 생성을 지원합니다.
학습 내용 :
기능적 요구 사항 및 비 기능적 요구 사항
기능 요구 사항
예제를 통해 기능적 요구 사항이 무엇인지 이해하겠습니다.
예: 자동차 ADAS 프로젝트에서 서라운드 뷰 시스템 기능 요구 사항은 '후면 카메라가 위협 또는 물체를 감지해야합니다'일 수 있습니다. 여기서 비 기능적 요구 사항은 '카메라 센서가 위협을 감지 할 때 사용자에게 얼마나 빨리 경고를 표시해야 하는가'일 수 있습니다.
다른 걸 가져가 예 인포테인먼트 시스템 프로젝트의 사용자는 HMI에서 Bluetooth를 활성화하고 Bluetooth 활성화 여부를 확인합니다. 노트 , 사용자가 Bluetooth를 활성화하면 다른 Bluetooth 서비스가 활성화됩니다 (회색에서 굵게).
ps4와 호환되는 가상 현실 헤드셋
따라서 기능 요구 사항은 사용자가 작업을 수행 할 때 특정 시스템 결과에 대해 이야기합니다. 반면 비 기능적 요구 사항은 기능이 아닌 시스템 또는 구성 요소의 전체 동작을 제공합니다.
기능 요구 사항의 유형
기능 요구 사항에는 기능 테스트의 일부로 측정 할 수있는 다음 구성 요소가 포함될 수 있습니다.
# 1) 상호 운용성 : 요구 사항은 소프트웨어 시스템이 서로 다른 시스템에서 상호 운용 가능한지 여부를 설명합니다.
예: 자동차 인포테인먼트 시스템의 블루투스 기능 요구 사항의 경우 사용자가 블루투스 지원 Android 기반 스마트 폰을 QNX 기반 인포테인먼트 시스템에 페어링 할 때 전화 번호부를 인포테인먼트 시스템으로 전송하거나 전화 장치에서 인포테인먼트 시스템으로 음악을 스트리밍 할 수 있어야합니다.
따라서 상호 운용성은 서로 다른 두 장치 간의 통신이 가능한지 여부를 확인합니다.
다른 예 Gmail과 같은 이메일 서비스 시스템에서 가져온 것입니다. Gmail에서는 Yahoo.com 또는 Rediffmail.com과 같은 다른 메일 교환 서버에서 이메일을 가져올 수 있습니다. 이는 이메일 서버 간의 상호 운용성 때문에 가능합니다.
# 2) 보안 : 기능 요구 사항은 소프트웨어 요구 사항의 보안 측면을 설명합니다.
예: 보안 위협으로부터 시스템을 보호하는 CAN (Controller Area Network)을 사용하는 ADAS 서라운드 뷰 카메라 기반 시스템의 사이버 보안 기반 서비스입니다.
다른 예 소셜 네트워킹 사이트 Facebook에서 . 사용자의 데이터는 안전해야하며 외부인에게 유출되지 않아야합니다. 이 Facebook 사례가 최근 Facebook의 데이터 유출 사건과 Facebook이 직면 한 결과로 인해 독자들에게 더 넓은 보안 범위를 제공하기를 바랍니다.
# 3) 정확도 : 정확도는 시스템에 입력 된 데이터가 시스템에서 올바르게 계산되고 사용되며 출력이 올바른지 정의합니다.
예: Controller Area Network에서 CAN 신호 값이 ECU (즉, ABS 장치, HVAC 장치, 계기판 장치 등)에 의해 CAN 버스를 통해 전송되면 다른 ECU는 전송 된 데이터가 올바른지 여부를 식별 할 수 있습니다. CRC 확인을 통해.
다른 예 온라인 뱅킹 솔루션에서 가져올 수 있습니다. 사용자가 자금을받을 때받은 금액은 정확히 계좌에 입금되어야하며 정확성의 변동은 허용되지 않습니다.
# 4) 규정 준수 : 규정 준수 기능 요구 사항은 개발 된 시스템이 산업 표준을 준수하는지 확인합니다.
예: Bluetooth 프로필 기능 (즉, A2DP를 통한 오디오 스트리밍, HFP를 통한 전화 통화)이 Bluetooth SIG 릴리스 프로필 버전을 준수하는지 여부.
다른 예 자동차 인포테인먼트 시스템에서 Apple Car play의 것일 수 있습니다. 인포테인먼트의 앱은 다음으로부터 인증서를받습니다. 사과 Apple 웹 사이트에 언급 된 모든 전제 조건이 타사 Car Play 장치 (이 경우 인포테인먼트)에서 충족되는 경우.
다른 예 철도 발권 시스템을위한 웹 기반 애플리케이션에서 가능합니다. 웹 사이트는 사이버 보안 지침을 따르고 접근성 측면에서 World Wide Web을 준수해야합니다.
요구 사항 양식의 예 :
몇 가지 예를 통해 기능 요구 사항이 무엇인지 이미 살펴 보았습니다. 이제 IBM DOORS와 같은 요구 사항 관리 도구에 통합 될 때 기능 요구 사항이 어떻게 보이는지 살펴 보겠습니다. 요구 사항 관리 도구에서 기능 요구 사항을 문서화하는 동안 고려해야 할 여러 속성이 있습니다.
다음은 고려해야 할 몇 가지 속성입니다.
- 개체 유형 : 이 속성은 요구 사항 문서의 어느 섹션이이 속성의 일부인지 설명합니다. 표제, 설명, 요구 사항 등이 될 수 있습니다. 대부분 '요구 사항'섹션은 구현 및 테스트를 위해 고려되며 표제 및 설명 섹션은 더 나은 이해를위한 요구 사항에 대한 지원 설명으로 사용됩니다.
- 책임있는 사람: 요구 사항 관리 도구의 요구 사항을 문서화 한 작성자입니다.
- 프로젝트 / 시스템 이름 : 요구 사항이 적용되는 프로젝트, 예를 들면 '자동차 회사 인 XYZ OEM (Original Equipment Manufacturer)을위한 인포테인먼트 시스템 또는 ABC 은행 유한 회사를위한 웹 애플리케이션'.
- 요구 사항 버전 번호 : 이 필드 / 속성은 고객 업데이트 또는 시스템 설계 변경으로 인해 요구 사항이 여러 번 수정 된 경우 요구 사항의 버전 번호를 알립니다.
- 요구 사항 ID : 이 속성은 고유 한 요구 사항 ID를 언급합니다. 요구 사항 ID는 데이터베이스의 요구 사항을 쉽게 추적하고 코드의 요구 사항을 효율적으로 매핑하는 데 사용됩니다. 또한 버그 추적 도구에서 결함을 기록하는 동안 요구 사항에 대한 참조를 제공하는 데 사용할 수도 있습니다.
- 요구 사항 설명 : 이 속성은 요구 사항을 설명하는 가장 중요한 속성 중 하나입니다. 이 속성을 읽으면 엔지니어는 요구 사항을 이해할 수 있습니다.
- 요구 사항 상태 : 요구 사항 상태 속성은 요구 사항 관리 도구의 요구 사항 상태 (예 : 프로젝트 수락, 보류, 거부 또는 삭제 여부)를 나타냅니다.
- 코멘트: 이 속성은 책임자 또는 요구 사항 관리자에게 요구 사항에 대한 설명을 문서화하는 옵션을 제공합니다. 예: 기능적 요구 사항에 대한 가능한 코멘트는 '요구 사항을 구현하기 위해 타사 소프트웨어 패키지에 의존'일 수 있습니다.
DOORS의 스냅 샷
비즈니스 요구 사항에서 기능 요구 사항 도출
이것은 이미 섹션“ 비즈니스 요구 사항에서 기능 요구 사항 도출 ' 아래의 요구 사항 분석 조.
비즈니스 요구 사항 대 기능 요구 사항
이 차이는 요구 사항 분석 조. 그러나 우리는 아래 표에서 몇 가지 추가 사항을 강조하십시오.
| Sl. 아니. | 비즈니스 요구 사항 | 기능 요구 사항 |
|---|---|---|
| 7 | 예를 들면 온라인 뱅킹 시스템에서 비즈니스 요구 사항은 '사용자로서 현금 거래 명세서를받을 수 있어야합니다'가 될 수 있습니다. | 이 온라인 뱅킹 시스템의 기능적 요구 사항은 '사용자가 트랜잭션 쿼리에 날짜 범위를 제공 할 때이 입력은 서버에서 사용되며 웹 페이지에 필요한 현금 트랜잭션 데이터가 제공됩니다'일 수 있습니다. |
| 1 | 비즈니스 요구 사항은 고객 요구 사항의 '무엇'측면을 말합니다. 예, 사용자가 로그인 한 후 사용자에게 표시되어야하는 내용입니다. | 기능적 요구 사항은 비즈니스 요구 사항의 '어떻게'측면을 말합니다. 예, 사용자가 인증 할 때 웹 페이지에 사용자 로그인 페이지를 표시하는 방법. |
| 두 | 비즈니스 요구 사항은 비즈니스 분석가가 식별합니다. | 기능 요구 사항은 개발자 / 소프트웨어 설계자가 생성 / 파생합니다. |
| 삼 | 그들은 조직에 대한 이익을 강조하고 비즈니스 목표와 관련이 있습니다. | 그들의 목표는 고객 요구 사항 충족입니다. |
| 4 | 비즈니스 요구 사항은 고객이 제공합니다. | 기능적 요구 사항은 소프트웨어 요구 사항에서 파생되며, 이는 차례로 비즈니스 요구 사항에서 파생됩니다. |
| 5 | 비즈니스 요구 사항은 소프트웨어 테스트 엔지니어가 직접 테스트하지 않습니다. 대부분 고객이 테스트합니다. | 기능 요구 사항은 소프트웨어 테스트 엔지니어가 테스트하며 일반적으로 고객은 테스트하지 않습니다. |
| 6 | 비즈니스 요구 사항은 높은 수준의 요구 사항 문서입니다. | 기능 요구 사항은 세부 기술 요구 사항 문서입니다. |
비 기능적 요구 사항
비 기능적 요구 사항은 '시스템이해야 할 일'(기능적 요구 사항)이 아니라 '시스템이되어야하는 것'에 대해 말합니다. 대부분은 고객 및 기타 이해 관계자의 입력을 기반으로하는 기능 요구 사항에서 파생됩니다. 비 기능적 요구 사항 구현 세부 사항은 시스템 아키텍처 문서에 문서화되어 있습니다.
비 기능적 요구 사항은 구성 할 시스템의 품질 측면을 설명합니다. 성능, 이식성, 유용성 등 기능적 요구 사항과 달리 비 기능적 요구 사항은 모든 시스템에서 점진적으로 구현됩니다.
URPS (유용성, 신뢰성, 성능 및 지원 가능성) 퍼프 소프트웨어 개발자의 품질을 측정하기 위해 IT 업계에서 널리 사용되는 (기능, 사용성, 안정성, 성능 및 지원 가능성) 품질 속성은 모두 비 기능적 요구 사항에 포함됩니다. 그 외에도 다른 품질 속성도 있습니다 (세부 사항은 다음 섹션 참조).
Wikipedia는 이식성 및 안정성과 같은 다양한 품질 속성의 존재로 인해 비 기능적 요구 사항을 때때로 '불일치'라고 부릅니다.
비 기능적 요구 사항의 유형
비 기능적 요구 사항은 다음과 같은 하위 유형으로 구성됩니다 (완전하지 않음).
# 1) 성능 :
비 기능적 요구 사항의 성능 속성 유형은 시스템 성능을 측정합니다. 예: ADAS 서라운드 뷰 시스템에서 '자동차 점화를 시작한 후 2 초 이내에 후면 카메라 뷰가 표시되어야합니다'.
다른 예 성능은 인포테인먼트 시스템 내비게이션 시스템에서 나올 수 있습니다. “사용자가 내비게이션 화면으로 이동하여 목적지에 들어가면“X”초 이내에 경로를 계산해야합니다.” 하나 더 예 웹 애플리케이션 로그인 페이지에서. '로그인 후 사용자 프로필 페이지가로드되는 데 걸리는 시간.'
시스템 성능 측정은 부하 측정과 다릅니다. 부하 테스트 중에 시스템 CPU와 RAM을로드하고 시스템 처리량을 확인합니다. 성능의 경우 정상적인 부하 / 스트레스 조건에서 시스템 처리량을 테스트합니다.
# 2) 사용성 :
핵심 자바 인터뷰 질문 및 답변
유용성은 개발중인 소프트웨어 시스템의 유용성을 측정합니다.
예를 들면 , 해당 지역의 배관공 및 전기 기술자의 가용성에 대한 정보를 제공하는 모바일 웹 애플리케이션이 개발되었습니다.
이 앱에 대한 입력은 현재 위치로부터의 우편 번호와 반경 (킬로미터)입니다. 그러나 이러한 데이터를 입력하기 위해 사용자가 여러 화면을 탐색해야하고 데이터 입력 옵션이 사용자에게 쉽게 표시되지 않는 작은 텍스트 상자에 표시되면이 앱은 사용자 친화적이지 않으므로 앱의 유용성이 떨어집니다. 매우 낮은.
# 3) 유지 보수성 :
소프트웨어 시스템의 유지 보수 가능성은 시스템을 유지 보수 할 수있는 용이성입니다. 개발중인 시스템의 MTBF (평균 고장 간격)가 낮거나 MTTR (평균 수리 시간)이 높으면 시스템의 유지 관리 가능성이 낮은 것으로 간주됩니다.
유지 관리 가능성은 종종 Cyclomatic 복잡성을 사용하여 코드 수준에서 측정됩니다. 순환 적 복잡성은 코드가 덜 복잡할수록 소프트웨어를 유지하는 것이 더 쉽다는 것을 말합니다.
예: 많은 수의 데드 코드 (다른 기능이나 모듈에서 사용되지 않는 코드)가 많고, if / else 조건, 중첩 루프 등의 과도한 사용으로 인해 매우 복잡하거나, 코드가 실행되는 시스템이 거대한 경우 소프트웨어 시스템이 개발되었습니다. 수백만 줄의 코드에 적절한 주석이 없습니다. 이러한 시스템은 유지 보수성이 낮습니다.
다른 예 온라인 쇼핑 웹 페이지 일 수 있습니다. 사용자가 제품 개요를 볼 수 있도록 웹 사이트에 외부 링크가 많으면 (메모리 절약을 위해)이 웹 사이트의 유지 관리 가능성이 낮습니다. 이는 외부 웹 페이지 링크가 변경되면 온라인 쇼핑 웹 사이트에서도 업데이트해야하고 너무 자주 업데이트해야하기 때문입니다.
# 4) 신뢰성 :
안정성은 가용성의 또 다른 측면입니다. 이 품질 속성은 특정 조건에서 시스템의 가용성을 강조합니다. 유지 보수성과 마찬가지로 MTBF로 측정됩니다.
예: ADAS 서라운드 뷰 카메라 시스템의 후방 카메라 및 트레일러와 같은 상호 배타적 인 기능은 서로 간섭없이 시스템에서 안정적으로 작동해야합니다. 사용자가 트레일러 기능을 호출 할 때 두 기능이 모두 차량의 후방 카메라에 액세스하므로 후방 시야가 방해를 받아서는 안됩니다.
다른 예 온라인 보험 청구 시스템에서. 사용자가 청구보고를 시작한 다음 관련 비용 청구서를 업로드 할 때 시스템은 업로드가 완료 될 때까지 충분한 시간을 제공해야하며 업로드 프로세스를 빨리 취소해서는 안됩니다.
# 5) 이식성 :
이식성은 기본 종속 프레임 워크가 동일하게 유지되는 경우 소프트웨어 시스템이 다른 환경에서 작동 할 수있는 능력을 의미합니다.
예: 자동차 제조업체를 위해 개발 된 인포테인먼트 시스템 (즉, 블루투스 서비스 또는 멀티미디어 서비스)의 소프트웨어 시스템 / 구성 요소는 두 인포테인먼트 시스템이 완전히 다르지만 코드를 거의 또는 전혀 변경하지 않고 다른 인포테인먼트 시스템에서 사용할 수 있도록해야합니다. .
다른 것을 가져 가자 예 WhatsApp에서. IOS, Android, Windows, Tablet, Laptop, Phone에서 메시징 서비스를 설치하여 사용할 수 있습니다.
# 6) 지원 가능성 :
소프트웨어 시스템의 서비스 가능성은 서비스 / 기술 전문가가 소프트웨어 시스템을 실시간 환경에 설치하고, 시스템이 실행되는 동안 시스템을 모니터링하고, 시스템의 기술 문제를 식별하고, 문제를 해결하기위한 솔루션을 제공하는 능력입니다.
서비스 용이성을 위해 시스템이 개발되면 서비스 가능성이 가능합니다.
예: 소프트웨어 업데이트에 대한 주기적 알림 팝업을 사용자에게 제공하고, 문제를 디버그하기위한 로깅 / 추적 메커니즘을 제공하고, 롤백 메커니즘을 통해 실패에서 자동 복구 (소프트웨어 시스템을 이전 작업 상태로 롤백)합니다.
다른 예 ...에서 Rediffmail. 웹 기반 메일 링 서비스 버전에 업데이트가있을 때 시스템은 사용자가 이전 버전을 몇 달 동안 그대로 유지하면서 새로운 버전의 메일 링 시스템으로 전환 할 수 있도록했습니다. 이것은 또한 사용자 경험을 향상시킵니다.
# 7) 적응성 :
시스템의 적응성은 소프트웨어 시스템이 동작의 변화없이 환경의 변화에 적응할 수있는 능력으로 정의됩니다.
예: 자동차의 잠금 방지 브레이크 시스템은 모든 기상 조건 (더운 날씨 또는 추운 날씨)에서 표준에 따라 작동해야합니다. 다른 예 Android 운영 체제 일 수 있습니다. 그것은 다른 유형의 장치에서 사용됩니다. 스마트 폰, 태블릿 컴퓨터 및 인포테인먼트 시스템이며 적응력이 뛰어납니다.
위에 나열된 7 가지 비 기능적 요구 사항 외에도 다음과 같은 많은 요구 사항이 있습니다.
접근성, 백업, 용량, 규정 준수, 데이터 무결성, 데이터 보존, 종속성, 배포, 문서, 내구성, 효율성, 악용 가능성, 확장 성, 장애 관리, 내결함성, 상호 운용성, 수정 가능성, 운영 성, 개인 정보 보호, 가독성,보고, 복원성, 재사용 성, 견고성, 확장 성, 안정성, 테스트 가능성, 처리량, 투명성, 통합 성.
이러한 모든 비 기능적 요구 사항을 다루는 것은이 문서의 범위를 벗어납니다. 그러나 이러한 비 기능적 요구 사항 유형에 대한 자세한 내용은 Wikipedia.
기능적 요구 사항에서 비 기능적 요구 사항 도출
비 기능적 요구 사항은 여러 가지 방법으로 도출 될 수 있지만 대부분의 업계에서 시도되고 테스트 된 최상의 방법은 기능적 요구 사항에서 비롯됩니다.
이 기사의 몇 군데에서 이미 취한 인포테인먼트 시스템의 예를 들어 보겠습니다. 사용자는 인포테인먼트 시스템 즉, 여러 작업을 수행 할 수 있습니다. 노래 변경, USB에서 FM 또는 Bluetooth 오디오로 노래 소스 변경, 내비게이션 대상 설정, 소프트웨어 업데이트를 통한 인포테인먼트 소프트웨어 업데이트 등
# 1) 비 기능적 요구 사항 수집 :
기능 요구 사항의 일부인 사용자가 수행 한 작업을 나열합니다. UML 사용 사례 다이어그램 (각 타원)에 사용자 작업이 기록되면 모든 사용자의 작업에 대한 관련 질문 (각 사각형)을 시작합니다. 이러한 질문에 대한 답변은 비 기능적 요구 사항을 제공합니다.
# 2) 비 기능적 요구 사항 분류 :
다음 단계는 질문을 통해 확인한 비 기능적 요구 사항의 분류입니다. 이 단계에서 가능한 답을 확인하고 가능한 비 기능적 범주 또는 다른 품질에 대한 답을 분류 할 수 있습니다.
아래 이미지에서 답변에서 식별 된 가능한 품질 속성을 볼 수 있습니다.
기능적 요구 사항과 비 기능적 요구 사항
우리는 이미 기능적 및 비 기능적 요구 사항이 무엇이며 어떻게 파생되는지 살펴 보았습니다. 기능적 요구 사항과 비 기능적 요구 사항의 주요 차이점을 살펴 보겠습니다.
| Sl. 아니 | 기능 요구 사항 (FR) | 비 기능적 요구 사항 (NFR) |
|---|---|---|
| 7 | 기능적 요구 사항은 소프트웨어 시스템 구현의 골격을 형성합니다. | 비 기능적 요구 사항은 기능적 요구 사항이 마치 근육처럼 서로 붙도록 도와줌으로써 SW 시스템을 완성합니다. |
| 1 | 그들은 시스템이 무엇을해야하는지 말합니다. | 그들은 시스템이 무엇이어야한다고 말합니다. |
| 두 | 시스템 설계 문서에 자세히 설명되어 있습니다. | 시스템 아키텍처 문서에 자세히 설명되어 있습니다. |
| 삼 | 기능 또는 기능의 동작에 대해 이야기합니다. | 특정 기능이 아닌 전체 시스템 또는 시스템 구성 요소의 작동 동작에 대해 이야기합니다. |
| 4 | 사용자는 입력을 전달하고 출력이 올바르게 표시되는지 확인합니다. | 사용자가 입력을 전달하면 NFR이 다음 질문에 답할 수 있습니다. i) 출력을 표시하는 데 시간이 얼마나 걸리나요? ii) 출력이 시간과 일치합니까? iii) 입력 매개 변수를 전달하는 다른 방법이 있습니까? iv) 입력 매개 변수를 전달하는 것이 얼마나 쉬운가요? |
| 5 | 웹 애플리케이션에서 사용자는 FR 인증을 통해 로그인 할 수 있어야합니다. | 웹 응용 프로그램에서 웹 사이트에 로그인하는 데 걸리는 시간, 로그인 페이지의 모양과 느낌, 웹 페이지의 사용 용이성 등은 NFR의 일부입니다. |
| 6 | 기능 요구 사항은 먼저 소프트웨어 요구 사항에서 파생됩니다. | 비 기능적 요구 사항은 기능적 요구 사항에서 파생됩니다. |
| 8 | 기능적 요구 사항은 비 기능적 요구 사항없이 존재할 수 있습니다. | 비 기능적 요구 사항은 기능적 요구 사항없이 존재할 수 없습니다. |
| 9 | 기능 요구 사항은 기능에 대한 구체적인 정보를 제공합니다. 예 , Facebook의 프로필 사진은 로그인시 표시되어야합니다. | 기능적 요구 사항에는 많은 비 기능적 요구 사항 속성이있을 수 있습니다. 예, 로그인 시간 (성능), 프로필 페이지의 모양과 느낌 (사용성), 한 번에 로그인 할 수있는 사용자 수 (용량, 성능) |
| 10 | 거의 모든 비즈니스 요구 사항에 대해 SW 요구 사항에서 기능 요구 사항을 도출 할 수 있습니다. | 관련 질문이 FR에 대해 묻지 않기 때문에 NFR은 종종 문서화되지 않습니다. |
| 열한 | 기능적 요구 사항 구현은 일반적으로 하나의 소프트웨어 빌드에서 수행됩니다. | NFR은 원하는 동작이 달성 될 때까지 프로젝트의 수명주기 동안 구현됩니다. |
| 12 | 이는 대부분 고객에게 표시됩니다. | 이는 대부분 고객에게 보이지 않지만 장기적으로 경험할 수 있습니다. 예, 유용성, 성능 등은 장기적으로 만 경험할 수 있지만 전혀 볼 수 없습니다. |
결론
요구 사항은 소프트웨어 시스템을 개발하기위한 기본 빌딩 블록을 형성합니다. 기능적 요구 사항이있는 시스템을 구축하는 것은 가능하지만 그 능력을 결정하거나 측정 할 수 없습니다. 그러나 고품질의 작동 소프트웨어 시스템을 갖기 위해서는 비즈니스 요구 사항에서 파생 된 양질의 기능 요구 사항을 갖는 것이 매우 중요합니다.
따라서 기능적 요구 사항은 소프트웨어 시스템의 구현 방향을 제공하지만 비 기능적 요구 사항은 최종 사용자가 경험하게 될 구현 품질을 결정합니다.