요구사항공학 (Requirements Engineering)
쉽게 풀면
건물을 짓기 전에 건축주와 건축가가 "방은 몇 개, 주차장은 어디에, 예산은 얼마까지"를 먼저 정확히 합의해야 하듯이, 소프트웨어나 시스템을 만들기 전에도 "이 시스템이 정확히 무슨 일을 해야 하는가"를 먼저 정리해야 합니다. 요구사항공학은 이 과정을 크게 네 단계로 다룹니다. 첫째, 사용자·고객·현업 담당자를 인터뷰하거나 관찰해서 필요한 기능을 끌어내는 도출(elicitation), 둘째, 이를 문서나 다이어그램으로 명확하게 정리하는 명세(specification), 셋째, 정리된 요구사항들이 서로 모순되지 않고 실현 가능한지 확인하는 검증(validation), 넷째, 개발 도중 요구사항이 바뀔 때 이를 추적하고 관리하는 관리(management)입니다. 이 과정을 소홀히 하면 "다 만들고 보니 정작 필요한 기능이 빠져 있었다"는 상황이 생기기 쉽습니다.
왜 중요한가
소프트웨어 프로젝트 실패의 상당수는 코딩 실력의 문제가 아니라 처음부터 무엇을 만들어야 하는지가 잘못 정의되었기 때문에 발생합니다. 요구사항공학은 이런 문제를 개발 초기 단계에서 방지하기 위한 체계적 방법론이어서, 소프트웨어공학 연구뿐 아니라 애자일 개발, 대규모 시스템 통합, 안전이 중요한 시스템(의료기기, 항공 소프트웨어 등) 개발 논문에서도 핵심적으로 다뤄집니다. 요구사항이 얼마나 명확하고 검증 가능하게 정리되었는지는 이후 설계·구현·테스트 단계의 품질에 직접적인 영향을 미칩니다.
논문에서는 이렇게 쓰입니다
이 문장은 "시스템 관련자들을 인터뷰해서 시스템이 해야 할 기능과, 성능·보안 같은 부가 조건들을 뽑아내고, 이를 구체적인 사용 시나리오 형태로 정리했다"는 뜻입니다.
애자일 소프트웨어 개발 맥락에서, 처음부터 모든 요구사항을 완벽히 정리하기보다 개발을 진행하며 짧은 단위로 요구사항을 계속 다듬어가는 접근을 취했다는 뜻입니다.
안전이 중요한 시스템 개발 맥락에서, 요구사항 하나하나가 어떤 규제 요건에서 비롯되었는지 근거를 추적할 수 있게 관리해야 한다는 뜻입니다.
조금 더 깊게 보면
요구사항공학에서는 요구사항 간의 추적성(traceability)을 얼마나 잘 유지하는지가 중요한 품질 지표로 다뤄집니다. 이는 하나의 요구사항이 어떤 설계 요소, 코드, 테스트 케이스와 연결되어 있는지 계속 추적할 수 있는 능력을 말하며, 요구사항이 바뀌었을 때 영향을 받는 범위를 파악하는 데 필수적입니다. 또한 요구사항 간 상충(예를 들어 성능을 높이려면 보안 검증 단계가 늘어나 속도가 느려지는 경우)을 어떻게 우선순위화하고 절충하는지도 이 분야의 주요 연구 주제입니다.
주의할 점
요구사항공학에서는 "기능적 요구사항"(무엇을 하는가)뿐 아니라 "비기능적 요구사항"(얼마나 빠른가, 얼마나 안전한가 등)도 함께 정의해야 합니다. 비기능적 요구사항을 누락하면 기능은 제대로 동작해도 실제 사용 환경에서 성능이나 보안 문제로 시스템이 실패할 수 있으므로, 두 유형을 모두 문서화하고 검증했는지 확인해야 합니다.