소프트웨어 요구사항에 대한 일반적인 진실 8가지

많은 프로젝트가 진행 도중에 요구사항이 변경되고 확장되어 통제 불능 상태에 빠지게 됩니다. 이러한 문제점은 프로젝트 초반에 요구사항을 분석/정의하는 과정을 제대로 거치지 않았기 때문에 발생하지요.

실제로 Nielsen에서 조사한 바에 따르면, 70% 가량의 프로젝트 일정 지연을 프로젝트 시작 전에 요구사항 정의를 명확하게 함으로써 피할 수 있다고 밝혔습니다. 중간에 업무 범위가 크게 변경되는 상황을 최소화하고 변경된 사항을 컨트롤할 수 있어 효율적으로 프로젝트를 관리할 수 있게 되는 것이지요.

하지만 대부분의 사람들이 요구사항 분석의 중요성을 간과하거나 요구사항을 정의하는 데에 어려움을 겪곤 합니다. 오늘은 이러한 어려움을 겪는 분들에게 도움이 될 만한 내용이 있어 소개해드리고자 하는데요, Karl E. Wiegers의 저서인 ‘실용적인 소프트웨어 요구사항(More About Software Requirements)‘에서 소프트웨어 요구사항에 대한 일반적인 진실에 소견을 적은 내용이 있어 요약 및 재가공하여 여러분에게 소개해드리려고 합니다.

Karl E. Wiegers는 소프트웨어 프로세스 개선을 연구하는 단체인 ‘Process Impact’의 수석 컨설턴트로서 요구사항 공학과 소프트웨어 프로세스 개선 분야에서 연설가, 저술가, 컨설턴트로 활동하고 있습니다.

소프트웨어 관련 사항들은 “그때그때 다르다”는 말로 쉽게 표현할 수 있을 정도로 불확실성이 큽니다. 하지만 그는 수많은 조직에서 일하면서 느낀 보편적으로 어디에나 적용 가능할 수 있는 몇 가지 특성들이 있다고 말합니다.

 

 

소프트웨어 요구사항에 대한 보편적인 진리 8가지

1. 제대로 된 요구사항을 얻지 못한다면, 그 이후에 프로젝트를 얼마나 잘 수행하는냐는 논할 가치도 없다

요구사항은 모든 프로젝트 업무의 토대입니다. 요구사항을 통해 프로젝트가 끝났을 때 산출물이 무엇인지를 설명할 수 있어야 하지요. 이는 프로젝트 초기에 준비되는 요구사항 명세서(SRS, Software Requirement Specification) 초안을 말하는 것이 아니라, 프로젝트 진행 전반에 걸쳐 점증적으로 개발된 요구사항 관련 지식의 전체를 말하는 것입니다.

소프트웨어 개발 프로젝트의 목표는 특정 사용자 그룹에게 가치를 제공하는 제품을 생성하는 것입니다. 즉, 최종 사용자의 요구를 만족할 것이라는 사실을 입증해 보이는 것을 포함합니다. 사용자가 주요 업무를 올바르게 수행하고 일반적인 오류상황에 적절히 대처하며 사용자가 요구하는 품질 기준을 만족하는 것이 프로젝트 성공의 기준인 것이지요.

요구사항 개발에 대한 합의는 작업 초기에 전달 받는 고객의 피드백, 제품에 대한 기대치, 필요성 변경이 지속적으로 이루어지면서 변하게 되지요. 이에 대한 적절한 검토나 적용이 이루어지지 않고선 고객을 만족시킬 수 없습니다.

 

2. 요구사항 개발은 단순히 수집하는 과정일 뿐만 아니라 탐색하고 창조하는 과정이다

사람들은 보통 ‘요구사항을 수집한다’라고 이야기 합니다.  마치 주변에 가만히 떨어져 있는 꽃을 줍기만 하면 되는 것처럼 말이지요. 하지만 필자는 ‘요구사항을 수집한다’는 말보다 ‘요구사항을 유도한다’고 표현하는 것이 옳다고 말합니다. 유도는 클라이언트나 관련 분야 전문가가 제시하는 정보의 조각들을 기록하는 것뿐만 아니라, 약간의 조사와 창조를 포함하기 때문이지요.

유도는 반복을 요구합니다. 요구사항을 전달해야 하는 클라이언트들은 처음부터 필요한 모든 것을 고려하고 있지 않을 것이며, 이들의 생각은 프로젝트가 진행됨에 따라 변화할 것입니다. 따라서 단순히 클라이언트가 말하는 것을 받아쓰는 것이 아니라, 조사관의 입장에서 질의를 통해 고객이 보다 활발하게 생각하도록 유도하고 숨어 있는 정보를 찾아내고 새로운 아이디어를 고안해야 하는 것이지요.

여러분은 클라이언트의 요구에 부합하는 요구사항을 제안할 수 있습니다. “이런 시스템이 XXX 기능을 제공한다면 도움이 될까요?” 라고 질의하면, 고객은 “아뇨, 별 필요 없을 것 같아요.” 라든가 “그런 방법도 있군요. 사용자들의 시간을 절약할 수 있는 좋은 기능인 것 같네요.”라고 응할 수도 있지요. 이런 창의성은 요구사항 협의 단계에서 여러분이 창출할 수 있는 가치의 일부입니다. 요구사항은 이해 당사자들의 목표에 대한 합의이며 성공에 대한 광범위한 정의라는 생각을 가지고 있어야 합니다.

 

3. 변경은 발생하게 되어 있다

거의 모든 소프트웨어 프로젝트가 애초 계획보다 규모가 커지는 경향이 있는데, 이는 요구사항도 마찬가지 입니다.  Capers Johns(2000)라는 컨설턴트에 의하면 설계와 코딩 기간에 발생하는 요구사항 증가는 평균 월 1~3% 수준이라고 합니다. 이와 같은 결과는 장기간의 프로젝트에서 치명적일 수 있지요. 어느 정도 예측된 증가에 부합하기 위해 프로젝트 일정의 불확실성에 대한 여유 시간을 고려해야 합니다. 이러한 여유 시간은 변경이 발생함으로써 일정 준수 약속이 깨지는 것을 막아줍니다.

요구사항이 불확실하고 변경 가능성이 크다면 증분법 또는 반복적인 개발 생명주기를 사용해야 합니다. 절대 초반에 모든 요구사항을 수집하고 고정하려 하지 않아야 합니다. 그 대신 당시에 가능한 수준으로 초기 요구사항 세트(베이스라인)를 명기해야 합니다. 베이스 라인은 특정 해당 시점에서의 요구사항 상태에 관한 명세로 “우리는 이 요구사항이 고객 요구와 부합하며 설계 및 개발을 진행하기에 적절한 기초가 될 수 있다고 믿는다.”라는 의미를 갖는다고 할 수 있지요. 이후 베이스라인에 언급된 부분에 대한 개발을 수행하고 고객의 피드백을 얻고, 다음 기능으로 진행하도록 합니다. 이러한 방법이 애자일(Agile) 개발 방법론, 반복 프로토타이핑 등 점진적 접근법의 근간이 되지요.

개발 프로젝트 도중 요구사항이 변할 것이라는 건 불 보듯 뻔한 사실입니다. 새로운 사용자와 시장이 개척되고, 비즈니스 규칙과 정부 규정은 개정되며, 운영 환경 또한 수시로 변화하기 때문이지요. 따라서 변경을 금지하기 보단 변경을 제어하고 관리할 수 있는 프로세스가 필요합니다. 여러분은 충격과 비용을 최소화하기 위해 변경을 예측하고 받아들일 필요가 있습니다.

 

 

4. 고객이 항상 옳은 것은 아니지만 그에 따른 의미는 있다.

일부 집단에서는 ‘고객은 항상 옳다’라고 주장하며 고객의 요청은 무조건 들어줍니다. 하지만 고객이 항상 옳을 수는 없습니다. 때때로 고객들은 잘 모르고 있거나, 합리적이지 않을 수 있지요.

따라서 여러분은 고객의 요청을 다 들어주기보다는 고객의 요청 이면의 진정한 뜻을 이해하고 수용 가능한 결론을 유도해야 합니다. 고객이 항상 옳은 것은 아닐 수 있지만 분석하는 과정에서 제품에 대한 특성이나 속성에 대해 요청하고 있는 본질이 무엇인지에 대해 존중하고 또 이해할 필요가 있는 것이지요. 고객이 틀렸을 때 이를 경고해 주는 역할 또한 여러분이 수행해야할 몫입니다.

다음은 고객의 요청이 잘못된 경우의 대표적인 몇 가지 예시입니다.

• 요구사항의 겉치레에 대한 솔루션을 제시하는 경우
• 요구사항 우선순위를 망치거나 우선권을 갖기 위해 큰소리치는 경우
• 비즈니스 규칙이나 다른 제한사항에 대해 논의하지 않거나 회피하는 경우
• 분석가나 개발자가 제기한 문제에 대한 올바른 결정을 내리지 못하는 경우
• 기능/비기능 요구사항에 대한 조율의 필요성을 받아들이지 못하는 경우
• 불가능한 책임을 요구하는 경우
• 변경에 따른 비용을 수용하지 않는 경우

 

5. 새로 제시된 요구사항에 대해 가장 먼저 던져야 할 질문은 “이 요구사항이 개발 범위 내에 있는 사항입니까?”다

소프트웨어 비즈니스에 어느 정도 몸담아온 사람이라면 누구나 한번쯤은 범위 변경 문제로 골치 아픈 프로젝트를 겪어본 적이 있을 것입니다. 프로젝트를 진행하면서 요구사항이 커지는 것은 자연스러운 현상이며 때로는 이득이 될 수도 있지만, 통제할 수 없을 정도로 요구사항이 계속 커져서 제품을 일정에 맞춰 납품할 수 없게 된다면 큰 문제가 됩니다.

범위 문제를 제어하기 위해서는 프로젝트 관계자들이 범위 정의, 즉 주어진 제품 릴리즈를 위한 범위 내에 가능한 기능들과 그렇지 않은 것들에 대한 경계에 동의하도록 하여야 합니다. 그런 다음 관계자 중 누군가가 새로운 요구사항이나 특성, 또는 유스케이스를 제안하였을 때 범위 내에 있는 것인지 질문할 수 있지요. 어떤 특정 요구사항이 처음에는 범위 밖이었다가 이후에 포함되기도 하고 다시 범위 밖으로 제외되는 등의 혼란이 발생한다면 프로젝트 범위 경계가 제대로 확립되지 못함을 뜻하는 증상으로 범위 혼란 문제를 겪을 가능성이 크다는 것을 뜻합니다.

 

6. 아무리 뛰어난 요구사항 문서라고 해도 사람 사이의 대화를 대신할 수는 없다

특정 시점에 해당 관계자들이 동의한 내용을 문서화한 것은 단순히 기억에 의존하는 것보다 신뢰성을 갖습니다. 하지만 제아무리 뛰어난 요구사항 명세서라 해도 개발자가 업무를 수행하는데 필요한 모든 정보를 담고 있을 수는 없습니다. 관계자들 사이에 암묵적으로 당연시되는 항목들이 있게 마련이며, 이들은 SRS에 명확한 표현들로 명기되어야 하지요.

여러분은 세부사항을 개선하고 모호함을 명확하게 하거나 공백을 채우기 위해 관련 항목 전문가나 해당 분야에 대해 잘 알고 있는 사용자들과 대화할 필요성이 있습니다. 대화를 통해 모든 관계자들이 동일한 수준으로 이해할 수 있도록 해야 하지요.

의사 결정권자들과의 잦은 협의가 불가능한 경우, 요구사항 명세서는 보다 상세할 필요가 있습니다. 요구사항의 의미를 명확히 하고 동의하기 위한 검토 과정에 엄청난 시간이 소요되고 질문에 대한 응답이나 요청 사항에 대한 결정을 기다리는 과정에 지연이 발생될 것이며, 이로 인해 전체 프로젝트 일정이 늦어질 수 있기 때문이지요.

 

 

7. 요구사항이 모호할지도 모르지만 제품은 명확할 것이다

요구사항을 완벽하게 정의하는 것은 너무나도 어렵습니다. 무엇인가 새로운 것을 만들고 있는 중인데, 그 누구도 이 제품이 어떻게 되어야 하며 또 어떤 기능을 해야 하는지 모르기 때문이지요. 때로는 모호한 요구사항에 만족해하고 이런 불분명한 요구사항을 특정 시점에 자신들에게 유리한 방향으로 개선할 빌미로 삼는 경우도 있습니다. 클라이언트는 모호함을 무기 삼아 여러분에게 무리한 요구를 할 수 있고, 개발자들은 모호한 요구사항에 대해 마음대로 구현하면 되는 것으로 생각하기도 하지요. 하지만 이런 생각들은 고품질의 소프트웨어 개발과는 거리가 멉니다.

궁극적으로 여러분은 단 하나의 제품을 만들고 있으며 누군가는 이 제품이 어떤 것이 되어야 하는지를 결정합니다. 만일 클라이언트가 결론을 내리지 못한다면, 결국 최종적으로는 여러분에게 압박이 가해지게 됩니다. 이것은 핵심 관계자들이 그들의 책임을 포기하여 문제점에 대해 그들보다 잘 모르는 사람들이 책임을 떠맡게 되는 상황이지요. 요구사항이 너무 모호할 경우, 클라이언트에게 모호함을 인지시키고 프로토타이핑과 같은 방법을 동원하여 구체화하는 방법을 제안할 수도 있습니다.

 

8. 완벽한 요구사항이란 없다

요구사항 개발은 절대 끝나거나 완성되지 않습니다. 빠뜨린 요구사항이 없다는 것을 확인할 방법은 없으며, 특정 사항은 기록할 필요성을 느끼지 못해 빼먹는 경우는 항상 있게 마련입니다. 요구사항에 대해 ‘완성본’이라고 표기하기보다는 특정 시점에 베이스라인을 작성해야 합니다. 일단 베이스라인이 준비되면 요구사항을 변경할 때는 변경 제어 프로세스를 따르고 변경에 따른 영향성을 인식해야 하지요.

현실적인 관점에서 요구사항 개발이란 설계를 진행하거나 구현하고 테스트할만한 정도의 위험성 범위를 만족하는 수준의 요구사항을 이끌어 내는 것입니다. 여기서 위험성이란 큰 비용이 소요되고 필요 없는 재작업이 투입되어야 하는 경우의 가능성을 말하지요. 초기 요구사항 유도 단계 이후에 프로젝트가 진행되면서 어떤 변경도 금지할 수 있다는 생각은 버려야 합니다.