[요구사항 공학] 요구사항 분석하기 (3) - 보다 나은 요구사항의 비즈니스 가치

보다 나은 요구사항의 비즈니스 가치

잘만들어진 요구사항은 어떤 가치를 가질까?

 

모든 관리자들이 요구사항 개발이 요구사항 개발이나 관리에 대한 개선의 필요성을 인정하고 있지는 않다. Standish 그룹의 "CHAOS Reports"에서 지적하고 있는 프로젝트를 망치거나 힘들게 하는 세 가지 가장 큰 요인은 다음과 같다.

• 사용자 제공 정보의 부족
• 불완전한 요구사항 및 명세서
• 변화하는 요구사항 및 명세서

e-비즈니스에서의 성공 위협 요소

• 불안정하고 계속해서 변화하는 요구사항 ( 66% )
• 미숙한 요구사항 명세 (55% )
• 승인 지연, 요구사항 변경, 부족한 의사소통 등과 같은 고객의 행위(42%)

          [표] 요구사항 결함의 상대적인 수정 비용

오류 발견 시점	상대적인 수정 비용 (배수)
요구사항 개발	1
실계	2 - 3
구현	5- 10
시스템/수락 시험	8 - 20
운용	68 - 110

보다 나은 요구사항의 효과

- 회사에서 진행할 여러가지 프로젝트 중에서 우선적으로 수행할 수 있도록 결정하는 자료가된다.

- 프로젝트를 수행함에 있어서 필요한 자원이 노력의 정도를 가늠할 수 있다.

- 시간에 쫒기는 프로젝트에서 구현해야 할 기능에 대한 우선 순위를 결정할 수 있다.

- 제품 설계에 기초가 된다.

- 시스템 테스트의 기준이 된다.

 

• 15개의 뱅킹 및 통신 프로젝트에 관한 연구 결과 이 중 가장 성공적인 프로젝트의 경우 요구사항 공학에 28%에 달하는 프로젝트 자원을 할당한 반면 평균치는 15.7%에 머물고 있다. (Hofmann과 Lehner 2001)
• NASA 프로젝트에서는 요구사항 개발에 대한 예산 비율을 높임으로써 비용과 일정 모든 면에서 초과나 지연이 줄어들었다.(Hooks와 Farry 2001)

좋은 요구사항은 몇가지 측면에서 개발을 가속화 할 수 있다. 제품 결과물을 정의함으로써 관계자들은 공동의 비전, 목표 및 기대를 공유할 수 있다. 문제점은 일찍 발견하고 고칠수록 수정 비용이 적게 든다.

 

요구사항을 얻는데 소요되는 기간

시스템의 요구사항을 얻은데 얼마의 시간이 소요될까?

여러 사람이 이에 대해 벤치 마킹을 해서 자료를 냈으나, 근거 요소가 너무 부족하여 자료로 활용하지는 않는것이 좋겠다. 다만 아래에 프로젝트 진행요소에서 기간이 단축되는 경우와 기간이 연장되는 경우를 알아보자.

여러 프로젝트를 진행하다 보면 "뭔가 잘못됐는데, 이러면 안되는데..." 고개를 갸우뚱 거릴 때가 있다.

이러한 느낌은 나만 느끼는것이 아니라, 프로젝트에 관계된 모든 사람이 느끼는 것으로 향후 프로젝트는 실패할 확률이 굉장히 커진다. 이때 누군가 이러한 요소를 해결해 준다면 프로젝트는 조기에 정상으로 회복되고 기간도 줄어들 것이다.

 

"기간 단축"

• 고도로 훈련되고 숙달된 분석가
• 적합한 사용자 대표에 의한 광범위한 고객 참여
• 과거 프로젝트 자원의 재활용
• 재빨리 질의에 응답해 주는 고객 대표자
• 명확하고 안정된 비전과 범위
• 응용프로그램 영역에 숙달된 개발자
• 구식 응용프로그램 교체
• 불명확함과 실수를 제거하기 위한 효과적은 점증 동료 검토

"기간 연장"

• 생소한 프로젝트 또는 응용프로그램 영역
• 이해 당사자들과의 지리적인 분리
• 프로젝트 참여자들 간의 언어 장벽
• 형편없는 의사 결정 프로세스
• 대규모 프로젝트
• 많거나 다양한 사용자 계층
• 소프트웨어 개발과 비지니스 프로세스 수정의 병행
• 외부 의존 요소 및 불확실성
• 하드웨어와 소프트웨어 컴포넌트 사이의 복잡한 상호작용
• 요구사항 개발 프로세스의 부재

요즘은 폭포수모델을 이용해서 개발하기 보다는 점증적 방법을 많이 사용한다.

점증적 방법은 개발 기간동안 계속해서 욕구사항 개발이 포함된다.

 

 

요구사항 유도 계획하기

요구사항 개발 역시 보이는 것 이상으로 많은 것이  내재해 있다. 분석가가 수해하여야 할 업무를 식별하고 있다면 다음에 나열된 활동들이 필요한지에 대해 고려해보자.

• 제품 챔피언(각 업무의 대표자)들과 책임에 대해 협상
• 요구사항 유도 워크숍을 개최하고 검토 작업 진행
• 기존 문서와 제품 검토
• 설문 조사의 준비, 배포, 분석 작업
• 프로토타입, 분석 모델, 기타 요구사항 조사 작업 생성과 평가
• 가능성, 위험도, 안정성, 실패 및 위해 요소에 대한 분석 수행
• 요구사항 정보의 데이터 베이스 입력작업
• 요구사항 명세 검토
• 요구사항으로부터 테스트 케이스 생성 및 테스트 케이스 검증
• 검토나 테스트 분석에 따른 요구사항 명세 수정 보완

여러분의 팀에서는 프로젝트에 대해 요구사항 유도, 분석, 명세 및 검증 작업의 일환으로 위의 모든 활동을 수행하지 않을 수도 있고, 다른 작업을 수행해야 할 수도 있다. 분석가의 실제 업무에 대한 사항들과 이 업무들의 수행 시기에 대한 지식은 앞으로 수행하게 될 프로젝트에서 요구사항 개발 노력을 평가할 수 있는 능력을 향상시켜 줄 것이다.

 

고객들은 프로젝트 발주와 동시에 결과를 보려고 안달한다. 과연 이들과 함께 요구사항을 도출하는 길고 어려운 과정을 지날 수 있는 좋은 방법은 무엇일까?