[TIL][CS/소프트웨어 설계] 요구사항 정의 및 분석, 분석 도구

오늘은! 소프트웨어 설계에 필요한 요구사항 정의 및 분석에 대해 공부했다.

요구사항이 뭐고, 요구사항을 어떻게 정의하고, 어떤 과정을 통해서 분석하는지 보겠음

 

우선 가장 첫 번째로 현행 시스템의 구성을 파악하는 것이 필요하다.

✏️ 현행 시스템 파악 절차

• 개발하려는 시스템의 방향성을 설정하기 위해, 현행 시스템의 구성을 파악하는 절차
• 1단계 : 시스템 구성, 시스템 기능, 시스템 인터페이스 파악
• 2단계 : 아키텍처, 소프트웨어 구성(DBMS, 운영체제) 파악
• 3단계 : 하드웨어 구성, 네트워크 구성 파악

 

🔹 운영체제(OS) 파악 시 고려 사항

• 가용성, 성능, 기술지원, 주변기기, 구축 비용이 얼마나 되는지, ... 이런 것
• 메모리 누수 성능 영향⭐, 구축비용 TCO (특정 기간동안 OS를 관리하고 사용하고 ~ 뭐 이러는 비용) 확인
• 운영체제 종류: Mac OS, Windows, UNIX, Linux, etc 

 

🔹 DBMS 파악 시 고려 사항

• 가용성, 성능, 기술지원, 상호 호환성, 구축 비용 봐야함 
• 설치 가능한 운영체제 및 JDBC, ODBC 호환 여부를 파악
• DBMS 종류: MySQL, SQLite, MongoDB, Redis, Oracle, IBM DB2, Microsoft SQL Server

 

🔹 WAS (Web Application Server) 파악 시 고려 사항

• 가용성, 성능, 기술지원, 구축 비용 봐야함
• 가비지 컬렉션 (GC; Garbage Collection) 옵션 여부 (메모리 누수를 방지하기 위해 메모리 관리를 해주는 그런 개념)
• 종류: Tomcat, Jetty, JBoss, WebLogic, JEUS, WebSphere

 

✏️ 요구 사항이란?

• 기능 요구사항과 비기능 요구사항으로 구분
• 기능 요구사항 
  '사용자가 원하는 기능'으로 시스템이 사용자에게 반드시 수행하여 제공해야하는 기능
  시스템이 어떻게 동작하는지, 무엇을 하는지, 어떤 기능을 하는지에 대한 요구사항
• 비기능 요구사항
  성능, 품질, 보안, 환경, 제약사항 같은 보조적인 요구사항

 

✏️ 요구 사항 개발 프로세스

• 시작하기 전, 타당성 조사 선행 해야함
• 앞자리 따서 도분명확이라고 외웠다 ㅎ

🔹도출

• 첫 번째 단계로 소프트웨어가 해결해야 할 문제를 이해하는 과정
• 요구사항 위치 파악, 수집 방법 고민, 이해관계자 식별
• 다양한 이해관계자와 효율적인 의사소통 중요 ⭐
• 요구사항 도출 기법 : 설문, 인터뷰, 브레인스토밍, Use Case, 프로토타이핑

🔹분석

• 앞에서 도출 된 요구사항 목록들 중,  명확하지 않거나 모호한 사용자의 요구사항을 걸러내는 과정
• 요구사항 분석 도구 : UML, *자료 흐름도(DFD), *자료사전(DD), Mini-Spec, 개체관계도(ERD)

🔹명세

• 앞에서 분석된 결과를 바탕으로 모델을 작성하고 문서화(=명세화) 하는 과정
• 요구사항 명세 기법 : 정형 명세 기법, 비정형 명세 기법

🔹확인

• 정리된 명세서를 확인하고 검증하는 과정
• 요구사항 이해도 확인, 실제 요구사항이 얼마나 반영됐는지 확인, 재작업 비용 발생 방지
• 목적 : 확인 단계를 거쳐서 재작업 비용이 발생하지 않도록 방지하는 것 
• 다만 모든 문제를 미리 확인하는 건 불가능하단 걸 인지하자 

 

이제 위에서 언급한, 요구사항 분석 단계에서 활용되는 도구들을 알아보자.

---

[🔎 분석 도구]

✏️ 자료 흐름도 (DFD; Data Flow Diagram)

• 구조적 분석 기법에 이용되는 분석 도구로, 자료 흐름, 변환 과정, 기능을 4가지 기호로 기술함

요소에 따라 어떻게 표기하는지 봐두자

 

🔹자료 흐름도 작성 원칙 

• 자료 보존의 원칙 : 출력 데이터 플로우는 반드시 입력 데이터 플로우를 이용해 생성
• 최소 자료 입력의 원칙 : 출력 자료 산출에 필요한 최소 데이터 플로우만 입력
• 독립성의 원칙 : 프로세스는 오직 자신의 입력 자료와 출력 자료 자체에 대해서만 인지
• 지속성의 원칙 : 항상 프로세스 수행 상태 지속
• 순차 처리의 원칙 : 입력 데이터 플로우의 순서를 출력되는 데이터 플로우에서도 유지 
• 영구성의 원칙 : 데이터 스토어의 자료는 사용해도 제거되지 않음
• 자료 변환의 원칙 : 본질의 변환, 합성의 변환, 관점의 변환, 구성의 변환
• 이런 원칙들이 있다고만 쭉 봐두자!

 

✏️ 자료 사전 (DD; Data Dictionary)

• 분석 도구로, 자료 흐름도에 기술된 자료들에 대해 정의한 것 
• 소프트웨어에서 사용하는 자료 항목을 규칙에 맞게 정리한 집합

 

✏️ CASE 분석 기법 (Computer Aided Software Engineering)

• 소프트웨어 생명주기 전체 과정을 지원하는 자동화 도구
• 다이어그램을 쉽게 작성하고, 작업 과정 및 데이터 공유를 하는 역할  
• 장점) 소프트웨어 시스템의 문서화 품질을 개선, 명세를 쉽게해서 유지보수 비용을 감소시킬 수 있음 

 

🔹요구 사항 분석을 위한 CASE 

• 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구 

이런 것들이 있다

 

 

✏️ HIPO (Hierarchy Input Process Output)

• 구조적 분석 및 설계 방법
• 시스템 분석, 설계, 문서화용 기법
• HIPO Chart를 많이 활용함.
  가시적 도표, 총체적 다이어그램, 세부적 다이어그램으로 구성되어 있음 
  계층 구조를 표현하는 역할이면서, 하향식 소프트웨어 개발을 위한 문서화 도구로 활용

---

[🔎 시스템 인터페이스 요구사항 관리 방법] 
✏️ 시스템 인터페이스 요구사항 분석

• 요구사항 명세서에서 *기능적인 요구사항과 비기능적인 요구사항을 분류하고 구체화한 뒤, 이해관계자에게 전달하는 작업
• 요구사항 선별 후 요구사항 명세 작성 → (작성된 명세를 바탕으로) 요구사항 관련 자료를 준비 →  기능적/비기능적 요구사항 분류 →  요구사항 명세서 구체화 →  요구사항 명세서 공유 

✏️ 시스템 인터페이스 요구사항 분류 

• 기능적 요구사항
  - 소프트웨어가 시스템 간의 연계를 통해 수행해야 하는 기능에 대한 요구사항
  - 시스템의 기능 설명, 시스템의 동작 방식/입출력/데이터 처리 방식 기술
• 비기능적 요구사항
  - 시스템이 정상적으로 작동하기 위한 제약 조건 
  - 시스템 성능, 보안, 안정성, 사용성, 확장성과 같은 기능 이외의 사항 기술 

✏️ 시스템 인터페이스 요구사항 검증

• 요구사항이 명세서에 명확히 기술되었는지 검토하고 개발 범위를 설정하는 과정
• 검증 방법 : 프로토타이핑, 테스트 설계, (앞에서 언급한) CASE 도구 활용, 동료검토, 워크스루, 인스펙션 
  - 동료 검토(Peer Review) : 작성자가 동료에게 내용을 설명하여 결함을 검토하는 방법
  - 워크 스루(Walk Through) : 미리 명세서를 공유해서 모두가 사전 검토하고, 짧은 검토 회의를 진행하여 결함을 검토하는 방법
  - 인스펙션 (Inspection) : 작성자가 아닌 전문가가 명세서를 확인하며 오류를 찾는 방법 

 

이상 끝 !!