소프트웨어 개발의 핵심 - 요구사항 관리
실용적인 소프트웨어 요구사항을 읽고 난 후 요구사항 관리의 개인적 의견을 정리해 보았다.
요구사항이 개발 대상이다.
소프트웨어 공학에서 SDLC(Software Development Life Cycle)은 대부분 요구사항 도출 -> 분석 -> 설계 -> 구현 -> 테스트 -> 운영 그리고 이들의 반복이다. 분석해야 하는 대상은 개발해야 하는 요구사항이다. 즉, 분석의 입력값은 개발해야 하는 요구사항들이다. 이 요구사항을 가지고 개발이 진행되는데, 이 요구사항을 내는 주체를 비용을 지불하는 고객이라고 봐야 하고, 비용을 직접 내는 고객이 아니더라도 고객의 승인 또는 동의를 받아야 한다.
그래서 요구사항 도출 과정을 분석 단계 앞에서 명확하게 해야 하며, 이렇게 도출한 요구사항은 명확하고도 명시적으로 관리해야 한다. 결국 소프트웨어 품질 관리는 이러한 요구사항 관리에서부터 운영과 반복에 이르는 전 영역을 보증하는 것이어야 한다. 요구사항은 다양한 형태로 존재하는데, 이러한 요구사항들을 개발한다는 것은 다양한 변수들로 이루어진 로직을 제품에 구현하는 것과 같은 이야기이다.
사용자가 만족해하는 품질 좋은 제품
하나의 간단한 요구사항을 처리하기 위해서 역할(role)을 만들고 도구(tool)를 사용하는 등의 고민을 할 필요는 없다. 그러나 기획안 자체만을 요구사항으로 봐야 할지? 기획은 형체가 반드시 있어야만 하는 것인지? 구두로 전달되는 것은 기획이 될 수 없는 것인지? 아이디어를 요구사항으로 봐야 하는 것인지? 기획으로 봐야 하는지? 구두로 전달된 아이디어는 요구사항이 될 수 있는지? 등은 프로젝트 팀 내 합의가 필요하다.
궁극적으로 사용자가 만족해하는 품질 좋은 제품을 제작할 수 있는 방법을 요구사항 관리에서부터 적용해야 한다. 이때 불확실한 요구사항이 맞는지 또는 요구사항의 속성이 불확실성을 내포하고 있는지를 고민해야 한다.
요구사항 이론서들의 출시는 요구사항 관리의 중요도가 그만큼 증가하기 때문이다. 이것은 눈에 보이지 않는 소프트웨어로 개발할 때 발생할 수 있는 복잡성과 불확실성이 증가하고 있다는 것이고, 이로 인한 이슈와 리스크가 현장에서 그만큼 증가하고 있다는 것을 의미한다. 이러한 불확실성의 증가는 다양한 방식의 개발 방식을 요구하고 있지만, 어떠한 방식으로 운영하더라도 중요한 요소는 요구사항(Requirement)이다.
요구사항 관리
이 요구사항 자체를 하나의 완성된 작은 서비스로 바라봐야 한다. 그렇다면 개발팀에서 제품을 소스코드로 제작하듯이 비용을 지불하는 고객도 이러한 요구사항을 완결된 형태로 제출해야 하는 것일까?
요구사항을 전달해야 하는 고객은 요구사항이 무엇일지도 모르는 상태라면, 요구사항을 도출하는 과정부터 거칠 것이며, 이 요구사항은 개발 완료 후 테스트까지를 고려해야 한다. 요구사항 관리 주체를 명시적으로 두는 것도 효과적일 수 있지만 그보다 중요한 것은 소프트웨어 개발 생명 주기 내에서 요구사항을 관리하는 것이다.
요구사항 공학의 핵심 역량은 요구사항을 선별해서 추출하고, 비정형 요구사항을 정형화시키고, 이를 지원할 수 있는 스킬과 관리할 수 있는 역량이다. 요구사항들을 정형화시키려면 분석하고 정의 내리고, 분류화가 가능해야 한다.
요구사항 자체의 품질도 중요 있지만, 요구사항이 프로젝트 전반에 미치는 품질 즉 SDLC 자체에 영향을 주는 품질도 중요하다. 이를 엮어 낼 수 있는 수단은 결국 정량화시킨 수치(Metrics)이다. 이 수치를 통해서 프로젝트와 제품의 품질을 이야기할 수 있어야 한다.
결과적으로 SDLC 품질을 보증할 수 있는 기반을 만들려면 요구사항을 어떻게 잘 관리할 것인가가 관건이다. 불확실성을 내포하고 있는 요구사항을 어떻게 도출해서 분석하고 설계하고 구현할 것인지에 대한 깊은 고민을 프로젝트가 지속적으로 해야 하고, 이것을 통해서는 궁극적으로 제품 품질의 향상을 목표로 삼아야 한다.
 |
|
댓글
댓글 쓰기