[요구사항 공학] 요구사항 분석하기 (2) - 소프트웨어 요구사항에 대한 일반적인 진리

 소프트웨어 요구사항에 대한 일반적인 진리

 

컨설턴트라면 누구나 알고 있듯이 소프트웨어에 대한 거의 모든 질문에 대한 정확한 대답은 "그때 그때 달라요"이다.

이 말이 단순히 컨설턴트의 변명이라고만 할 수  없다. 주어진 상황에 대한 최선의 대처법에 대한 조언은 프로젝트 성격, 제한사항, 조직이나 팀 내 문화, 비즈니스 환경 등에 따라 달라진다. 그렇다고 고객의 질문에 그렇게 답할 수는 없다. 그래서 요구사항의 "보편적 진리"들과 이들이 실제 요구사항 분석가 훈련 시에 어떤 의미를 갖는지 설명하도록 하겠다.

 

[요구사항 실체]

 

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

요구사항은 뒤따르는 모든 포르젝트 업무의 토대이다.

 

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

요구사항은 주변에 가만이 떨어져있는 꽃처럼 줍기만 하면 되거나 분석가가 사용자의 머릿속에서 빨아내기만 하면 되는 것으로 보인다. 분석가는 단순히 고객이 말하는 것을 받아쓰는 사람이 아니다. 분석가는 고객이 보다 활발하게 생각하고 의견을 낼 수 있도록 유도하는 사람이다.  "고객님 시스템이 XYZ 기능을 제공한다면 어떤 도움이 될까요?"와 같이 숨은 요구사항을 탐색할 수 있어야 한다.

 

일반적인 진리 #3 : 변경은 발생하게 되어 있다.

요구사항은 변할 것이라는 것은 불을 보듯 뻔한 사실이다. 시장이 변하고, 정부의 규제, 업무 규칙, 운영 환경이 변하기 때문에 수시로 변화한다. 그래서 "요구사항 변경관리"가 필요하다. 그러나 요구사항이 합의된 후에도 변경사항이 예상외로 많으면 충분한 유도작업을 하지 못했거나, 고객과 합의가 불충분 하다는 것이다. 모든 개발팀은 요청된 변경에 대해 누가 평가하고 결정권을 가지며 거부권을 갖게될지 결정해야 한다. 이러한 기능을 수행하는 그룹을 보통 변경통제위원회(CCB: Change Control Board)라고 한다. 프로젝트를 진행하면서 계획보다 규모가 커지는데, 요구사항의 증가는 월 1~3%한다. 따라서 프로젝트 일정에 불확실성에 대비한 여유시간(관리용 예비)을 넣어 두어야 한다. 만약 이 시간이 없으면 변경이 발생할 경우 처리가 어렵다.

 

이러한 문제는 애자일 개발방법론, 나선형 모델, 반복 프로토타이핑, 발전적 출시 및 점진적 접근법을 이용해 개선할 수 있다.

 

[요구사항 이해 관계자]

일반적인 진실 #4 : 모든 프로젝트 관계자들의 관심사들은 요구사항 프로세스 내에서 서로 교차한다.

컨설턴트 Time Lister는 프로젝트의 성공을 "핵심 관계자들의 기대치에 상응하는 모든 요구사항과 조건 세트를 만족하는 것"으로 정의 한 바 있다. 이해관계자는 개인 또는 그룹을 의미하며, 적극적으로 프로젝트에 개입하고 프로젝트에 의해 영향을 받거나 프로젝트산출물에 영향을 미칠수 있는 사람이다. 요구사항 분석가는 의사소통의 중심에 위치하며 모든 이해관계자들의 상호작용 할 책임이 있다. 더 나아가 분석가는 시스템 아키텍트와 함께 시스템이 모든 관계자들이 사용할 수 있게 정의되고 있는지 감독할 의무를 가지고 있다.

 

프로젝트 사작과 함께 핵심 관계자 그룹과 각 그룹의 대표자들을 식별하도록 한다. 반드시 충족되어야 하는 관심사들 간에 혼선이 있을 때 이들에게 의존할 수 있다.   그들 모두가 서로 상대에 대한 거부권을 가지고 있을 수는 없다. 재빨리 이런 혼란을 처리할 수 있는 결정권자를 찾아내어야 한다.   Christian Fahlbusch "보통 하나의 프로젝트에 한 명의 최고 결정권자가 있으며, 종종 핵심 스폰서가 이에 해당된다. 나는 그 사람을 찾아내기 전에는 맘 편히 쉴 수도 없을 것이고, 항상 그가 프로젝트 진행 상황을 알고 있게 할 것이다."

 

 

일반적인 진리 #5 : 고객 참여는 소프트웨어 품질에 가장 크게 기여하는 요소이다.

요구사항은 변할 것이라는 것은 불을 보듯 뻔한 사실이다. 시장이 변하고, 정부의 규제, 업무 규칙, 운영 환경이 변하기 때문에 수

부적절한 고객 참여가 소프트웨어 프로젝트를 실패로 이끈다.

• 사용자 계층의 식별 : 고객들은 관계자의 일부이고 사용자들은 고객의 일부이다. 누락된 사용자 그룹이 있다면 출시된 제품에 실망하는 사람들이 나타나게 될 것이다.
• 제품 챔피언 선택 : 각 고객 계층의 목소리를 대변할 사람을 결정할 필요가 있다. 이들을 제품 챔피언이라 부르고 이들은 그들이 속한 사용자 분류의 대표이다.
• 프로토 타입 제작 : 프로토 타입은 사용자 대표자들이 궁극적인 시스템의 시뮬레이션 또는 그 일부를 이용해 비교해 볼 수 있는 기능을 제공한다. 요구사항 명세서와 비교하면 훨씬 현실적이긴 하지만, 상세 요구사항의 문서화에 대한 대안이 될 수 없다. 반드시 문서를 작성하라.
• 고객 권리와 책임에 대한 합의 : 반드시 함께 일해야 하는 사람들은 협업에 관해 잘 논의 하지 않는다. 분석가는 프로젝트 초기에 고객 대표자들과 합의를 통해 요구사항 프로세스 측면에서 각 측의 책임 소재를 명확히 하여야 한다. 이와  같은 합의에 기초한 협업 정책은 참가자들 모두에게 이익이 되는 매우 강력한 수단이다.

일반적인 진리 #6 : 고객이 항상 옳은 것은 아니지만 항상 그에 따른 의미는 있다.

고객이 항상 옳은 것은 아닐 수 있지만 분석가는 이 과정에서 고객이 제품의 대해 요청하고 있는 본질은 무엇인지에 대해 파악하고 의견을 존중해야 할 필요가 있다. 다음은 고객이 잘못 된 경우의 대표적인 몇가지 예이다.

• 요구사항의 겉치레에 대한 솔루션을 제시하는 경우
• 요구사항 우선순위를 망치거나 우선권을 갖기 위해 큰소리치는 경우
• 비즈니스 규칙이나 다른 제한 사항에 ㄷ해 논의하지 않거나 회피하는 경우
• 비즈니스 프로세스 변경들을 처리하기 위해 새로운 소프트웨어 시스템을 요구하는 경우
• 요구사항 유도 작업에 적합한 사용자 대표를 참여시키지 않는 경우
• 분석가나 개발자가 제기한 문제에 대한 올바른 결정을 내리지 못하는 경우
• 기능/비기능 요구사항에 대한 조율의 필요성을 받아들이지 못하는 경우
• 불가능한 책임을 요구하는 겨웅
• 변경에 따른 비용을 수용하지 않는 경우

이러한 고객과는 일을하면 안되는 건가?

 

[요구사항 명세]

일반적인 진리 #7 : 새로이 제시된 요구사항에 대해 분석가가 가장 먼저 던져야 할 질문은 "이 요구사항이 개발 범위 내에 있는 사항입니까?" 이다.

범위 문제를 제어하기 위해서는 프로젝트 관계자들이 범위 정의 즉 주어진 제품 릴리즈를 위한 범위 내에 가능한 기능들과 그렇지 않은 것들에 대한 경계에 동의하도록 하여야 한다. 그런다름 새로운 요구사항에 대해 "범위내에 있는 것인가요?"

어떤 특정 요구사항이 처음에는 범위 밖에었다가 이후에 포함되기도 하고 다시 범위 밖으로 제외되는 등의 혼란이 발생한다면 프로젝트 범위 경계가 제댈 확립되지 못함을 뜻하는 증상으로 범위 혼란 문제에 봉착할 가능성을 시사한다.

 

일반적인 진리 #8 : 아무리 뛰어난 요구사항 문서도 사람 사이의 대화를 대신 할 수 없고 또 그래서도 안된다.

제아무리 최고의 요구사항 명세서라고 해도 개발자와 테스터의 업무를 수행하는데 필요한 모든 정보를 담고 있을 수는 없다. 옳건 그르건 관계자들 사이에 암묵적으로 당연시되는 항목들이 있게 마련이다. 명확한 항목은 반드시 SRS에 명기되어야 한다.

사용자 대표자들이나 다른 의사 결정권들과의 잦은 협의가 불가능할 경우 요구사항 명세서는 보다 상세할 필요가 있다.

 

일반적인 진리 #9 : 요구사항이 모호할지도 모르지만 제품은 명확할 것이다.

요구사항을 완벽하게 정의하는 것은 너무나도 어렵다. 무엇인가 새로운 것을 만들고 있는  중인데, 그 누구도 이 제품이 어떻게 되어야 하며 또 어떤 기능을 해야 하는지 모르고 있다. 대로 모호한 요구사항에 만족해한다. 그렇다고 개발자가 모호한 요구사항에 대해 마음대로 구현하면 안된다. 모호함을 인지하고 프로토타이핑과 같은 방법을 동원하여 구체화시키도록 노력한다. 요구사항을 명세하는데 도움이 될만한 방법은 적합성 기준(fit criteria)을 정의하는 방법인데, 이렇게 함으로써 사용자나 테스터는 이 기준에 의거하여 해당 요구사항이 적절하게 의도대로 구현되었는지 판단할 수 있다.

 

일반적인 진리 #10 : 완벽한 요구사항은 없다.

요구사항은 끝나거나 완료되지 않는다. 빠뜨린 요구사항이 없다는 것을 확인하는 방법은 없으며 분석가가 기록할 필요성을 느끼지 못해 빼먹는 요구사항은 항상 있게 마련이다. 요구사항에 대해 "완성본"이라고 표기하기보다는 특정 시점에서 [베이스라인]을 작성하도록 한다. 일단 베이스라인이 준비되면 요구사항을 변경할 때는 변경 제어 프로세스 따르고 변경에 따른 영향성을 인식하도록 한다.

 

완벽한 SRS를 작성했다고 해서 프로젝트가 성공하는 것이 아니다. 현실적인 관점에서 요구사항 개발이란 설계를 진행하거나 구현하고 테스트할만한 정도의 위험성 범위를 만족하는 수준의 요구사항을 이끌어 내는 것이다. 여기서 위험성이란 큰 비용이 소요되고 필요 없는 재작업이 투입되어야 하는 경우의 가능성이다. 자신의 작업에 근간을 이루는 요구사항에 대해서는 해당 팀원이 직접 검토하도록 하여 이어지는 작업에 혼선이 없도록 한다. 고품질의 요구사항을 추구할 때 항상 "충분한 괜찮은 수준"이라는 실용적인 목표를 머릿속에 간직하도록 하라.