요구사항 추출
요구 사항 추출(requirement elicitation)은 소프트웨어 개발에서 특별히 중요한 작업이다. 사용자가 무엇을 원하는지 결정을 내리는 작업이며 여러가지 기법이 동원됩니다. 현재 사용되는 수동 작업 시스템이 있다면 요구를 추출하는 작업은 비교적 수월합니다. 하지만 아직 존재하지 않아 문제에 대한 해법을 생각해 보지도 않은 경우 사용자와 함께 아이디어와 해결책을 찾는 것이 어려울 수 있습니다.
요구 사항을 추출하기 위하여 다음 세 가지 단계의 작업이 필요하다.
- Step 1. 응용에 대한 정보 출처 파악
- Step 2. 응용에 대한 정보 취합
- Step 3. 요구와 제한 사항의 정의
요구 추출은 응용 분야에 대한 정보를 모으는 일부터 시작된다. 많은 조각 정보들이 응용문제를 이해하고 요구와 제한 사항을 추출하는 데 도움이 된다. 비즈니스 목표, 현재 업무의 상황, 정책, 법령과 표준 등이 여기에 포함된다. 취합된 정보는 분석 과정을 통하여 우선순위가 정해지며 요구와 제한으로 정리된다.
요구 사항 추출은 우선 사용자에게 누가 시스템과 관련되어 있는지 또한 시스템의 범위가 어디까지 인지 물어보고 정보 출처를 결정하는 것으로 시작됩니다. 또한 어떤 데이터가 어디서 어디로 전달되며 어떤 과정을 거쳐 변경되는지 알아내야 합니다. 요구 사항 추출 작업은 사용자가 진정 무엇을 원하는지 알아보기 위하여 같은 질문을 여러가지 다른 형태로 물어보게 됩니다.
요구 추출을 위한 정보를 모으는 방법은 여러 가지가 있습니다. 고객의 발표를 듣는 방법부터 문헌을 조사하는 방법, 업무 절차와 양식을 조사하는 방법, 관련자들의 설문지, 사용자와의 인터뷰, 브레인스토밍 회의, 사용 스토리 또는 사용 사례를 작성해 보는 방법이 있습니다.
시스템의 요구란 주로 시스템과 관련된 객체와 상태, 수행하여야 할 기능과 성능을 찾아내는 것입니다. 예를 들면 회사의 급여 시스템을 구축한다고 합시다. 매달 급여명세서를 발급하는 일이 중요한 요구이고 온라인으로 급여를 지급하는 것이 하나의 제한 사항이 될 것입니다. 또한 사원들은 장소를 가리지 않고 회사에서나 집에서도 급여를 확인할 수 있어야 합니다. 이러한 요구들은 개발될 시스템의 기능이나 성능을 구체적으로 나타낸 것입니다. 시스템의 객체(회사를 위하여 일하고 월급을 지급받는 사원), 성격(40시간 이상 일하는 정규직), 관계(사원 A가 B의 업무를 관리할 책임이 있다면 A는 B의 상사) 등을 찾아내야 합니다.
요구 사항은 우선순위에 따라 다음 세 가지로 구별하면 좋다.
- 절대적으로 필요한 요구
- 요망되나 꼭 필요한 것은 아닌 요구
- 요구로 판단될 수 있으나 제외될 수도 있는 요구
예를 들면 신용카드 대금청구서 발급 시스템에서 거래 내용을 나열하는 기능과 사용 총 금액 계산하는 기능, 납부기일까지 대금을 청구하는 기능은 1번 요구에 속합니다. 카드 사용자의 이해를 돕기 위하여 일시불이나 할부 등 구매 형태를 분리 표시하는 기능은 2번 요구에 해당될 것입니다. 카드 사용으로 인한 신용거래를 붉은색으로 표시하고 취소로 인한 추심권을 푸른색으로 표시하려 한다면 이는 3번 요구에 해당한다.
이와 같이 카테고리에 의하여 요구를 분리하면 어떤 것이 사용자가 진정으로 요구하는 것인지 이해하는데 도움이 될 것입니다. 또한 소프트웨어 개발 프로젝트의 기간과 비용이 제한되어 더 이상 계속될 수 없다면 카테고리 3에 해당하는 요구는 버리고 카테고리 2에 해당하는 요구를 선별하여 구현하거나 연기할 수가 있습니다.
요구 정보 출처
요구 추출 작업은 미래의 시스템에 대한 역량을 결정하는 과정입니다. 의사 결정 작업은 정보의 분석이 필요합니다. 따라서 먼저 정보를 모으는 작업이 필요한데 그 정보를 어디서 찾을 수 있는지 알아야 합니다.
시스템 이해 당사자의 (stakeholder), 도메인 전문가, 사용자 거의 동일한 용어로 여길 수 있습니다. 하지만 소프트웨어 제품, 특징, 요구에 대하여 결정할 때 역할이 달라 구별되어야 합니다.
고객의 프로젝트를 유치시키고 재정적으로 지원하며 운명을 결정하는 당사자를 말합니다. 소수이지만 프로젝트의 재정적인 지원을 맡고 중요한 의사 결정으로 하므로 프로젝트에 상당한 영향력을 행사하는 역할입니다. 프로젝트에 대한 기대와 관심이 다른 그룹이 여럿 있다면 고객이 자원과 시간의 낭비를 막기 위하여 문제를 해결하여야 합니다.
도메인 전문가 비즈니스 도메인은 기업의 작은 업무 영역이라 할 수 있습니다. 비즈니스 도메인을 지원하는 시스템을 구축하기 위하여 도메인 전문가가 필요합니다. 예를 들면 회계 시스템을 구축하기 위하여 회계사가 필요 하고 ATM 시스템을 구축하기 위하여 은행 전문가가 필요한 것처럼 입니다.
이해 당사자 이해 당사자(stakeholder)는 시스템 운용으로 인하여 영향을 받는 사람들입니다. 이해 당사자는 시스템의 사용자가 될 수도 있고 안될 수도 있다. 따라서 이해 당사자의 주된 관심은 사용자 인터페이스가 아니라 시스템이 비즈니스 목표, 규칙 등에 부합하는지 보는 것이다. 예를 들어 창고 운영을 위한 시스템은 여러 가지 비즈니스 영역에 걸쳐 있다. 재고를 관리하는 일, 재고를 채우는 주문, 창고와 관련된 판매, 재정적으로 관련되기 때문에 회계 등이 밀접하다. 이 중에 상품을 관리, 주문, 결재, 판매하는 직원이 시스템에 가장 관심이 많을 것이다. 반면 창고의 상품 위치를 이동시키는 직원은 관심이 적을 것이며 윈도 장식하는 직원은 이 시스템에 거의 관심이 없다.
사용자 시스템을 직접 사용하는 사람들이다. 이해 당사자는 꼭 시스템을 사용하지 않을 수 있다. 사용자는 주 사용자와 단순 운영자로 나눌 수 있다. 주 사용자는 업무 프로세스에 참여하여 무엇을 하는지 뿐만 아니라 왜 하여야 하는지도 아는 지식을 가지고 있고 단순 운영자는 주 사용자를 보조하고 반복 업무만 수행할 수 있다.
역 공학 레거시 시스템이나 현재 문서는 요구와 업무 규칙에 대한 풍부한 출처가 될 수 있다. 따라서 철저히 조사하고 분석하여야 한다. 일정한 기간 사업을 하였던 기업은 소프트웨어, 문서, 절차, 규정, 매뉴얼 등 이 많이 축적되어 있다. 대부분의 경우 시간과 자원을 절약하기 위하여 이런 애플리케이션이나 문서, 규정 등을 파헤친다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)