[정보처리기사] 1. 요구사항 확인

01 현행 시스템 분석

1. 현행 시스템 분석

1.1 현행 시스템 파악

현행시스템 파악

: 시스템의 구성과 제공 기능, 연계 정보, 기술 요소에 대해 파악

  사용 소프트웨어와 하드웨어,네트워크 구성 파악

 

1.2 현행시스템 파악 절차

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

구성 - 주요 업무를 처리하는 기간 업무/지원 업무로 구분지어 파악

       > 정보시스템의 명칭,주요 기능 명시

       > 모든 정보시스템의 현황 파악이 가능하도록

 

기능 - 단위 업무 시스템이 현재 제공하는 기능 파악

        > 단위 업무 시스템 기능을 주요 기능/하부 기능으로 구분하여 계층형으로 표시

        

인터페이스 - 단위 업무 시스템이 타 시스템과 통신하는 데이터 종류, 형식, 프로토콜, 연계유형, 주기 파악

                  > 데이터 형식,통신규약,연계유형

 

2) 아키텍처 및 소프트웨어 구성 파악

아키텍처 - 기간 업무 수행에 필요한 계층별 기술 요소를 최상위 수준에서 파악

              > 핵심 기간 업무 처리 시스템 기준으로

 

소프트웨어 - 소프트웨어들의 제품명, 용도, 라이선스, 적용 방식, 라이선스 수 파악

   

3) 하드웨어 및 네트워크 구성 파악

하드웨어 - 서버의 위치, 운용 서버의 주요사양, 수량, 이중화 구현 여부 파악

 

네트워크 - 네트워크 장비의 구성

 

1.3 소프트웨어 아키텍처

소프트웨어 아키텍처

: 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 구성요소간 관계를 표현하는 시스템 구조

 

소프트웨어 아키텍처 프레임워크

: 아키텍처가 표현해야하는 내용, 관계를 제공하는 아키텍처 기술 표준

 - 아키텍처 명세서, 이해관계자, 관심사, 관점, 부, 근거

 

소프트웨어 아키텍처 4+1 뷰 개념

: 4개의 분리된 구조의 아키텍처 개념(논리 뷰, 구현 뷰, 프로세스 뷰, 배포 뷰) + 유스케이스

 이 때 유스케이스는 시스템의 요구사항을 충족시키는지 증명하기 위한 체크 방법

 

1.4 현행 시스템 분석서 작성 및 검토

1) 현행 시스템 자료 수집                                                            

정보시스템 구성,기능,인터페이스 자료 수집팀

시스템 아키텍처,소프트웨어 자료 수집팀

하드웨어, 네트워크 자료 수집팀

 

2) 수집 자료 분석

위에서 취득한 자료를 바탕으로 분석 

 

3) 분석한 결과를 기반으로 산출물 작성

취득 자료를 분석으로 이슈나 문제점 포함하여 산출물 작성

 

4) 산출물에 대한 검토 수행

상호 검토하여 의견 제시 후 의견 반영하여 산출물 수정,완료

 

2. 개발 기술 환경 정의

2.1 개발 기술 환경 현행 시스템 분석

2.1.1 운영체제 현행 시스템 분석

1) 운영체제 개념

: 컴퓨터가 제공하는 하드웨어, 소프트워어를 사용가능하게 하며 사용자와 하드웨어 간 인터페이스 담당

 

2) 운영체제 현행 시스템 분석

- 품질 측면 : 신뢰도,성능

- 지원 측면 : 기술 지원, 주변 기기, 구축 비용

 

3) 운영체제 종류 및 특징

- PC : 윈도즈, 유닉스 , 리눅스

- 모바일 : 안드로이드 , iOS

 

2.1.2 네트워크 현행 시스템 분석

1) 네트워크 개념

: 컴퓨터 장치 노드 간 연결을 사용하여 데이터 교환 가능하게 함

- 유선 매체 : 광케이블

- 무선 매체 : 와이파이

 

2) OSI 7계층

: 응용, 표현, 세션, 전송, 네트워크, 데이터 링크, 물리

3) 네트워크 현행 시스템 분석

: 백본망, 라우터, 스위치, 게이트웨이, 방화벽 등 조사

 

2.1.3 DBMS 현행 시스템 분석

1) DBMS의 개념

: 데이터 집한인 데이터베이스 만들고 저장 관리하도록 기능 제공

 

2) DBMS의 기능

: 중복 제어, 접근 통제, 인터페이스 제공, 관계 표현, 샤딩/파티셔닝, 무결성 제약조건, 백업 및 회복

 

3) DBMS 현행 시스템 분석

데이터베이스의 가용성, 성능, 기술 지원, 호환성, 구축 비용 분석

 

2.1.4 미들웨어의 현행 시스템 분석

1) 미들웨어의 개념

: 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간 원만한 통신 가능하도록 제어

 

2) 웹 애플리케이션 서버의 개념

: 서버계층에서 애플리케이션이 동작할 수 있는 환경 제공

 안정적인 트랜잭션 처리,관리, 타시스템과 애플리케이션 연동

 

3) 미들웨어의 현행 시스템 분석

: 가용성, 성능, 기술 지원, 구축 비용 분석

 

2.1.5 오픈 소스 사용 시 고려 사항

: 라이선스 종류, 사용자 수, 기술의 지속가능성 고려

 자유 배포, 소스 코드 공개, 파생작업 허용, 소스 코드 일관성 확보, 라이선스 배포 등

 

2.2 개발 기술 환경 요구사항 파악

2.2.1 기술 환경 정의를 위한 자료 수집

- 수집 자료 목록, 조사 항목 설정 후 자료와 인터뷰 기록 분석

 

2.2.2 조사 자료 분석 및 개발 기술 환경 설정

- 조사 자료 바탕으로 운영체제, DBMS, WAS 등을 결정

- 고려 사항을 반영하여 개발 기술 환경 결정

 

2.2.3 요구사항 정의서, 목표 시스템 구성도 반영 및 검토

- 시스템 용량 산정 결과 -> 요구사항 정의서, 목표 소프트웨어 구성도, 목표 하드웨어 구성도에 반영

- 팀별 산출물 상호 검토하여 의견 제시 -> 의견 반영하여 수정 후 완료

02 요구사항 확인

1. 요구사항 

1.1 요구사항의 분류

: 문제 해결, 목적 달성을 위해 고객에 의해 요구되거나 표준,명세를 만족시키기 위한 서비스 혹은 제약사항

 

1) 기능적 요구사항

- 입출력, 프로세스

> 기능성, 완전성, 일관성 

 

2) 비기능적 요구사항

- 품질 속성, 제약조건

> 신뢰성, 사용성, 효율성, 유지보수성, 이식성

 

3) 요구사항 개발 프로세스

    도출 -> 분석 -> 명세 -> 확인

 

4) 요구사항 관리 프로세스

요구사항 협상 - 우선순위 설정, 시뮬레이션

요구사항 기준선 - 공식 회의, 형상 관리

요구사항 변경 관리 - CCB, 영향도 분석

요구사항 확인 및 검증 - 확인 및 검증

 

1.2 요구사항 분석

요구사항 분석 기법 - 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석

 

1.3 요구사항 확인

요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트

 

1.4 요구사항 확인 프로세스

요구사항 목록 확인, 요구사항 정의서 작성 여부 확인,

비기능적 요구사항 확인, 타 시스템 연계 및 인터페이스 요구사항 확인

 

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

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

- 성능 및 용량 산정의 적정성, 시스템 간 상호 운용성, IT 시장 성숙도 및 트렌드 부합성, 기술적 위험 분석

 

2.2 요구사항의 기술적 타당성 분석 프로세스

- 타당성 분석 결과 기록, 타당성 분석 결과의 이해관계자 검증, 타당성 분석 결과 확인 및 배포/공유

 

3. 비용산정 모델

3.1 비용산정 모델 개념

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

 

3.2 비용산정 모델 분류

하향식 산정 방법 : 전문가에게 비용산정 의뢰하거나 전문가 조정자를 통한 산정

상향식 선정 방법 : 세부적인 요구사항,기능에 따라 비용 산정 

 

3.3 하향식 비용산정 모델

- 전문가 판단 : 경험 많은 전문가가 비용 산정

- 델파이 기법 : 전문가가 미례 예측 + 조정가

 

3.4 상향식 비용산정 모델

- LoC : 기능별 원시 코드 라인 수의 비관치, 낙관치, 기대치 측정하여 예측 -> 비용 산정

- Man Month : 프로그래머의 월간 생산성 * 인력

- COCOMO : 프로그램 규모에 따라 비용 산정, 개발 노력 승수를 결정

- 푸트남 모형 : 개발 주기의 단계별 인력 분포 가정

- 기능 점수(FP) :요구기능에 가중치 부여하여 기능 점수로 계산하여 산정

03 분석 모델 확인하기

1. 분석 모델 검증

1.1 분석 모델 검증 방법

유스케이스 모델 검증 : 유스케이스 모형 상세화 수준,적정성 검증을 위해 액터, 유스케이스, 유스케이스 명세서 점검

개념 수준의 분석 클래스 검증 : 도메인 개념을 분석 클래스로 도출하는데 이 때 적절성, 명확성 점검

분석 클래스 검증 : 유스케이스 실현에 필요한 분석 클래스 도출 확인

 

1.2 분석 모델 검증 프로세스

검토의견 컬럼 추가 : 분석 모델까지 요구사항 추적표 작성, 검토의견 컬럼 추가

검토의견 작성 : 유스케이스 모델에 대한 검토의견 작성

검토의견 정제 : 요구사항에 대한 검토의견 정제

 

2. 분석 모델의 시스템화 타당성 분석

2.1 분석 모델의 기술적 타당성 검토

성능 및 용량 산정의 적정성 : 시스템 자원 식별

시스템 간 상호 운용성 : 시스템 간 상호 정보, 서비스 교환이 가능한지 검토

IT 시장 성숙도 및 트렌드 부합성 : 트렌드에 부합하는지 확인

기술적 위험 분석 : 시스템의 기술 구조, 프레임워크, 하드웨어, 소프트웨어와 부합하는지

 

2.2 분석 모델의 시스템화 타당성 분석 프로세스

타당성 검토의견 컬럼 추가

타당성 검토의견 작성

타당성 분석 결과 검증

타당성 분석 결과 확인 및 배포/공유

 

[ 간단 리뷰 ] 

가독성이 많이 떨어질 것 같지만 챕터별 내용이 생각보다 많아서 한 페이지에 작성하려면 이게 최선일 것 같습니다. 

요구사항 확인의 경우 이전에 정처기 설명에서 말했듯이 소프트웨어 공학에서 언급되는 내용이 주를 이룹니다. 

그래서 용어는 딱히 낯설지 않지만 전반적으로 이해하고 넘어가는 내용과 암기해야할 양이 있는 편이여서 생각보다 시간이 걸렸습니다.

현업 입장에서 바라봤을 때 요구사항 확인은 진짜 중요하다고 생각합니다. 

SM 업무를 하다보면 주기적으로 신규 개발건이 들어오고 현행 시스템을 보완할 일들이 생기는 데

이 때 이해관계자 간의 요구사항 확인이 간소하게 이뤄지면서 위의 내용들을 고려하며 진행해야합니다. 

SI 업무라면 요구사항 확인의 중요성이 더 커질 것 같습니다. 

요약하자면 챕터 1의 내용이 소프트웨어공학의 내용과 연계되며

현업에서도 굉장히 중요한 부분이라는 점을 염두하길 바랍니다.  

 

> 다음글 보러가기