새소식

자격증/정보처리기사

2020 정보처리기사 실기 - 1. 요구사항 확인

  • -

1.1 현행 시스템 분석하기

개발, 기획을 본격적으로 들어가기전에 현행 시스템에 대한 지식을 습득하는 단계

- 정의: 소프트웨어뿐만 아니라 HW, Network 등 관련 인프라를 확인하고 어떤 기술 요소를 적용할 것인지를 판단하기 위한 사전지식 습득 과정

 

- 현행 시스템 파악 절차

1. 구성/기능/인터페이스 파악 2. 아키텍처 및 소프트웨어 구성 파악 3. 하드웨어 및 네트워크 구성 파악
시스템 구성 현황 파악
시스템 기능 파악
시스템 인터페이스 현황 파악
아키텍처 파악
소프트웨어 구성 파악
시스템 하드웨어 현황 파악
네트워크 구성 파악

 

- 구성/기능/인터페이스 파악

-> 현행 시스템 구성 현황

    기간 업무(주요 멉무 처리 시스템) + 지원업무(기간업무 지원)

-> 기능 현황

현재 제공하고 있는 기술(글 쓰기, 삭제, 수정 등..)

-> 인터페이스 현황(상호간의 연결고리를 나타냄)

데이터의 종류(JSON/XML), 네트워크 프로토콜(TCP) 등 파악

 

1.2 요구사항 확인하기

- 요구 공학

시스템의 개발, 변경의 목적(WHAT)을 식별하기 위해 이해관계자들의 요구를 이해 및 조정하여 체계적으로 수집, 분석, 명세화, 확인하느느 공정 또는 이에 관한 학문

* SWEBOK: IEEE Computer Society에서 Software Engineering 분야에서 지식을 정리한 체계

- 요구사항 개발 프로세스 순서(도 분 명 확)

이 과정을 통해 프로젝트 과제에 대한 베이스라인을 설정하고, 상호 검증 하에 프로젝트를 수행

1. 출(Elicitation)

-> 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계

-> 요구사항 정보 수집을 위해 관련된 일련의 활동 등을 총칭하는 단계

-> 이해관계자 식별을 통해 개발팀과 고객 사이의 관계 형성

-> 다양한 이해관계자와 효율적인 의사소통 중요

2. 석(Analysis)

-> 시스템 요구사항을 정제하여 소프트웨어 요구사항 도출

-> 요구사항 분류, 개념 모델링, 기술 구조설계 및 요구사항 할당, 요구사항 협상

3. 세(Specification)

-> 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성

-> 시스템 정의서, 시스템 요구사항 명세서, 소프트웨어 요구사항 명세서

4. 인(Validation)

-> 분석가가 요구사항을 제대로 이해했는지 확인 필요

-> 일관성과 완전성이 충족되는지 검증(Verification)하는 것이 중요

-> 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증 수행

-> 검토, 프로토타이핑, 모델 검증, Test

 

- 요구사항 도출 필요성

-> 범위 기준선(Baseline) 제공

-> 일정, 원가에 영향: 원가, 예산 산정의 기준

-> 추적성 제공: 요구사항과 산출물 간의 관계를 검증할 수 있느 속성 제공

 

그러면 이제 도출, 분석, 명세 확인에는 각각 어떤것들이 있는지 알아보자

 

- 요구사항 도출 기법

-> 핵심그룹: 이해관계자 중 Project 스폰서와 Owner 구분(해당 주제 전문가 집단)

-> 심층 워크숍: 1박 이상의 워크숍을 통한 심층 분석

-> 인터뷰

-> 집단창의력기법(델파이 기법): 형식에 구애 없이 토론 진행 -> 집단 지성, 다양한 이해관계자들의 토론

-> 설문지 및 설문조사

-> 사용자업무 관찰 기법

-> 프로토 타입: 시제품 제공을 통해 요구사항 정보 수집

-> 집단의사결정기법: 다양한 환경, 상황, 시나리오 등을 통한 의사결정(만장일치, 과반수)

* 요구사항을 기능(기능, 자료, 인터페이스, 사용자) / 비기능(보안, 성능) 으로 나누어 추출할 수도 있다

 

- 요구사항 분석 기법

소프트웨어의 범위를 파악하고 환경과 어떻게 상호작용 하는지 이해

-> 요구사항 분류: 기능/비기능, 요구사항 범위 등 기준을 가지고 분류

-> 개념 모델링: 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심, 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책 설명

-> 요구사항 할당: 요구사항을 만족시키기 위한 아키텍처 구성 요소 식별, 다른 요소와 어떻게 작용하는지 분석 -> 추가 요구사항 발견

-> 요구사항 협상: 복수의 이해관계자가 서로 상충되는 내용을 요구하거나, 요구사항, 리소스 기능/비기능 요구사항들이 서로 상충되는 경우 진행하는 협의

-> 정형 분석: 형식적으로 정의된 Semantics을 지닌 언어로 요구사항을 표현, 오해의 소지 최소화, 요구사항 분석의 마지막 단계에서 수행

 

- UML(Unified Modeling Language)

소프트웨어 집약 시스템의 시각적 모델을 만들기 위해 도안 표기법 사용, 객체 관리를 위해 표준화된 모델링 언어

-> UML의 특징

    -> 가시화 언어: 개념 모델 작성, 오류 없이 전달, 의사소통 용이, 그래픽

    -> 구축 언어: 다양한 프로그래밍 언어와 연결, 왕복 공학 가능(순/역 공학), 실행 시스템 예측 가능

    -> 명세화 언어: 정확하고 완전한 모델 제시

    -> 문서화 언어: 시스템에 대한 통제, 평가, 의사소통의 문서

-> UML 4 + 1 View Model

고객 요구사항을 중심으로 설계자, 시스템 통합자, 시스템 엔지니어의 관점으로 SW 아키텍처를 구축하는 설계 방법

     -> Use-case View: 사용자 관점, 요구사항 분석을 통한 시스템 기능 명세, Use-case diagram

     -> Logical View: 설계자 관점, class diagram

     -> Implementation View: 개발자 관점, 컴포넌트들 간의 관계 정의, package diagram

     -> Process View: 시스템 통합 관점, 비기능적 요구사항 기술, activity diagram

     -> Deployment View: 시스템 엔지니어 관점, deployment diagram

 

- SRS(Software Requirement Specification)

요구분석 단계의 요구사항와 스펙을 정리한 산출물, 소프트웨어 프로젝트의 중심이 되는 SW 요구사항명세문서

 

- 요구사항 명세

시스템의 목표를 기술하고, 사용자가 기대하는 기능 요구사항 및 비기능 요구사항을 작성하는 단계

체계적으로 검토, 평가 승인될 수 있는 문서 작성

-> 요구사항 명세서의 평가 기준: 정확성, 명확성, 완전성, 일관성, 중요성

 

- 요구사항 확인(검증)

요구 변경을 최소화하고, 최초 정의된 요구사항에 맞게 구현되었는지 감리 시행을 통해 품질을 보장하는 활동

-> 요구사항 확인 기법

1. 요구사항 검토
2. 프로토타이핑
3. 모델 검증
4. 인수 테스트: 최종 제품이 요구사항을 만족시키는지 확인 가능해야 함, 각각의 요구사항을 어떻게 확인할 것인지 계획 수립

 

- 프로젝트 수행 시 요구사항 봊방을 위한 방안

-> 상세요구사항 분석 -> 요구 분석 -> 분할 발주 -> 보증활동 -> 감리 시행 -> 요구사항 보장

 

- 요구사항의 기술적 타당성 검토

적용기술의 적합성 및 기술실현의 가능성이 분석의 핵심적 내용

-> 성능 및 용량산정 적정성: 성능 관련 비기능 요구사항과 비교하여 적정한지 판단

-> 시스템 간 상호 운용성: 이종 간 시스템 사이의 정보 및 서비스 교환 등 시스템 능력

-> IT 시장 성숙도 및 트렌드 부합성: 유지보수 관점에서 시스템의 시장성과 발전 가능성 확인

-> 기술적 위험 분석: 위험 발생 가능성 및 영향도 파악

 

1.3 분석 모델 확인하기

각 단계에서 어떠한 내용 수행하는지, 정적인지 동적인지 판단해야 함

- 정적인 diagram: class, component, object, composite structure, deployment, package

- 동적인 diagram: activity, use case, state machine, sequence, interaction overview, communication, timing

- 분석모델 검증 과정

-> 1. 유스케이스 모델 검증: 엑터, 유스케이스, 유스케이스 명세서

-> 2. 개념 수준 분석 클래스 검증: 클래스 도출, 속성, 클래스들간의 관계

-> 3. 분석 클래스 검증: 스테레오 타입, 경계 및 제어 클래스 도출

 

- 유스케이스 모델 검증

엑터 모든 엑터가 도출되었는가?
엑터명이 역할 중심인가?
요구사항 정의서/기술서에 외/내부 엑터가 모두 도출되었는가?
엑터가 타당한가?
유스케이스 유스케이스 모두 도출??
논리적??
유스케이스 명세서에 모두 반영?
논리적으로 그룹화??
중복 없음??
유스케이스 명세서 중요항목이 누락되지 않았는가???
주요 이벤트 흐름이 모두 도출되었는가??
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.