이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
비즈니스 요구사항을 정의할 때 가장 먼저 하는 건 이 요구사항이 어떤 문제를 해결하기 위한 것인지를 확인하는 것입니다. 요청을 그대로 구현하면 원하는 결과가 나오지 않는 경우가 종종 있어, 요청의 배경을 먼저 이해하는 것이 중요합니다. 수업 프로젝트에서 시스템 요구사항 문서를 작성할 때, 현재 상태(AS-IS)와 목표 상태(TO-BE)를 구분해 작성했더니 개선 범위가 명확해졌습니다. 요구사항은 기능 요구사항과 비기능 요구사항을 분리해서 작성하는 것이 개발 단계에서 도움이 됩니다. 예를 들어 로그인 기능 자체는 기능 요구사항이고, 응답 시간이나 동시 접속 허용 범위는 비기능 요구사항입니다. 요구사항 정의는 확인을 반복하는 과정이기도 합니다. 한 번 정리 후 이해관계자에게 검토를 요청해 해석 차이를 초반에 정렬하는 것이 나중의 재작업을 줄입니다.
비즈니스 요구사항을 정의하는 것에서 가장 어려운 자리는 이해관계자마다 원하는 것이 다를 때 어떻게 하나의 요구사항으로 만드느냐입니다. 개발팀은 기술적 실현 가능성을 기준으로 보고, 영업팀은 고객 요청을 기준으로 보며, 경영진은 비용과 일정을 기준으로 봅니다.
모든 기준을 만족하는 요구사항이 항상 존재하지 않기 때문에, 어느 기준을 우선할지를 결정하는 것이 본질입니다.
요구사항 문서를 잘 작성해도 그 문서를 보는 사람마다 해석이 달라지는 경우가 생깁니다. 수업 프로젝트에서 팀원 간 이해가 달라 기능 구현 방향이 처음부터 어긋난 경험이 있었습니다. 해석 차이가 초반에 정렬되지 않으면 개발이 끝난 뒤 재작업이 발생합니다.
요구사항 정의의 한계는 문서 작성이 아니라 합의 만들기라는 것을 알고 있습니다.
비즈니스 요구사항 정의 경험이 이후 비슷한 작업에서 처음부터 가져가는 절차로 남았습니다. 요구사항을 정의할 때는 먼저 왜 이 기능이 필요한지를 묻고, AS-IS와 TO-BE를 구분해 작성하며, 기능과 비기능을 분리하는 것이 그 절차입니다. 작성 후 이해관계자 검토를 빠르게 거치는 것이 초반 정렬에서 가장 중요한 단계입니다.
검토 없이 다음 단계로 넘어가면, 나중에 방향이 달랐다는 것을 알게 됩니다. 팀 프로젝트에서 이 절차를 지켰을 때와 생략했을 때 결과 품질이 달랐다는 것을 경험했습니다. 초반에 정렬하는 비용이 이후 수정 비용보다 항상 낮다는 것을 알고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성증권 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.