품질 속성의 기술과 평가

Software Requirement 문서를 작성할 때 보통은 Functional Requirement(FR)와 Non Functional Requirement(NFR)로 구분하여 작성하게 됩니다. 대부분의 사람들이 FR에 비해서 NFR을 작성하는데 보다 어려움을 느끼고 있습니다. NFR은 Quality Attribute(QA)라고도 합니다. 우리말로는 품질 속성이라고도 합니다. QA는 Software Architecture에 큰 영향을 미치게 되며, 설계와 구현까지도 그 영향에서 결코 자유로울 수는 없습니다.

그런데 이렇게 중요한 QA가 FR에 비해서 작성하기 어려운 이유는 무엇일까요? Performance는 H/W의 사양이나 시나리오에 따라 측정 결과는 제 각각입니다. Modifiability의 경우 코드의 수정용이성인데 “코드는 수정하기 쉬워야 한다.”같은 정성적(qualitative)인 표현 방식으로는 요구사항의 수용여부를 측정할 방법이 없습니다.

품질관리를 위해서는, 보다 좋은 Architecture를 보유하기 위해서는 품질요구사항을 정리하는 것이 무엇보다 중요할 것 입니다. 이를 위해서는 Stakeholder들이 모여 Quality Attribute Workshops(QAWs)을 작성하는 것도 좋은 방법 중 하나입니다. “코드는 수정하기 쉬워야 한다.”는 “기술본부에 접수된 버그는 개발본부에 의해서 수정되어 4일 이내에 고객에게 패키지가 제공되어야 한다.”와 같은 구체적인 언어로 기술될 필요가 있습니다. Performance의 경우도 단순한 속도 향상이 아니라 “1000만원 이하의 Unix 호환 서버에서 인덱스가 있는 1000만 건의 레코드를 가진 테이블에서 인덱스를 사용하여 1건의 레코드를 원격지에서 초당 10만회 이상 조회할 수 있어야 한다.”와 같이 기술될 필요가 있습니다. 이렇게 도출된 품질요구사항에 개발난이도나 중요도를 추가하면 QAWs의 작성이 완료됩니다.

QAWs를 기반으로 다수의 Architecture가 작성되게 되며 QAWs의 기반으로 Architecture를 선택해야 합니다. 각 Architecture가 각 품질요구사항을 얼마나 잘 충족시키는지를 평가해야 합니다. 이 자료를 바탕으로 보다 중요한 품질요구사항을 보다 많이 충족시키는 Architecture를 선택해야 합니다.

하지만 QAWs의 품질요구사항이 모두 만족되어야 하는 것은 아닙니다. 만약 당신이 “10톤의 화물을 싣고 안락한 승차감으로 고속도로를 300Km/h로 달릴 수 있는 자동차”를 만들고자 한다면 실패할 수 밖에 없기 때문입니다.