CH 7 소프트웨어 요구사항 분석 (1)

개요!!

• 7.1 요구사항 개요
• 7.2 요구사항 분석의 중요성과 어려움
• 7.3 요구사항 분석 프로세스
• 7.4 요구사항 명세
• 7.5 요구사항 검증
• 7.6 기타

---

✅ CH 7.소프트웨어 요구사항 분석 (1)

---

🔷 7.1 요구사항 개요

7.1.1 요구사항의 정의

• 문제 해결 또는 목적 달성을 위해 시스템이 갖추어야 할 서비스 또는 제약사항
• 고객이 요구한 사항뿐 아니라 명시되지 않았더라도 반드시 제공되어야 할 사항 포함

7.1.2 요구사항의 분류

1. 기능적 요구사항 (Functional Requirements)
   • 소프트웨어가 가져야 할 기능
   • 예: 파일 저장, 편집, 보기 기능 등
2. 비기능적 요구사항 (Non-Functional Requirements)
   • 성능, 사용성, 보안, 안정성 등 품질 관련 속성
   • 예: 응답 시간, 처리량, 보안성 등

---

🔷 7.2 요구사항 분석의 중요성과 어려움

요구사항 분석의 유명한 그림ㅎ..

7.2.1 분석의 중요성

• 요구사항 분석이 정확해야 의사소통 시간 절약
• 상세한 요구사항이 있어야 규모 산정과 계획 수립 가능
• "시스템은 두 번 만들어진다 – 요구사항과 구현"
  → 첫 단추를 잘 끼우는 것이 핵심

7.2.2 분석의 어려움

1. 문제 영역에 대한 이해 부족
   • 전문성 부족, 필수 요구 누락 가능성
2. 의사소통 문제
   • 견본이 없어 설명이 어려움, 요구사항 일관성 부족
3. 변화하는 요구사항
   • 환경 변화, 사용자 지식 변화로 요구 변경
4. 애매모호한 요구사항
   • 명확하지 않아 모순되거나 불완전한 요구 도출

---

🔷 7.3 요구사항 분석 프로세스

7.3.1 개요

• 고객/발주자로부터 요구사항을 도출하고,
  개발자가 이해 가능한 형식으로 분석 및 문서화

7.3.2 분석 단계

요구사항 수집 → 요구사항 분석 → 요구사항 명세 → 요구사항 검증 → 요구사항 관리

7.3.3 요구사항 추출

• 의미: 고객의 요구를 수집하고 시스템 기능/제약을 식별
• 중요성: 초기 요구는 추상적 → 명확한 파악 필수
• 기법:
  • 인터뷰/설문조사: 직접 질문하여 정보 획득
  • 시나리오: 사용자-시스템 상호작용을 기반으로 작성
  • 관찰: 사용자의 실제 작업 관찰 → 인터뷰 보완

7.3.4 요구사항 분석

• 정의: 추출된 요구를 식별/이해 가능한 명확한 요구로 정제
• 중요성: 이후 단계 설계 및 구현에 직접 영향

분석 방법론:

1. 구조적 분석
   • 기능 중심, DFD 활용 (데이터 흐름 중심 프로세스 분석)
2. 객체지향 분석
   • 사용자 시나리오 중심, 유스케이스 모델 사용
3. 정보공학 분석
   • 데이터 중심 분석, ER 다이어그램 활용

---

🔷 7.4 요구사항 명세

7.4.1 정의 및 목적

• 분석된 요구사항을 명확하고 완전하게 기록
• 소프트웨어의 모든 기능, 제약조건, 품질사항 기술
• 최종 산출물: 요구사항 명세서 (SRS: Software Requirements Specification)

7.4.2 SRS의 역할

• “무엇”을 수행할 것인지 기술
  (“어떻게” 수행하는지는 기술하지 않음)
• 사용자/개발자/테스터 모두에게 공통 목표 제시

7.4.3 작성 시 유의사항

• 시스템 기능과 제약 조건을 빠짐없이 기술
• 간결하고 명확하게, 고객도 이해할 수 있도록 작성
• 모든 요구사항은 검증 가능해야 하며, 그 방법/기준 명시
• 특정 알고리즘/구조 언급은 피함, 외부 동작만 기술
• 계층 구조, 고유 식별자 부여, 우선순위 명시

7.4.4 명세 기법

• 비정형 명세 기법
  • 자연어/다이어그램 사용
  • 장점: 이해 용이, 작성 간단
  • 단점: 모호성, 불완전성 가능
• 정형 명세 기법
  • 수학적 표기 기반
  • 장점: 정확성, 검증 용이
  • 단점: 학습/이해 필요

---

🔷 7.5 요구사항 검증

7.5.1 정의 및 내용

• 사용자 요구가 명세서에 올바르게 반영되었는지 검토

7.5.2 검증 항목

항목 설명

무결성 / 완전성	에러 없이 요구를 완전히 반영
일관성	서로 간 모순 없음
명확성	누구나 동일하게 해석 가능
기능성	무엇을 중심으로 기술되었는가
검증 가능성	요구사항 만족 여부를 검증 가능해야 함
추적 가능성	요구사항 ↔ 설계문서 간 연결 가능해야 함

---

🔷 7.6 기타

• 요구공학:
  소프트웨어 요구사항을 정의, 분석, 명세, 검증, 관리하는 전반적인 학문
• IEEE-Std-830:
  요구사항 명세서(SRS) 작성의 표준 형식 제공