04_요구 분석

0. 요구 분석 단계 개요

• 요구 분석 단계
  • 소프트웨어 개발의 실질적인 첫 단계
  • 사용자의 요구를 이해하고 조정하는 작업

단계	설명	산출물
1. 요구 추출	기능 요구 / 비기능 요구 추출	요구
2. 도메인 분석	요구에 대한 정보와 배경 분석	도메인 정보
3. 모델링	다이어그램을 통한 개념화	모델
4. 프로토타이핑과 시험	분석된 기능의 타당성 시험	요구 분석서
5. 문서화	요구 분석서 작성	—

1. 요구

1.1. 요구의 정의

• 요구 (Requirements)

  • 시스템에 대한 고객의 요청을 확정한 것

  • SW개발 관점: 사용자와 개발자 간에 합의한 개발 범위에서 시스템이 제공해야 하는 기능

  • 진정한 요구를 찾는 일 = 프로젝트 성공의 필수 조건

  • 여러 **이해 당사자(stakeholder)**의 이해 관계와 관련

1.2. 요구의 분류

(1) 기능 요구

• 기능 요구 (Functional Requirements)
  • 시스템이 외형적으로 나타내는 기능과 동작
  • 동사로 표현, 쉽게 파악됨 → 유스케이스로 정리
  • ATM 예: 현금 인출, 잔금 조회, 계좌 이체, 현금 서비스
  • 표현 방식: “시스템은 …을 해야 한다”

분류	핵심 질문
기능	시스템이 무엇을 언제, 어떤 모드로 하는가?
자료	입출력의 형태, 정확도, 보관 기간은?
입출력	외부 시스템과 주고받는 데이터는?
사용자	누가, 몇 그룹이, 어떤 경험으로 사용하는가?

(2) 비기능 요구

• 비기능 요구 (Non-Functional Requirements)

  • 시스템이 제공하는 기능에 직접 관련되지 않은 요구
  • 환경, 품질, 제약사항에 대한 요구
  • 형용사로 표현, 파악하기 어려움 → 품질 속성 시나리오로 정리

• 제약 사항 (Constraint)

  • 이미 이루어진 설계 결정으로 자유가 없음
  • 예: “자바 언어로 개발해야 한다”, “윈도우/리눅스 모두 실행 가능해야 한다”

품질 속성	설명
신뢰성 (reliability)	주어진 시간과 환경에서 고장 없이 사용 가능
성능 (performance)	응답 시간, 처리량 등 사용자 조건 만족
보안성 (security)	미인증자의 시스템 접근 차단
안전성 (safety)	SW 오류로 인한 인명 피해 방지
사용성 (usability)	혼란 없이 편하게 사용할 수 있는 편의성

• 품질 달성 전술
  • 신뢰성: 결함 탐지·복구·방지 (모니터, 활성 다중화, 예외 처리)
  • 성능: 동시성 증가, 리소스 증설, 데이터 복사본 유지
  • 보안성: 침입 탐지, 데이터 암호화, 접근 취소, 감사 추적

2. 요구 추출

• 요구 추출(Requirement Elicitation)의 세 가지 단계
  1. 요구에 대한 정보 출처 파악
  2. 요구에 대한 정보 취합
  3. 요구와 제한 사항의 정의

2.1. 요구 정보 출처

출처	설명
고객	프로젝트를 발주한 당사자
도메인 전문가	비즈니스 도메인 지식 보유자 (예: 회계사)
이해당사자 (stakeholder)	시스템 운용으로 영향 받는 사람
사용자	시스템을 직접 사용하는 사람
역공학	레거시 시스템, 현재 문서 분석

2.2. 정보 수집 방법

1. 고객의 발표

   • 개발팀이 시스템에 대한 초기 개념을 파악
   • 업무 책임자나 관리자가 발표 / 2시간 이내 권장

2. 문헌 양식 조사

   • 유사 프로젝트, 업무 문서, 산업 표준, 정부 정책/규제 조사

3. 인터뷰

   • 형식: 정형 (사전 질문 설정) / 비정형 (자유 대화) / 부분 정형 (가장 일반적)
   • 절차: 대상자 선정 → 일정 계획 → 질문 작성 → 인터뷰 → 분석 및 정리

4. 설문

   • 다양한 이해당사자 대상 / 무기명 설문으로 숨겨진 정보 도출

5. 브레인스토밍 (Brainstorming)

   • 훈련된 요원 주재, 아이디어를 쏟아내는 회의, 익명성 보장
   • JAD(Joint Application Development): 개발자와 사용자가 격리된 장소에 모여 집중 세션

6. 프로토타이핑

   • 최종 시스템의 일부 기능을 빠르게 구현 → 고객 피드백 조기 획득
   • Paper Prototype: 그림으로 흐름을 표현한 가장 단순한 형태
   • Mockup UI: 프로토타이핑 전용 언어로 UI 작성 (가장 흔한 형태)

3. 요구 분석

3.1. 요구 품질

품질 속성	설명
원자적 (atomic)	단일 목적만 표현
완전성 (complete)	정보의 모든 것을 포함
비모호성 (unambiguous) + 통일성 (consistent)	명확하게 표현
추적성 (traceable)	추적 가능한 고유 번호 부여
우선순위화 (prioritize)	중요도 파악
테스트 가능성 (testable)	검증 가능하도록 기술

3.2. 도메인 분석

• 도메인: 요구의 비즈니스 배경

• 목표: 요구의 비즈니스 배경을 이해해서 개발될 시스템을 설명하는 개념 정의

• 도메인 분석 3단계

  1. 도메인 개념 찾기: 비즈니스 배경을 SW에 필요한 용어들로 정의 (객체, 프로세스)
  2. 도메인 사전 작성: 사용된 용어들을 간결하게 정의
  3. 비즈니스 규칙 정리: 절차, 가이드라인, 표준

3.3. 시나리오 기반 분석

• 5W1H 원칙으로 표현

  • 언제(when), 어디서(where), 누가(who), 무엇(what), 왜(why)
  • 어떻게(how)

• 사용자 스토리 (User Story)

  • 애자일 방법에서 사용
  • 형식: <사용자>는 <목적>을 위하여 <기능>를 원한다

4. 유스 케이스

4.0. 모델링 개념

요구 사항 표현 - 모델링

요구 분석: 요구 만족을 위해 시스템에 구현할 것들을 골라 요구로 정의하는 작업
모델링: 요구 만족을 위해 시스템이 가져야 할 기능·동작·구조를 표현하는 작업

• 모델링 (Modeling)

  • 복잡한 문제를 추상화(Abstraction)를 통해 간단하게 표현하는 기법
  • UML(Unified Modeling Language): 소프트웨어 모델링의 공통 언어

• 모델링 구성 요소

  • 표현(Representation): 시각적으로 도식화
  • 규약(Convention): 기호(Symbols)에 대한 약속
  • 명세(Specification): 도식화된 내용을 텍스트로 서술

4.1. 유스케이스 다이어그램

• 시스템의 기능을 나타내기 위해 사용자 요구를 추출·분석하는 데 사용

구성 요소	설명	표기
사용 사례 (Use Case)	시스템에서 제공하는 단위 기능	타원
액터 (Actor)	시스템과 상호작용하는 모든 것 (사용자, 시스템)	막대 인형
연관 (Association) 관계	액터와 유스케이스의 상호작용	실선

4.2. 유스케이스 사이의 관계

1. 포함 (Include) 관계

   • UC1이 실행될 때 UC2가 반드시 실행되어야 동작하는 관계
   • 표기: UC1 ----<<include>>--→ UC2 (점선 화살표)

2. 확장 (Extend) 관계

   • UC3이 특정 상황에서만 UC4를 실행할 수 있는 관계
   • 표기: UC4 ----<<extend>>--→ UC3 (점선 화살표, 방향 주의!)

3. 일반화 (Generalization) 관계

   • 부모-자식 유스케이스 간의 상속(Inheritance) 관계
   • 자식 → 부모 방향으로 삼각형 실선 화살표

4.3. 유스케이스 모델링 단계

단계	내용
1단계	시스템 상황 분석 → 문제 기술서 작성
2단계	액터 식별 (역할 이름 사용, 특정인 이름 X)
3단계	유스케이스 식별 (액터 관점에서 시스템 기능 파악)
4단계	유스케이스 다이어그램 작성 (관계 설정: include / extend / 일반화)
5단계	유스케이스 명세서 작성 (기본 흐름 / 대안 흐름 / 예외 흐름)

• 액터 식별 시 확인할 질문들
  • 시스템 주요 기능을 사용하는 사람은?
  • 시스템 기능을 지원하기 위해 필요한 사람은?
  • 시스템을 유지·관리하는 사람은?
  • 시스템과 상호작용하는 다른 시스템은?

5. 요구 명세

요구 사항 문서화

5.1. 요구 분석 명세서 (SRS)

• 요구 분석 명세서 (SRS; Software Requirement Specification)
  • 산출물 중 가장 중요: 사용자, 설계자, 개발자, 테스터 모두의 공통 목표 제시
  • What을 기술 (어떻게가 아님)
  • IEEE Std. 830 표준 준수

SRS 목차	주요 항목
1. 소개	SRS의 목적, 제품의 범위, 정의·동의어·약어, 참조문서, 개요
2. 일반적인 기술사항	제품 개관·기능, 사용자 특성, 제약사항, 가정 및 의존성
3. 상세한 요구사항	외부 인터페이스, 기능요구, 성능요구, 논리 DB, 설계 제약사항 등
4. 추가 정보	목차, 색인

• Gilbert의 요구 분석서 작성 주의사항
  1. 사용자와 개발자 모두가 쉽게 이해할 수 있도록 작성
  2. 기술된 조건은 양측이 모두 동의한 것이어야 함
  3. 목표 시스템이 수행할 모든 기능을 정확히 기술
  4. 목표 시스템에 영향을 주는 모든 제약 조건을 기술
  5. 시스템 인수를 위한 테스트 기준 제공
  6. 원하는 시스템의 품질과 중요도 및 측정 방법 기술

5.2. 요구사항 검증 항목

검증 사항	설명
이해용이성 (comprehensibility)	요구 명세서의 의미를 잘 이해할 수 있는가?
중복 (redundancy)	필요 없이 중복된 부분이 없는가?
완전성 (completeness)	빠진 요구나 정보가 없는가?
일관성 (consistency)	요구사항이 서로 모순되지 않는가?
모호성 (ambiguity)	모든 참여자가 명확하게 이해할 수 있는가?
검증 가능성 (verifiable)	요구사항 분석 내용과 개발 시스템이 일치하는지 검증 가능한가?
추적 가능성 (traceable)	설계문서 및 구현과 매핑되어 추적할 수 있는가?