요구사항 분석

요구사항 분석이란 무엇인가

요구사항 분석(Requirement Analysis)은 식별 단계에서 모아 온 이해관계자의 요구를 정리해 누락·중복·상충을 가려내고, 각 요구가 실제로 실현 가능한지를 판정하는 활동이다. 수집된 원시 요구는 표현이 제각각이고 서로 모순되거나 같은 말이 반복되는 경우가 많아, 그대로 명세로 옮기면 설계와 개발 단계에서 충돌이 터진다.

분석은 이 흩어진 요구를 한자리에 모아 정합성을 점검하고, 기술·일정·예산의 제약 안에서 무엇을 수용하고 무엇을 보류할지 구분하는 거름망 역할을 한다. 요구사항 정의를 식별·분석·명세·검증·변경의 다섯 단계로 나누어 통제할 때, 분석은 그 중심에서 품질의 분기점이 되는 단계다.

누락·중복·상충을 가려낸다

분석의 첫 임무는 모인 요구들 사이의 관계를 점검하는 것이다. 빠진 요구가 없는지 확인하는 누락 점검, 같은 요구가 다른 표현으로 여러 번 등장하지 않는지 보는 중복 점검, 두 요구가 동시에 만족될 수 없는지 살피는 상충 점검이 한 묶음으로 진행된다.

예를 들어 한 부서는 응답 속도를 최우선으로 두고 다른 부서는 보안 절차 강화를 요구할 때, 두 요구는 같은 자원을 두고 경쟁하므로 그대로 둘 수 없다. 이런 충돌은 분석 단계에서 표면화시켜 이해관계자가 보는 앞에서 조정해야 하며, 미루면 개발 후반에 재작업으로 돌아온다.

가려낸 결과는 다음 단계인 명세서 작성의 입력이 된다.

실현가능성과 Trade-Off

모든 요구가 받아들여질 수는 없으므로 분석은 실현가능성 판정을 동반한다. 기술적으로 구현이 가능한지, 주어진 일정과 공수 안에 들어오는지, 운영 환경에서 유지될 수 있는지를 따져 수용 가능한 요구와 그렇지 않은 요구를 나눈다.

이 과정은 본질적으로 Trade-Off의 연속이다. 성능을 높이면 비용이 오르고, 보안을 강화하면 편의성이 내려가며, 기능을 늘리면 일정이 밀린다.

PM과 분석가는 어느 한쪽을 절대 기준으로 삼기보다, 이해관계자가 합의한 우선순위 위에서 무엇을 내주고 무엇을 지킬지를 명시적으로 결정해야 한다. 결정의 근거를 남겨 두어야 이후 변경 요청이 들어왔을 때 일관되게 대응할 수 있다.

기능과 비기능을 함께 본다

분석에서 자주 빠지는 축이 비기능 요구사항이다. 화면과 처리 같은 기능 요구는 이해관계자가 먼저 말하지만, 응답 시간·가용성·보안 수준·확장성 같은 비기능 요구는 명시적으로 요청되지 않은 채 당연한 기대로 남는 경우가 많다.

이 영역을 분석 단계에서 수치와 조건으로 끌어내지 않으면, 기능은 다 만들었는데 느리거나 불안정해서 검수에서 반려되는 사태가 벌어진다. 비기능 요구는 시스템 전반에 걸쳐 영향을 미치므로 설계 구조를 좌우하며, 뒤늦게 추가하면 이미 만든 구조를 갈아엎어야 한다.

따라서 분석가는 기능 목록을 정리하는 동시에, 각 기능이 어떤 품질 조건 아래 동작해야 하는지를 반드시 병기해야 한다.

분석 결과의 추적성

분석의 산출물은 그 자체로 끝나지 않고 뒤 단계로 이어질 수 있도록 추적성을 갖춰야 한다. 어느 이해관계자의 어떤 요구에서 비롯되었고, 어떤 판단으로 수용 또는 보류되었으며, 어느 설계 항목으로 연결되는지가 끊기지 않고 남아야 한다.

추적성이 확보되면 변경이 발생했을 때 그 파장이 어디까지 미치는지를 빠르게 가늠할 수 있고, 검증 단계에서 빠진 요구가 없는지를 역으로 확인할 수 있다. 반대로 분석 결과가 단편적인 메모로만 흩어지면, 같은 논쟁이 단계마다 되풀이되고 합의했던 우선순위가 흐려진다.

분석은 결정을 내리는 활동인 동시에 그 결정의 근거를 문서로 고정하는 활동이다.

분석을 건너뛴 대가

일정이 촉박하다는 이유로 수집한 요구를 곧장 명세로 옮기면 당장은 빨라 보이지만, 정리되지 않은 충돌과 실현 불가능한 요구가 개발 단계까지 그대로 흘러간다. 설계가 진행된 뒤에야 상충이 드러나면 이미 작성한 코드와 설계를 되돌려야 하고, 그 비용은 분석 단계에서 처리했을 때와 비교할 수 없이 커진다.

분석은 눈에 보이는 산출물이 적어 생략되기 쉬운 단계지만, 후반의 재작업을 줄이는 가장 값싼 보험이다. 충분한 분석을 거친 요구는 명세서에서 명확한 문장으로 기록되고, 검증 단계에서 합의된 기준으로 확인되며, 변경 단계에서 통제 가능한 범위 안에 머문다.