요구사항 공학: 시스템 개발을 좌우하는 정의·검증·변경 관리

개발의 방향은 요구사항에서 정해진다

요구사항은 사용자 요구와 비즈니스 목표를 시스템의 서비스와 제약사항으로 전환하는 작업이다. 구현, 테스트, 운영은 모두 이 기준을 따라가므로 요구사항이 흔들리면 이후 활동도 같은 방향을 잃는다.

요구사항은 문제를 해결하거나 목적을 달성하기 위해 사용자가 요청하는 내용이면서, 표준과 명세를 충족하기 위해 시스템이 갖춰야 하는 서비스 및 제약사항이기도 하다. 요구사항 오류는 전체 프로젝트 비용의 80%까지 차지할 수 있는 리스크가 될 수 있다. 2003년 토요타 자동차 CRM 시스템 구축 실패는 불명확한 요구사항으로 10억 달러 이상 손실이 발생한 사례로 언급된다.

시스템을 규정하는 요구의 성격

기능적 요구사항은 시스템이 제공해야 할 기능과 서비스를 명시한다. 입력에 대해 시스템이 어떻게 반응하고 어떤 방식으로 동작해야 하는지가 여기에 속한다. 예를 들어 “사용자는 이메일과 비밀번호로 로그인할 수 있어야 한다.”는 기능적 요구사항이다.

비기능적 요구사항은 기능 자체보다 시스템의 품질 특성과 제약을 다룬다. 성능, 보안, 사용성, 신뢰성, 확장성이 대표적인 범주다.

성능 요구사항은 응답시간, 처리량, 자원 활용을 다룬다.
보안 요구사항은 인증, 권한, 데이터 보호와 관련된다.
사용성 요구사항에는 UI/UX, 접근성, 학습 용이성이 포함된다.
신뢰성 요구사항은 가용성, 장애 복구, 데이터 정확성을 대상으로 한다.
확장성 요구사항은 사용자와 데이터 증가에 대응하는 능력을 규정한다.

“시스템은 99.9% 이상의 가용성을 제공해야 한다.”는 비기능적 요구사항의 예다.

도메인 요구사항은 특정 응용 분야의 지식과 규칙에서 나온다. 해당 분야를 이해하지 못하면 요구 자체를 해석하기 어렵다. 의료 시스템이 HIPAA 규정을 준수해야 한다는 요구가 이에 해당한다.

도출한 요구를 운영 가능한 기준으로 만드는 흐름

요구사항 활동은 한 번의 문서 작성으로 끝나지 않는다. 수집한 요구를 분석하고 명세로 남긴 뒤 검증하며, 변경이 생기면 다시 도출 단계와 연결해야 한다.

⤢✕

요구사항 도출에서는 이해관계자로부터 필요한 내용을 수집한다. 구조화 또는 비구조화 인터뷰, 다수 의견을 모으는 설문조사, 브레인스토밍, 실제 업무 환경의 사용자 행동을 보는 관찰이 활용된다. 초기 모델로 피드백을 받는 프로토타이핑, 워크샵 형태의 JAD(Joint Application Development), 기존 시스템 문서를 검토하는 문서 분석도 도출 기법이다.

분석 단계에서는 수집 결과를 구조화하고 서로 충돌하는 요구를 조정한다. UML 다이어그램, ERD, DFD 같은 모델링 기법을 활용할 수 있으며, 요구사항 사이의 우선순위도 이 과정에서 설정한다.

⤢✕

분석 결과는 SRS(Software Requirements Specification), Use Case Specification, 애자일 방법론의 User Story 같은 산출물로 명세화한다. 명세는 정확성(Correctness), 완전성(Completeness), 일관성(Consistency), 명확성(Clarity), 검증가능성(Verifiability), 추적성(Traceability), 실현가능성(Feasibility)을 기준으로 검증한다.

이후에는 요구사항 변경을 관리하고 추적해야 한다. 형상 관리 도구를 활용해 베이스라인을 설정하고, 변경이 미치는 영향을 통제하는 일이 요구사항 관리의 핵심이다.

모호하지 않은 요구를 남기는 방식

요구사항은 SMART 원칙으로 점검할 수 있다. 구체적(Specific)이어야 모호함이 줄고, 측정 가능(Measurable)해야 검증 기준을 세울 수 있다. 달성 가능(Achievable)한지, 비즈니스 목표와 관련성(Relevant)이 있는지, 일정 기준(Time-bound)이 분명한지도 함께 확인한다.

명세에는 식별자와 검증 방법, 의존 관계까지 남겨야 변경 이후에도 추적할 수 있다.

REQ-ID: 고유식별자
제목: 간결한 요구사항 제목
설명: 요구사항 상세 설명
우선순위: High/Medium/Low
출처: 요구사항 도출 출처(이해관계자 정보)
검증 방법: 해당 요구사항 검증 방법
의존성: 관련 요구사항 목록

반복 개발과 배포 흐름 안의 요구사항

애자일 방식에서는 사용자 스토리를 중심으로 요구사항을 다룬다. 형식은 “As a [role], I want [feature], so that [benefit]”이며, 백로그를 통해 우선순위를 조정한다. 요구사항은 점진적이고 반복적으로 개발된다.

DevOps 환경에서는 지속적인 피드백을 요구사항에 반영하고, 자동화된 요구사항 추적 시스템을 사용할 수 있다. 기능 플래그(Feature Flags)는 기능을 점진적으로 배포하는 수단이 된다.

요구사항 관리에는 JIRA의 이슈 추적 및 프로젝트 관리 기능, Confluence의 문서 협업 및 지식 관리 기능을 활용할 수 있다. IBM Rational DOORS는 엔터프라이즈급 요구사항 관리를, ReqView는 요구사항 추적 및 관리를, Modern Requirements는 요구사항 작성 및 추적을 지원한다.

기존 해법을 새 환경에 옮길 때 생기는 문제

1996년 아리안 5호 로켓 폭발은 아리안 4용 소프트웨어를 아리안 5에 재사용하면서 요구사항 불일치가 발생한 사례다. 기존 시스템에서 동작했던 소프트웨어라도 새로운 컨텍스트에 적용할 때는 요구사항을 다시 검토해야 한다.

영국 NHS 전자건강기록 시스템은 2002-2011년에 지나치게 복잡한 요구사항과 잦은 변경을 겪었고, 100억 파운드 이상 손실이 발생했다. 이 사례는 점진적으로 접근하고 이해관계자가 지속적으로 참여해야 한다는 점을 보여준다.

분석과 추적의 자동화가 넓어지는 방향

요구사항 관리에는 자연어 처리를 이용해 품질을 개선하는 AI 기반 요구사항 분석, 유사 프로젝트의 요구사항을 추천하는 ML 기반 추천 시스템이 적용될 수 있다. 요구사항·설계·코드·테스트 사이의 자동화된 추적성도 확대되는 영역이다. VR/AR을 활용한 몰입형 프로토타이핑은 요구사항을 검증하는 방식으로 활용될 수 있다.

요구사항은 문서 작성 절차에 그치지 않고 시스템이 무엇을 해야 하며 어떤 조건을 지켜야 하는지 정하는 활동이다. 개발 과정 전체에서 검증과 변경 관리를 이어갈 수 있어야 요구사항은 프로젝트의 기준으로 기능한다.