[SW-테스팅]요구사항 정의 및 관리

ACAI BERRY DEVELOVER·2023년 9월 12일

오늘 전문 컨설턴트 업체에서 나오신 이학우 강사님께서 요구사항 정의 및 관리에 대해 말아주셨다. 어디 컨설턴트 업체에서 오신 분인지는 수업에 늦게 참여해 확인하지 못했지만 강사님께서 명확하게 설명해주셔서 요구사항을 정의하는 것부터 관리까지 전반적으로 프로세스나 각 절차의 목표, 목적, 할 일등을 알 수 있어서 좋은 시간이었다.

나같은 신입 tester들은 회사에 들어가게 된다면 아마 요구사항을 보고 관련 테스트를 수행하거나 직접 testCase를 만드는 업무를 하게 될 것이다. 개발 초기부터 들어가 이해관계자들과 요구사항을 함께 분석하고 정의하는 업무는 사실 연차가 더 쌓여서 PM이 되거나 manager가 되면 하게 될 업무라고 한다.

그러나 요구사항에 대해 어느정도 공부가 되어있는 신입이라면 프로젝트의 전반적 흐름이나 이해도가 그렇지 않은 신입보다 더 높지 않을까 싶다.
그리하여 오늘도 수업을 들으면서 강사님만의 현업에서 얻은 경험 + 잘 짜여진 강사님의 1 day 커리큘럼을 따라 기록해보았다.

테스트 업무중에서 가장많이 수행해야 할 업무가 요구사항 테스트이다.
요구사항을 어떻게 도출하고 도출된 요구사항을 어떻게 분석해 문서화하는지 배울 수 있음.

요구사항의 중요성, 유형, 도출하는 방법, 정의서작성하는 방법을 배우는 게 이번 강의의 목표이다.

1️⃣ 요구사항 개요

⎮요구사항 개념

무엇을 개발할 것인가?

☑️ 요구사항 도출의 어려움 : 대부분의 고객들이 두루뭉실하게 대명사를 쓰면서 요구사항을 이야기한다. (체계가 잡힌 곳은 뭔가를 만들 때 SPEC을 써서 보내줌, 책으로 써서 요구사항을 보내줌 ex)항만, 무기, 항공)

고객이 요구사항을 얘기했을 때 식별하고 제대로 분석해서 구현하고 테스팅해야 한다.

<그 유명한 tree swing development meme>

⎮요구사항의 중요성

❒ 프로젝트 실패 주요 3가지 원인

stakeholders input 부족
요구사항은 뽑아내는 것도 중요하지만 이미 만들어진 요구사항에 대해 케어를 해줘야함 - 요구사항 변경에 대한 통제 상실

요구사항 변경에도 기술이 필요하다! 막 바꾸면 안된다. 정리가 안되고 뒤죽 박죽 하게 됨

불완전하거나 잘못 이해된 요구사항

프로젝트 실패 주요 원인이 주로 요구사항과 관련된 것이었다.

❒ 요구사항 획득 실패 3가지 원인

시간부족(61%)
자원부족(22%) - 돈
접근성 부족(17%) - 내 제품이 누가 사용할 지 그것을 파악하지 못하는 경우가 없다. 설문조사도 돈이다. 안한다. 그러니까 사용자식별을 못하고 개발을 한다는 말!

⎮요구사항 파악의 어려움

: 강사왈 "엄청 어렵다"
사람의 말 그대로를 받아들이는 것은 쉬운데 그 속뜻을 파악하기는 힘들다.

❒ 요구사항 제공자

요구사항 제공자 제공 주체가 명확하지 않음
요구사항제공자가 요구사항을 명확히 표현하지 못하는 경우도 있음
R&D는 레퍼런스가 없어서 고객을 특정하기가 상당히 어렵다. 대략적으로 요구사항을 쓰고 개발이 진행될 수록 요구사항을 상세화시킨다.

❒ 요구사항 변경

지식이 확대되면서
기술이 변화하면서
기대사항이 변경되면서
요구사항 내용 및 우선순위가 바뀜
:
내부 알력 다툼, 예산 끊김 프로젝트 범위가 축소가 됨, 돈은 그대론데 기간이 줄던가 , 돈은 줄고 기간이 그대로던가
이렇게 되면 개발자들은 중요한 것만 구현하고, 중요도에 따라 뺄 건 빼게 된다.
이렇게 제대로 된 요구사항을 개발자들이 파악하기 어렵다.

⎮요구사항(Requirements) 정의

요구사항 : 문제의 해결 또는 목적 달성을 위해 고객에 의해 요구되거나 표준, 명세를 만족하기 위해 시스템이 가져야 하는 서비스(기능) 또는 제약 사항
( IEEE-atd-610 )
ex) 카카오톡 - 메시지 보내기, 선물 보내기(기능) - 큰 범주로 보면 서비스

유사용어로는 요구사항, 요건, 요구도, 사양이 있다.
건설,국방은 요건이나 사양이라고 하기도 함 , 기본 통용 단어는 요구사항임

⎮요구사항 분류

구현 측면의 요구사항 분류
❶ 올바른 요구사항
❷ 잘못된 요구사항
❸ 필수적 요구사항 → 돈주는 사람이 부탁하는 거
기능적 측면의 요구사항 분류⭐️⭐️⭐️
❶ 기능적 요구사항 - 우리 제품이 수행해야할 임무
❷ 비기능적 요구사항 (성능, 품질속성 요구사항)
관리적 측면의 요구사항 분류
❶ 지속성 요구사항
❷ 휘발성 요구사항 - 특정 시점에서만 사용되는 요구사항임

⎮요구사항 vs 요구사항 관리

❖ 요구 공학
요구사항을 어떻게 식별해서 어떻게 끄집어내고 어떻게 정의할 거냐 분석, 정의 할거냐를 기술적인 학문으로 만들어 논것
소프트웨어 개발에 있어서 어떤 것이 개발되어야 하는지 결정하는 공정

요구사항 식별
요구사항 분석 및 명세
요구사항 협의
시스템 모델링
요구사항 검증
요구사항 관리

❖ 요구사항 관리
식별된 요구사항들에 대한 관리 측면의 접근

요구사항 수집 및 분석 → 명세화
요구사항의 변경관리
요구사항 추적

⎮요구공학/요구사항 정리 로드맵

요구사항 식별, 분석에서 테스팅까지 갈수록 요구사항의 모호성은 줄어들게 된다.
요구사항의 완전성은 늘어난다.
언어 정형성도 늘어난다. (식별, 분석시는 대략적 설계, 코딩시 구현을 위해 언어적 정형성은 높아짐)
초점 : 요구사항분석은 "what"이지 "how"가 아님, 설계는 "how"
how - 어떻게 할 수 있어야 한다는 설계에서 기술되어야 한다는 의미
템플릿 : SRS(시스템, 소프트웨어 요구사항정의서)- 요구사항 식별, 분석 SDD(소프트웨어 디테일드 디자인, 소프트웨어상세정의서)- 상위, 하위 설계
추적, 변경은 개발 프로세스동안 계속 이루어진다.

⎮ 요구사항 개발 절차

SWEBOK에 기술된 일반적인 요구사항 개발의 절차

❶Requirement Elicitation
❷Requirement Analysis
❸Requirement Specification
❹Requirement Validation

⎮요구사항 프로세스 모델

요구사항 프로세스는 워터폴처럼 수직선상으로 진행되는게 아니라 돌고 돌며 발전하는 사이클이다. - 요구사항 모호성이 줄고 명확해지는 이유

요구사항 프로세스는 프로젝트 초기에 시작되어 라이프 사이클을 통해 지속적으로 개선, 관리
소프트웨어 요구사항을 형상항목으로 인식, 소프트웨어 형상관리 방안을 이용해서 관리
조직과 해당 프로젝트 상황에 맞게 적용해야 함
요구사항 도출, 분석, 검증과 같은 활동들이 어떻게 다른 타입의 프로젝트와 제약조건에 따라 변경되는지 관계

시작점은 있다!
❶Requirement Elicitation 이 시작점이다.

비즈니스 요구사항 정의 (아주 초창기 요구사항)
참여자 식별
초기 요구사항 추출

⬇️ Candidate Requirements

❷Requirement Analysis

요구사항 모델링 - 검증가능성등 확인
요구사항 우선순위화 - 요구사항 줄세우기
요구사항 선정

⬇️ Agreed Requirements

❸Requirement Specification

요구사항 명세기준 정의 (요구사항 그룹핑:요구사항의 구조화)
각 요구사항을 레이어링 해서 문서화
기능 요구사항 명세
비기능 요구사항 명세

⬇️ Consistent Requirements, Formal Requirements

❹Requirement Validation

요구사항 명세 내용 검증
요구사항 명세 구조 검증
요구사항 베이스라인 설정

⬇️ Baselined Requirements
다시 요구 사항 추출단계로 순환

❺ 요구사항 변경관리

변경제어
추적 제어
버전 제어

2️⃣ 요구사항 도출 (현업에서 가장 어려운 부분)

소프트웨어 요구사항은 어디에서 나오며
소프트웨어 엔지니어가 어떻게 요구사항을 수집할 수 있으며
해결해야 할 소프트웨어 문제들을 이해하는 것이 요구사항 도출의 첫 단계.
도출훈련이 되어있지 않으면 잘 되지 않는다(소프트웨어 공학부분)
의사소통의 중요성 (근본)
소프트웨어 사용자와 개발자 사이에 원만한 의사소통
요구사항 전문가는 이러한 의사소통의 경로를 형성하고 소프트웨어 사용자영역과 개발자 영역의 중재 역할을 수행.
아직까지 요구사항 전문가를 따로 고용하는 경우는 없다.

⎮요구사항 생성 요인

❖ 목표

SW에 대한 상위레벨의 목표를 얘기함
목적성을 제대로 알 지 못하면 개발단부터 흐지부지하게 됨
기본인데 가장 잘 안지켜지는 부분

❖ 도메인 지식

요즘엔 소프트웨어에 AI 모델이 들어간다.
요즘엔 AI를 따로 빼서 소프트웨어와 동급으로 보기도 한다.

소프트웨어 엔지니어는 어플리케이션 도메인에 대한 지식을 습득하거나 이해할 필요가 있음

❖ 이해 관계자

사람관계가 제일 어렵다

다양한 타입의 이해관계자들의 관전을 인지하고 표현하며 효율적으로 다룰 필요가 있다.
사용자와 고객은 다르다.
고객의 입장, 실 사용자의 입장, 중소기업의 설계자들의 입장들이 다 있다.
요구사항을 정의, 분석할 때는 이해관계자들을 잘 식별해 관련된 이들의 의견을 종합해 정의해야 한다.

❖ 운영환경

서버, CPU, 메모리, 클라우드등.. 운영환경이 상당히 큰 고려요인으로 뽑힐 수있다.

❖ 조직환경(엄청 중요하다)
조직환경이 총체적인 말일 수 있는데 가장 첫번째 고민해야 할 것은 "규정"이다.
국가 규정, 수출해야 할 해외국가 규정, 회사별 성격 환경 등 규정이 있다.
이런 것들이 다 고려되서 요구사항에 반영되어야 한다.

요구사항 도출 기법

❖ 인터뷰/설문 (= 돈 , 시간 )- 효과적, 효율적인 방법, 고객과 1:1 /효용성은 있을 수 있으나 요구사항 도출 시 크게 도움은 안된다. 개발 후단에서 만족도 조사, 사용도 조사에서는 설문지 기법이 조금더 효율적
❖ 요구사항 워크샵 = 브레인 스토밍 가능
❖ 브레인 스토밍
❖ Prototype = 스타트업이 많이 사용,
스타트업 : 돈, 시간, 인력 x, 최대한 빨리 제품을 내어 피드백을 받고 개선하고 팔아야함.
기능만 만들고 껍데기를 씌어놔서 고객들에게 제공해 피드백을 받아 발전시킴
애자일이 이거에 가깝다. 기능만 뽑아서 주,달별로 제공함.= 린 방법론이라고도 함 (애자일쪽 한 방법)

❶ 요구사항 도출 기법 - 인터뷰

가장 중요, 직관적인 요구사항 수집 기법
어떤 상황에서도 사용할 수 있는 단순, 직접적인 방법
고객과의 대화에서 이해의 차이가 존재해 어려움
Context-free interview : 소프트웨어 개발 도메인에서 사용자나 관계자의 요구사항을 도출하는데 사용될 수 있는 구조적인 인터뷰 방법
잠재적인 솔루션에 대한 어떠한 고려도 배제하고 사용자의 문제에만 집중
쓰느니 녹음이 최고다.

❷ 요구사항 도출 기법 - 워크샵

❒ 요구사항 식별을 위한 방법 중 가장 효과적인 방법

모든 핵심 관계자들이 모여 집중적으로 요구사항 식별 및 리뷰활동을 수행
짧은 기간 동안 진행

❒ 장점 :

프로젝트의 성공이라는 목적 달성을 위한 효율적인 팀 구성에 도움
응용 시스템이 무엇을 해야 할지에 대해 관계자들과 개발자들간의 합의 가능
공동의 목표 의식을 가질 수 있음 (워크샵의 주 목적)
합의를 위해 동의록을 쓰기도 함... 책임분담도 가능
프로젝트 성공을 방해하는 정치적인 이슈들을 찾아내고 해결 가능
Feature 수준의 초기 시스템 정의가 즉시 가능
(초기에 대략적으로 밑그림이 그려져야 함 - 논의를 통해 정의가능 )

❒ 리더 선정 (중요)

요구사항 관리 프로세스에 대한 경험이 있는 외부 인력을 선정
회의를 도전적으로 이끌어갈 수 있는 역량을 가진 사람

3️⃣ 요구사항 분석 = 도출 된 것을 사용할 수 있게 가공한다.

요구사항 분석

❖ 정의 : 참여자들로부터 추출된 불완전하고 비 정형적인 추상적 요구사항을 명세서가 생성되기 이전에 완전하고 일관성 있는 요구사항으로 만들기 위한 것

❖ 요구사항 분석 기준 :

일할 때는 기준이 필요함, 기준이 목표가 될 수 있음 즉 요구사항 분석 시 기준과 목표가 있어야 함
고객이 준 요구사항 1~10을 분석기준에 따라 분석하고 명세해서 설계로 넘겨야 함
분석은 시스템을 계층적이고 구조적으로 표현해야 함

요구사항 기준 : feasibility(실행할 수 있음)평가 , 운영환경에 대한 평가, 검증가능성 평가 (testability검증, test방법)

요구사항 분석 - 요구사항 분석 활동

❖ 요구사항 분석 활동

잘못된, 요구사항의 충돌, 모호한 요구사항, 중복, 비현실적 요구사항이 발견 시 즉시 변경요구를 통하여 수정해야함
분석 단계에서의 관리 활동

❖ 목표 분석

완전성/일치성, 표준 적합성, 요구사항 충돌, 기술적 에러, 모호한 요구사항 등에 대한 검증을 수행
먼저 분석가가 시스템을 기본적으로 이해하고 개발 범위와 시스템에서 분석될 기능을 결정

구조적 분석 - 기능 중심으로

✔︎ 현장 SW/Sys 요구사항 분석 과정

❶ 목표 : 구조기반/객체지향으로 분석
❷ 구조화 : 개발자가 이해할 수 있게 구조화, 체계화 , 요구사항을 -> Sys req, SW req... 으로 변환,이렇게 계층화를 시키면 기능/비기능으로 묶음, + 외부I/F(우리가 개발하려고 하는 제품 말고 외부의 제품 , 우리의 제품과 데이터를 주고받는 제품)도 확인해서 구조화
후 대략적 요구사항 리스트가 나옴
❸ 기준 : 구현가능성, 검증가능성, 기술복잡도, 운영환경을 기준으로 세워 요구사항을 각각 하나 하나 평가함

❹ 명세 : 위에 거를 문서화함

4️⃣ 요구사항 명세

요구사항 리스트
요구사항 도출서 = 맨 초기에 고객 요구사항을 받아 원초적으로 작성한 문서
요구사항 분석서 = 명세서에 있는 내용을 분석한 것
요구사항 정의서(S&S) = 앞의 내용을 전부 총괄한 것
정부사업은 이걸 다 따로 따로 갖고 있고 그 외 요즘 회사는 S&S를 갖고 있다.

❖ 기능 & 비기능 & 인터페이스 요구사항

❶ 고객/ 이해관계자 - 도출
❷ 사용자 요구사항 - 변환
❸ 시스템 요구사항

요구사항은 해결책이 아니다.

초기 요구사항은 니즈, 기대사항, 해결책이 섞여 기술되는 경향이 있음
종종 실제 문제도 아니며, 최선책도 아님
해결책과 무관한 실제 문제를 찾아내야 함

요구사항 분류

❶ 사용자 요구사항

인터페이스 , 기능, 비기능 요구사항

❷ 소프트웨어/시스템 요구사항

인터페이스, 기능, 성능 , 속성 요구사항(=품질요구사항으로 신뢰, 사용, 유지보수,이식성 )

명세 do/don't

회피구조("꼭 필요하다면") 쓰지 않기
애매한 단어/용어 쓰지 않기 - 통상, 일반적으로, 자주, 보통, 전형적으로 = 소프트, 시스템 요구사항에서 쓰면 안됨 , 정량적으로 써줘야 함!!
희망적인 생각 ("100% 신뢰할 수 있는" 등 ) x
추측 요구사항 don't
시험 가능한 요구사항 O
단순하고 직결되는 요구사항 O

요구사항 관리

요구 사항 관리 필요성

통제되지 않은 요구사항 변경

일정, 비용증가
고객 불만족
사업기회 상실

• 1 :10 :100
요구사항 분석 단계에서 결함 발견시 비용시 적게 들어감 - 설계 구현시 10배정도 - 서비스 오픈시 100배가 들어감

요구사항 변경의 원인

내부 : 요구사항제공자를 파악하지 못함, 요구사항이 초기에 적절히 정의되지 않음
고객 : 나중에 새로운 요구사항을 추가함, 요구사항을 정확히 해석하지 않음
환경 : 기술 개발이 프로젝트를 앞서 나감, 기대한 기술이 늦게 개발됨, 자원 부족으로 프로젝트 범위가 축소됨

요구사항 변경 관리 방법

규모가 있거나 SI성 사업을 하는 기업은 요구사항 변경관리가 매우 중요하다.
• SI = 고객의 니즈를 받아 고객에 회사에 가서 직접 개발, 운영하는 것
• 운영관리단에서도 계속 요구함

베이스라인을 유지하라
각각의 베이스라인 지점을 만들자
버전 유지하고, 베이스라인 변경 시 그 내용을 공유함
변경 요청을 공식적으로 처리하라
변경 영향 평가하고 승인을 받음, 공식적이란 건 어길 시 처벌할 수 있는 근거를 줌
변경 후 관련 문서를 변경하라
요구사항추적표 활용

변경은 일어나기 마련이다 !

요구사항은 SW 개발 중 항상 변경된다.

⭐️ 요구사항 변경 관리 프로세스 ⭐️

⭐️ Software Requirements Tracking Spreadsheet = 요구사항 추적표 ⭐️

정의한 모든 요구사항을 다 구현했는가
제품/서비스가 오픈했을 때를 대비(결함발견 시 역추적하기 위해 추적표가 필요함)
요구사항이 많아지면 많아질수록 (변수조합때문에) 툴을 많이 사용한다. (ex. 레드마인에서 구현 가능 (Task = 요구사항으로 정의) + 플러그인을 써서 추적표처럼 만들 수 있음, 요구사항 관리툴도 있음 )
비행기나 자동차는 최후의 케이스까지 고려해야 함. 추적표를 중요하게 생각함
추적표를 쓰지 않으면 인증을 안내줄 정도 (상당히 중요함)
요구사항관리 툴을 사용하지 않으면 doc 문서나 엑셀을 사용함.
doc 파일 = 요구사항 아이디/요구사항/관련 UR = 요구사항 고정 테이블 (관리자입장에선 번거로움 , 파일 무게등 )
그리하여 요즘은 엑셀로 많이 사용 (골자는 doc와 비슷)
중요도/우선순위를 기록해놓으면 WBS 를 통해 어떤 기능, 모듈을 먼저 구현할지 계획이 수립가능하다.

++ 필자는 아직 정확히 어떤 도메인이 하고 싶은지 어떤 테스팅을 잘 하는지 알지 못한다. 같이 수업듣는 분들 얘기 들어보면 게임QA나 가전제품테스팅에 관심이 있다고 얘기를 많이 하신다. 하지만 난 아직 어떤 경험도 없고, 사실상 개발자를 희망하다 좌절되서 tester로 틀어버린 케이스라 딱히 test에 관심이 있어서 여기에 발을 들인 건 아니였다.

그런데 이 교육과정을 들으며 tester란 직업에 대해 알게 되면 알게 될수록 매력적인 직업이란 생각이 들었다. 우선 tester는 나이가 들어서까지도 일을 할 수 있다. 또한 AI가 IT업계를 커버해가고 있어도 이 tester란 직업은 사라지지 않는다. (AI도 우리가 검증하니까...) 단적인 예를 들어 성능이나 코드관련된 테스팅들은 점차 AI에 의해 커버되겠지만 사용자테스팅과 같은 휴먼 인터페이스 분야는 AI가 할 수 없는 영역이기에 앞으로도 tester의 직업의 중요성은 대두되면 더 대두되지 소멸되지 않을 거라는게 현업에 계신 전문가들의 입장이다.

또한 나이가 들어도 할 수 있는 직업이라 생각하는 것은 이쪽 분야가 테스트 수행을 넘어서 컨설팅이나 교육등 다른 방향으로도 진출할 수 있기 때문이라 생각이 되어지기 때문이다.
오늘 강사님은 컨설팅 펌에서 근무하시는 분이시고, 경력을 여쭤봤다. 경력은 10년정도 되셨고 전공이 경영쪽이라고 말씀하셨다. 처음부터 컨설팅펌에 들어가셔서 근무하신 케이스고 정확히는 품질쪽 컨설팅을 맡고 계신다고 하셨는데 사실 컨설팅도 프로세스, 품질, 테스팅 이렇게 있다고 말씀하셨다. 품질 쪽에 계시는 거 같다(사실 기억잘 안남)

ACAI BERRY DEVELOVER

쓸때 대충 쓰지 말고! 공부하면서 써!

이전 포스트

ISTQB 전반적 시험 개요

다음 포스트