[SW 공학] 5주차- 요구 분석 단계와 모델

-> 여기서는 프로세스 2번째 단계인 요구분석에 대해 배운다. 사용자의 요구를 분석해서 그에 따른 서비스를 만들어주는 것이 중요한데, 요구 사항을 잘 표현하기 위해 적절한 모델링을 해주는 것이 중요하다.

😀 요구사항과 요구 분석 정의 및 목적

• 요구사항: 이용자가 어떤 문제를 풀거나 목표를 달성하는 데 필요한 조건이나 능력으로, 사용자가 필요로 하는 기능

1. 기능 요구
2. 비기능 요구: 품질

• 요구 분석 정의와 목적
  : 사용자 요구사항을 조사하고 확인하는 과정
  -> 수요자의 요구를 충분히 잘 분석하여, 개발자가 그 요구를 잘 반영해야 함
  -> 요구 분석 명세서: 시스템의 기능이 무엇인지 (사용자가 어떤 기능을 요구하는지)

😀 요구 분석의 어려움

• 이해력 부족: 문제 영역에 대한 분석가의 이해력 부족 (전문적인 이해력 부족, 잘못 이해)
• 의사소통 문제: 분석가에게 요구 사항을 설명하기가 어려움, 요구사항 추가
• 사용자의 모호한 요구사항: 모호하게 분석하게 요구사항 전달하면 문제 발생

😀 요구분석 절차

1. 자료 수집
   <요구사항 수집 방법>

• 자료 수집
• 인터뷰
• 설문조사: 모집단 조사 대상의 수에 비례해야 함

2. 요구 사항 도출: 수집한 자료를 잘 정리해 요구사항 도출
3. 문서화: 요구 분석 명세서
4. 검증 : 사용자의 요구가 정확히 기록되었는지, 모순되는 것은 없는지 검증

😀 요구사항 분류

• 기능 요구사항
  : 사용자가 원하는 기능으로, 아래 2가지 조건을 만족해야 함
  @ 완전성: 사용자가 원하는 기능이 모두 포함
  @ 일관성: 요구사항 간에 모순이 없어야 함
• 비기능 요구사항: 품질/제약사항 (군사무기나 의료 장비에서 매우 중요)
  @ 제약사항: 소프트웨어가 수행될 환경에 의한 조건
  @ 품질(신뢰도): 장애 없이 동작하는 것
  --> 신뢰도 높은 소프트웨어의 조건:
  고장을 일으키지 않고 회피할 수 있는 능력
  고장 발생하더라도 이전 수준의 성능 회복되어야 함
  고장으로 영향을 받은 데이터들이 정상적으로 복구됨
  @ 가용성: 고장없이 가동되는 비율
• 가용성: 가용시간(MTBF) = 가용시간(MTBF)/(가용시간(MTBF)+평균수리시간(MTTR))
• MTBF = MTTF(평균 가동 시간) + MTTR(평균 고장 시간)

😀 요구사항의 표현과 모델

• 모델: 요구사항을 명확히 표현하기 위한 것

• 소프트웨어 개발 모델 사용의 장단점:
  장점

1. 이해도 향상: 단순화, 시각화를 통해
2. 유지보수 용이: 추후 요구사항 변경에 따른 유지보수에 활용가능
   단점
3. 과도한 문서 작업으로 일정 지연: 실제 개발 업무 지연
4. 형식적인 산출물로 전락할 가능성: 변경된 내용을 산출물에 즉시 반영해줘야 함

😀 요구사항 모델링

: 모델을 제작하는 과정 또는 작업

• 자연어를 사용한 표현

• 형식 언어를 사용한 표현

• UML 다이어그램을 사용한 표현

• 개발 방법에 따른 모델링 언어
  @ 구조적 방법: DFD
  @ 정보공학 방법: ERD
  @ 객체지향 방법: UML
  @ UML 표기법: DIAGRAM, USECASE

😀 DFD (구조적 방법)

: 데이터 흐름에 중점 (기능- 입력과 출력자료- 데이터베이수 테이블- 출원지와 목적지)

• 처리(기능), 에이전트, 자료 흐름, 자료 저장소

DFD 작성 규칙

1. 데이터 보존의 원칙: 출력은 반드시 입력 데이터 흐름을 이용하여 생성된 것이어야 함
2. 최소 데이터 입력의 원칙: 반드시 필요로 하는 최소의 데이터 흐름만을 입력해야 함
3. 독립성의 원칙: 자기의 처리는 오직 자신의 입력 자료와 출력 자료에 대해서만 알면 됨
4. 지속성의 원칙: 항상 준비되어 있어야 함. 데이터 흐름이 들어오기만 한다면 항상 수행할 준비를 갖추고 있어야 함
5. 순차 처리의 원칙: 입력되는 데이터는 도착되는 순서대로 처리해야 함
6. 영구성의 원칙: 데이터 자장소의 데이터는 아무리 읽어도 없어지지 않음
7. 데이터 변환의 원칙: 데이터가 어떻게 출려될 지는 변화 한다.

• 데이터 본질의 변환: 데이터 표현 방식이 바뀔 수 있음
• 데이터 합성의 변환: 데이터 항목이 합성되어 산출될 수 있음
• 데이터 관점의 변환
• 데이터 구성의 변환: 데이터의 구성 형태가 변화

😀 ERD

: 개체들 간의 관계를 나타냄

1. 개체 파악
2. 속성 파악
3. PK 지정
4. 관계 타입 지정

관계 타입 유형

<새 발 표기법>

⭕ 나의 언어로 정리:
사용자의 요구를 파악하는 것이 매우 중요하다. 하지만, 그 요구 분석은 어렵다. 그 요구 사항은 기능과 비기능(품질, 제약사항, 가용성)으로 나눌 수 있다. 그 요구 사항은 정해진 견본이 없기 때문에 애매모호할 수 있다. 따라서, 특정 모델을 이용해줘야 한다. 그 모델을 이용하는 것을 모델링이라고 한다. 모델링 방법은 여러 가지가 있는데, 이번 시간에는 ERD(개체 간의 관계), DFD (데이터 흐름 중심)를 배웠다.