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

요구 사항

 

요구사항 개념

 

(1) 요구공학 : 요구 반영되는 시스템을 개발하기 위해 도출, 분석, 명세, 확인 및 검증 하는 구조화된 활동

 

(2) 목적

- 효과적인 의사소통 수단을 제공하고 요구 사항에 대한 공통 이해 선정, 오류로 인한 불필요한 비용 절감하고 요구사항 변경 추적 가능, 개발 비용과 시간을 절약하고 효과적인 의사소통 수단 제공

 

(3) 분류 : 시스템의 요구사항에 대한 파악 -> 기능적 비기능적으로 나뉨

기능적 요구사항	비기능적 요구사항
시스템 제공하는 기능 서비스에 대한 요구사항	시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구 사항
특정 입력에 대한 시스템이 어떻게 반응 및 동작 해야하는지 기술	품질에 관련해 시스템이 갖춰야할 사항에 관한 기술, 제약 조건 기술
기능성, 완전성, 일관성	신회성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약 사항

 

요구 공학 프로세스

- 요구 사항 프로세스 = 요구사항 개발 단계 + 요구사항 관리 단계

 

(1) 요구사항 개발 프로세스

- 도출 -> 분석 -> 명세 -> 확인 및 검증

• 요구사항 도출 : 해결 문제 이행, 추상적 요구 식별, 수집 된 요구 구체적 표현, 이해관계자 식별 -> 의사소통 중요
  • 활동 : 고객 분석, 조직 환경 분석, 후보 요구사항 분류, 후보 요구사항 정제, 요구사항 소스 관리
• 요구사항 분석 : 충졸, 중복, 누락등 완전성과 일관성 확보, SW 범위 파악과 상호 작용 이해 단계
  • 활동 : 요구사항 정제 SW 요구사항 분류, 후보 요구 모델링, 우선순위 부여, 릴리즈 요구사항 선정, 협의
  • 비용과 일정에 대한 제약 설정, 타당성 조사, 정의 문서화 실행
• 요구사항 명세 : 체계적 검토, 평가, 승인 될 수 있는 문서 작성
  • 활동 : 요구사항 명세 기준 정의, 요구사항 명세서 작성, 요구사항 추적 관련 정보 저장
• 요구사항 확인 및 검증 : 확인 후 적합한지 이해, 일관성 있고, 완전한지 검증 단계
  • 활동 : 요구사항 명세서 검토, 용어 검증, 베이스라인 수립

(3) 개발 단계

 

(3) - 1 요구사항 도출 단계

• 인터뷰 : 관계자와 대화 통해 공식, 비공식적 정보 수집
• 브레인스토밍 : 아이디어 비판 없이 수용 회의
• 델파이 기법 : 전문가의 경험 지식 통해 문제 해결 및 미래 예측
• 롤 플레잉 : 장면 설정, 역할을 연기해 요구사항 분석하고 수집
• 워크숍 : 집중적인 노력 통해 전문적인 정보 획득 공유, 모든 인원이 참여, 팀 협력이 필요하며 사전 준비 요구
• 설문 조사 : 설문지 또는 여론조사 간접적 정보 수집

(3) - 2 요구사항 분석 단계

- 분석 통해 완정성과 일관성 확보

 

절차

• 요구사항 분류 : 기능 비기능 확인, SW 영향 범위 파악, 생명 주기 동안 변경 파악, 요구사항에서 유도된 것인지 다른 원천인지 파악
• 개념 모델링 생성 및 분석 : 상황 단순화, 개념적 표현 -> 모델, 엔티티들과 개별 관계 및 종속성 반영
  • 유스케이스 다이어 그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터랙션, 객체 모델, 데이터 모델
  • 표기는 주로 UML 사용
• 요구사항 할당 : 아키텍처 구성요소를 식별하는 활동, 상호 작용하는지 분석 통해 추가적인 요구 발견
• 요구사항 협상 : 상충되는 내용 요구, 지지보다는 합의해 활동, 우선순위 부여해, 저 중요한 것 인식
• 정형 분석 : 의미가 있는 언어로 표현, 구문과 의미 갖는 정형화된 언어 사용해 수학적 기호

단계 기법

• 자료 흐름 지향 분석 : 데이터 흐름도 및 자료 사전으로 구조 유도
• 객체 지향 분석 : 기능과 데이터 함께 분석, UML 표준

분석 기술

• 청취 기술 : 관계자로 의견 듣는 기술
• 인터뷰와 질문 기술 : 만나서 이야기를 나누는 기술
• 분석 기술 : 추출된 요구사항에 충돌, 중복, 누락 분석을 통해 완전성과 일관성 확보
• 중재 기술 : 관계자의 상반된 요구에 대한 중재 기술
• 관찰 기술 : 관찰하면서 사용자가 언급하지 않은 미묘한 의미 탐지
• 작성 기술 : 문서 작성
• 조직 기술 : 수집된 정보를 일관성있게 구조화
• 모델 작성 기술 : 수집 자료 바탕으로 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 쉽게 모델링

(3) - 3 요구사항 명세 단계

- 체계적으로 검토, 평가, 승인될 문서를 작성 단계

- 검증 항목 : 명확성, 완전성, 검증 가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성

 

주요 기법

• 비정형 명세 기법 : 자연어를 기반으로 서술, 사용자와 개발자 이해가 용이, 명확성 및 검증에 문제
• 정형 명세 기법 : 수학적인 원리와 표기법 서술, Z-스키마, Petri Nets, 상태차트 활용, 간결하고 명확하고 검증이 용이, 이해가 어려움

산출물로써 요구사항 명세서가 존재한다.

 

(3) - 4 요구사항 확인 및 검증 단계

- 올바르게 기술되었는지 검토, 베이스라인 설정, 확인하고 요구사항 표준에 적합한지, 일관한지, 완전한지 검증

- 개발 단계나 운영 중인 상태에서 발견 된다면 오류 수정 및 재작업 비용 소모

 

확인 및 검증 절차

- 요구사항 목록 확인 -> 요구사항 정의서 작성 여부 확인 -> 비기능적 요구사항의 확인 -> 타 시스템 연계 및 인터페이스 요구사항 확인

 

요구사항 정의서 목록

- ID, 이름, 유형, 품질 속성, 우선순위, 중요도, 출처, 관련 부서, 전제 조건, 내용, 관련 요구사항, 버전, 수용 여부

 

확인 및 검증 단계 기법

• 요구사항 검토 : 차이 검토, 시스템 정의서, 사양서, 요구사항 명세서 환성한 시점에서 검토
• 정형 기술 검토
  • 동료 검토, 워크 스루, 인스펙션
  • 관리 리뷰 : 전반적인 검토 바탕으로 범위, 일정, 인력 대한 통제 및 의사 결정 지원 리뷰
  • 기술 리뷰 : 명세 준수 여부 검토, 적절 구현 -> 대안 추천 검토
  • 인스펙션 : 동료검토라고 불린다.
  • 워크 스루 : 짧은 시간 동안 회의 진행해 리뷰 -> 가장 비형식적인 검토 기법
  • 감사 : 표준, 가이드라인, 계획 절차 준수한지 독립적 평가 -> 제공자, 소비자, 제 3기관
• 프로토타이핑 활용 : 기능 일부 개발해 시연을 통해 경험, 피드백 제공, 이해가 문서나 그래픽 모델보다 용이
• 모델 검증 : 모델 품질 검증, 의사소통 경로 검증위한 정적 분석 수행에 유용
• 테스트 케이스 및 테스트 통한 확인 : 요구사항 만족시키는지 확인 가능해야함, 계획 수립하고 테스트 케이스 작성, 작성 후 단계별 테스트 및 인수 테스트(알파, 베타)에 사용
• CASE 도구 활용 검증 : 자동화된 일관성 분석 제공, 관계자들이 요구사항 명세서 검토가 필요하니 형상 관리 가능한 CASE이용
• 베이스라인 통한 검증 : 추적하고 통제하는 시점인 베이스라인을 통한 요구사항 지속적 검증 수행
• 요구사항 추적표 : 정의서 기준 개발단계별 최종 산출물이 어떻게 반영되고 변경되었는지 확인

(4) 요구사항 관리 단계

- 일치성과 무결성 제공 위해 변경제어와 추적등 일련의 관리를 수행 -> 산출물 = 요구사항 변경 요청서, 변경 승인서, 추적표

 

관리 단계 절차

• 요구사항 협상 : 구현 가능 기능 협상 : 우선순위 설정, 시뮬레이션
• 요구사항 기준선 설정 : 명세서 통해 기준선 설정 : 공식 회으, 형상 관리
• 요구사항 변경 관리 : 모든 변경 공식적 통제 : 형상통제 위원회, 영향도 분석
• 요구사항 확인 및 검증 : 기대한 요구사항에 부합한지 확인 : 확인 및 검증

 

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

 

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

- 성능 및 용량의 적정성, 상호 운용성, 시장 성숙도 및 트렌트 부합성, 기술적 위험 분석 거친다

 

순서

• 성능 및 용량 산정의 적정성 : 목표 시스템의 용량이 산정되면, 재조정한 후, 비기능 요구사항과 비교해 적정성 여부 판단
• 시스템 간 상호 운용성 : 조직 내외 타 시스템과 연동을 요구하는 경우, 운용이 가능한지 판단
• IT 시장 성숙도 및 트렌드 부합성 : 성숙도 및 발전 방향 파악 후 부한한지 파악, 사용되지 않을 가능성이 높은 시스템들은 향후 유지보수가 어려운 상황이 발생
• 기술적 위험 분석 : 적용한 기술의 복잡성, 검증 여부, 의존성에 대해 위험 방생 가능성, 영향도 파악

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

순서

• 타당성 분석 결과 기록 : 속성을 추가하고 타당성 분석 결과 기록
  • 성능 용량 시스템 간 상호 운용성, 시장 성숙도 및 트렌드 부합성, 기술 복잡성, 기술 검증 여부, 기술 의존성
• 타당성 분석 결과의 이해관계자 검증 : 관계자에게 배포해 사전 검토 요청, 시스템화 타당성 분석 결과 검증, 중재 하에 합의
• 타당성 분셕 결과 확인 및 배포 공유 : 결정자가 확인 후 배포 공유