반응형

2025/04/15 2

요구사항을 "명확하게" 썼는데, 왜 여전히 문제가 생길까요? - 소프트웨어 비기능 요구사항의 적절성

비기능 요구사항 작성은 항상 어렵습니다. 표현은 애매하고, 해석은 다르고, 검증은 어렵습니다.비기능 요구사항을 설명하고자 "안정적이게", "빠르게", "사용자 친화적으로"라는 모호한 표현들이 수반되고,이들이 반복될 수록 개발 현실에서는 더 많은 질문들이 쏟아집니다. "얼마나 빠르게?""얼마나 안정적으로?""사용자 친화적이라는 누구를 기준으로 하나요?" 그래서 비기능 요구사항 작성을 위한 한걸음 더 들어가보면, 결국 비기능 요구사항은 시스템이 무엇을 해야 하는지보다, 어떻게 동작해야 하는지를 규정하는 것인데, 일반적으로 다음과 같은 품질 속성과 관련된 요소들을 포함하게 됩니다. 성능: 응답 시간, 처리량가용성: 가동 시간, 중단 시간보안: 인증, 권한, 암호화사용성: 직관성, 접근성유지보수성: 수정 용이성..

도대체 "빠르게"가 얼마나 빨라야 하나요? - 소프트웨어 비기능 요구사항의 명확성

소프트웨어 요구사항에서 비기능 요구사항을 작성할 때 자주 빠지는 함정은 이 비기능 요구사항을 "설계 가이드"나 "바람"처럼 모호하게 적는 것입니다. 하지만 비기능 요구사항도 요구사항이며, 따라서 품질을 보장하기 위한 명확한 작성 기준이 필요할 것입니다. 다행히 INCOSE의 니즈 및 요구사항 명세 특성 (in Guide to Writing Requirements, GWR)은 요구사항이 가져야할 몇가지 기준을 이미 제시하고 있습니다. 이를 이용하여 별도의 비기능 요구사항 특성을 정의하지 않고도, 다음과 같은 물음을 통해 비기능 요구사항의 품질을 확보 할 수 있을것으로 생각합니다.비기능 요구사항이 명확하게 정의되었는가? (C3, Unambiguous): INCOSE 요구사항 작성 가이드(GWR): Unamb..

반응형