A-RMS는 ALM 시스템(Atlassian Jira, Redmine 등)과 연계하여 제품(Service)(기반의 요구사항( Issue)을 공유할 수 있는 RMS (Requirement Management System)입니다.

현존하는 이슈 기반 요구사항( Issue) 관리 시스템은 없으므로, A-RMS를 만들어서 제품(Service)별 요구사항( Issue)을 관리 및 전파하여 추적성을 확보하고 ALM 시스템과 통합하여 제품(Service)기반 프로젝트 진척도를 파악 할 수 있는 가시성을 제공하는 시스템 입니다.

제품(Service)별 요구사항( Issue ) 기반 진척상황 파악 : 제품(Service) 진척 상황을 쉽게 파악할 수 있는 시스템이 부재하여, 프로젝트 참여자들은 실시간으로 제품의 진행 상황을 파악하기 어려운 점이 있습니다.

요구사항( Issue) 이력 관리 부재: 요구사항( Issue)의 등록, 채택, 거절 및 변경 이력을 관리하지 않음으로써, 프로젝트의 진행 과정에서 어떤 변화가 있었는지 추적하기 어려운 상황이 발생합니다.

제품(Service)별 요구사항과 ALM Project Issue간 매핑 어려움: 제품(Service) 와 요구사항( Issue) 간의 매핑이 복잡하여, 프로젝트 기반의 작업 플로우를 제품(Service) 기반으로 확장하기 어렵습니다. 이로 인해 요구사항과 실제 제품(Service) 간의 일치 여부 파악이 어려워지는 점이 있습니다. 이를 파악하기 쉽게 해결하고자 합니다.

요구사항( Issue) 변경 권한 관리 필요성: 요구사항( Issue) 변경에 대한 권한 관리가 필요하며, 이를 통해 요구사항( Issue)의 변경이 비효율적으로 이루어지거나 예기치 못한 변경이 발생하는 상황을 방지하고자 합니다.

개발 진척 상황 보고의 어려움: 개발 진척 상황을 문서화하여 개발 팀장에게 보고하는 과정이 복잡하고 시간 소모적으로 진행되며, 보고 자료의 작성에 상당한 시간과 노력이 소요됩니다.

SRS에 적시되는 요구사항( Issue)의 작성자: 현재 SRS에 기재되는 요구사항( Issue)은 주로 개발자가 작성하고 있습니다. 이는 개발자의 기술적인 시각으로부터의 관점이 강조될 수 있으며, 고객이나 업무 담당자의 요구와 일치하지 않을 수 있습니다

요구사항( Issue)의 발의자: 요구사항( Issue)의 발의는 고객 또는 업무 담당자와 직접적으로 상호작용하는 사람들이 주로 수행하고 있습니다. 또한 기획자나 내부 개발자 역시 요구사항( Issue)을 발의하는데 관여하고 있습니다. 이로 인해 다양한 역할들 간의 의사소통 부재와 일관성의 결여가 문제로 작용할 수 있습니다.

요구사항( Issue)의 발의자: 요구사항( Issue)의 발의는 고객 또는 업무 담당자와 직접적으로 상호작용하는 사람들이 주로 수행하고 있습니다. 또한 기획자나 내부 개발자 역시 요구사항( Issue)을 발의하는데 관여하고 있습니다. 이로 인해 다양한 역할들 간의 의사소통 부재와 일관성의 결여가 문제로 작용할 수 있습니다.

요구사항( Issue)에 대한 이력 미관리: 현재 요구사항( Issue) 변경에 대한 이력은 SRS에 기록됨에도 불구하고, 변경 사항의 추적성이 부족합니다. 변경 사항의 최종 형상만 확인되며, 중간 과정의 변경 및 이력이 적절히 관리되지 않습니다.

요구사항( Issue) 충족 여부 확인의 어려움: 요구사항( Issue)을 발의한 사람들이 제시한 대로 제품(Service) 개발되고 있는지 확인하는 것이 어렵습니다. 개발 팀장을 통해 요구사항( Issue)의 해석과 개발 진행 상황을 전달받기 때문에, 요구사항( Issue)의 충족 여부를 정확하게 확인하기 어려운 상황이 발생합니다.

이러한 문제점들은 요구사항( Issue) 관리 및 프로젝트 진행 상황 파악에 대한 투명성과 효율성을 제한하는 요인으로 작용하고 있습니다. 이러한 배경을 통해 새로운 요구사항( Issue) 관리 시스템의 필요성과 중요성을 높이고자 합니다.