요구사항 정의

요구사항 정의
  : 컨설팅 ~ 설계 단계

 

요구사항은 프로젝트 발주시 고객사에서 원하는 것들needs을 말한다.
다른 의미로, "프로젝트 수행 목적"이 아닐까 한다.
이런 고객사의 요구사항을 정리한 것이 요구사항 정의서(산출물)이다.

요구사항 정의서는 
  1. 프로젝트 제안시 제안한 내용과
  2. 컨설팅 단계에서 정의한 내용과
  3. 설계 단계까지 진행하며, 추가적으로 요청/수용한 기능들을 정리한 산출물이다.

제안 및 컨설팅 단계까지는 거시적인 관점에서의 요구사항을 정의했다면
설계 단계에서는 요구사항의 구현 가능 여부를 검토하고 구체화하는 작업을 진행한다.
이렇게 정의하고 확정된 요구사항은 프로젝트 종료시까지 관리된다.

끝날때까지 끝난게 아니다.

요구사항을 정리하다보면, 내용이 구체화 될수록 점점 더 기능이 늘어난다.
어느정도 정리가 되면, 추가적인 기능과 편의성이 눈에 보이기 때문이다.
때로는 문제점을 발견하고, 요구사항의 기준 자체가 바뀌는 경우도 종종있다.
이러다보니 실제 통합테스트까지 요구사항이 추가/변경되는 경우가 (꽤 자주 많이) 발생한다.
농담반 진담반으로 오픈 전날까지 변경될 수 있다고...

요구사항은 명확하게!
중요한 내용이나 의견이 많을수록 회의록은 필수!

말로는 쉽게 할 수 있지만, 개발하기는 까다로운 것들이 있다.
말로 할 때는 한마디로 표현가능한데
개발을 하려고하면, 유관 업무 협의부터 시작해서 모델링부터.. 공수가 어마어마한 것들도 있다.
또한 (사람에 따라 관점에 따라 달라질 수 있기 때문에) 완벽한 개발이란 존재하기 힘들다.
이렇다보니 요구사항 발의자의 요청needs를 명확히 판단하고 기능을 정의해야 한다.
잘 개발하고도 의도에 맞지 않아 재개발의 해야 하는 경우가 발생할 수 있기 때문이다.

또한, 여러 의견들을 논의한 과정에서 결정된 사항이나
개발할 수 없는 (환경적, 기술적) 요구사항을 변경 및 축소하여
최초 발의자의 생각과 바뀌게 된 요구사항은 반드시 회의록을 통해 기록하고 공유되어야 한다.
일정 시간이 흐른 후 다시 생각이 바뀔 수 있고, 원안의 요구사항이 다시 언급되어 이슈가 될 때가 있다.
이 때 회의록을 남겨두면, 논의된 과정을 이해할 수 있고, 최종 협의된 결과를 알 수 있기 때문이다.
실제 "기억이 없다. 그렇게 얘기하지 않았다" 등의 말로 난감한 상황들이 자주 발생한다.

협상과 조율

흔히 "IT가 안되는게 뭐 있어?" 라는 말을 하곤 한다.
대부분의 요구사항은 어떤식으로든 구현이 가능하다.
단, 정해진 시간에 원하는 퀄리티가 나올수 있을지가 관건이다.
프로젝트란 한정된 자원(시간, 인력)으로 진행하기 때문에 공수를 생각하지 않을 수 없다.
요구사항의 중요도와 공수에 따라 신중히 검토해야 한다.

고객은 무조건 되어야 한다고 요구하지만, 수행사 입장에서는 공수를 생각하지 않을 수 없다.
이런 입장차이가 때론 좁혀지지 않아 이슈가 되기도 한다.
이를 잘 조율하고 협상하여, 서로 윈-윈 할 수 있는 방안을 찾는것이 중요하다.
하지만, 현실적으로 쉽지 않은 일들이다.
특정 요구사항들은 거절해야 하고, 거절해도 되는 내용이지만
현실인 여러가지 요인으로 인해 어쩔수없이 해야하는 경우가 많다.

이슈가 될만한 요구사항일수록
선제적으로 대응해서 추후 문제가 되지 않도록 해야 할 필요가 있다.
이를 잘 조율하는 것 또한 업무의 능력이라 하겠다.

무조건

이렇게 정의된 요구사항들은 프로젝트 기간내에 반드시 수행되어야 한다.
정의시, "나중..."은 없다.
나중에...라는 안일한 생각으로 진행하면, 추후 문제가 될 수 있고
이러한 문제들이 모이면 프로젝트 실패의 큰 원인이 된다.

 

첫 단추를 잘 끼워야 나머지 단추들도 문제가 없다.
가장 먼저 하는 첫번째 작업Task이고, 프로젝트의 목표를 정하는 일이므로
무엇보다 신중히 진행하여야 하겠다.

 

참조 링크

☞ 프로젝트 단계

 

The End.