역사적으로 IT 프로젝트에서는 시스템이 해야 할 일에 주목하여 기능적 요구 사항에 주의가 집중되었습니다. 이와 함께 성능, 신뢰성, 확장성, 가용성, 보안 및 유지 관리와 같은 문제(정확히 이러한 특성이 "비기능적 요구 사항", NFR이라는 용어로 집합됨)는 오랫동안 부차적인 것으로 간주되어 형식화되지 않는 경우가 많았습니다.
비기능적 요구 사항을 무시하거나 형식적으로 설명하면 운영에서 심각한 문제가 발생합니다: 시스템이 예상되는 부하에 준비되지 않거나 사이버 공격을 견디지 못하며, 유지 관리 및 확장성이 어렵거나 필요한 사용자 수에 접근할 수 없습니다.
현대의 시스템 분석가는 NFR을 시작하고, 형식화하고, 분석하고 문서화해야 합니다. 여기에는 다음이 포함됩니다:
주요 특징들:
"제품 품질"과 "비기능적 요구 사항"의 차이는 무엇입니까?
제품 품질은 형식화 가능한 매개변수뿐만 아니라 주관적인 평가(예: UX/UI 편의성)를 포함하는 더 광범위한 개념입니다. NFR은 자동 검증이 가능한 명확하게 측정 가능한 특성(성능, 신뢰성 등)입니다.
분석가가 아키텍트에게 모든 비기능적 요구 사항을 정의하도록 위임할 수 있나요?
아니요, 분석가는 아키텍트 및 비즈니스와 함께 분석 단계에서 이러한 요구 사항을 식별해야 합니다. 그렇지 않으면 요구 사항이 불완전하거나 비즈니스 요구를 고려하지 않고 기술적인 측면에서만 설명될 수 있습니다.
비기능적 요구 사항을 일반적인 문구(예: "시스템은 신뢰할 수 있어야 함")만으로 표현할 수 있습니까?
아니요, 이러한 표현은 모니터링 및 테스트에 적합하지 않습니다. 구체화가 필요합니다: 예를 들어, "장애 발생 후 서비스 복구 시간은 10분을 초과해서는 안 됩니다".
부정적 사례: 국가 서비스 포털 프로젝트는 피크 부하에 대한 요구 사항을 형식화하지 않았습니다. 시스템은 인기 있는 서비스가 시작되는 날에 "다운" 되었고, 보안 문제 사건이 발생했습니다.
장점:
단점:
긍정적 사례: 산업 자동화 공장 프로젝트 시작 시 분석가는 운영 팀과 함께 시스템 가동 중단이 새로운 기능보다 중요하다는 것을 파악했습니다. SLA, 비상 시나리오를 수립하고 구체적인 지표를 문서화했습니다.
장점:
단점: