CH9. 소프트웨어 요구사항 개요 및 명세 방법

김유찬·2023년 6월 11일

소프트웨어 공학

목록 보기

8/12

■ 소프트웨어 요구사항 개요

조사결과 프로젝트 완료 이전 취소, 납기지연, 비용초과의 근본적인 원인은 부적절한 견적 및 계획과 요구관리 미흡으로 판명
프로젝트 실패 요인은 기술적보다 관리적 측면이 더 많음
프로젝트 실패 원인
-고객과의 비효율적인 의사소통으로 인한 사용자 입력 부족
-불명확하게 설정된 목표와 범위로 인한 불완전한 요구사항
-잘못된 프로젝트 계획과 추정으로 인해 변경
요구사항 및 고객참여가 시스템 개발에 있어서 성공과 실패의 가장 중요한 요소임

○ 요구사항 오류수정 비용 및 재작업

요구사항 오류수정 비용이 가장 쌈
프로젝트 요구사항의 일관성 및 완전성에 대한 결함을 사전에 제거하여 재작업을 감소시킴으로써 궁극적으로 프로젝트의 납기 달성에 긍정적인 효과 제공
일반적으로 결함이 다음 단계로 이전될 때 결함 제거 비용은 10 - 13배씩 증가 함
잘못된 요구사항 관리는 변경으로 인한 재작업을 가져옴

○ 요구사항 관리와 투입공수 및 부적정한 요구관리 적용의 위험

시스템 개발 비용은 초기단계에서 80%가 결정됨
시스템 개발의 초기단계에 시스템 요구사항을 명확하게 정의하면 cost overrun 감소
요구사항 관리에 개발노력의 10% 수준으로 투입하면 비용초과나 일정 지연이 줄어듦
요구사항 관리에 13% 이상 투자 시 비용 증가 추세가 안정화

○ 요구사항의 비밀

대부분 개발된 소프트웨어 기능의 절반은 한 번도 사용되지 않음
대부분의 시스템과 소프트웨어 프로젝트에 투입된 노력의 절반 이상은 낭비됨
고객이 기술한 요구사항이 실제 요구사항은 아님
테스트 단계에서 발견되는 결함원인의 80%는 부정확하거나 누락된 요구사항
프로젝트 성공을 위하여 참여자와의 사전노력이 필요
결함을 줄이기 위하여 Inspection 프로세스를 수행해야 함
인스펙션은 적용이 쉽고 비용이 낮지만 대부분 적용하지 않음
대부분의 프로젝트에서 좋은 의사소통 기법을 사용하지 않음

○ 요구사항 도출 개요

기능적 요구사항 + 비기능적 요구사항(사용성, 신뢰성, 성능, 유지보수성, 디자인 제약사항)
ex) 제로백이 3초였으면 좋겠어요 -> 비기능요구사항(성능), 엑셀을 밟았을 때 차가 앞으로 갔으면 좋겠다 -> 기능 요구사항
두 가지만 기억. 제약조건, 품질 속성 등이 있으면 비기능
비기능 요구사항의 품질특성 중 안전성은 우리가 흔히 아는 safety와는 다름
비기능 요구사항에서는 특히 성능에 관한 내용이 많이 나옴 ex) ATM 인출 요청은 10초 이내에 인증되어야 한다

○ 소프트웨어 품질 특성

기능성: 적절성, 정확성, 상호운영성, 보안성
신뢰성: 성숙성, 결함수용성, 복구용이성
사용성: 이해용이성, 학습성, 운영성, 기호성
효율성: 시간효율성, 자원활용성
유지보수성: 분석성, 변경성, 안전성, 시험성
이식성: 환경적응성, 설치용이성, 치환성, 공존성

○ 정확한 시스템 Goal 식별

개발 범위 정의
-product와 boundary 정의
-특정 릴리즈에 대한 범위 정의
-범위 확장 관리
gold-plate 방지
-소프트웨어 공학이나 프로젝트 관리(또한 보통의 시간관리)에서 프로젝트나 작업에서 추가적인 기능을 위해서 기존의 목적 또는 수준을 지나쳐서 계속해서 일하는것

○ 프로젝트 비전 및 범위 정의서

프로젝트 목적 및 비전
-프로젝트 발주사의 정책을 고려한 효율적인 정보화 체계구축
프로젝트 범위
-업무영역, 대상조직, 수행기간, 가정사항, 제약사항
작업단계
-적용방법론, S/W Life Cycle 등 기술
주요산출물
-방법론에 따른 세그먼트, 태스크, 산출물, 제출부수, 제출시기 등 기술
소요기술 및 자원
-본 프로젝트 구행과정에서 요구되는 요소기술 및 자원
소요 H/W 및 S/W 자원
-자원명, 세부내역 및 용도, 필요시기, 조달방법, 조달자 등을 기술
프로젝트 작업장 및 요구사항
-프로젝트 수행과정에서 필요한 OA 기기 및 기타 소모품 등에 대한 제공 방안 기술
고객 책임 수행사항
-프로젝트 수행과정에서 고객 책임 및 고객 의무사항 기술

○ 고객 중심의 요구사항 도출

사용자 관점에서 문제를 해결한다
-개발자 중심의 문제접근을 피한다
-수동적 요구사항 수집이 아닌 능동적 요구사항 도출활동을 한다
-참여자가 많을수록 더 많은 기능을 요구한다(참여자 제거)
고객으로부터 요구사항 정보를 도출한다
-지속적인 탐색과 발견의 과정
-listen carefully, ask question
사용자와 개발자가 동일한 용어를 사용한다
용어집을 작성한다
-공통의 표현법으로 기술한다

■ 요구사항 도출 기법

■ 인터뷰

관련자들과 직접 대화를 통해 상세정보 도출
적용 가능한 경우: 소수의 인원이 많은 정보를 알고 있을 때, 업무영역전문가가 존재할 때
closed interview: 많은 준비 필요, 응답자 주관적인 왜곡 방지
open interview: 관련없는 데이터 및 자료 수집의 가능성 존재, 시간과 교육 필요

● 인터뷰의 고려사항

인터뷰 전의 고려사항
-인터뷰 목적과 contextual 영역 정의
-시스템 관련지식, 공통용어 수집
-인터뷰 수행자의 특성: Bias 배제
인터뷰 중의 고려사항
-인터뷰 대상자의 말을 경청
-앞선 질문으로부터 다음 질문을 유추
-피드백과 이해를 위해 모델과 스케치 사용
종료 전의 고려사항
-종료 전에 정보요약 및 결과 설명 후 다음 질문

■ 설문서

통계적 분석기법 기반
효율적인 설문 수행: 사전질문 -> 설문
미리 정의된 질문 사용

■ 브레인스토밍

소수 인원의 그룹에 의한 의견 생성(2~5)
빠른 시간에 많은 의견을 생성
다양한 견해를 제공

■ 사용자 관찰

분석가가 고객의 일상 작업 수행과정을 관찰
활용가능 시점: 현재 시스템의 문제를 찾을 때, 고객이 알고 있지만 표현을 하지 못할 때

■ 요구사항 워크샵

주제에 대한 토론(~20명 이상)
일정 주제 기반의 의견 공유 및 합의 세션
너무 많은 인원이 아닌 최소의 연락이 참여하는 것이 바람직

● 워크샵 수행 고려사항

진행규칙을 정한다
워크샵의 수행범위를 넘지 않는다
토론팀의 규모를 작게 유지한다
기록 시 향후 고려항목을 위한 공간을 준비한다

■ 요구사항 도출 시 주의사항

What이 중요
최소의 인력

■ 누락 요구사항

CRUD 매트릭스 등으로 확인

■ 요구사항 분석 개요

요구사항 정제
추상적 요구사항을 상세화 및 합의하는 행위
요구사항 분석 활동: 모델링, 우선순위화, 선정

■ 요구사항 모델링 종류

대부분 기능요구사항에 할애
환경 모델
-시스템 영역과 외부 영역의 경계를 결정
-context diagram, use case diagram

행위 모델
-시스템과 환경의 interation 및 시스템 내부의 처리를 기술하는 diagram 관련
-DFD, ERD, Scenario, Use Case, ...

※ DFD 작성 규칙

-프로세스와 타 프로세스는 직접적인 커뮤니케이션을 할 수 없고 데이터 스토어를 통함
-프로세스명은 동사와 목적어를 사용해 명확히 정의
-하나의 다이어그램에서 8~10개 이상의 프로세스를 포함하지 않음
-DFD의 원은 대부분 I/O를 동시에 필요로 함

※STD Modeling(state transition diagram)

※ Use Case Diagram

■ 요구사항 우선순위 기법

● Analytical Hierarchy Process(AHP)

통계기법을 활용

● Value-Based Prioritization

고객의 value와 risk 중심

■ 요구사항 명세 개요

● 좋은 요구사항 명세 속성

necessary
correct
feasible
prioritized
understand
verifiable

● 전체 요구사항 문서 속성

complete
consistent
modifiable
traceable(추적성)

■ 소프트웨어 명세 및 실습

■ 요구사항 수집 방법

document-based
interview: 가장 직접적인 요구사항 습득기법, 간단, 실질적으로 모든 상황에서 적용 가능
workshop: 정해진 짧은 기간 안에 고객의 주요 요구사항을 얻을 수 있느 기법
설문조사
role-playing: 고객의 비즈니스가 매우 복잡할 경우, 고객의 입장에서 고객의 실세계를 경험하게 하여 이해를 높이고자 할 때 사용되는 기법