소프트웨어 엔지니어링의 비기능적 요구 사항은 무엇입니까?
찰스 무어
⚡ 스마트 요약
비기능 요구사항은 성능, 보안, 사용성, 신뢰성, 확장성 및 이식성과 같은 품질 속성을 명시하여 소프트웨어 시스템이 얼마나 잘 작동해야 하는지를 정의하고, 모호한 기대치를 개발 수명 주기 전반에 걸쳐 측정 가능하고, 테스트 가능하며, 시행 가능한 엔지니어링 목표로 전환합니다.
비기능 요구사항이란 무엇인가요?
A 비기능적 요구사항 비기능 요구사항(NFR)은 소프트웨어 시스템의 품질 속성을 명시합니다. NFR은 시스템의 응답성, 사용성, 보안, 이식성 및 성공에 중요한 기타 품질 속성을 기준으로 시스템을 평가합니다. 일반적인 비기능 요구사항의 예는 다음과 같습니다. "웹사이트가 얼마나 빨리 로드되나요?" 기능 외적인 요구사항을 충족하지 못하면 사용자가 불편함을 느끼는 시스템이 만들어집니다.
소프트웨어 엔지니어링에서 비기능 요구사항은 애자일 백로그 전반에 걸쳐 시스템 설계에 제약을 가합니다. 예를 들어, 동시 접속자가 10,000명을 초과할 경우 사이트는 3초 이내에 로드되어야 합니다. 비기능 요구사항을 기술하는 것은 기능 요구사항을 파악하는 것만큼 중요합니다.
비기능 요구사항의 유형
비기능 요구사항의 주요 범주는 다음과 같습니다.
비기능적 요구사항의 유형
- 편의성
- 서비스 가능성
- 관리
- 복구 가능성
- 보안
- Data Integrity
- 생산 능력
- 이용 가능 여부 (Availability)
- 확장성
- 상호 운용성
- 신뢰성
- 유지 보수성
- 규제 준수
- 환경 제약
기능 외 요구 사항의 예
다음은 비기능 요구사항의 실제 사례입니다.
- 사용자는 최초 로그인 성공 후 초기 비밀번호를 변경해야 하며, 초기 비밀번호는 절대로 재사용해서는 안 됩니다.
- 직원은 자신의 급여 정보를 직접 수정할 수 없으며, 그러한 시도가 있을 경우 보안 관리자에게 보고해야 합니다.
- 사용자가 데이터 항목에 접근하려는 모든 실패 시도는 감사 추적 기록에 기록됩니다.
- 웹사이트는 응답 속도 저하 없이 20천만 명의 동시 접속자를 지원해야 합니다.
- 해당 소프트웨어는 이식성이 뛰어나야 하므로, 한 운영 체제에서 다른 운영 체제로 옮겨도 문제가 발생하지 않아야 합니다.
- 정보의 프라이버시, 제한된 기술의 수출 및 지적 재산권은 감사 대상이 되어야 합니다.
기능적 요구 사항 대 비기능적 요구 사항
기능적 요구사항과 비기능적 요구사항의 주요 차이점은 다음과 같습니다.
| 파라미터 | 기능적 요구 사항 | 비기능적 요구사항 |
|---|---|---|
| 그것은 무엇인가? | 동사 | Attributes |
| 요구 사항 | 필수입니다 | 필수사항은 아닙니다 |
| 캡처 유형 | 사용 사례에서 캡처됩니다. | 이는 품질 속성으로 캡처됩니다. |
| 최종 결과 | 제품 기능 | 제품 속성 |
| 캡처 | 캡처가 용이함 | 캡처하기 어려움 |
| 목표 | 소프트웨어의 기능을 확인하는 데 도움이 됩니다. | 소프트웨어의 성능을 확인하는 데 도움이 됩니다. |
| 초점 영역 | 사용자 요구사항에 집중 | 사용자의 기대에 집중합니다. |
| 문서 | 제품의 기능을 설명하세요. | 제품의 작동 방식을 설명합니다. |
| 테스트 유형 | 기능 테스트 시스템, 통합, 엔드 투 엔드, API 테스트 등과 같은 것들 말입니다. | 성능, 스트레스, 유용성, 보안 테스트 등과 같은 비기능 테스트 |
| 테스트 실행 | 테스트 실행은 비기능 테스트 전에 수행됩니다. | 기능 테스트 후 |
| 제품 정보 | 제품 특징 | 제품 속성 |
비 기능 요구 사항의 장점
의 주요 이점 비기능 테스트 위치 :
- 비기능적 요구사항은 시스템이 법률 및 규정 준수 규칙을 따르도록 보장합니다.
- 시스템의 신뢰성, 가용성 및 성능을 보호합니다.
- 사용자 경험이 좋고 조작이 간편합니다.
- 그들은 소프트웨어의 보안 정책을 수립합니다.
비기능적 요구사항의 단점
비기능 요구사항의 일반적인 단점은 다음과 같습니다.
- 비기능적 요구사항은 여러 상위 소프트웨어 하위 시스템에 영향을 미칠 수 있습니다.
- 이러한 요소들은 건축 및 고급 설계 단계에서 특별한 고려가 필요하므로 비용이 증가합니다.
- 구현은 단일 소프트웨어 하위 시스템에 대응하는 경우가 드뭅니다.
- 일단 설계 단계가 완료되면 수정하기가 어렵습니다.
FURPS+ 모델을 이용한 비기능 요구사항 분류
FURPS+는 비기능 요구사항에 가장 널리 사용되는 분류 체계입니다. 원래 휴렛팩커드에서 개발된 이 체계는 품질 속성을 다섯 가지 주요 범주와 "+"로 표시된 추가 제약 조건으로 분류합니다. 이 모델은 비즈니스 분석가가 특정 유형의 요구사항을 놓치는 것을 방지하는 데 도움이 됩니다.
- 기능 : 기본 기능 목록을 뛰어넘는 역량, 보안 및 재사용성.
- 유용성 : 인간적 요소, 미학, 일관성, 문서화 및 사용자 경험의 반응성.
- 신뢰성 : 가용성, 평균 고장 간격, 복구 가능성, 예측 가능성 및 정확도.
- 성능 : 부하 시 속도, 처리량, 용량, 확장성 및 자원 소비량.
- 지원 가능성: 제공되는 시스템의 테스트 용이성, 유연성, 설치 용이성, 현지화 용이성 및 유지보수성.
- 플러스(+): 설계, 구현, 인터페이스 및 물리적 제약 조건(예: 필수 플랫폼, 표준 또는 하드웨어).
모든 비기능적 요구사항을 FURPS+ 범주에 매핑하는 팀은 기능은 충족하지만 성능, 보안 또는 유지 관리 측면에서 실패하는 시스템을 출시할 가능성이 더 낮습니다.
테스트 가능한 비기능 요구사항 작성 방법
잘 작성된 비기능 요구사항(NFR)은 측정 가능하고, 검증 가능하며, 시간 제한이 있어야 합니다. "시스템은 빨라야 한다" 또는 "앱은 안전해야 한다"와 같은 모호한 진술은 요구사항이 아니라 희망 사항일 뿐입니다. 아래 단계를 따라 의도를 테스트 가능한 NFR로 변환해 보세요.
- 품질 속성을 파악하십시오. 우려 사항을 FURPS+ 범주에 매핑하여 팀이 해당 요구 사항이 성능, 사용성, 보안 또는 신뢰성 요구 사항인지 알 수 있도록 합니다.
- 측정 기준을 선택하세요. 모든 비기능 요구사항(NFR)에는 단위가 필요합니다. 밀리초, 초당 요청 수, 동시 사용자 수, 가동 시간 비율 또는 ISO 27001과 같은 규정 준수 표준 등이 될 수 있습니다.
- 수치 임계값을 설정하세요. "빠른"을 "95번째 백분위수에서 400밀리초 미만"으로, "높은 가용성"을 "월간 가동률 99.9%"로 대체하십시오.
- 증상을 설명하세요. 임계값이 적용되는 부하, 환경 또는 사용자 세그먼트를 명시하십시오. 예를 들어 "동시 사용자 10,000명이 접속하는 최대 판매량 시점"과 같이 명시할 수 있습니다.
- 검증 방법을 정의하십시오. 테스트 유형(부하 테스트, 침투 테스트, 혼돈 실험, 접근성 감사 등)과 임계값을 확인하는 데 사용할 도구를 기록해 두세요.
- SMART 점검을 적용하세요. 요구사항을 백로그에 추가하기 전에 해당 요구사항이 구체적이고, 측정 가능하며, 달성 가능하고, 관련성이 있으며, 기한이 정해져 있는지 확인하십시오.
예시 재작성: "시스템은 빨라야 한다"는 문장을 "결제 페이지는 5,000명의 동시 접속 사용자를 기준으로 95번째 백분위수에서 500밀리초 이내에 응답해야 하며, 이는 검증을 거쳤다"로 바꿉니다. JMeter "각 릴리스마다 부하 테스트를 실시하십시오." 수정된 문구는 개발자가 이를 고려하여 설계하고, 테스터가 이를 검증하며, 제품 소유자가 이의 없이 수용할 수 있도록 합니다.
