요구사항 추출 방법
요구사항은 누구나 알고 있는 자명한 사실이 아닙니다. 여러 가지 방법을 동원하여 사용자로부터 또는 여러 정보를 통하여 추출하여야 합니다. 이번 글에서는 요구사항을 추출하는 여러 가지 방법에 대하여 알아봅시다. 각 방법마다 추출하는 요구사항의 범위와 효율이 다릅니다. 즉 요구사항의 범위가 넓게 추출되는 방법이 있고 깊게 추출되는 방법이 있습니다.
요구를 모으는 작업은 업무 프로세스와 애플리케이션 도메인에 대한 정보에 초점을 두어야 합니다. 특히 다음과 같은 질문에 대한 답을 얻기 위하여 여러 가지 요구 추출 방법을 동원하게 됩니다.
- 자동화 시스템을 구축하는 것은 어떤 업무를 위한 것인가?
- 현재 업무의 상황, 즉 어떻게 운용되는가?
- 시스템의 환경과 배경은 무엇인가?
- 현재의 업무 프로세스, 입출력은? 서로 어떻게 연관되어 있는가?
- 현재 시스템의 문제는 무엇인가?
- 현재 업무 또는 제품의 목표는 무엇인가?
- 현재 시스템과 미래 시스템의 사용자는 누구인가?
- 고객과 사용자는 미래 시스템을 위하여 무엇을 원하는가? 업무의 우선순위는?
- 품질, 성능, 보안의 고려할 점은?
위의 질문에 답을 얻기 위하여 다음과 같은 방법들을 동원합니다.
고객의 발표
고객의 발표는 요구사항 추출을 시작하는 좋은 방법입니다. 고객의 발표는 개발 팀에게 고객의 업무를 빨리 소개하고 의심되는 것을 명확히 할 수 있도록 질문을 할 수 있게 합니다. 발표를 하면 개발팀이 구축하는 시스템에 대하여 초기에 개념을 잡을 수 있습니다. 효과적인 가이드라인은 다음과 같습니다.
- 누가 발표하든 업무 및 고객과 사용자가 원하는 것을 100% 정확하지는 않지만 잘 알고 있어야 한다. 일상적 운영 책임자나 관리자가 발표하는 것이 제일 적당하다. 신입 사원은 이러한 발표에 적절하지 않다.
- 고객이나 대표 발표자에게 무엇을 다루어야 하는지 알게 한다. 부족하면 추가 정보를 얻을 수 있는 제3자를 요구한다.
- 발표하기 전에 개발 팀원이 필요한 정보가 들어 있는지 발표 자료를 검토한다.
- 발표하는 동안 의심이 가는 부분을 명확히 하기 위한 질문을 하고 구현과 관련된 토의는 배제한다.
- 발표의 목적은 업무와 고객이 시스템에 대하여 무엇을 원하는지 아는 것이다.
- 발표 내용의 복사본을 요청하고 팀원과 공유한다.
- 2시간 이상의 긴 발표회는 피한다.
문헌조사
비슷한 프로젝트를 조사하거나 업무 문서나 양식을 조사하면 현재의 업무 시스템 정보에 대하여 깊은 이해를 할 수 있습니다. 그 외에도 산업 및 기업 표 준, 관련 정부 정책, 규제 등의 문서를 조사한다. 또한 개발 팀은 도메인 영역의 교육이나 튜토리얼의 참여하여 이런 정보를 얻을 수 있다. 유사 프로젝트에 대한 정보는 현재 개발 중인 시스템에 대하여 아주 가치 있는 통찰을 제공합니다. 새로운 시스템의 설계와 구현은 유사 시스템의 설계와 구현에서 혜택을 얻을 수 있습니다.
업무 절차 및 양식 조사
업무관련 문서, 절차, 양식, 운영 매뉴얼 등은 매우 중요한 출처입니다. 이런 것들을 조사함으로써 업무 절차와 처리의 입출력을 더 잘 이해할 수 있습니다. 미래의 시스템은 업무 절차를 일부 또는 모두 자동화하는 것입니다. 따라서 개발 팀은 고객에게 관련된 모든 문서와 양식을 요청하여 자세히 연구하여야 합니다. 산업과 기업은 내부의 표준을 가지고 있습니다. 컴퓨터화 된 시스템은 이런 표준을 지원합니다. 이런 표준이 요구와 제한사항을 찾는 데 도움이 됩니다. 정부, 산업, 기업의 특수정책이나 규정이 해결책에 대하여 제한을 가하게 됩니다. 이런 제한점이 시스템의 요구 분석서의 제한 사항이 됩니다.
설문
설문은 관리자나 사용자와 같은 이해 당사자들로부터 요구를 찾아내기 위하여 사용되는 좋은 도구입니다. 여러 가지 장점이 있지만 무엇보다 이해 당사자들이 의사결정 과정에 포함된다는 것이 중요하다고 생각합니다. 무기명의 설문은 이해 당사자들이 관심과 내부정보, 개선의견을 나타내기에 좋습니다. 다른 방법으로는 감추어진 정보를 끌어내기가 어렵다고 봅니다. 이런 정보는 새로운 시스템을 위한 요구사항을 만드는 데 사용됩니다. 설문지를 사용할 때 유의하여야 할 사항은 다음과 같습니다.
- 질문은 간단하여야 하고 중요한 이슈에 집중하여야 한다.
- 가능하면 다른 이해 당사자 그룹에 대하여 다른 설문지를 준비한다. 고객을 대표하여 질문이 적절하고 잘 기술되었는지 확인하게 한다.
인터뷰
인터뷰는 고객, 사용자, 도메인 전문가로부터 요구에 관한 정보를 효과적으로 모을 수 있어 널리 사용하는 방법입니다. 인터뷰 기법은 미리 잘 계획해야 많은 정보를 얻을 수 있습니다. 인터뷰가 중요한 기술임에도 불구하고 소프트웨어 엔지니어들이 인터뷰를 수행하는 방법을 교육받는 일이 드뭅니다. 아래 소개한 가이드라인이 인터뷰의 중요한 단계를 효과적으로 수행하는데 도움이 될 것입니다.
먼저 가능하면 많은 관련 당사자들과 많은 소프트웨어 엔지니어링 팀원들이 인터뷰할 수 있도록 계획합니다. 관련자 이외의 사람들과의 인터뷰도 고려하고 경쟁 제품의 사용자, 마케팅 담당자, 다른 시스템을 사용하는 사용자와 도 대화를 나눕니다.
인터뷰 일정을 분산시키고 오래 걸리지 않을 것으로 예상되더라도 각 인터뷰마다 여유시간을 사용해야 합니다. 인터뷰 사이에는 들은 내용을 분석하고 정리하는 시간을 갖고 추가질문을 생각해 봅니다. 또한 인터뷰 대상자가 많은 정보를 제공하고 대화하여 약속시간을 넘기더라도 여유를 가지고 계속하도록 합니다. 가장 중요한 관련자에 대하여는 여러 번의 인터뷰를 계획하여 깊이 있게 다루도록 합니다. 이렇게 되면 중간 기간 동안에 지식과 분석이 향상됩니다.
계획한 인터뷰에서 질문에 대답할 충분한 시간이 없어 실망하더라도 충분한 분량의 질문을 준비합니다. 질문 리스트를 만드는 작업은 다음 포스팅에서 설명할 브레인스토밍 방법이 적합합니다. 잊지 말고 포함시켜야 할 질문 유형은 다음과 같습니다.
- 최대, 최소, 예외 규칙, 예상되는 변동 등 아주 자세한 사항까지 질문한다. 예를 들어 만일 어떤 기관의 문서결재 시스템을 개발할 때 개의 의사결정을 위한 과정이 있다고 하면 그것이 무엇인지, 이 숫자를 바꿀 수 있는지도 물어보아야 합니다. 사용자가 변동 가능성이 없다고 하더라도 설계 단계에서는 확장성을 고려하여야 한다. 신문, 잡지 등의 저널리스트가 육하원칙 중 다섯 가지 누가, 무엇을, 언제, 어디서, 왜를 묻는 것이 요구 추출을 위한 인터뷰에도 잘 적용될 수 있다.
- 관련자에게 시스템에 대한 미래의 비전을 질문한다. 이런 질문으로 획기적인 아이디어를 발견하게 될 수도 있고 시스템이 어떤 융통성을 가져야 하는지 제안될 수도 있다. 비전을 제시하는 아이디어는 사실 쉽게 구현될 수도 있지만 즉시 검토되어야 한다. 기술에 익숙하지 않은 사용자와 고객이 단지 현재의 작업과정을 자동화하는 것으로 생각하고 더 이상의 과도한 변화는 얻기 어려운 것으로 믿을 수도 있기 때문이다. 고객이나 사용자가 시스템에 대한 구체적인 아이디어를 제시한다면 또 다른 차선의 방법이 없는지, 개발 측이 가지고 있는 대안에 대한 생각은 어떤 지 질문한다. 이렇게 하면 시스템의 융통성을 검증할 수 있다.
- 문제에 대한 최소한의 허용 가능한 솔루션이 무엇인지 질문한다. 요구를 수집하면서 너무 많은 아이디어를 얻는 경우가 있다. 이럴 때 무엇보다 중요한 것은 고객과 사용자가 기본적으로 필요한 것이 무엇인지를 실감하는 것이다. 이런 정보 없이는 나중에 사용되지 않을 너무 많은 기능을 만들어 내게 된다.
- 다른 정보원이 없는지 물어본다. 보고 싶은 문서를 인터뷰한 관련자들이 소유하고 있을 수도 있고 유용한 지식을 가진 다른 사람을 알고 있을 수도 있다.
- 인터뷰 대상자에게 다이어그램을 작성하게 한다. 다이어그램을 그리면 정보의 흐름, 명령의 순서, 기술이 어떻게 작용하는지, 실제적인 것을 나타낼 수 있다. 다이어그램은 정보 수집을 더욱 촉진하는 초점이 될 수 있다.
인터뷰하는 사람은 무엇보다도 고객과 사용자를 공감하고 잘 듣는 훈련이 되어야 합니다. 공감한다는 것은 인터뷰 대상자의 마음에 가까이 다가가서 진정 그들이 느끼는 것을 같이 실감하는 것을 의미한다. 경청하는 기술은 인터뷰 대상자가 말하는 것을 참을성 있게 흡수하고 이를 자기말로 바꾸어 말해 주어 오해가 없는지 확인하는 것을 의미한다. 공감하면 훨씬 잘 경청할 수 있습니다. 왜냐하면 사용자가 말한 업무 또는 업무 정책에 대한 좌절감이 섞인 감정 적인 사실을 말할 수 있기 때문입니다. 인터뷰하는 사람은 대상자의 느낌을 이 해한다는 것을 보여줄 수 있어야 하며 동시에 그 들로부터 사실과 요구를 찾아 낼 수 있어야 합니다.
인터뷰하는 것이 혹 다른 사람을 위협하는 것이 될 수도 있습니다. 이럴 때 고객과 사용자는 화를 낼 수 있습니다. 두 당사자가 상당히 다른 지식 배경을 가지고 있기 때문에 의사소통에 심각한 문제가 생길 수도 있습니다. 이런 마찰을 피하기 위하여 대화의 수준을 명확히 할 필요가 있습니다. 만일 인터뷰 대상자가 이해할 수 없는 복잡한 것을 이야기하면 쉬운 것을 말해 달라고 요구합니다. 만일 이미 알고 있는 것을 설명한다면 이미 알고 있는 것을 정리하여 말하면 되풀이 할 필요가 없다는 것을 느낄 것입니다.
인터뷰의 초기 단계는 주로 정보를 수집하는데 사용되므로 분석이 이루어질 수 없습니다. 특히 사용자가 시스템에서 보기를 원하는 바로 그것을 불러주기 시작하였다고 해서 원하는 것을 그대로 인도받을 것이라는 인상을 주어서는 안 됩니다. 대신에 내준 아이디어가 중요하나 분석해 보고 다른 사람과 상의해 볼 것을 짚어 둡니다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)
인터뷰 절차를 따라 다음단계는 발견한 정보를 요약하고 이를 관련자들과 함께 나누면서 의견을 묻는 것입니다. 이렇게 하는 것이 관련자를 자극하여 더 많은 아이디어를 발굴하는데 도움이 될 것 입니다.