6.소프트웨어 공학 요구분석 (1)

1. 요구사항

요구사항의 정의

• 사전적 정의: ‘이용자가 어떤 문제를 풀거나 목표를 달성하는 데 필요한 조건이나 능력’
• 소프트웨어 개발에서의 정의: 사용자와 개발자가 합의한 범위 내에서 사용자가 필요로 하는 기능, 시스템이 제공하는 기능 요구와 품질과 같은 비기능 요구로 나뉨
• 요구사항이 정확히 무엇인지 파악하는 작업은 요구분석 단계에서 이루어짐

2. 요구분석의 정의와 목적

요구분석의 정의와 목적

집짓는 과정의 예시

• 집을 지으려는 사람은 본인이 수집한 자료와 구상한 내용을 토대로 건축 설계사에게 어떤 집을 짓고 싶은지 설명
• 본인이 가지고 있는 예산과 언제 입주하고 싶은지, 건축에 필요한 제반 사항 등에 대해서도 이야기를 나눔
• 이 과정에서 고객은 어떤 건물을 원하는지 충분히 설명할 수 있고 건축 설계사는 고객이 원하는 것을 설계 도면에 빠짐없이 반영할 수 있음

요구분석의 정의와 목적

요구분석의 정의

• 컴퓨터 용어사전: 시스템이나 소프트웨어의 요구사항을 정의하기 위해 사용자 요구사항을 조사하고 확인하는 과정
• 요구분석은 소프트웨어 개발 성패의 열쇠

요구분석의 목적

• 목적사용자에게서 필요한 요구사항을 추출해 목표하는 시스템의 모델을 만들고 요구분석명세서를 작성하기 위해서

  요구분석명세서

• 요구분석 단계에서 생성 되는 최종 산출물로 시스템의 기능이 무엇인지(what)에만 초점을 두고 정리
• 요구분석단계 후 설계 단계에서는 설계서가 만들어지는데 이 문서는 어떻게(how) 구현할지 기술

요구분석 관련자(대학 학사관리시스템 개발의 예시)

• 발주사: 외주 방식으로 학사관리시스템 개발을 의뢰한 A대학교
• 경영자(총 책임자): 학사관리시스템 개발을 결정한 A대학교 총장
• 발주 담당자: 학사관리시스템 개발을 외주로 진행하는 모든 절차를 준비하는 담당자
• 사용자: 외주 방식으로 개발된 학사관리시스템을 실제 사용하는 사람 (학생, 교수, 조교, 학사담당직원 등)
• 수주사: A대학교의 학사관리시스템 개발을 위한 응찰 경쟁에서 이겨 개발이 결정된 업체 (B개발사)
• 분석가: 사용자 요구사항이 무엇인지 파악하고 추출 및 정리하는 것까지 담당
  • B개발사의 분석가는 A대학교를 방문해 현행 시스템 의 현황과 문제점을 파악하고 새로운 요구사항을 수집해
  • 최종 산출물인 요구분석명세서를 작성
• 설계자: 요구분석명세서를 바탕으로 아키텍처 설계, 모듈 설계, 데이터베이스DB 설계, 사용자 인터페이스 설계 등을 담당
• 개발자: 넓은 의미에서 개발자는 학사관리시스템 개발에 참여하는 B개발사의 분석가, 설계자, 프로그래머 등을 포함 (좁은 의미에서는 프로그래머)

요구분석의 어려움

문제 영역에 대한 분석가의 이해력 부족

• 법적인 문제를 해결할 경우 해당 분야에 전문적인 변호사를 선임
• 요구분석가는 IP 분야의 전문가라 문제 영역(회계 분야, 금융 분야, 기업의 통합관리 등)에 대한 이해력이 부족할 수 있음
• 사용자 요구를 잘못 이해한 채 분석해 필수 요구사항을 빠뜨릴 수도 있음
• 이런 문제를 최소화하려면 문제 영역과 관련된 프로젝트를 개발한 경험이 많은 분석가를 투입하는 것이 바람직

사용자와 분석가의 의사소통 문제

• 소프트웨어 개발에서는 견본이 없는 경우가 대부분이므로 사용자가 분석가에게 요구 사항을 설명하기가 어려움
• 원하는 바를 분석가에게 어떻게 설명해야 할지 잘 모름
• 필요한 요구사항은 반영하지 못하고 불필요한 사항만 포함되기도 함
• 의사소통 문제는 개발자 간에도 있을 수 있음

사용자의 계속되는 요구사항 추가

• 사용자의 처음 요구는 단순하고 간단할 수 있지만 분석가와 대화 후 점점 새로운 생각이 늘어나거나 관련 지식이 늘어남
• 그에 따라 새로운 요구가 생기고 요구사항이 계속 추가될 수 있음
• 소프트웨어 개발 과정 중에 목표 환경이 달라지면서 요구사항이 변경되기도 함

사용자의 모호한 요구사항

• 사용자는 분석가에게 모호하게 요구사항을 전달하면 분석가가 해석할 수 있는 여지가 많으므로 오해로 인한 문제가 발생
• 세부적인 내용을 전달하지 않는다면 분석가는 세부적인 요구사항을 본인의 경험에 비추어 해석해 사용자의 의도와 달라짐
• 부서 간의 요구가 서로 어긋나고 경영진, 실무자의 요구가 상반되어 일관성이 없고 모순되는 요구사항이 발견될 수 있음
• 분석가는 이러한 요구를 정리해서 반영 하기 위해 이해 당사자 간의 주장을 조율해야 함

요구사항 수집

자료 수집

• 가장 먼저 할 일은 A대학교의 현행 시스템에서 모든 업무의 입력 화면과 출력물을 받아 기본 기능을 분석하는 것
• 관련 직원으로부터 현행 시스템의 문제점과 개선점, 새로 추가되어야 할 요구사항을 파악

인터뷰

• 가능하면 먼저 자료를 수집한 후 이를 정리해 분석한 결과를 바 탕으로 각 부서 담당자를 인터뷰하는 것이 효율적
• 미리 받은 자료를 토대로 대화를 해야 큰 줄기를 흩트리지 않고 계획대로 진행할 수 있음
• 오랜 시간 동안 대화하기보다는 핵심 요구사항을 빨리 습득하는 것도 능력

설문 조사

• 설문 조사를 통해 또 한 번의 요구사항을 도출할 수 있음
• 중요한 것은 효율적인 설문 조사를 위해 설문 문항을 잘 만들어야 한다는 것

---

3. 요구분석 절차와 요구사항 종류

요구분석 절차와 요구사항 분류

요구 분석 절차

❶ 자료 수집   현행 시스템의 문제점 도출, 실무 담당자 인터뷰, 현재 사용하는 문서 검토 등을 통해 가능한 모든 자료를 수집

❷ 요구사항 도출   수집한 자료를 정리해 적절히 분류하고 개발에 반영할 요구사항을 도출

❸ 문서화   도출한 요구사항을 요구분석명세서로 작성

❹ 검증   요구분석명세서에 사용자 요구가 정확히 기록되어 서로 모순되는 사항은 없는지, 빠뜨리지 않고 전부 기록했는지 등을 점검

요구 분석 분류

• 사용자 요구사항은 개발될 소프트웨어가 제공할 기능 요구사항과 성능, 제약 사항, 품질과 같은 비기능 요구사항으로 분류

기능 요구사항

• 사용자가 원하는 기능
• 사용자는 시스템을 통해 기능을 제공받기 바라며 시스템은 사용자에게 필요한 기능을 제공
• 사용자가 원하는 기능은 요구분석명세서에 완전하고 일관성 있게 표현해야 하며 시스템에도 전부 반영
• 완전성: 사용자가 원하는 모든 기능이 포함  /  일관성: 요구사항 간에 모순이 있어서는 안 됨

비기능 요구사항

비기능 요구사항의 개요

• 수행 가능한 환경, 품질, 제약 사항 등을 말함
• 비기능 요구사항이 매우 중요한 소프트웨어에는 군사 무기나 의료 장비 등이 해당

제약 사항

• 개발 소프트웨어가 수행될 환경에 의한 조건

  예시)

• 자바 언어를 사용해 개발하고, CBD 개발 방법론을 적용해야 함
• 레드햇 리눅스 엔터프라이즈 버전에서 실행해야 함
• 웹 로직 서버를 미들웨어로 사용해야 함
• 윈도 운영체제와 리눅스 운영체제에서 모두 실행할 수 있어야 함

기능

신뢰성

• 소프트웨어에서의 신뢰성: 소프트웨어를 믿고 사용할 수 있는 것
• 일반적으로 신뢰성은 신뢰도로 나타내며 신뢰도는 장애 없이 동작하는 시간의 비율로 나타냄
• 소프트웨어를 1,000번 수행했을 때 오류 없이 동작하는 횟수가 999번인 경우: 99.9%

• 1,000시간 작동하는 동안 1시간의 장애가 있었던 경우: 99.9%(신뢰도 측정은 가용성(이용 가능성)을 척도로 사용)

• 신뢰도 높은 소프트웨어의 조건
  • 시스템에 오류가 있더라도 고장을 일으키지 않고 회피할 수 있는 능력이 높아야 함
  • 고장이 발생하더라도 이전 수준으로 성능이 회복되어야 함
  • 고장으로 영향을 받은 데이터들이 정상적으로 잘 복구됨

가용성

• 소프트웨어가 총 운용 시간 동안 얼마나 정상적으로 고장 없이 가동되었는지를 비율로 나타냄

MTBF(평균 정상 작동 시간 또는 고장 간 평균 시간)

• 고장이 나서 수리 후 정상 작동 하다가 다시 고장이 날 때까지 작동한 시간
• 정상 작동 시간의 합을 횟수로 나눈 값
• MTBF와 비교되는 개념으로 고장까지의 평균 시간 (고장은 수리가 불가능한 상황에 해당)

MTTR(평균 수리 시간)

• 수리 시간의 합을 횟수로 나눈 값
• 수리 시간: 고장 시점에서 수리가 완료되어 재가동되는 시점까지의 시간