예전에 모 과제의 품질 관리 용역 프로젝트를 하다가 청천벽력같은 상황이 발생하였다. NIPA공학센터 에서 점검 및 컨설팅을 주기적으로 나오기로 했다는 것이다.

졸지에 내 일이 많아져 버렸다고 느꼈고 그 슬픔 예감은 틀린 적이 없게 되어 버렸다. 일단 원하는것은 「요구사항의 추적성 확보」

프로젝트 내부에서 여러가지 이야기가 많이 나왔다. 결국 중론은 그냥 점검위원들이 해 달라는 대로 해 주자고 방향이 정해졌고, 요구 사항 추적 매트릭스 및 대응표를 만들고 이를 관리하기 시작하였다.

그런데 문제는 개발 산출물과 요구사항 추적과의 연결이었다. 정리를 하다보니 요구사항 : 클래스 가 多대多의 관계로 되어 버리다 보니 정리에 혼선이 오는 것이었다.

어떻게 이는 마무리가 되었지만, 결국 100% 내가 원하는 방향으로 되지는 못하였다. 내가 하는 일은 어떻게든 점검위원들의 요구사항에 맞추면서 산출물을 효율적으로 줄일 수 있는 방법을 찾는 게 되어 버렸다. 프로젝트에서 가장 최악 이라는 “감사 대응팀” 의 역할을 맡게 된 것이다.

우여곡절 끝에 프로젝트는 NIPA공학센터에서 “우수 품질과제” 로 소개되는 성과를 거두며 끝이 났지만, 마음 속으로는 “이게 아닌데..” 라는 생각이 떨어지지 않았다. 그 이유는 다음과 같았다.

  1. 요구사항의 추후 발생율은 90% 이상이다. 이를 추적관리 한다는 것은 생각보다 분명 어려운 일이다. 요구사항 하나가 수정되면 이를 일일일 추적하여 수정하는 “엄청난” 공수가 들어간다.
  2. 요구사항 추적이 “누구를” 위한 것인지를 생각해 봤다. 분명 당시 프로젝트 상황에서는 감리 제출용으로 “요구사항 커버리지” 를 증명하기 위해 한 것이다. 개발자들에게는 “전혀” 도움이 되지 않았던 산출물 작업 이었다.

최근에 교육 하나※를 들으면서 위의 고민이 틀리지는 않았음을 알 수 있었다. 당시 강사님의 요구사항에 대한 의견은 다음과 같았다.

  1. 요구사항의 명세화는 큰 의미는 없다. 유즈케이스 문서 등을 요구사항 정리로 대체 할 수 있다.
  2. 고객의 사인을 받기 위한 레벨의 고객 요구사항 의 정리는 의미가 있다. 개발자에게 도움을 주지 못하는 프로세스는 제거하라.

그렇다. 나만 그렇게 생각하는 게 아니었구나. 저 나이 지긋하신 강사님도 저렇게 생각한다고 하네.

내가 이제 내린 요구사항의 정리 관련 결론은 다음과 같다.

  • 고객의 요구사항은 정리한다.
  • 추적성 관련 작업은 無意味하다.
  • 가급적이면 요구사항을 대체할 만한 다른 산출물이 있으면 그것으로 대체한다. (유즈케이스, 화면정의서 등)

※SW공학 프랙티스 - SWEBOK 3.0 개요, SW공학 Best Practices & Lessons Learned(강사: 김영온)