요구사항 식별

요구사항이 성패의 절반

프로젝트 실패 원인의 약 절반은 요구사항에서 비롯된다. 발주자가 무엇을 원하는지 명확히 정의하지 못하는 불충분한 입력(Poor User Input), 누락과 모호함이 섞인 불완전한 요구(Incomplete Requirement), 진행 중 끊임없이 바뀌는 변경 요구(Change Requirement)가 대표적이다.

그래서 요구사항을 다루는 첫 단계인 식별(Elicitation)의 품질이 프로젝트 전체의 품질을 좌우한다.

식별. 폭넓게 끌어낸다

식별 단계는 RFP, 인터뷰, 벤치마킹, 설문, 초기 프로토타입 등에서 가공되지 않은 원천 데이터를 모으는 과정이다. 이 단계의 데이터에는 불확실한 요구나 실현 불가능한 요구가 섞여 있지만, 거르기보다 잠재 요구(needs) 수준까지 폭넓게 끌어내는 것이 우선이다.

무엇을 채택하고 무엇을 제외할지 가리는 일은 다음 단계인 분석의 몫으로 분리하는 것이 원칙이다.

요구사항 정의를 분할하라

요구사항 정의를 하나의 과업으로 묶어 두면 통제가 어렵다. 식별·분석·명세·검증·변경의 다섯 단계로 분할해야 각 단계의 누락과 충돌을 다룰 수 있다.

기초 데이터는 식별에서 확보하고, 분석에서 누락·중복·상충을 정리한 뒤, 명세(초안, 0.9)와 검증(고객 확정, 1.0)을 거쳐 요구사항을 안정화한다.

출처를 반드시 기록한다

충분히 수집했다고 판단해도 누락은 발생한다. 이를 방지하는 핵심이 ‘출처’의 기록이다.

요구사항 정의서에 각 항목이 기술 협의, 브레인스토밍, 인터뷰 등 어디에서 도출되었는지를 함께 적어두면, 출처를 역추적해 빠진 요구를 찾아낼 수 있다. 같은 방식으로 중복과 상충도 출처 비교를 통해 정리한다.

이러한 절차는 SWEBOK에 체계적으로 정리되어 있으므로 참고할 가치가 크다.

분석으로 이어지며 함께 보는 것

식별이 끝나면 분석으로 넘어가며 두 가지를 함께 본다. 첫째는 트레이드오프(Trade-Off)다.

성능과 보안처럼 한쪽을 높이면 다른 한쪽이 낮아지는 상충 관계를 인지하지 못한 요구는 후반에 반드시 문제를 일으킨다. 둘째는 기능과 비기능의 구분이다.

잠재 요구에서 확정 요구로 좁혀가며 드러나는 추가 요구는 대개 비기능(성능·보안·사용성)에서 나오므로, ISO/IEC 25010이나 FURPS 같은 체크리스트로 비기능 누락을 막아야 한다.

검수와 발주 유형을 염두에 둔다

요구사항은 결국 검수의 기준이 되므로, 식별 단계부터 그 분리 체계를 염두에 두어야 한다. 검수는 과정 중심으로는 산출물로, 결과 중심으로는 범위로 이루어지며, 기능은 결함률 같은 품질지표로 비기능은 보안·성능으로 확인한다.

또한 발주 유형이 통합이냐 분리냐에 따라 검수의 경계가 달라진다. 이러한 분리 기준은 IEEE와 SWEBOK에 체계적으로 정리되어 있다.

식별 단계에서 폭넓게 모은 요구를 이후 기능과 비기능, 과정과 결과로 나누어 정리해 두면, 검수 시점의 분쟁을 줄이고 누락되기 쉬운 비기능을 조기에 발견할 수 있다.