질문 배경:
요구사항을 공식화하는 초기 초점은 기능적 능력에 있었으나, 시간이 지나면서 처음에는 "보이지 않는" 기준(성능, 보안, 장애 내성 등)이 제품의 성공적인 구현과 생존 가능성에 매우 중요하다는 것이 분명해졌습니다. 이들을 무시하면 소프트웨어가 출시된 후 실패하거나 예측할 수 없는 행동을 하게 됩니다.
문제:
비기능 요구사항은 종종 맥락을 고려하지 않고 틀에 박힌 방식으로 기록됩니다. "체크 마크"를 위해서 언급되거나 너무 추상적인 방식으로 형성됩니다. 예를 들어: "시스템은 사용자 친화적이어야 한다" 또는 "시스템은 빠른 속도를 가져야 한다"고 할 수 있습니다. 이는 개발자, 아키텍트 및 테스터에게 명확한 KPI를 제공하지 않습니다.
해결책:
시스템 분석가는 비즈니스, IT 및 운영 전문가와의 세션을 통해 실제 제약 조건을 파악하고, 수치적 메트릭(예: SLA, TPS, 지연 시간 지표)을 기록하며, 비기능 요구사항을 명시적으로 명세서에 기술한 후 테스트 케이스 및 프로젝트 아키텍처 아티팩트와 연결하여 테스트 가능성을 보장합니다.
주요 특징:
단순히 "시스템은 24/7 이용 가능해야 한다"라는 요구사항 그룹을 남겨둘 수 있나요?
아니요, 가용성 파라미터(예: 99.95%) 및 복구 조건을 반드시 구체화해야 합니다.
"응답 속도는 빨라야 한다"고만 언급하는 것으로 충분할까요?
아니요, 이러한 표현은 일하지 않습니다. 예를 들어: 응답 시간 < 3초, 95% 요청에서 하중 X.
비기능 요구사항이 일반적인 사양서에만 기재된 경우 공식화된 것인가요?
아니요, 이를 분해하고 아키텍처 결정 및 테스트 계획과 연결해야 하며, 그렇지 않으면 실행 가능하지 않거나 검증되지 않은 상태로 남게 됩니다.
부정적 사례: E-banking 프로젝트는 "24/7 가용성, 빠른 작업"을 요구하며 SLA를 명확히 하지 않고 시작되었습니다.
장점:
단점:
긍정적 사례: 분석가는 운영 부서와 협력하여 99.9% 가동 시간, 최대로 응답 시간 2초를 기록하고, 저하 시나리오를 기술했습니다.
장점:
단점: