요구사항 정의 지침 6가지

모든 문제는 대개 기본을 지키지 못함으로써 발생한다. IT 프로젝트를 진행하면서 다음과 같은 지침을 명확하게 지킬 수만 있다면, 프로젝트는 충분히 통제가능하고 또한 좋은 성과를 이루어낼 수 있을 것이다. “이렇게까지 해야 하느냐?”는 낙관론과 “그것은 불가능한 것이다!”는 비관론을 경계한다. 중요한 것은 기본을 이해하고 그것을 어떻게 수행할 지에 대해 고민하고 실천하는 것이다. 다음의 지침은 J. 데이빗슨 프레임 의 견해를 바탕으로 IT적 관점을 접목시키고 부연 설명한 것이다.

​

지침 1. 요구사항을 명확히 문서화하고 프로젝트팀과 고객이 이에 서명한다. 옛 격언에 이런 말이 있다. “너와 나는 똑같은 책을 밤새워 읽었다. 그러나 내가 백 (Ⲩ)이라고 본 것은 너는 흑(䗡)이라고 보았다.”사회 생활을 해본 사람이라면 열이면 열 사람 모두 생각이 다르다는 것을 가슴 절절히 느껴본 적이 있을 것이다. 그리고 그런 문제는 사물을 바라보는 관점에 차이가 있거나 이해 관계가 상충되는 경우 극대화 된다. 그것을 방지하는 것은 서로의 코드를 최대한 일치시키는 방법뿐이다.

​

지침 2. 현실성 있는 요구사항을 정의하도록 한다. 욕구는 환경에 따라 계속 변화할 수 있다는 것을 기억하자. 너무 이상적이거나 엄격하게 요구사항을 정의하지 않도록 하자.

​

지침 3. 가능한 한 그림, 모형, 도해, 그리고 다른 비언어적 방법을 총동원하여 요구사항의 형태를 나타내라. 언어의 한계에 대해서는 익히 말하지 않아도 우리 모두 알고 있다. 한 언어심리 학자는 인간이 얘기하는 말의 90%는 모두 무의미하며, 본인 스스로도 말하면서 잊어버린다고 했다. 그리고 글로 되어 있는 내용은 그림, 도해 등에 비해 눈에 잘 들어오지 않으며 이해하기도 어려운 경우가 많다. 생각해 보라. 그 누가 글로만 잔뜩 작성되어 있는 수백여 페이지의 기획, 설계 문서를 꼼꼼하게 읽겠는가? 이미 업계에서 사용하고 있는 UML의 유스케이스나 ERD 작성은 기본이고, 고객과 프로젝트 팀을 이해시킬 수 있는 모든 수단을 강구하도록 하자.

​

지침 4. 요구사항이 잘못 해석될 가능성이 있다면 반드시 잘못 해석될 것이라고 가정 해라. 중요한 프로젝트라면 독립적인 전문가를 고용하여 정의된 요구사항을 검토시킴으로써 잘못 해석될 수 있는 여지를 사전에 봉쇄하는 것이 좋다. 사실 사전에 철저하게 예방하고 준비하는 것은, 현재 우리의 문화적 풍토에 잘 맞지 않는 부분이 있는 것은 사 실이다. 하지만 프로젝트 관리를 성공적으로 완료하기 위해서는 잘못될 가능성이 있는 것들을 사전에 인지하고, 그것의 정량적/정성적 분석을 통하여 철저한 대비책을 마련해 놓은 것이 필수적이라는 사실을 명심하자. 성공적인 프로젝트 관리를 위해서는 체계적인 교육과 함께 우리의 마인드도 바뀌어야 한다.

​

지침 5. 요구사항에 가해진 어떠한 변화라도 모니터링할 수 있는 시스템을 만들어라. 건축업을 하는 회사들은 이미 예전부터 프로젝트에 가한 변경을 꼼꼼히 기록해두지 않으면 파산한다는 것을 깨닫고 이를 추적할 수 있는 시스템을 사용하고 있다. 하지만 수백 억대의 IT 프로젝트를 진행하는 대기업조차도 그렇게 하지 않고 있다는 사실이 우리를 경악하게 한다. 물론 그러한 시스템이 전혀 없는 것은 아니지만, 그것은 실효성의 문제이다. 프로젝트는 그 자체로 하나의 시스템이기 때문에 관련 요소들이 유기적으로 미묘하게 연관되어 있다. 그러므로 프로젝트에 가해지는 단편적인 변경일지라 도 그것 하나만으로 끝나는 것이 아니라 도미노처럼 연쇄 작용을 일으킬 수 있다는 것을 기억하자. 또 하나의 문제는 변경은 비용을 증대시킨다는 점이다. 사실 이 부분에 대해서만 살펴본다고 하더라도 족히 책 한 권은 나올 것이다.

​

지침 6. 프로젝트 팀과 고객에게 요구사항 규정에 관한 문제를 교육시켜라. 프로젝트 경험이 없는 사람들과 프로젝트를 함께 진행하는 것은 프로젝트의 커다란 위험 요소 중 하나이다. 경험 없는 프로젝트 팀원과 자신의 요구사항에 대해서만 생 각하는 단순한 고객이야말로 프로젝트 매니저가 관리하고 교육시켜야 할 대상인 것 이다. 그러한 순진함, 무지, 단순함에서 비롯된 요구사항 변경이 프로젝트에 가져올 재앙과 해악의 가능성은 정말 놀라운 것이다. 그들에게 요구사항 변경이 프로젝트에 미칠 수 있는 심각한 문제들에 대해 교육해야 하며 동의를 이끌어내야 한다. 이것은 프로젝트 초기에 이루어져야 하며 초기에 교육하지 않고 나중에 실제 문제 발생시 이러한 사실을 언급하게 되면 당신이 책임을 회피하기 위해 발뺌하는 것이라는 오해를 받을 수도 있을 것이다. 모든 것이 술술 잘 풀릴 때에는 사람들과 함께 행복한 프로젝 트를 영위할 수도 있지만, 문제가 생기기 시작하면 사람들은 해당 문제의 책임 소재를 따지기 시작한다. 그리고 모든 프로젝트에서는 수백 수천 가지의 문제가 반드시 발생한다.

 

https://multicore-it.com/52