[정보처리기사 실기] 1. 요구사항 확인-Chapter 2. 요구사항 확인

정리 내용은 [수제비 2020 정보처리기사 실기]책을 기반으로 작성하였습니다.

2020 수제비 정보처리기사 실기(1권+2권 합본세트)

---

1. 요구사항

개념
문제의 해결 또는 목적을 달성을 위하여 고객에 의해 요구되거나 표준이나 명세 등을 만족하기 위하여 시스템이 가져야 하는 서비스 또는 제약사항

분류

기능적요구사항	비기능적 요구사항
시스템이 제공하는 기능, 서비스에 대한 요구사항	시스템이 수행해야 하는 기술 이외의 사항. 시스템 구축에 대한 제약사항에 관한 요구사항
특정 입력에 대해 시스템의 반응 기술 특정 상황에 대해 시스템의 동작 기술	품질 속성에 관련하여 시스템의 기술 시스템이 준수해야할 제약조건에 대한 기술
기능성 / 완전성 / 일관성	신뢰성, 사용성, 효율성, 유지보수성, 이식성

개발 프로세스
[1단계] 요구사항 도출
요구사항이 어디에 있고, 어떻게 수집할 것인지 파악하는 단계
이해관계자가 요구사항을 식별, 개발팀과 고개사이의 관계 형성
다양한 이해관계자와 효율적인 의사소통 중요
기법: 인터뷰 / 설문조사 / 브레인스토밍 / 워크숍
[2단계] 요구사항 분석
상충되는 요구사항을 해결, 소프트웨어범위 파악, 소프트웨어가 환경과 어떻게 상호작용하는지 이해하는 관계
시스템 요구사항을 정재하여 소프트웨어 요구사항 도출
기법: 자료흐름지향분석(데이터 흐름,DFD로 소프트웨어 구조 유출) / 객체지향분석(시스템의 기능과 데이터를 함께 분석 & UML로 표준화)
[3단계] 요구사항 형성
체계적으로 검토, 평가, 승인될 수 있는 문서를 작성
요구사항 명세에서는 시스템 정의, 시스템 요구사항, 소프트웨어 요구 사항 작성
기법: 자연어에 의한 방법 / 정형화에 의한 방법
[4단계] 요구사항확인
요구사항 문서가 표준에 적합하고, 이해 가능하며, 일관성 있고, 완전한지 점검
기법: 동료검토(2~3명이 진행하는 리뷰) / 워크스루(회의 전 배포하여 사전 검토 후 리뷰) / 인스팩션(다른 전문가 또는 팀이 검사)

 

요구사항 관리 프로세스 및 기법

요구사항 협상: 우선순위 설정, 시물레이션
2. 요구사항 기준: 공식 회의, 형상관리
3. 요구사항 변경 관리: CCB, 영향도 분석
4. 요구사항 확인 및 검증: 확인 및 검증

 

요구사항 분석
요구사항 분류: 요구사항이 기능인지 비기능인지 확인 / 요구사항이 소프트웨어에 미치는 영향의 범위 파악 / 요구사항이 소프트웨어 생명주기 동안 변경이 발생하는지 확인
개념 모델링: 개념 모델은 문제 도메인의 엔티티들과 개별 관계 및 종속성 반영 / 시나리오는 나타내기 위해 유스케이스 다이어그램 주로 사용 / 대부분의 모델링 표기법 UML 사용
요구사항 할당: 요구사항을 만족시키기 위한 아키텍쳐 구성요소를 식별 / 다른 구성요소와 어떻게 상호작용하는지 분석을 통해 추가적인 요구사항의 발견 가능
요구사항 협상: 두명의 이해관계자가 서로 상충되는 내용을 요구하는 경우, 어느 한 쪽을 지지하기보다는 적절히 합의
정형 분석: 형식적으로 정의된 의미를 지닌 언어로 요구사항 표현 / 요구사항 분석의 마지막 단계에서 이루어짐

 

요구사항 확인
요구사항 문서가 기업의 표준에 적합하고, 이해 가능하고, 일관성이 있고, 완전한지 검증해야 함
요구사항 검토: 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이를 검토 / 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서를 완성한 시점에서 검토
프로토타이핑: 새로운 요구사항을 도출하기 위한 수단 및 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 사용 / 요구사항이 잘못된 경우 피드백 제공, 사용자 인터페이스의 동적인 행위가 문서나 그래픽 모델보다 이해 용이
모델 검증: 분석단계에서 개발된 모델의 품질 검증 필요 / 객체 모델의 경우 객체들 사이의 존재하는 의사소통 경로를 검증하기 위한 정적 분석 수행에 유용
인수 테스트: 요구사항의 주요한 속성은 최종 제품을 기준으로 요구사항을 만족시키는지 확인 가능해야 함 / 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획 수립 후 요구사항 확인하는 테스트

 

요구사항 확인 프로세스
1. 요구사항 목록 확인: 요구사항 목록에서 업무기능에 대한 요구사항 반영 여부 확인
2. 요구사항 정의서 작성 여부 확인: 요구사항 목록 중 수용인 경우, 요구사항 정의가 작성되었는지 확인 / 요구사항 정의서에서 시스템 동작방식을 명확하고 구체적으로 기술하였는지 확인
3. 비기능적 요구사항의 확인: 시스템 특성, 품질, 제약사항 등 비기능적 요구사항이 명확하게 도출되었는지 검토 / 성능, 가용성, 사용 용이성, 유지보수 용이성, 안전성, 보안성 등에 대한 요구사항의 문서화 여부 확인
4. 타시스템 연계 및 인터페이스 요구사항 확인: 타 시스템 또는 하위 시스템 등과의 모든 인터페이스 요구사항이 정의도어 있는지 확인 / 인터페이스 구분(내부/외부), 주기, 방법, 제공자, 요청자 등이 명확하게 정의되어 있는지 확인

 

2. 요구사항의 시스템화 타당성 분석

요구사항의 기술적 타당성 검토
1. 성능 및 용량의 산정의 적적성: 목표시스템의 용량이 산정되면, 과거 유사 프로젝트 경험치를 적용하여 필요시 재조정한 후, 성능 관련 비기능 요구사항과 비교하여 적정성 여부 판단
2. 시스템 간 상호 운용성: 요구사항 중 목표시스템이 조직 내외 타 시스템과의 연동을 요구하는 경우, 상호 운용이 가능한지 여부 판단
3. IT 시장 성숙도 및 트랜드 부합성: 시스템 구축 시 요구되는 영역별 기술들의 시장 성숙도 및 발전 방향을 파악하고, 요구사항이 이에 부합되는지 판단. 향후 사용되지 않을 가능성이 높은 향후 유지보수가 여려운 상황 발생
4. 기술적 위험 분석: 요구사항을 만족시키기 위하여 적용한 기술의 복잡성, 검증 여부, 의존성, 등에 대하여 위험 발생 가능성, 영향도 파악

 

요구사항 기술적 타당성 분석 프로세스
[1단계] 타당성 분석 결과 기록
[2단계] 타당성 분석 결과의 이해검증자 검증
[3단계] 타당성 분석 결과 확인 및 배포/공유

 

3. 비용산정 모델

개념
소프트웨어 규모 파악을 통한 투입자원, 소요시간을 파악하여 실해 가능한 계획을 수립하기 위해 비용을 산정하는 기법

 

분류
1. 하향식 비용산정 모델
경험 많은 전문가에게 비용산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정
전문가 판단: 조직 내에 있는 경험이 많은 두명 이상의 전문가에 비용산정 의뢰하는 기법
델파이 기법: 전문가의 경험적 지식을 통한 문제해결 및 미래 예측을 위한 기법. 전문가들의 편견이나, 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성
2. 상향식 비용산정 모델
세부적인 요구사항 기능에 따라 필요한 비용을 계산
코드라인수(Loc): 소프트웨어 각 기능의 원시라인 코드 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정

Man Month: 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 기법
(Man Month=LoC ÷ 프로그래머 월간 생산성 / 프로젝트 기간=Man Month ÷ 프로젝트 인력)
COCOMAO: 보헴이 제한한 모형으로 프로그램 규모에 따라 비용산정
- 단순형: 중소규모의 소프트웨어, 일괄자료 처리나 과학기술 계산용, 비즈니스처리 개발. 5만 라인 이하
- 중간형: 단순형과 임베디드의 중간. 트랜젝션 처리, 운영체제, DB 관리 시스템 개발 30만 라인 이하
- 임베디드형: 초대형 규모의 트랜젝션 처리 시스템이나 운영체제 개발에 적용. 30만 라인 이상
푸트남 모형: 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 모형. 자동화 추정도구 SLIM있음
기능점수: 요구기능을 증가시키는 인자별로 가중치를 부여하여 기능점수를 계산하여 비용을 산정
입력, 출력, 질의, 파일 인터페이스의 개수로 소프트웨어 규모 표현, 경험을 바탕으로 단순 보통, 복잡한 정도에 따라 가중치를 부여