요구사항 분석

기능적 요구사항은 시스템이나 소프트웨어가 반드시 수행해야 하는 구체적인 행동, 작업, 기능을 정의한다. 즉, "무엇을 해야 하는가"에 초점을 맞춘다. 이는 사용자가 시스템을 통해 달성하고자 하는 업무 목표와 직접적으로 연결되며, 시스템의 입력, 처리, 출력과 관련된 구체적인 서비스를 명시한다. 예를 들어, "사용자는 아이디와 비밀번호를 입력하여 로그인할 수 있어야 한다" 또는 "시스템은 매월 1일에 모든 고객에게 청구서를 자동으로 발송해야 한다"와 같은 명세가 해당한다.

기능적 요구사항은 주로 유스케이스, 사용자 스토리, 시퀀스 다이어그램 등을 통해 도출되고 문서화된다. 유스케이스는 특정 액터(사용자나 외부 시스템)가 시스템과 상호작용하여 달성하는 하나의 목표를 기술하며, 기능적 요구사항을 구조화하는 데 널리 사용되는 기법이다. 사용자 스토리는 애자일 방법론에서 간결한 형식("~로서, ~기능을 원한다, 그래서 ~이유 때문이다")으로 요구사항을 표현하는 방식이다.

이러한 요구사항은 시스템 테스트와 인수 테스트의 기준이 되며, 최종 제품이 명세된 대로 정확히 작동하는지 검증하는 데 사용된다. 따라서 기능적 요구사항은 명확하고, 검증 가능하며, 모호하지 않게 작성되어야 한다. 잘 정의된 기능적 요구사항은 개발팀이 구현해야 할 핵심 기능의 범위를 이해하는 데 필수적이며, 프로젝트의 성공적 납품을 보장하는 기초가 된다.

비기능적 요구사항은 시스템이 "무엇을" 해야 하는지보다 "어떻게" 수행해야 하는지를 정의하는 제약사항과 품질 속성이다. 이는 시스템의 성능, 보안, 사용성, 신뢰성, 확장성 등과 같은 운영 및 환경적 특성을 규정한다. 기능적 요구사항이 시스템의 핵심 기능과 서비스를 명시한다면, 비기능적 요구사항은 그 기능들이 어떤 기준과 조건 하에서 제공되어야 하는지를 기술한다.

주요 유형으로는 성능 요구사항(예: 응답 시간, 처리량), 보안 요구사항(예: 접근 제어, 데이터 암호화), 사용성 요구사항(예: 학습 용이성), 신뢰성 요구사항(예: 가용성, 평균 고장 시간), 호환성 요구사항(예: 특정 운영체제 지원), 유지보수성 요구사항 등이 있다. 또한 법적, 규제적 제약이나 윤리적 기준도 중요한 비기능적 요구사항에 포함될 수 있다.

이러한 요구사항은 종종 측정 가능한 지표로 정의되어야 하며, 예를 들어 "시스템은 100명의 동시 사용자 하에서 주요 화면의 응답 시간이 2초 이내여야 한다"와 같이 구체적이고 검증 가능한 형태로 명세화된다. 명확한 비기능적 요구사항은 시스템 아키텍처 설계, 기술 스택 선택, 테스트 계획 수립에 결정적인 영향을 미친다.

비기능적 요구사항을 소홀히 하면, 시스템이 기능적으로는 완성되었더라도 실제 운영 환경에서 성능 저하, 보안 취약점, 사용자 불만 등으로 인해 프로젝트가 실패할 수 있다. 따라서 프로젝트 초기 단계부터 기능적 요구사항과 함께 체계적으로 도출, 분석, 문서화하여 품질 관리의 기준으로 삼아야 한다.

요구사항 도출은 이해관계자로부터 시스템에 대한 필요와 기대를 수집하고 발견하는 첫 번째 단계이다. 이 과정은 소프트웨어 개발 생명 주기의 초기에 이루어지며, 프로젝트의 성공적 기반을 마련하기 위해 필수적이다. 도출 활동은 단순한 정보 수집을 넘어, 고객이 명확히 표현하지 못한 숨겨진 요구사항을 발견하고, 다양한 이해관계자 간의 상충되는 의견을 조율하는 역할도 포함한다.

주요 도출 기법으로는 인터뷰, 설문조사, 워크숍, 브레인스토밍, 관찰 등이 널리 사용된다. 또한 기존 시스템의 문서를 분석하거나 벤치마킹을 통해 요구사항을 발견하기도 한다. 특히 애자일 방법론에서는 사용자와의 지속적인 소통을 강조하며, 사용자 스토리 작성과 프로토타이핑을 중요한 도출 수단으로 활용한다.

효과적인 도출을 위해서는 적절한 이해관계자를 식별하고, 그들이 속한 비즈니스 도메인에 대한 기본적인 이해가 필요하다. 도출된 요구사항은 초기에는 불완전하고 모호할 수 있으므로, 이후의 분석 및 명세 단계를 통해 점진적으로 정제되고 구체화된다.

도출된 요구사항은 분석 단계를 거쳐 체계적으로 정리되고 구조화된다. 이 단계에서는 수집된 초기 요구사항들이 서로 충돌하거나 모순되는지 확인하고, 불완전하거나 모호한 부분을 명확히 하며, 기술적 실현 가능성을 평가한다. 또한 요구사항들 간의 우선순위를 설정하고, 상세한 기능과 제약 조건을 구체화한다. 이를 통해 단순한 의견이나 아이디어 수준의 요구사항이 명확하고 검증 가능한 조건으로 발전한다.

분석된 요구사항은 명세화 활동을 통해 공식적인 문서로 작성된다. 이는 요구사항 명세서라는 형태로 가장 일반적이며, 시스템이 무엇을 해야 하는지에 대한 상세한 설명을 포함한다. 명세화의 핵심은 고객, 사용자, 개발자 등 모든 이해관계자가 동일한 내용을 이해할 수 있도록 모호성을 배제하고 명확하게 기술하는 것이다. 명세화 기법에는 자연어 서술, 구조적 의사결정표, 유스케이스, 시퀀스 다이어그램 등 다양한 형태가 사용되며, 요구사항의 복잡성과 프로젝트 특성에 따라 선택된다.

효과적인 명세화를 위해서는 요구사항이 검증 가능하고, 추적 가능하며, 일관성을 가져야 한다는 원칙이 중요하다. 또한 기능적 요구사항과 비기능적 요구사항을 구분하여 명시하는 것이 일반적이다. 이렇게 완성된 명세 문서는 이후 설계 단계의 직접적인 입력 자료가 되며, 테스트 케이스 작성의 기준이 되어 프로젝트의 품질을 좌우하는 핵심 산출물이 된다.

요구사항 검증 및 확인은 문서화된 요구사항이 정확하고 완전하며 일관성이 있으며, 이해관계자의 실제 필요와 의도를 올바르게 반영하는지 점검하는 활동이다. 이는 요구사항 분석 과정의 마지막 단계로, 이후 설계 및 구현 단계로 넘어가기 전에 오류를 조기에 발견하고 수정하여 프로젝트 비용과 시간을 절감하는 데 핵심적인 역할을 한다.

검증 활동은 주로 요구사항 명세서나 사용자 스토리와 같은 산출물 자체를 대상으로 한다. 주요 검증 항목으로는 요구사항 간의 모순이나 충돌이 없는지 확인하는 일관성, 필수 기능이나 성능 기준이 누락되지 않았는지 평가하는 완전성, 기술적, 법적, 비즈니스적 제약 조건을 모두 만족하는지 살펴보는 타당성, 그리고 명세된 내용이 실제 구현 가능한지 판단하는 실현 가능성이 포함된다. 이를 위해 동료 검토, 워크숍, 체크리스트 활용 등 다양한 기법이 사용된다.

한편, 요구사항 확인은 문서화된 내용이 최종 사용자나 고객을 비롯한 이해관계자의 기대와 의도에 부합하는지 최종적으로 확인하고 승인을 받는 과정이다. 이는 검증이 요구사항 문서의 내적 질을 점검하는 것이라면, 확인은 외부 기준과의 일치성을 평가한다고 볼 수 있다. 일반적으로 프로토타이핑을 통한 시연, 사용자 승인 테스트 계획 수립, 또는 공식적인 서명을 통한 승인 절차를 거쳐 이루어진다.

이러한 검증 및 확인 활동을 통해 프로젝트 팀은 명확하고 오류가 적은 요구사항 기반을 확보할 수 있으며, 이는 소프트웨어 품질 향상과 프로젝트 관리의 성공 가능성을 높이는 데 기여한다. 특히 애자일 방법론에서는 짧은 스프린트 주기마다 지속적인 피드백과 확인을 통해 요구사항의 정확성을 유지한다.