요구공학으로 요구사항을 명확히 정의하고 변경을 관리하는 방법

프로젝트의 기준은 요구사항을 어떻게 다루는가에서 갈린다

소프트웨어가 해결해야 할 문제를 제대로 규정하지 못하면, 이후 설계와 구현이 아무리 정교해도 프로젝트는 흔들린다. 요구공학(Requirements Engineering)은 이해관계자의 요구 가운데 충돌하는 부분을 파악하고 조율하면서, 이를 수집·분석·명세화·검증하는 체계적인 공정이자 학문 분야다.

이 활동은 기능 목록을 작성하는 데 그치지 않는다. 시스템이 제공해야 할 능력과 지켜야 할 제약을 식별하고, 사용자와 개발팀 사이의 해석 차이를 줄이는 일이 본질이다. 요구사항의 모호함과 빈번한 변경은 소프트웨어 위기의 주요 원인으로 지적되어 왔으며, 요구공학은 그 간극을 관리하는 기반이 된다.

비정형적인 사용자 요구를 개발에 사용할 수 있는 명세로 전환하면 기준선(Baseline)을 마련할 수 있다. 이 기준은 요구 누락을 줄이고 변경 이력을 추적하게 하며, 완성된 제품이 품질 기준을 충족하는지 확인할 근거가 된다.

특히 다음과 같은 문제를 다룬다.

사용자가 자신이 원하는 바를 정확히 설명하지 못해 생기는 의사소통 단절
개발 과정에서 계속 들어오는 변경 요청
개발자가 제각각 해석할 수 있는 모호한 명세

타당성 검토에서 검증까지 이어지는 요구사항 개발

요구사항 개발은 타당성을 판단하는 일에서 출발해 요구사항 문서를 검증하는 단계까지 이어진다. 각 단계는 산출물을 남기며, 그 결과가 다음 활동의 입력으로 사용된다.

먼저 타당성 분석(Feasibility Analysis)에서는 기술적 구현 가능성, 경제적 가치, 법적·사회적 제약을 검토한다. 여기서 작성되는 타당성 보고서는 프로젝트 착수 여부를 판단하는 핵심 문건이다.

요구사항 추출 및 분석(Elicitation & Analysis) 단계에서는 이해관계자의 요구를 끌어내고 분류하며 우선순위를 정한다. 설문, 인터뷰, 브레인스토밍, 프로토타이핑 등을 활용할 수 있고, 분석 결과로 시스템 모델을 만들면서 요구사항 사이의 충돌을 해소한다.

명세화(Specification)는 분석 결과를 문서로 정리하는 작업이다. 사용자가 읽기 쉬운 자연어와 개발자가 참조할 정형화된 모델링 언어를 함께 사용해 시스템 요구사항 명세서를 작성한다.

마지막으로 검증(Validation)에서는 문서가 사용자의 의도를 정확히 담았는지, 표준에 맞는지, 내부적으로 일관된지를 확인한다. 검토(Review), 워크스루(Walkthrough), 인스펙션(Inspection)은 요구사항 문서의 품질을 확정하는 데 쓰인다.

⤢✕

기준선을 세운 뒤에도 요구사항은 계속 관리된다

요구사항 개발이 끝났다고 관리가 끝나는 것은 아니다. 소프트웨어 생명주기 전반에서 요구사항은 변경될 수 있으며, 요구사항 관리는 그 변화에 대응하면서 시스템의 무결성을 지키는 역할을 한다.

이해관계자의 요구가 충돌하면 요구사항 협상(Negotiation)이 필요하다. 비용, 일정, 기술적 한계를 함께 고려해 합의점을 찾아야 하며, 모든 요구를 수용하기보다 비즈니스 가치가 높은 항목을 우선 선택할 수 있다.

검증된 요구사항 명세서는 공식 기준선(Baseline)으로 확정한다. 기준선 이후의 변경은 공식 절차를 거쳐야 하므로, 이는 프로젝트 범위를 관리하는 중심 장치가 된다.

변경관리(Change Management)는 변경 요청을 분석하고 승인 여부를 결정하는 과정이다. 변경이 시스템 전반에 미칠 영향을 미리 분석해 파급효과와 리스크를 줄인다. 동시에 구현 결과가 명세서와 일치하는지 확인하는 Verification, 그리고 실제 사용자 목적에 맞는지 점검하는 Validation을 지속적으로 수행한다.

명세서는 구현과 검증을 연결할 수 있어야 한다

요구사항 명세서의 품질은 개발 효율성과 직접 연결된다. 명세서는 실제 사용자가 원하는 기능을 정확하게 표현해야 하며, 하나의 의미로 해석될 수 있도록 명확해야 한다. 시스템의 기능과 제약이 빠짐없이 포함되고, 요구사항 사이에 모순이 없어야 한다.

변경이 발생했을 때 수정하기 쉬워야 하고, 각 요구사항의 출처부터 설계·코드·테스트까지 이어지는 연결 고리도 확인할 수 있어야 한다. 비전문가인 고객과 전문가인 개발자가 함께 이해할 수 있는 문서여야 하며, 운영과 유지보수 단계에서도 활용 가치가 있어야 한다.

또한 요구사항마다 중요도와 긴급도를 표시하고, 객관적인 테스트나 검사를 통해 구현 여부를 확인할 수 있어야 한다. 정확성, 명확성, 완전성, 수정 용이성, 추적 가능성, 이해 용이성, 일관성, 개발 후 이용성, 우선순위 포함, 검증 가능성은 이러한 평가의 기준이 된다.

점진적으로 구체화되는 요구와 사람의 조정 역량

애자일(Agile) 방법론이 확산되면서 요구공학의 방식도 달라지고 있다. 폭포수 모델처럼 초기에 모든 요구사항을 확정하려 하기보다, 지속적인 소통과 피드백을 통해 요구사항을 점차 구체화하는 접근이 선호된다.

AI와 머신러닝을 요구공학에 접목해 자연어 요구사항의 오류를 자동으로 탐지하거나, 유사 프로젝트 데이터를 바탕으로 요구사항을 추천하는 연구도 진행되고 있다. 다만 이해관계자가 드러내지 않은 니즈를 파악하고, 상충하는 요구를 조정하는 공감과 커뮤니케이션 역량은 여전히 요구공학 전문가의 핵심 자질이다.

요구공학은 무엇을 만들지 정하는 절차이면서, 왜 그것을 만들어야 하는지 확인하는 과정이기도 하다. 개발 절차, 관리 기법, 평가 기준을 함께 적용할 때 프로젝트의 불확실성을 줄이고 소프트웨어 산출물의 품질을 뒷받침할 수 있다.