[소프트웨어 설계] 요구사항 확인

Chapter 01 요구사항 확인

1. 현행 시스템 분석 - 분석 항목, 기법, 유형

1. 플랫폼 기능 분석

• 플랫폼의 개념
  • 플랫폼이란 애플리케이션 구동에 필요한 소프트웨어 환경이다. 동일 플랫폼 내에서는 상호 호환이 가능하도록 만들어진 집합체를 의미하며, 공급자/수요자 등 복수의 그룹이 참여하여 각각의 원하는 가치를 공정하게 거래/교환할 수 있도록 구축된 환경이다.
• 플랫폼의 유형
  1. 싱글 사이드 플랫폼
     • 제휴 관계를 통해 소비자-공급자 연결
     • 예시: 아이튠즈, 안드로이드 마켓
  2. 투 사이드 플랫폼
     • 두 그룹 중개, 모두에게 개발
     • 예시: 소개팅 앱
  3. 멀티 사이드 플랫폼
     • 다양한 이해관계 그룹을 연결하여 중개하는 형태
     • 예시: 페이스북, 인스타그램
• 플랫폼의 기능
  • 소프트웨어 개발/운영 비용 감소
  • 생산성 향상
  • 동일 플랫폼의 커뮤니티 형성, 네트워크 효과
• 플랫폼 기능 분석 절차
  1. 현행 플랫폼 자료 수집: 현행 시스템 담당자 제시 자료/인터뷰를 통해 필요한 자료 수집/파악
  2. 수집 자료 분석: 수집 자료에 산발적으로 존재하는 정보 취합/정제
  3. 결과 산출물 작성: 수집된 자료 기반 플랫폼 기능분석도 작성

1. 플랫폼 성능 특성 분석

• 플랫폼 성능 특성 분석 이유
  • 사용자의 서비스 이용 시 속도 적정성 파악
  • 사용자 요구사항 중 성능 개선이 시스템 플랫폼 성능 개선으로 이어질 수 있음
• 플랫폼 성능 특성 분석 기법
  • 사용자 인터뷰: 현행 플랫폼 사용자 인터뷰를 통해 속도 적정성 확인, 인터뷰 결과서 산출
  • 성능 테스트: 현행 플랫폼 대상 성능/부하 테스트 수행, 성능 테스트/부하 테스트 결과서 산출
  • 산출물 점검: 유사 제품의 성능 자료 분석, 벤치마킹 테스트 결과서 산출
• 플랫폼 성능 특성 측정 항목
  • 경과 시간(Turnaround Time): 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료되기까지 걸린 시간
  • 사용률(Utilization): 애플리케이션이 의뢰한 작업 처리 과정에서 사용된 자원 사용률
  • 응답 시간(Response Time): 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
  • 가용성(Availability): 서버, 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도

1. 운영체제 분석

• 운영체제 개념
  • 하드웨어/소프트웨어 자원을 효율적으로 관리하며 공통된 기능을 제공하는 소프트웨어, 즉 사용자가 컴퓨터를 좀 더 쉽게 사용할 수 있도록 지원하는 소프트웨어
• 운영체제 현행 시스템 분석
  • 운영체제 현행 시스템 분석 시 품질, 지원 측면을 고려해야 함
  1. 품질 측면
     • 신뢰도: 장기간 시스템 운영 시 운영체제의 장애 발생 가능성, 운영체제의 버그로 인한 재기동 여부
     • 성능: 대규모(배치) 작업 처리, 지원 가능한 메모리 크기(32, 64bit)
  2. 지원 측면
     • 기술 지원: 공급사의 안정적 기술 지원, 오픈소스 여부
     • 주변 기기: 설치 가능 하드웨어, 주변기기 지원 여부
     • 구축 비용: 지원 가능한 하드웨어 비용, 응용 프로그램의 라이선스 정책 및 비용, 유지관리 비용
• 운영체제 종류/특징
  • 운영체제의 유형은 크게 컴퓨터/모바일로 나뉨
  1. 컴퓨터
     • 윈도우(Microsoft): 중/소규모 서버, 일반 PC등의 유지관리비용 장점
     • 유닉스(IBM, HP, SUN): 대용량 처리, 안정성 높은 엔터프라이즈급 서버
     • 리눅스(Linus Torvalds): 중/대규모 서버 대상, 높은 보안성, 비용 가장 적음
  2. 모바일
     • 안드로이드(Google): 스마트폰, 태블릿PC, 다양한 기기 호환성 제공
     • iOS(Apple): 스마트폰, 태블릿PC, 높은 보안성과 고성능

1. 네트워크 분석

• 네트워크 개념
  • 컴퓨터 장치들이 노드 간 연결(데이터 링크)을 사용해 서로 데이터를 교환하는 기술
  • 데이터 링크들은 유선 매체(광케이블) 또는 와이파이와 같은 무선 매체를 통해 성립
• 네트워크 현행 시스템 분석
  • 네트워크 구성도를 통해 현행 시스템의 네트워크 구조 분석
  • 네트워크 구성도: 서버 위치, 서버 간 연결 방식 파악 가능
  • 백본망: 네트워크를 상호 연결하는 컴퓨터 네트워크의 일부로서 다른 LAN이나 부분망 간 정보 교환 경로 제공
  • 라우터: 3계층 데이터 패킷을 발신지-목적지로 전달하기 위해 최적 경로 지정, 해당 경로로 데이터 패킷을 다음 장치로 전달하는 네트워크 장비
  • 스위치: 2계층 장비, 동일 네트워크 내에서 출발지에 들어온 데이터 프레임을 목적지 MAC 주소 기반으로 전달하는 네트워크 장비
  • 게이트웨이: 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간 통신을 가능하도록 하는 네트워크 장비
  • 방화벽(firewall): 외부로부터 불법 침입/내부로부터 불법 정보 유출 방지, 내/외부 네트워크 상호 간 영향 차단을 위한 보안 시스템
  • 위의 백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석
  • 위치 관계 파악, 보안 취약 분석 가능
  • 네트워크 장애 발생 시 추적/대응 가능

1. DBMS 분석

• DBMS 개념
  • 데이터베이스라는 데이터의 집합을 만들고 저장/관리할 수 있는 기능을 제공하는 응용 프로그램
• DBMS 기능
  • 중복 제어: 동일 데이터 중복 방지
  • 접근 통제: 권한에 따른 접근 제어
  • 인터페이스 제공: SQL, CLI, GUI 등 다양한 인터페이스 제공
  • 관계 표현: 데이터 간 관계 표현
  • 샤딩/파티셔닝: 구조 최적화를 위해 작은 단위로 나눔
  • 무결성 제약조건: 제약조건 정의/검사 기능
  • 백업 및 회복: 데이터베이스 장애 발생 시 데이터 보존
• DBMS 현행 시스템 분석
  1. 성능 측면
     • 가용성: 시스템 장기간 운영 시 장애 발생 가능성, 백업/복구 편의성, DBMS 이중화/복제 지원
     • 성능: 대규모 데이터 처리, 다량 거래 처리, 다양한 튜닝 옵션 지원 여부, 비용 기반 최적화 지원/설정 최소화
     • 상호 호환성: 설치 가능 운영체제 종류, 다양한 운영체제에서 지원되는 JDBC(Java DataBase Connectivity), ODBC(Open DataBase Connectivity)
  2. 지원 측면
     • 기술 지원: 공급 업체의 안정적 기술 지원, 사용자 간 정보 공유, 오픈 소스 여부
     • 구축 비용: 라이선스 정책 및 비용, 유지관리 비용

1. 비즈니스 융합Convergence 분석

• 비즈니스 융합 개념
  • 융합 기술이 제공하는 기회나 융합의 원리를 적용해 새 제품/서비스/산업을 창출하거나 기존 제품을 혁신하기 위한 기업 활동
  • 산업/시간 간 경계를 허물어 새 비즈니스 모델로의 범위 확대
• 비즈니스 융합 유형
  • 고객 가치(Why): 개인, 사회, 인류의 행복/번영을 위한 가치 창출(신재생에너지, 친환경 농산물 생산)
  • 시장 유통(Whom): 신시장 개척, 미래시장 선점(자율주행, 글로벌 통신망)
  • 가치 제안(What): 시장/고객의 미충족 욕구를 위한 신상품 개발(드론배송, 협동 로봇, 소셜 로봇)
  • 공급 역량(Who): 신기술/역량을 활용한 상품 생산/판매(스마트 밴드, 스마트 헬스케어)
  • 생산 방식(How): 생산 방식/판매 프로세스 혁신(스마트 팩토리, 옴니채널)
• 비즈니스 융합 분석 절차
  1. 기업전략 분석: 기업 환경, 경쟁전략 분석
  2. 영역 및 방향 설정: 기업전략 기반 영역 설정
  3. 포트폴리오 선정: 부합성, 생존성, 경쟁, 성장성 평가
  4. 융합모델 설계/평가: 구체적 비즈니스 모델 설계, 융합모델 유효성 평가/시범 적용
  5. 비즈니스 융합 실행/개선: 프로토타이핑, 사업화 타당성 확인

2. 요구사항 확인

1. 요구분석 기법

• 요구분석 개념
  • 사용자 요구를 추출해 목표를 정하고 해결 방식을 정하는 단계
  • 개발 대상에 대한 사용자 요구사항 중 모호한 부분을 발견/걸러내기 위한 과정
• 요구분석 특징
  • 소프트웨어 개발의 첫 단계, 사용자 요구에 대해 이해
  • 분석 결과 문서화로 유지보수에 이용
  • 소단위 명세서를 이용해 구체적인 명세
  • 개발 비용은 적음
  • 도메인 분석: 요구 관련 정보 수집, 배경 분석을 토대로 모델링
• 요구사항 분석 단계 절차
  • 요구사항 확인, 검증, 비용 추정
  1. 요구사항 분류
  2. 개념 모델링 생성 및 분석
  3. 요구사항 할당
  4. 요구사항 협상
  5. 정형 분석
• 요구사항 분석 기술
  • 청취
  • 인터뷰/질문
  • 분석
  • 중재
  • 관찰
  • 작성
  • 조직
  • 모델 작성
• 요구사항 분석에 사용하는 기능 모델링 기법
  1. 데이터 흐름도(Data Flow Diagram); 자료 흐름 그래프/버블 차트
     • 구조적 분석 기법에 이용
     • 데이터 흐름에 중심
     • 제어 흐름은 중요하지 않음
     • 시간 흐름을 표현하기 힘듦
     • 구성요소: 처리기(Process), 데이터 흐름(Data flow), 데이터 저장소(Data Store), 단말(Terminator)
  2. 자료 사전(Data Dictionary)
     • 기호
       • =: 구성요소로 자료 정의
       • +: 자료 연결
       • (): 자료 생략 가능
       • {}: 자료 반복
       • []: 자료 선택
       • **: 자료 설명(주석)
     • 작성 원칙
       • 자료 의미 기술
       • 자료 구성항목 기술
       • 동의어 규정 준수
       • 자료 정의 중복 제거
• 요구사항 분석의 어려움
  • 개발자-사용자 간 표현의 차이로 인한 상호 이해의 어려움
  • 사용자 요구사항의 모호성
  • 요구사항 변동
  • 요구사항의 다수의 예외

1. UML

• UML의 개념
  • Unified Modeling Language란 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술/방법론의 표준화된 범용 모델링 언어
• UML의 특징
  • 가시화 언어
  • 구축 언어
  • 명세화 언어
  • 문서화 언어
• UML 구성요소
  • 사물Things: 주제, 명사/동사
  • 관계Relationships: 사물의 의미 확장, 사물간 연결/관계, 형용사/부사
  • 다이어그램: 사물-관계를 그림으로 표현
• UML 다이어그램
  1. 구조적 다이어그램/정적 다이어그램
     • 클래스 Class
     • 객체 Object
     • 컴포넌트 Component
     • 배치 Deployment
     • 복합체 구조 Composite Structure
     • 패키지 Package
  2. 행위적 다이어그램/동적 다이어그램
     • 유스케이스 UseCase
     • 시퀀스 Sequence
     • 커뮤니케이션 Communication
     • 상태 State
     • 활동 Activity
     • 타이밍 Timing
• UML 다이어그램 상세
  1. 클래스 다이어그램
     • 객체 지향 모델링 시 클래스 속성/연산, 클래스 간 정적 관계를 표현한 다이어그램
     • 구성요소: 클래스 이름, 속성, 연산, 접근 제어자
  2. 유스케이스 다이어그램
     • 시스템 제공 기능, 관련 요소를 사용자 관점에서 표현한 다이어그램
     • 구성요소: 유스케이스, 액터, 시스템
     • 구성요소 간 관계
       • 연관: 유스케이스와 액터 간 상호작용이 있음, 실선
       • 포함: 유스케이스가 다른 유스케이스의 실행을 전제로 함, 점선 화살표, include
       • 확장: 특정 조건에 따라 확장 ㄱ기능 유스케이스 수행, 점선 화살표, extend
       • 일반화: 유사 유스케이스/액터를 모아 추상화, 실선 화살표
  3. 시퀀스 다이어그램(순차/동적 다이어그램)
     • 객체 간 상호 작용을 메시지 흐름으로 표현한 다이어그램
     • 구성요소: 객체, 생명선, 실행, 메시지, 회귀 메시지
  4. 상태 다이어그램
     • 하나의 객체가 자신이 속한 클래스의 상태 변화, 상호작용을 통한 상태 변화를 표현한 다이어그램
     • 구성요소: 상태, 시작 상태, 종료 상태, 전이, 이벤트, 전이 조건
• UML 관계
  • 연관: 서로 관련(실선 화살표, 실선)
  • 의존: 필요한 경우에만 서로에게 영향(점선 화살표)
  • 일반화: 상속(속이 빈 실선 화살표)
  • 실체화: 다른 객체에 오퍼레이션 수행하도록 지정(속이 빈 점선 화살표)
  • 포함: 포함하는 사물 변화가 포함되는 사물에 영향(속이 채워진 마름모 실선 화살표)
  • 집합: 한 사물이 다른 사물에 포함(속이 빈 마름모 실선 화살표)
• UML 확장 모델의 스테레오타입(Streo Type)
  • UML의 기본 요소 이외의 새 요소를 만들어 내기 위한 확장 매커니즘
  • 기존 UML의 요소 그대로 사용, 내부 의미는 다른 목적으로 사용
  • ‘<<>>’(길러멧) 기호로 표현
  • 유형
    • <>: 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계
    • <>: 하나의 유스케이스가 어떤 시점에 다른 유스케이스 실행/실행X 하는 확장 관계
    • <>: 모든 메서드가 추상 메서드, 바로 인스턴스 생성 불가능
    • <>: 정보, 오래 지속되는 연관행위 형상화 클래스
    • <>: 시스템-외부 액터 상호작용 담당
    • <>: 시스템 기능 로직/제어 담당

1. 애자일 Agile

• 애자일 방법론 개념
  • 소프트웨어 개발방법론의 하나로서 개발과 함께 즉시 피드백을 받아 유동적으로 개발하는 방법
• 애자일 방법론 등장 배경
  • 소프트웨어 개발 환경 변화
  • 기존 개발방법론의 한계: 신속 대응 부족, 빠르고 효율적 개발 요구
• 애자일 방법론 특징
  • 기능 중심의 요구사항
  • 절차/도구보다 개인/소통
  • 작업 계획이 짧아 요구 변화에 유연, 신속 대응 가능
  • 소프트웨어 실행에 가치
  • 고객의 피드백 중요
• 애자일 선언문
  • 공정과 도구보다 개인과 상호작용
  • 계획을 따르기보다 변화에 대응하기
  • 포괄적인 문서보다 동작하는 소프트웨어
  • 계약 협상보다 고객과의 협력
• 애자일 방법론 유형
  1. XP(Extreme Programming)
     • 의사소통 개선과 즉각 피드백으로 소프트웨어 품질을 높이기 위한 방법론
     • 실용성 강조
     • 가치: 용기, 단순성, 의사소통, 피드백, 존중
     • 기본원리: 짝 프로그래밍, 공동 코드 소유, 지속적 통합, 계획 세우기, 작은 릴리즈, 메타포어, 간단한 디자인, 테스트 기반 개발, 리팩토링, (최대)40시간 작업, 고객 상주, 코드 표준
  2. 스크럼(SCRUM)
     • 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
     • 주요 용어
       • 제품 책임자: PO; 요구사항 작성 주체, 이해관계자 의견 종합, 의사 결정
       • 제품 백로그: 제품, 프로젝트에 대한 요구사항
       • 스프린트: 2~4주 짧은 개발 기간
       • 스크럼 미팅: 매일 15분 정도의 짧은 미팅, To-Do list
       • 스크럼 마스터: 프로젝트 리더
       • 스프린트 회고: 스프린트 주기 되돌아보며 규칙 준수 여부, 개선점 확인
       • 번다운 차트: 남아있는 백로그 대비 시간을 그래픽으로 표현한 차트
  3. 린(Lean)
     • 낭비 요소를 제거해 품질을 향상시킨 방법론
     • JIT(Just In Time), 칸반 보드(참여, 업무, 팀원에 따른 작업량을 한번에 표현한 애자일 관리 도구) 사용
  4. 크리스탈(Crystal)
     • 프로세스, 도구보다 사람에게 중점을 두는 방법론
  5. ASD(Adaptive Software Development)
     • 개발을 혼란으로 규정, 혼란을 대전제로 그에 적응 가능할 수 있는 소프트웨어 방법 제시를 위해 만들어진 방법론
     • 합동 애플리케이션 개발(Joint Application Development) 사용
  6. FDD(Feature Driven Development)
     • 상품/서비스 단위가 아닌 신규 기능 단위로 하는 개발 방법론

3. 분석 모델 확인

1. 모델링 기법

• 모델
  • 모델 개념
    • 객체, 시스템, 개념 구조나 작업을 보여주기 위한 패턴
    • 개발 대상 추상화, 시각적 표현
  • 모델 특징
    • 소프트웨어 이해도 향상, 의사소통 향상
    • 문제 상황에 대한 이해도 향상, 해결책 설명
    • 개발될 시스템에 대한 유추
    • 문제 도메인의 엔티티, 관계 종속성 반영
• 모델링
  • 모델링 개념
    • 실세계의 물리현상을 이용하기 쉬운 형식으로 표현하는 기법
  • 모델링 특징
    • 공통 개념 공유에 도움
    • 개발팀 응용문제 이해에 도움
    • 결과물이 다른 모델링 작업에 영향
    • 프로세스 위주의 모델링 방법
    • DFD, DD 등 사용
    • 객체 지향 방법론에서는 UML 사용
    • 실세계 모델링이 소프트웨어 요구사항 분석의 핵심

1. 분석 자동화 도구

• 분석 자동화 도구 개념
  • 요구사항을 자동으로 분석해 명세서를 기술하도록 개발된 자동화 도구(CASE)
• 분석 자동화 도구 등장 배경
  • 산업 측면: 소프트웨어 위기 극복
  • 관리 측면: 요구사항-시스템 간 차이 발생 극복, 시스템 재사용성, 생산성, 유지보수 어려움 극복
• 분석 자동화 도구 특징
  • 표준화 적용, 문서화 - 품질 개선
  • 변경사항, 변경으로 인한 영향 추적 가능
  • 유지보수 비용 축소
  • 소프트웨어 품질 향상
  • 재사용성, 유지보수성 향상
  • 구조적 기법, 프로토타이핑 기술, 자동프로그래밍 기술, 정보 저장소 기술, 분산 처리 기술
• 분석 자동화 도구 분류
  • 상위 CASE: 계획수립, 요구분석, 기본설계 단계를 다이어그램으로 표현
  • 하위 CASE: 구문 중심 편집, 정적/동적 테스트 지원
• 분석 자동화 도구 주요 기능(CASE 도구; Computer Aided Software Engineering)
  • 그래픽 지원
  • 소프트웨어 생명주기 전 단계 연결
  • 다양한 개발 모형 지원
  • 표준화된 개발환경 구축, 문서 자동화 기능
  • 작업과정, 데이터 공유로 작업자 간 소통 증대

1. 요구사항 관리 도구

• 요구사항 관리 도구 개념
  • 요구사항 기반 프로젝트 관리, 설계, 개발, 테스트 수행 역할 지원 도구
• 요구사항 관리 도구 필요성
  • 비용 편익, 변경 추적, 영향 평가
• 요구사항 관리 도구 기능
  1. 기본 기능
     • 프로젝트 생성
     • 요구사항 작성
     • 요구사항 불러오기/내보내기
  2. 핵심 기능
     • 요구사항 이력 관리
     • 요구사항 베이스라인
     • 요구사항 추적성
  3. 부가 기능
     • 협업 환경
     • 외부 인터페이스
     • 확장성