심기보 숭실대학교 정보과학대학원 교수


▲ 심기보 숭실대학교 정보과학대학원 교수



제1회 요구정의를 성공으로 이끄는 필수 스킬


제1회 요구정의를 성공으로 이끄는 필수 스킬

소프트웨어 개발 프로젝트에서 요건정의를 실패하면 설계 이후 공정에서 재작업이 발생하여 예정된 납기나 비용을 지킬 수 없게 된다. 실제로 요건정의의 실패로 문제가 된 프로젝트가 적지 않다. 최근에도 요건정의 실패로 인한 새로운 문제가 발생하고 있다. 요건정의 자체로 끝나지 않는다는 문제이다. 기업의 사업전략과 밀접하게 관련된 프로젝트가 증가하고 요건정의의 복잡화로 늘어나는 문제이다.
실제로 개발한 소프트웨어의 활용 수준은 20%에 불과 하다는 통계도 있다. 실로 엄청난 낭비를 초래하고 있다. 그렇다면 어떻게 하면 요건정의를 성공시킬 수 있을까? 중요한 것은 요건정의의 순서와 성과물(이하, 추진방법)을 이해하고 거기에 필요한 지식이나 스킬을 이해, 습득하는 것이 중요하다.
대다수 시스템에서는 설계 이후의 공정에 대해 구체적인 수준에서 추진방법을 표준화하고 있다. 그러나 요건정의에 대해서는 추진방법을 표준화하지 않거나, 대략적인 수준에서의 표준화에 머물러 있다. 동일 부서에 소속된 소프트웨어 엔지니어도 추진방법에 대한 인식이 달라 요건정의를 제대로 진행하지 못하는 경우도 있다.
요건정의의 추진방법을 이해한다 해도 이를 실천하려면 설계 이후의 공정과는 다른 다양한 지식이나 스킬이 필요하다.
업종이나 업무의 지식, 업무를 분석, 설계하는 스킬, 경영층이나 이용부문의 고도의 커뮤니케이션 스킬이다. 이러한 지식이나 스킬을 이해하고, 습득하지 않는다면 요건정의는 잘 진행될 수 없다.
정부(지식경제부)는 지난 5월 소프트웨어진흥법을 개정, 발주자의 명확한 제안요청서 작성을 위한 기준과 책임소재를 명백히 하기 위한 계약기준 마련 및 요구사항 명확화 등의 법적 근거를 신설(제20조) 하여 2013년 1월 1일부터 시행할 예정으로 있다. 우리나라의 소프트웨어 사업 환경의 변화에 대비하고 글로벌 수준의 소프트웨어 개발, 유지보수에 따른 수발주자 간의 관행과 문화를 선진화할 수 풍토 조성이 시급한 실정이다. 이에 따른 관련 전문가 양성에 기여하고자 소프트웨어 프로젝트 성공의 키 '요구정의'에 대해 이달부터 6회에 걸려 연재한다.


요구정의를 성공으로 이끄는 4개의 필수 스킬

방법론, 히어링 기법의 기본을 마스터하여 실천한다.

유저 기업은 요구를 결정하지 않고 또한 자꾸자꾸 변한다. 이와 같은 상황에서 벗어나려면 어떻게 하면 좋은가. 결론을 말하면 '은의 탄환'은 존재하지 않는다. 해야 할 일을 착실하게 실천하는 것이 최선이다. 그렇지만 요구정의를 실시하는 '자격'이 있는 IT 엔지니어는 결코 많지 않다, 클
래스도를 읽고 쓰는 것도 할 수 없는 사람은 오브젝트 지향 개발에 종사하지 말아야 하는 것처럼 요구정의를 할 때에도 '자격'이있다.

예를 들면 유저 기업의 업종·업무 지식에 깊이 통찰하고 있어야 하는 것이 그 중 하나이다. 업종₩업무의 전문 용어를 잘 알고 타사 사례나 전형적인 업무 플로우를 알고 있다. 또한 객관적인 근거를 바탕으로 업무의 개선안이나 시스템의 기능을 제안할 수 있다. 이 정도로 할 수 있는 엔지니어는 적다. 반대로 말하면 제대로 요구정의한다는 것은 그만큼 어렵다. 요구정의는 결코 보고 흉내 내는 가운데 저절로 터득할 수 있는 것은 아니다.

어려움을 증가시키는 요구정의

요구정의에 관한 문제는 뿌리가 깊다. 유저로부터 애매한 요구만 나오거나 요구가 나중에 자꾸 바뀌거나 하는 경우가 적지 않다. 근거가 되어야 할 방법론은 불완전하다. 방법론이 없는 기업이나 조직도 있다. 이런 상황에 직면하면 '요구정의를 잘 하는 건 무리'라고 단념해 버릴지도 모른다. 최근에는 요구정의의 어려움이 더욱 더 늘어나고 있다.



▲ <그림 1> 요구정의의 어려움이 증가하고 있는 배경





<그림 1>그 요인의 하나가 IT와 경영전략의 융합도가 높아지고 있기 때문이다. 유저 기업의 경영전략이나 사업 방침은 상황에 따라 변한다. 필연적으로 요구도 변한다. 업무의 효율화가 시스템의 주목적이었던 예전과는 요구정의의 어려움은 비교가 안 된다.

게다가 ERP나 SCM, EIP 등 부서 횡단 또는 전사에서 이용하는 시스템의 개발 안건이 증가하고 있다. 각 부서의 사정이 있으므로 시스템의 요구를 결정하기가 꽤 어려워지고 있다. ① 오브젝트 지향 개발이나 프레임워크, 소프트웨어의 부품화 등의 새로운 개발 기법의 등장에 따라 종래의 워터폴 형을 전제로 한 방법론을 적용하기 어려워졌다, ② 시스템 관련 업무의 아웃소싱이 진행되어 유저 기업내에 IT와 업무에 정통한 사람이 감소함으로써 엔지니어와 유저 사이의 커뮤니케이션·갭이 생기기 쉬워졌다, ③ 웹
시스템 등 단납기·저비용의 프로젝트가 증가함으로써 요구정의에 충분한 시간을 할애할 수 없게 되었다 등, 요구정의의 어려움을 증대시키는 요인은 많다.



<이하 상세 내용은 컴퓨터월드 9월 호 참조>

저작권자 © 아이티데일리 무단전재 및 재배포 금지