요구사항 조사

중요한 시작점이 요구사항 조사다. 고객이 원하는 시스템이 어떤 것인지 잘 듣고 정리해야 한다. 그래서, 불가능한 요구가 있다면 어째서 불가능한지 설명을 해야 하고, 서로 상충되어 도저히 만족할 수 없는 요구사항이 있다면 하나를 포기하도록 설득해야 한다. 이를 위해서 설득의 기술이 많이 필요하다. 참고로 가장 잘 먹히는 설득방법은, '대부분 프로젝트에서는 이렇게 합니다' 또는 '지난 프로젝트에서 이렇게 해서 지금까지 잘 운영되고 있습니다'이다. 결국 열심히 공부하고 사례를 찾아 보고 경험을 쌓는 것이 최선이다.

대개 고객은 IT에 대한 전문가가 아니고 일반적인 시스템 사용자의 관점에서 이야기한다. 이런 추상적인 요구사항을 IT적으로 구체화하는 과정이 요구사항 조사다. 고객의 요구사항을 머릿속에서 잘 소화시켜서 고객이 이해할 수 있는 쉬운 IT언어로 제공해야 한다. 이 과정에서 고객의 정리되지 않고 복잡한 요구사항을 잘 정리해서 IT적으로 단순하고 쉽게 구현할 수 있도록 설계하고 설득한다면 개발에 필요한 공수도 줄어들게 된다.

살아오면서 느낀 가장 일을 잘 하는 사람은 기술적으로 뛰어나서 뭐든지 다 만들어내는 사람은 아니었다. 이런 사람은 두번째로 일 잘 하는 사람이다. 첫번째로 일 잘 하는 사람은 요구사항을 듣고 필요없는 일은 설득해서 없애고 복잡한 요구사항은 단순하게 만드는 사람이다. 즉, 일을 쉽게 하는 사람은 할 일을 줄이고 시작한다. 

 

요구사항의 종류

기능 요구사항
만들려고 하는 시스템이 어떤 기능을 제공해야 하는지 고객으로부터 듣는 과정이다. 요구사항을 잘 정리해서 구현이 가능한 것인지 확인해야 하고, 중복되는 기능이 있다면 한쪽은 빼서 잘 정리해야 한다. 구현이 가능한지 잘 모르는 기능은 확인해 보고 말씀드리겠다고 하고 확인 후에 답변을 하면 된다. 잘 모르면서 무조건 가능하다고 해 놓고 나중에 안 된다고 하면 처음부터 신뢰를 잃게 되고, 안 되는 걸 부하직원에게 하라고 떠넘기면 아주 나쁜 상사가 되는 것이다.

성능 요구사항
시스템이 어느 정도의 성능을 요구하는지 정리하는 과정이다. 성능은 시간당 어느 정도의 데이터나 요청을 처리할 수 있는지와 데이터나 요청을 한 건을 얼마의 시간 안에 처리해야 하는지 결정하는 단계이다. 이런 요구사항은 프로젝트 종료시에 검수의 기준이 될 수도 있으므로 아주 신중하게 정해야 한다. 시간당 처리용량은 보통 프로젝트 계획단계에서 미리 정해서 하드웨어 용량산정할 때 정해지는 경우가 많기 때문에 확인만 하는 정도면 된다. 그러므로, SWA는 한 건에 대한 처리속도나 응답속도 정도만을 정한다.

 

요구사항 정리 방법

보통은 요구사항 추적매트릭스라는 문서에 작성한다. 여기에 정리된 요구사항을 작성하고 담당자를 지정하고 완료예정일을 작성한 후에, 구현이 완료되면 완료일을 적고 완료 표시를 한다.
그 외에 회의록도 잘 작성해 두는 것이 좋다. 나중에 요구사항에 관한 분란이 생겼을 때에는 요구사항 추적매트릭스 외에 원본인 회의록까지 확인해야 할 수도 있다. 초기에 사이가 좋아서 서로 믿으면서 하겠다고 생략하다가는 프로젝트 종료시에 이런 문제 때문에 검수가 되지 않아 페널티를 물게 될 수도 있다. 회의록 작성을 못 하게 하는 고객은 없으니 항상 작성하고 회의 후엔 공유하는 습관을 들이는 것이 좋다.

 

1. 소프트웨어 아키텍트란?

2. 요구사항 조사

3. 소프트웨어 아키텍처 설계

4. 개발 프레임워크 설계

5. 로컬 개발환경 구성

6. 개발프레임워크 준비

7. 개발가이드 작성 및 개발자 교육

8. 개발단계에서의 개발자 지원

9. 오픈 준비, 오픈, 안정화