[정보처리기사 필기] 1과목 정리 - 요구사항 분석

요구분석(Requirements Analysis)

소프트웨어 개발의 실질적인 첫 단계
사용자가의 요구에 대하여 이해하고 정리하는 작업

요구 분석 단계

• 요구 추출
• 요구 분석 및 정의
• 요구 확인

요구

• 시스템에 대한 고객의 요청을 확정한 것
• 진정한 요구를 찾는 일은 프로젝트 성공의 필수 조건
• 여러 이해 당사자(stakeholder)의 이해관계와 관련

제약사항

• 특정한 프로그래밍 언어, 특정한 제품 사용
• 소프트웨어 시스템의 해결책을 제한

요구의 분류

기능 요구(Functional Requirements)

• 시스템과 외부 요소들 간의 상호작용
• 시스템이 어떤 상태일 때 외부의 데이터나 명령에 대해 어떤 반응을 하는지 기술
• 기능적 요구 항목으로 제기되는 문제들은 사용자의 문제를 해결하기 위한 구현 기술과는 독립적인 사항

비기능 요구(Non-Functional Requirements)

• 시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 요구 사항
• 종류
  • 성능 - 시스템의 처리량, 반응시간, 실시간 처리, 자원 이용률
  • 품질 - 신뢰성, 가용성, 사용시 오류 발생률
  • 안전 - 의도하지 않은 오퍼레이션으로 인하여 원치 않는 상태에 있는 것을 방지하는 역량
  • 보안 - 시스템 자원을 악의적인 공격으로부터 보호할 수 있는 역량
  • 사용성 - 인터페이스, 동작, 보고 느끼는 것(Look and Feel)

요구 추출

단계

• 1. 응용에 대한 정보 출처 파악
• 2. 응용에 대한 정보 취합
• 3. 요구와 제한 사항의 정의

정보 수집 방법

 

• 고객의 발표
• 문헌 조사
• 업무 절차와 양식 조사
• 관련자들 설문지
• 사용자와의 인터뷰
• 브레인스토밍 회의
• 사용 스토리 또는 유스케이스 작성

요구사항 우선 순위

• 절대적으로 필요한 요구
• 요망되나 꼭 필요한 것은 아닌 요구
• 요구로 판단될 수 있으나 제외될 수도 있는 요구

어려움

• 개발 팀이 응용 도메인에 대하여 충분히 알지 못함
• 고객과 사용자가 SW가 무엇을 하는지 또한 어떻게 요구를 표현할지 모름
• 공통 배경지식 부족으로 개발 팀과 사용자 사이의 대화 장벽이 생김
• 소프트웨어 요구에 대한 명세와 구현이 분리될 수 없어 정확히 명시하기 어려움
• 요구 추출 작업을 관리자, 사용자, 개발자 모두 과소평가하는 경우가 많음
• 비기능적 요구를 파악하기 힘들며 이해하지 못함
• 요구가 계속 변경됨

요구 분석

요구 후보를 분석하고 결정하여 요구로 확정

요구 품질

• 원자적(atomic)
• 완전성(complete)
• 비모호성(unambiguous)과 통일성(consistent)
• 추적성(traceable)
• 우선순위화(prioritize)
• 테스트 가능성(testable)

도메인 분석

• 도메인(Domain) == 요구의 배경
  • 문제가 어디에 놓여 있는가? -> 배경에 대한 이해 필요
• 설계 모델링에 필요한 여러 개념과 비즈니스 규칙을 파악
• 응용 분야에 존재하는 개념을 정의하고 분석하여 시스템에 존재하는 개념으로 정립하는 단계
• 방법
  • 도메인 개념 찾기
    • 도메인 목적, 구조, 동작을 구성하는 객체, 프로세스, 사람, 규칙
    • 의료 정보 시스템 : 예약, 접수, 진료와 검사, 입원, 퇴원
  • 도메인 사전 작성
    • 도메인 개념을 조직화한 결과물
    • 각 항목은 용어가 사용될 때는 언제든 같은 의미로 통하게 하는 간결한 정의
  • 비즈니스 규칙 정리
    • 업무에서 지키기로 한 규정
    • 기업이 운영되는 자세한 정책, 규정, 절차, 가이드라인, 표준의 집합

시나리오 기반 분석

• 다양한 사람들이 참여하여 다양한 용어와 개념을 전달하여 요구를 도출
• 커뮤니케이션의 장벽 해소
  • 시나리오 기반(5H1W)
• 사용자 스토리
  • <사용자/역할(who)>는 <목표/혜택/이익(why)>를 얻기 위하여 <행위/작업(what)>을 원함

구조적 분석

• 사용자의 요구분석 사항을 파악하기 위하여 자료의 흐름과 가공절차를 그림 중심으로 표현하는 방법
  • 처리중심(process-oriented) 분석 기법
• 특징
  • 그림 중심의 표현
  • 하향식(top-down partitioning) 원리를 적용
  • 사용자의 업무 요구 사항을 쉽게 문서화
  • 사용자와 분석가 간의 의사소통을 위한 공용어
  • 실체의 모형(추상적 표현)을 추출
• 세부 작업 순서
  • 1. 배경도(Context Diagram) 작성
  • 2. 상위 자료 흐름도 작성
  • 3. 하위 자료 흐름도 작성
  • 4. 자료 사전 작성
  • 5. 소단위 명세서 작성

 

자료 흐름도(DFD, Data Flow Diagram)

• 자료흐름(Data Flow)
  • 자료흐름은 변형되어 이동중인 자료군을 나타냄
  • 이동 방향을 표시한 화살표로 나타냄
  • 화살표 위에 자료군의 이름을 붙임
  • 자료 저장소에 연결된 자료의 흐름은 저장소에 자료군을 운반하여 저장함을 뜻함

 

• 처리(Process)
  • 입력 자료흐름을 출력 자료흐름으로 변환
  • 원으로 표현하고 그 안에 처리의 이름을 적음
  • 처리 이름
    • 처리가 하는 일 or 처리를 수행하는 행위자로 기술
  • 고유번호가 주어짐
  • 차후 소단위 명세의 대상

 

• 자료 저장소(Data Store)
  • 머물고 있는 자료군의 집합(파일, 데이터베이스, 서류철 등)
  • 자료저장소는 한 쌍의 평행선으로 표현

 

• 단말(Terminator, Terminal)
  • 대상 시스템 밖에서 역할을 수행하는 사람, 부서 또는 다른 자동화 시스템
  • 단말은 사각형으로 표현하고 그 명칭을 부여
  • 명칭은 한 개인, 부서를 기술하기 보다는 그 역할을 기술

 

예시

DFD의 예시 - 수강신청 시스템

작성 순서

• 단계적 분할에 의하여 단계적으로 표현

Context Diagram - 출처 : https://han.gl/QDVCo

• 1. 배경도(context diagram) 작성
  • 개발하려는 시스템과 외부세계와의 인터페이스를 식별
  • 시스템 분석의 범위를 설정
  • 시스템 전체를 나타내는 하나의 처리와 관련된 단말들로 표시

중간 단계의 자료 흐름도 - 출처 :&nbsp;https://han.gl/QDVCo

• 2. 중간 단계의 자료흐름도
  • 자료흐름도 내의 하나 이상의 처리가 하위 자료흐름도로 분할되는 자료흐름도

최하위 단계의 자료 흐름도 -&nbsp;출처 :&nbsp;https://han.gl/QDVCo

• 3. 최하위 단계의 자료 흐름도
  • 자료흐름도 내의 모든 처리가 더 이상 분할되지 않는 자료흐름도
  • 모든 처리들이 소단위 명세서로 설명됨

 

자료사전(Data Dictionary, DD)

• 자료 흐름도에 나타나는 자료에 대한 정의를 모은 것
• 사용 기호

• 예

 

유스케이스 다이어그램(Use-case Diagram)

• 시스템의 기능을 나타내기 위하여 사용자의 요구를 추출하고 분석하는데 사용
• 구성
  • 유스케이스(Use-case)
    • 유스케이스는 컴퓨터 시스템을 사용할 때 사용자가 무엇을 경험/수행하는지를 글로 표현한 것임
    • 액터의 입장에서 본 시스템의 동작(외부동작)
    • 액터가 볼 수 있는 결과를 내는 이벤트의 집합
    • 다른 유스케이스를 가동시킬 수 있음
    • 개별 시나리오를 묶은 것
      • 정상적인 흐름
      • 오류, 예외 케이스
      • 시나리오는 유스케이스의 인스턴스라 볼 수 있음
    • 시나리오로부터 유스케이스 형성
    • 유스케이스 찾기
      • 시나리오 구성
        • 개발자와 사용자가 함께 작성
        • 현재의 응용 도메인에 대하여 기술한 여러 문서를 이용(지침서, 매뉴얼 등)
      • 시나리오 구성을 위한 질문
        • 시스템이 어떤 작업을 수행하기를 액터가 원하는가?
        • 액터가 원하는 정보는 무엇인가?
        • 누가 데이터를 생성하는가? 데이터는 조작, 삭제될 수 있는가? 이런 작업이 누구에 의하여 행해지는가?
        • 액터가 시스템에 정보를 알리는데 필요한 것은? 얼마나 자주 또 언제 이런 작업이 일어나는가?
        • 액터가 시스템으로부터 정보를 알아내는데 필요한 이벤트는? 이런 사건의 빈도는?
  • 액터(actor)
    • 시스템과 상호작용 하는 외부 엔티티
    • 구별되는 이름과 설명이 필요
    • 상호작용이 있는 다른 시스템
    • 액터는 역할을 추상화한 것으로 꼭 사람과 결부시킬 필요는 없음
    • 액터를 찾기 위한 질문
      • 어떤 사용자 그룹이 작업을 수행하기 위하여 시스템의 지원을 받는가?
      • 어떤 사용자 그룹이 시스템의 주요기능을 사용하는가?
      • 어떤 사용자 그룹이 유지 보수와 관리 등의 부수적 기능을 사용하는가?
      • 시스템이 다른 외부 하드웨어나 소프트웨어 시스템과 동작하는가?
• 유스케이스 명세

• 관계
  • 포함(include) 관계
    • 유스케이스 사이의 중복 제거
    • 어떤 유스케이스가 다른 유스케이스를 포함하는 관계
  • 확장(extend) 관계
    • 유스케이스가 일정 조건 아래 확장된 동작을 포함한다면 다른 유스케이스를 확장하는 관계
    • 정상적인 이벤트와 예외적인 이벤트를 분리

 

요구 분석 명세서(SRS, Software Requirements Specification)

• 시스템의 기능을 정확하고 완벽하며 일관성 있게 작성한 것
• 소프트웨어에 포함될 기능과 제약 조건들을 나열
• 기능에 대한 자세한 설명과 예외처리 기술
• 시스템 성능과 관련된 사항, 속도, 정확성, 사용 용이성 포함
• 명세서 작성 및 검토 과정
• 명세서 작성은 사용자와 개발자 간의 이해를 돕기 위함임
• Gilbert가 제안한 요구 분석서 작성 시 주의 사항
  • 사용자와 개발자 모두가 쉽게 이해할 수 있도록 작성해야 함
  • 기술된 조건은 개발자와 사용자 모두가 동의한 것이어야 함
  • 제안된 시스템에 의하여 수행될 모든 기능을 정확히 기술하여야 함
  • 제안된 시스템에 영향을 주는 모든 제약 조건을 기술하여야 함
    • 목표 하드웨어, 하드웨어 용량, 동작 환경 등
  • 시스템의 인수를 위한 테스트 기준을 제공하여야 함
  • 시스템의 품질과 상대적인 중요도 및 품질 측정 방법이 기술되어야 함