SW공학 - 요구사항 분석 알아보자.

사용자의 필요를 제대로 이해하고 개발로 옮기는 첫 단추

 

 

 

오늘은 요구사항 분석에 대해 알아보자.

오늘의 배움

요구사항의 정의와 유형 요구사항 분석의 단계 요구사항 명세 및 관리 기법

---

1. 요구사항 분석

 

• 정의: 소프트웨어 시스템이 충족해야 할 기능과 제약 조건을 파악하고 문서화하는 과정
• 한 줄 요약: 사용자가 진짜로 원하는 것을 정확히 알아내고, 이를 시스템에 반영하기 위한 분석 활동
• 특징: 커뮤니케이션 중심, 반복적 수행, 이해관계자와의 협업 필요
• 필요성: 프로젝트 방향 설정, 명확한 개발 범위 규정, 개발 리스크 감소
• 과정:
  • 요구사항 개발(Requirements Development): 새로운 요구사항을 식별하고 문서화하는 과정
  • 요구사항 관리(Requirements Management): 요구사항이 지속적으로 변경될 수 있는 환경에서 이를 효과적으로 유지·관리하는 과정
• 장점/단점:
  • 장점: 프로젝트 성공률 증가, 오류 예방, 개발 시간 단축
  • 단점: 요구사항 변경에 취약, 시간과 비용 소모
• 예시:
  • 온라인 쇼핑몰:
    • 고객은 상품을 검색하고, 장바구니에 담고, 결제해야 함 → 이것이 기능적 요구사항
      → "고객은 3초 이내에 검색 결과를 받아야 한다"는 것은 비기능적 요구사항
  • 은행 모바일 앱 개발 시, 요구사항 분석 단계에서 다음과 같은 내용을 문서화:
    • 기능적 요구사항: 계좌이체, 이체 내역 확인
    • 비기능적 요구사항: 이중 인증 적용, 1초 이내 응답 시간

 

• 요구사항 분석 = 요구사항 수집 + 분류 + 정제 + 명세 + 검토
• 주요 활동: 요구사항 도출 → 분석 → 명세 → 검증
• 관련 도구: Use Case Diagram, 요구사항 명세서(SRS), 요구사항 추적표

 

---

 

2. 핵심 개념 정리

2-1. 요구사항 개발

• 정의: 소프트웨어 시스템이 수행해야 할 기능과 제약 조건을 정의하는 과정
• 필요성: 정확한 요구사항 이해는 성공적인 소프트웨어 개발의 기반
• 과정:
  1. 도메인 분석: 시스템이 속한 특정 분야의 주요 개념 분석
  2. 문제 정의와 범위 설정: 해결해야 할 문제를 명확히 정의하고, 프로젝트의 범위 한정
  3. 요구사항 추출: 사용자 인터뷰, 워크숍, 문헌 조사 등을 통해 요구사항 수집
  4. 요구사항 문서화: 수집된 요구사항을 체계적으로 정리하고 문서화
  5. 요구사항 검증 및 확인: 문서화된 요구사항이 정확하고 일관성이 있는지 검토

출처: https://amaran-th.github.io/소프트웨어 설계/요구 공학 프로세스/

• 특징: 사용자 중심적, 반복적, 협력적 프로세스
• 장점/단점:
  • 장점: 개발 방향 명확화, 리스크 감소, 변경 비용 절감
  • 단점: 초기 비용 증가, 이해관계자 의견 조율 어려움
• 예시:

# 온라인 쇼핑몰 사용자 인증 요구사항
REQ-001: 사용자는 이메일과 비밀번호로 로그인할 수 있어야 한다.
REQ-002: 비밀번호는 최소 8자 이상이며, 문자, 숫자, 특수문자를 포함해야 한다.
REQ-003: 사용자는 SNS 계정(구글, 페이스북)으로 간편 로그인할 수 있어야 한다.
REQ-004: 3회 연속 로그인 실패 시 계정은 30분간 잠겨야 한다.

---

2-2. 도메인 분석

 

• 정의: 시스템이 속한 특정 분야(도메인)의 개념을 체계적으로 이해하는 과정
• 작동 원리:
  1. 도메인 정의: 시스템이 속한 산업 또는 서비스 영역을 분석하여 도메인의 특성 정의
  2. 핵심 개념 및 용어 수집: 도메인 내에서 자주 사용되는 핵심 용어 및 개념을 정리하여 공통 이해 확립
  3. 비즈니스 프로세스 분석: 도메인의 일반적인 업무 흐름을 파악하고, 기존 시스템의 한계 분석
  4. 도메인 모델 생성: 개념 모델 등으로 도메인의 주요 개념과 관계를 시각화
• 특징: 분야별 전문 지식 기반, 용어 정의 중심, 비즈니스 규칙 파악
• 장점/단점:
  • 장점: 시스템의 정확한 이해도 향상, 의사소통 개선
  • 단점: 전문가 의존성 높음, 시간 소요
• 필요성: 정확한 도메인 이해 없이는 적절한 시스템 설계 불가능
• 예시:

# 의료 시스템 도메인 용어 정의
- 환자(Patient): 의료 서비스를 받는 사람
- 진료기록(Medical Record): 환자의 질병, 치료, 처방전 등에 관한 기록
- 처방전(Prescription): 의사가 환자에게 처방한 약물 정보
- EMR(Electronic Medical Record): 전자 의무 기록 시스템

---

2-3. 문제 정의와 범위 설정

• 정의: 프로젝트가 해결해야 할 문제를 명확히 규정하고, 프로젝트 수행 범위를 합리적으로 한정하는 과정
• 작동 원리:
  1. 현황 분석(Current State Analysis)
     1. 현재 시스템 또는 프로세스에서 발생하는 문제점 파악
     2. 개선이 필요한 부분 정의
  2. 이해관계자 요구 분석(Stakeholder Needs Analysis)
     1. 사용자, 관리자, 개발자 등 이해관계자의 요구사항을 체계적으로 수집
  3. 핵심 문제 정의(Core Problem Definition)
     1. 분석된 문제 중 주요 문제를 선별
     2. 해결 목표를 명확히 설정
• 특징: 구체적 제약사항 정의, 시스템 경계 설정, MoSCoW 기법 활용
• 장점/단점:
  • 장점: 명확한 프로젝트 방향 설정, 범위 확대(scope creep) 방지
  • 단점: 전체 비전 제한 가능성, 지나친 범위 축소 위험
• 필요성: 무제한적 요구사항은 프로젝트 실패로 이어질 수 있음
• 예시:

# 도서관 시스템 MoSCoW 분석
Must Have: 사용자 도서 검색, 회원 대출/반납, 도서 등록 관리
Should Have: 온라인 예약, 연체료 계산, 대출 이력 확인
Could Have: 도서 추천, 리뷰 작성, 이용 통계 생성
Won't Have: 다국어 인터페이스, 전자책 대여, 음성 인식 검색

[context diagrams] https://www.geeksforgeeks.org/context-diagrams/

---

2-4. 요구사항 추출 기법

• 정의: 이해관계자로부터 시스템 요구사항을 도출하는 다양한 방법론
• 작동 원리: 다양한 기법(인터뷰, 워크숍, 관찰 등)을 활용하여 요구사항 수집
• 특징: 상호작용 중심, 다층적 정보 수집, 다양한 관점 통합
• 장점/단점:
  • 장점: 다양한 요구사항 포착, 숨은 니즈 발견
  • 단점: 시간 소요, 때로는 모순된 요구사항 발생
• 필요성: 다양한 이해관계자의 관점을 포괄적으로 수집해야 함
• 예시:

# 은행 모바일 앱 인터뷰 질문
1. 현재 모바일 뱅킹 사용 시 가장 불편한 점은 무엇인가요?
2. 어떤 기능을 가장 자주 사용하시나요?
3. 보안과 편의성 중 어느 쪽에 더 가치를 두시나요?
4. 타 은행 앱에서 도입했으면 하는 기능이 있으신가요?
5. 알림 서비스는 어떤 상황에서 받고 싶으신가요?

---

2-5. AI 서비스 요구사항 분석

• 정의: AI 시스템을 개발하기 위한 필수 요구사항을 정의하는 과정
• 작동 원리: 데이터 요구사항 정의 → AI 모델 선택 → API 및 배포 방식 결정
• 특징: 데이터 중심적, 모델 성능 지표 중요, 윤리적 고려 포함
• 장점/단점:
  • 장점: AI 시스템 특성 반영, 데이터 품질 보장
  • 단점: 일반 소프트웨어보다 불확실성 높음, 데이터 확보 어려움
• 필요성: AI 모델의 특성을 고려한 특화된 요구사항 정의 필요
• 예시:

# 고객 민원 자동 분류 AI 시스템 요구사항
1. 데이터 요구사항:
  - 최소 10,000건 이상의 레이블링된 민원 데이터 필요
  - 개인정보는 비식별화 처리 필수
  - 20개 이상의 민원 카테고리 분류 가능해야 함

2. 모델 요구사항:
  - 분류 정확도 85% 이상 달성해야 함
  - 추론 시간 1초 이내여야 함
  - 새로운 민원 유형 출현 시 모델 재학습 가능해야 함

3. API 요구사항:
  - REST API 형태로 제공
  - 초당 100건 이상의 요청 처리 가능
  - 인증 및 데이터 암호화 필수

[생성형 AI 벤치마크 점수 확인] https://www.salesforceairesearch.com/crm-benchmark

 

---

2-6. 요구사항 관리

• 요구사항 합의
  1. 요구사항 문서화 검토: 이해관계자와 함께 문서화된 요구사항을 검토하고 명확성을 확인
  2. 우선순위 설정: 기능 및 비기능 요구사항의 중요도를 평가하여 개발 순서를 정함
  3. 합의 도출: 이해관계자 간 의견 차이를 조율하고 최종적으로 승인된 요구사항을 확정
  4. 변경 관리 프로세스 수립: 이후 요구사항 변경이 필요한 경우를 대비하여 변경 관리 절차를 마련
• 요구사항 형상관리
  1. 버전 관리: 요구사항 문서의 변경 이력을 관리하여 특정 버전으로 복원 가능하게 함
  2. 변경 이력 추적: 요구사항 변경이 발생할 경우 변경 이유 및 영향을 명확히 기록
  3. 요구사항 베이스라인 설정: 특정 시점에서 요구사항을 고정하여 개발 프로세스를 안정화
  4. 요구사항 변경 승인 프로세스: 변경 사항이 발생할 경우 승인 절차를 거쳐 반영
     • 요구사항 변경 프로세스
       1. 요구사항 변경 요청이 발생한다. 고객, 기획자, 개발자 등 누구나 변경을 제안할 수 있다.
       2. 변경 제안이 접수되면 RFC(Request for Change)를 작성한다. 이 문서에는 변경 사유, 예상되는 영향, 우선순위 등의 정보가 포함된다.
       3. 작성된 RFC를 바탕으로 영향도 분석을 수행한다. 이때 기술적인 가능성, 일정이나 비용에 대한 영향, 발생할 수 있는 리스크 등을 검토한다.
       4. 분석 결과를 바탕으로 변경 검토 회의를 진행한다. 관련된 팀원이나 이해관계자가 모여 변경 여부를 판단한다.
       5. 회의 결과에 따라 승인 또는 거절이 결정된다. 승인되면 문서에 반영하고, 거절되면 요청을 종료하며 로그를 기록한다.
       6. 마지막으로, 승인된 변경사항을 문서에 반영하고 버전을 업데이트한다. 이때 Git, Jira, DVC 등 형상관리 도구를 사용하여 변경 사항을 체계적으로 관리한다.
• 요구사항 이력추적
  1. 추적 매트릭스 작성: 요구사항과 해당 기능 또는 테스트 케이스 간의 연관성을 문서화
  2. 변경 이력 기록: 변경된 요구사항과 그 영향을 추적하여 기록
  3. 요구사항 검증: 구현된 기능이 초기 요구사항을 충족하는지 테스트 및 검토
  4. 이해관계자 보고: 변경 내역과 추적 결과를 이해관계자에게 보고하여 검증 절차 진행
• 요구사항 추적 매트릭스 (RTM, Requirement Traceability Matrix)
  • 소프트웨어 개발 생애 주기 동안 요구사항의 추적성을 보장하기 위해 사용되는 도구이다.
  • 각 요구사항이 설계, 개발, 테스트 등의 단계에서 어떻게 반영되었는지를 추적하고, 요구사항이 제대로 구현되고 있는지 확인하는 데 도움을 준다.
  • 구성 요소
    1. 요구사항 ID: 요구사항을 고유하게 식별할 수 있는 번호나 코드
    2. 요구사항 설명: 각 요구사항에 대한 간단한 설명
    3. 설계 문서: 요구사항이 설계 문서에서 어떻게 반영되었는지
    4. 개발 문서: 요구사항이 코드나 기능 구현에서 어떻게 반영되었는지
    5. 테스트 케이스: 각 요구사항에 대해 작성된 테스트 케이스 ID
    6. 테스트 결과: 해당 요구사항에 대해 테스트가 통과했는지, 실패했는지 등의 결과
    7. 상태: 요구사항의 현재 상태 (예: 개발 완료, 테스트 완료, 대기 중 등)

• •