지난 시간까지는 소프트웨어 테스팅에 대한 기본적인 개념과 테스트 계획에 대해 알아보았다.

이번 시간에는 테스트 설계를 진행하기 전 단계는 요구사항 분석에 대해 알아보도록 하자.

1. 요구사항 정의

요구사항은 해결되어야 하는 문제를 정의한다.

시스템은 어떤 목적을 위해 필요한 모든 것을 정의할 뿐이지 문제를 해결하는 솔루션을 정의하는 것은 아니다. 요구사항은 무엇이 구현되어야 하는지에 대한 명세이며, 시스템이 따라야 하는 특징, 속성, 행위, 제한 사항이라 볼 수 있다.

1.1. 사용자 요구사항

사용자가 제품이나 서비스를 이용해서 무엇을 할 수 있는지에 대한 설명이며, 사용자들이 수행하려는 업무를 말한다.

1.2. 기능 요구사항

시스템이 반드시 수행해야 하거나, 시스템을 이용하여 사용자가 반드시 할 수 있어야 하는 것들에 관한 것으로, 시스템 동작에 대한 설명으로 볼 수 있다. 이는 사용자의 요구사항에서 나온다.

1.3. 비기능 요구사항

시스템이 제공해야 하는 속성이나 특징, 시스템이 고려해야 하는 제약조건에 대한 설명이다.

1.4. 비즈니스 요구사항

조직에서 프로젝트를 수행하는 이유에 대해 설명하고, 그로 인해 고객이 프로젝트에서 나온 제품이나 서비스를 통해 얻을 가치를 식별한다.

1.5. 시스템 요구사항

다수의 구성요소나 서브시스템으로 이뤄진 제품에 대한 요구사항을 설명한다(ISO/IEC/IEEE 2011). 시스템 요구사항은 SW, HW 서브시스템 모두를 포함할 수 있으며, SW 요구사항들은 시스템을 구성하는 SW 컴포넌트들에 할당된 기능/비 기능 요구사항을 나타낸다.

1.6. 외부 인터페이스

2. 요구사항 도출

요구사항 도출은 요구 분석가가 목표 시스템에 바라는 고객의 요구를 수집하는 활동으로, 다양한 이해관계자들의 요구와 제약사항을 식별하는 요구사항의 핵심이 되는 활동이다. 요구사항 도출 단계의 목적은 요구사항 분석 이전에 시스템이 구축 가능한지를 판단하고 고객의 요구에 중심을 두어 요구사항을 추출하기 위한 것이다.

2.1. 요구사항 도출 방법

요구사항을 도출할 때는 여러 가지 방법을 활용하는데, 요구사항의 크기, 복잡도, 도메인, 유형별 포함된 인원을 고려해 기법을 선정한다. 아래는 포함된 인원으로 기법을 선정하는 방식의 예이다.

<요구사항 도출 기법과 적용>

Ref. 소프트웨어 품질관리 실무가이드 / 프리렉

여러 가지 다양한 기법을 가지고 요구사항 도출 작업을 진행하며, 구체적으로 다음과 같은 기법을 사용한다.

· 인터뷰(Interviews) - 프로젝트 이해관계자들로부터 직접적으로 그들이 원하는 것을 얻을 수 있는 가장 유용한 방법이고, 직접 대화를 통하여 상세정보를 도출한다. 사용자, 고객 등의 관점에서부터 이미 이해하고 공감하고 있어야 한다. 대답하기 어려운 뻔한 질문은 피하고, “왜요?”를 남발하지 말아야 하며, 개방형 질문을 사용하고, 말을 하는 것보다 듣는다는 자세를 가지고 임해야 한다.

· 설문(Questionnaires) – 인터뷰를 하기에는 대상자가 너무 많아 광범위한 불특정 다수로부터의 의견 수집이 필요할 경우 사용하는 방법이다. 무엇보다 즉각적인 질문이 어렵기 때문에 미리 설문 항목을 준비해야 하고, 원래 묻고자 하는 내용이 응답자에게 잘 전달될 수 있어야 한다. 설문 기법은 응답이 적을 때 누락자의 의견 파악이 어려운 단점이 있다.

· 브레인스토밍(Brainstorming) – 소수 그룹(2~4, 4~20명)에서 짧은 시간에 최대한 많은 아이디어를 이끌어 내기 위한 방법이다. 여러 가지 제약에서 벗어나 자유롭게 생각을 확장할 수 있도록 도와주는 방법론으로 컨셉트를 구체화하기 위한 아이디어를 도출하고 영감을 얻기에 유용하다

· 스토리보드(Storyboards) – 구현할 SW의 서비스를 사용자 관점으로 설명하기 위해 그림이나 사진을 이용해서 시나리오를 시각화하는 방법론이다. 주로 그림이나 도식을 그리는 형식으로 표현되며, 웹 기반 시스템인 경우 사용자가 주요 화면을 통해 어떻게 서비스 기능을 사용하는지에 대한 흐름을 표현하기도 한다. 이를 기반으로 서비스 상황을 예측하고 검토하는 것을 목적으로 한다.

· 롤플레잉(Role Playing) – 사용자의 문제를 효과적으로 이해하기 위해서 역할극을 수행한다.

· 요구사항 도출 워크숍(Requirements workshop) – 개발 범위, 위험, 주요 특징에 대한 개발팀 전체의 동의를 이끌어내는 목적을 가진다. 요구사항 워크숍을 통하여, 사용자 요구사항을 나타내는 산출물(모델, 명세서 등)을 생성하고, 핵심 이해관계자와 전문가가 참여하여 요구사항을 정제를 통하여 완성하는 회의이다.

2.2. 유스케이스

사용자 관점의 (기능적) 요구사항의 단위로써, 시스템 기능을 명확하고 일관성 있게 표현하여 개발 시스템의 기능 요구사항을 최종 사용자와 개발자 간의 합의로 결정하고 표현한다. 또한, SW 개발 이해관계자와의 의사소통 수단이자 시스템의 기능을 검사하고 검증하는 수단이 된다.

<유스케이스 다이어그램>

Ref. 소프트웨어 품질관리 실무가이드 / 프리렉

유스케이스 분석 모델링은 객체지향 분석 개발이 유행하면서 요구사항 개발에 많이 사용하게 되었다. 유스케이스는 어떤 비즈니스 업무를 완수하기 위한 액터와 시스템 간 일련의 상호작용에 대한 기술이다. 이는 시스템의 기능적인 요구사항을 추출하는 데 효율적이다.

유스케이스 분석 모델링은 표준화 그룹 중의 하나인 OMG에서 시스템의 분석 및 설계를 위한 도구로 제정한 UML(unified Modeling Language)의 유스케이스를 기반으로 시스템을 분석 및 명세화하는 방법이다.

유스케이스 다이어그램은 사용자의 관점에서 시스템의 서비스 혹은 기능 및 그와 관련한 외부 요소를 보여주는 다이어그램이다. 유스케이스는 시스템의 쓰임새로서, 시스템 밖에 존재하는 액터(Actor)라는 외부 객체가 요구하는 시스템의 기능 단위이다. 유스케이스 다이어그램은 각 액터와 그에 연관되는 유스케이스와의 관계를 나타내는 모델링 도구다. 유스케이스 다이어그램은 유스케이스와 액터의 관계를 나타내는 것 이외에는 어떠한 내용도 포함되지 않으며, 유스케이스에 대한 세부적인 시나리오나 비즈니스 로직은 유스케이스 명세서에 정의한다.

유스케이스 다이어그램은 총 4개의 요소로 구성되어 있다.

Ref. 소프트웨어 품질관리 실무가이드 / 프리렉

3. 요구사항 명세서

요구사항 명세서는 고객과 개발자 사이에 공통의 이해를 제공하고 고객과 개발자가 같은 기대와 목적을 가지게 만드는 중요한 문서이다. 동의된 의사소통과 개발의 베이스라인으로서 시스템 구현의 기반이 되고, 사용자 중심의 명세이며, 또한 고객이 최종 산출물을 인수할 때까지 테스트의 베이스라인이 되며, 변경 시 관리되어야 한다. 시스템이 어떻게(How) 수행될 것인가가 아닌 무엇(What)을 수행할 것인가에 대해 기술하여야 한다. 단, 시스템이 이루어야 할 목표를 기술하지만 목표를 달성하기 위한 해결 방법은 기술하지 않는다.

<요구사항 명세서>

Ref. 소프트웨어 품질관리 실무가이드 / 프리렉

3.1. 요구사항 명세서 표준(IEEE Std 830)

이 표준은 권고사항이지 필수사항이 아니며 조직의 환경에 맞는 명세의 테일러링이 필요하다.

3.2. 요구사항 명세 고려 사항

요구사항 명세에 반드시 포함되어야 할 내용과 제외되어야 할 내용이 존재한다.

Ref. 소프트웨어 품질관리 실무가이드 / 프리렉

<참고 문헌>

“개발자도 알아야 할 소프트웨어 테스팅 실무 3판”, STA테스팅컨설팅

“소프트웨어 테스트 실무 가이드”, STA테스팅컨설팅

“소프트웨어 품질관리 실무가이드”, 프리렉