회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
Karl E. Wiegers는 소프트웨어 프로세스 개선을 연구하는 단체인 'Process Impact'의 수석 컨설턴트로서 요구사항 공학과 소프트웨어 프로세스 개선 분야에서 연설가, 저술가, 컨설턴트로 활동하고 있습니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
많은 프로젝트가 진행 도중에 요구사항이 변경되고 확장되어 통제 불능 상태에 빠지게 됩니다. 이러한 문제점은 프로젝트 초반에 요구사항을 분석/정의하는 과정을 제대로 거치지 않았기 때문에 발생하지요.
실제로 Nielsen에서 조사한 바에 따르면,70% 가량의 프로젝트 일정 지연을 프로젝트 시작 전에 요구사항 정의를 명확하게 함으로써 피할 수 있다고 밝혔습니다. 중간에 업무 범위가 크게 변경되는 상황을 최소화하고 변경된 사항을 컨트롤할 수 있어 효율적으로 프로젝트를 관리할 수 있게 되는 것이지요.
하지만 대부분의 사람들이 요구사항 분석의 중요성을 간과하거나 요구사항을 정의하는 데에 어려움을 겪곤 합니다. 오늘은 이러한 어려움을 겪는 분들에게 도움이 될 만한 내용이 있어 소개해드리고자 하는데요, Karl E. Wiegers의 저서인 '실용적인 소프트웨어 요구사항(More About Software Requirements)'에서 소프트웨어 요구사항에 대한 일반적인 진실에 소견을 적은 내용이 있어 요약 및 재가공하여 여러분에게 소개해드리려고 합니다.
Karl E. Wiegers는 소프트웨어 프로세스 개선을 연구하는 단체인 'Process Impact'의 수석 컨설턴트로서 요구사항 공학과 소프트웨어 프로세스 개선 분야에서 연설가, 저술가, 컨설턴트로 활동하고 있습니다.
소프트웨어 개발 프로젝트의 목표는 특정 사용자 그룹에게 가치를 제공하는 제품을 생성하는 것입니다. 즉, 최종 사용자의 요구를 만족할 것이라는 사실을 입증해 보이는 것을 포함합니다. 사용자가 주요 업무를 올바르게 수행하고 일반적인 오류상황에 적절히 대처하며 사용자가 요구하는 품질 기준을 만족하는 것이 프로젝트 성공의 기준인 것이지요.
요구사항 개발에 대한 합의는 작업 초기에 전달 받는 고객의 피드백, 제품에 대한 기대치, 필요성 변경이 지속적으로 이루어지면서 변하게 되지요. 이에 대한 적절한 검토나 적용이 이루어지지 않고선 고객을 만족시킬 수 없습니다.
유도는 반복을 요구합니다. 요구사항을 전달해야 하는 클라이언트들은 처음부터 필요한 모든 것을 고려하고 있지 않을 것이며, 이들의 생각은 프로젝트가 진행됨에 따라 변화할 것입니다. 따라서 단순히 클라이언트가 말하는 것을 받아쓰는 것이 아니라, 조사관의 입장에서 질의를 통해 고객이 보다 활발하게 생각하도록 유도하고 숨어 있는 정보를 찾아내고 새로운 아이디어를 고안해야 하는 것이지요.
여러분은 클라이언트의 요구에 부합하는 요구사항을 제안할 수 있습니다. "이런 시스템이 XXX 기능을 제공한다면 도움이 될까요?" 라고 질의하면, 고객은 "아뇨, 별 필요 없을 것 같아요." 라든가 "그런 방법도 있군요. 사용자들의 시간을 절약할 수 있는 좋은 기능인 것 같네요."라고 응할 수도 있지요. 이런 창의성은 요구사항 협의 단계에서 여러분이 창출할 수 있는 가치의 일부입니다. 요구사항은 이해 당사자들의 목표에 대한 합의이며 성공에 대한 광범위한 정의라는 생각을 가지고 있어야 합니다.
요구사항이 불확실하고 변경 가능성이 크다면 증분법 또는 반복적인 개발 생명주기를 사용해야 합니다. 절대 초반에 모든 요구사항을 수집하고 고정하려 하지 않아야 합니다. 그 대신 당시에 가능한 수준으로 초기 요구사항 세트(베이스라인)를 명기해야 합니다. 베이스 라인은 특정 해당 시점에서의 요구사항 상태에 관한 명세로 “우리는 이 요구사항이 고객 요구와 부합하며 설계 및 개발을 진행하기에 적절한 기초가 될 수 있다고 믿는다.”라는 의미를 갖는다고 할 수 있지요. 이후 베이스라인에 언급된 부분에 대한 개발을 수행하고 고객의 피드백을 얻고, 다음 기능으로 진행하도록 합니다. 이러한 방법이 애자일(Agile) 개발 방법론, 반복 프로토타이핑 등 점진적 접근법의 근간이 되지요.
개발 프로젝트 도중 요구사항이 변할 것이라는 건 불 보듯 뻔한 사실입니다. 새로운 사용자와 시장이 개척되고, 비즈니스 규칙과 정부 규정은 개정되며, 운영 환경 또한 수시로 변화하기 때문이지요. 따라서 변경을 금지하기 보단 변경을 제어하고 관리할 수 있는 프로세스가 필요합니다. 여러분은 충격과 비용을 최소화하기 위해 변경을 예측하고 받아들일 필요가 있습니다.
따라서 여러분은 고객의 요청을 다 들어주기보다는 고객의 요청 이면의 진정한 뜻을 이해하고 수용 가능한 결론을 유도해야 합니다. 고객이 항상 옳은 것은 아닐 수 있지만 분석하는 과정에서 제품에 대한 특성이나 속성에 대해 요청하고 있는 본질이 무엇인지에 대해 존중하고 또 이해할 필요가 있는 것이지요. 고객이 틀렸을 때 이를 경고해 주는 역할 또한 여러분이 수행해야할 몫입니다.
다음은 고객의 요청이 잘못된 경우의 대표적인 몇 가지 예시입니다.
- 요구사항의 겉치레에 대한 솔루션을 제시하는 경우
- 요구사항 우선순위를 망치거나 우선권을 갖기 위해 큰소리치는 경우
- 비즈니스 규칙이나 다른 제한사항에 대해 논의하지 않거나 회피하는 경우
- 분석가나 개발자가 제기한 문제에 대한 올바른 결정을 내리지 못하는 경우
- 기능/비기능 요구사항에 대한 조율의 필요성을 받아들이지 못하는 경우
- 불가능한 책임을 요구하는 경우
- 변경에 따른 비용을 수용하지 않는 경우
범위 문제를 제어하기 위해서는 프로젝트 관계자들이 범위 정의, 즉 주어진 제품 릴리즈를 위한 범위 내에 가능한 기능들과 그렇지 않은 것들에 대한 경계에 동의하도록 하여야 합니다. 그런 다음 관계자 중 누군가가 새로운 요구사항이나 특성, 또는 유스케이스를 제안하였을 때 범위 내에 있는 것인지 질문할 수 있지요. 어떤 특정 요구사항이 처음에는 범위 밖이었다가 이후에 포함되기도 하고 다시 범위 밖으로 제외되는 등의 혼란이 발생한다면 프로젝트 범위 경계가 제대로 확립되지 못함을 뜻하는 증상으로 범위 혼란 문제를 겪을 가능성이 크다는 것을 뜻합니다.
여러분은 세부사항을 개선하고 모호함을 명확하게 하거나 공백을 채우기 위해 관련 항목 전문가나 해당 분야에 대해 잘 알고 있는 사용자들과 대화할 필요성이 있습니다. 대화를 통해 모든 관계자들이 동일한 수준으로 이해할 수 있도록 해야 하지요.
의사 결정권자들과의 잦은 협의가 불가능한 경우, 요구사항 명세서는 보다 상세할 필요가 있습니다. 요구사항의 의미를 명확히 하고 동의하기 위한 검토 과정에 엄청난 시간이 소요되고 질문에 대한 응답이나 요청 사항에 대한 결정을 기다리는 과정에 지연이 발생될 것이며, 이로 인해 전체 프로젝트 일정이 늦어질 수 있기 때문이지요.
궁극적으로 여러분은 단 하나의 제품을 만들고 있으며 누군가는 이 제품이 어떤 것이 되어야 하는지를 결정합니다. 만일 클라이언트가 결론을 내리지 못한다면, 결국 최종적으로는 여러분에게 압박이 가해지게 됩니다. 이것은 핵심 관계자들이 그들의 책임을 포기하여 문제점에 대해 그들보다 잘 모르는 사람들이 책임을 떠맡게 되는 상황이지요. 요구사항이 너무 모호할 경우, 클라이언트에게 모호함을 인지시키고 프로토타이핑과 같은 방법을 동원하여 구체화하는 방법을 제안할 수도 있습니다.
현실적인 관점에서 요구사항 개발이란 설계를 진행하거나 구현하고 테스트할만한 정도의 위험성 범위를 만족하는 수준의 요구사항을 이끌어 내는 것입니다. 여기서 위험성이란 큰 비용이 소요되고 필요 없는 재작업이 투입되어야 하는 경우의 가능성을 말하지요. 초기 요구사항 유도 단계 이후에 프로젝트가 진행되면서 어떤 변경도 금지할 수 있다는 생각은 버려야 합니다.