STANDARD · ISO/IEC
ISO/IEC 25010
소프트웨어 품질 모델 표준. 비기능 요구사항(신뢰성·사용성·유지보수성·이식성 등)을 빠짐없이 점검하는 체크리스트.
QA vs QC
QA는 과정과 산출물을 보증하고, QC는 완성된 결과물을 검사한다.
QA는 만들면서 보증하고(과정과 결과), QC는 완성품을 받아 검사한다. PM의 역할은 직접 테스트가 아니라 누가·어떤 기법·어느 커버리지로 검증할지 지침을 세우는 것이다.
분석·설계 · 요구사항비기능 요구사항
기능 외의 품질 요구 · 성능·보안·사용성·신뢰성·유지보수성·이식성.
비기능 요구사항의 성패는 정량화 여부에서 갈린다. 빠르게·안전하게 같은 형용사를 응답 시간·가용성 비율·동시 처리량처럼 측정 가능한 지표로 못 박아야 검수의 기준이 되고, 정량화되지 않은 항목은 인수 단계에서 반드시 분쟁으로 돌아온다.
분석·설계 · 요구사항FURPS
비기능 점검 약어 · Functional·Usability·Reliability·Performance·Supportability(+).
FURPS는 요구사항을 다섯 관점으로 펼쳐 누락을 막는 출발선일 뿐, 목표값을 대신 정해 주지 않는다. 약어로 항목을 끌어낸 다음에는 반드시 각 항목을 측정 가능한 지표로 환산하고 상충을 조정해야, 점검표가 검증 가능한 명세로 바뀐다.
분석·설계 · 표준ISO/IEC 25010
소프트웨어 품질 모델 표준. 비기능 요구의 누락을 막는 체크리스트.
ISO/IEC 25010은 모든 특성을 채우는 양식이 아니라, 비기능 요구가 빠지지 않았는지 묻게 하는 점검표다. 각 특성에 측정 가능한 목표를 붙여 인수 기준으로 바꿔 둘 때 운영 단계의 품질 분쟁이 줄어든다. 시스템 성격에 따라 결정적 특성을 가려 역량을 집중하는 안목이 핵심이다.
분석·설계 · 비교기능 vs 비기능
동작을 정의하는 기능과 품질을 정의하는 비기능. 검수 분쟁은 대개 비기능에서 난다.
기능은 되느냐 안 되느냐로 판정되지만 비기능은 측정 기준이 없으면 영원히 합의되지 않는다. 빠르게·안전하게 같은 막연한 표현을 응답 시간·동시 처리량·복구 시간 같은 수치로 못 박아 두는 것이, 검수 막바지에 쏟아지는 추가 요구와 분쟁을 막는 가장 확실한 방법이다.