수제비 2022 정보처리기사 실기 수험서를 보고 공부한 기록입니다.
[요구사항 개념]
1. 요구공학(Requirements Engineering)의 개념
요구공학은 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동이다
2. 요구공학의 목적
- 이해관계자 사이에 효과적인 의사소통 수단을 제공하고 시스템 개발의 요구사항에 대한 공통된 이해를 설정한다
- 요구사항 누락 방지 및 이해 오류로 인한 불필요한 비용을 절감하고 요구사항 변경 추적을 가능하게 한다
- 초기 요구사항 관리로 개발 비용과 시간을 절약하고 효과적인 의사소통 수단을 제공한다
3. 요구사항의 분류
- 요구사항 파악의 기본은 시스템의 요구사항에 대한 파악이다
- 요구사항은 기능적 요구사항과 비기능적 요구사항으로 분류된다
| 구분 | 기능적 요구사항 | 비기능적 요구사항 |
|---|---|---|
| 개념 | -시스템이 제공하는 기능, 서비스에 대한 요구사항 | -시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항 |
| 도출 방법 | -특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술 -특정 상황에 대해 시스템이 어떻게 동작해야 하는지에 대한 기술 | -품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술 -시스템이 준수해야 할 제한 조건에 관한 기술 |
| 특성 | -기능성, 완전성, 일관성 | -신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약 사항 |
| 사례 | -온라인 홈페이지에서는 쇼핑카트에 주문하고자 하는 품목을 저장할 수 있는 장바구니 기능을 제공해야 함 -상품의 결제수단은 신용카드, 무통장 입금, 포인트 결제가 가능해야 함 | -특정 함수의 호출시간은 3초를 넘지 않아야 함 -시스템은 하루 24시간 가동되어야 하며 가동률 99.5%를 만족해야 함 -시스템은 운영되는 중에 패치 및 업그레이드를 할 수 있어야 함 |
[요구공학 프로세스]
요구사항 프로세스는 요구사항 개발 단계와 요구사항 관리 단계로 구성된다
1. 요구사항 개발 단계 구성(CMM Level 3 프로세스 영역)
- 요구사항 도출(Elicitatiton)
- 소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구 사항을 구체적으로 표현하는 단계
- 도출 단계에서 이해관계자(Stakeholder)가 식별되고, 개발팀과 고객 사이의 관계 형성되며 다양한 이해관계자와 효율적인 의사소통이 중요
- 주요 활동으로는 고객 분석, 조직 환경 분석, 후보 요구사항 분류, 후보 요구사항 정제, 요구사항 소스 관리가 있음
- 요구사항 분석(Analysis)
- 도출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계
- 요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해하는 단계
- 주요 활동으로는 시스템 요구사항을 정제하여 소프트웨어 요구사항 분류, 후보 요구사항 모델링, 요구사항의 우선순위 부여, 해당 릴리즈에 수행할 요구사항 선정, 요구사항 협의가 있음
- 요구사항 분석 활동으로 비용과 일정에 대한 제약설정, 타당성 조사, 요구사항 정의 문서화 수행
- 요구사항 명세(Specification)
- 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계
- 동의한 요구사항을 하나 이상의 형태로 저장하여 정형화된 요구사항을 생성하는 활동 수행
- 주요 활동으로는 요구사항 명세 기준 정의, 요구사항 명세서 작성, 요구사항 추적 관련 정보 저장이 있음
- 요구사항 확인 및 검증(Validation & Verification)
- 분석가가 요구사항을 이해했는지 확인(Validation)하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증(Verification)하는 단계
- 요구사항 명세서 검토, 요구사항 용어 검증, 요구사항 베이스라인 수립
- 이해관계자들이 요구사항 문서 검토 및 요구사항 관리 툴을 이용하여 요구사항 정의 문서들에 대한 형상 관리 수행
- 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증 수행
2. 요구사항 개발 단계 상세
① 요구사항 도출 단계
요구사항 도출 단계는 소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계이다
- 인터뷰(Interview)
- 이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집 방법
- 브레인스토밍(Brainstorming)
- 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판없이 수용할 수 있도록 하는 회의
- 델파이 기법(Delphi Method)
- 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법
- 롤 플레잉(Role Playing)
- 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
- 워크샵(Workshop)
- 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법
- 프로젝트에 참여하는 모든 핵심 인물의 참여가 필요
- 참석자들은 해당 전문 영역별로 팀 협력이 필요하며 사전 준비가 요구
- 설문 조사(Survey)
- 설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집하는 방법
- 개발될 시스템의 사용자가 다수일 때 의견 수렴에 용이
② 요구사항 분석 단계
요구사항 분석 단계는 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계이다
- 요구사항 분류
- 요구사항이 기능인지 비기능인지 확인하는 활동
- 요구사항이 소프트웨어에 미치는 영향의 범위를 파악
- 요구사항이 소프트웨어 생명주기 동안 변경이 발생하는지를 확인
- 하나 이상의 상위 요구사항에서 유도된 것인지 또는 이해관계자나 다른 원천으로부터 직접 발생한 것인지 분류
- 개념 모델링 생성 및 분석
- 요구사항을 더 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화, 개념적으로 표현한 것을 모델이라고 하며, 모델링은 이러한 모델을 만드는 활동
- 개념 모델은 문제 도메인의 엔티티(Entity)들과 개별 관계 및 종속성을 반영
- 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model), 상태 모델(State Model), 목표기반 모델(Goal-Based Model), 사용자 인터랙션(User Interactions), 객체 모델(Object Model), 데이터 모델(Data Model) 등과 같은 다양한 개념 모델 작성 가능
- 모델링 표기는 주로 UML을 사용
- 요구사항 할당
- 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별하는 활동
- 다른 구성요소와 어떻게 상호 작용하는지 분석을 통해 추가적인 요구사항 발견 가능
- 요구사항 협상
- 두 명의 이해관계자가 서로 상충되는 내용을 요구하는 경우, 어느 한 쪽을 지지하기보다는 적절한 지점에서 합의하기 위한 활동
- 요구사항이 서로 충돌되는 경우에 각각에 우선순위를 부여하면, 무엇이 더 중요한지를 인식할 수 있기 때문에 문제 해결에 도움이 됨
- 정형 분석
- 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현하는 활동
- 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현
- 요구사항 분석의 마지막 단계에서 이루어짐
요구사항 분석 단계 기법에는 자료 흐름 지향 분석, 객체 지향 분석이 있다
| 기법 | 설명 |
|---|---|
| 자료 흐름 지향 분석 | 데이터 흐름도 및 자료 사전으로부터 소프트웨어 구조를 유도하는 방법 |
| 객체 지향 분석 | 시스템의 기능과 데이터를 함께 분석, UML로 표준화 |
다양한 요구사항을 분석하기 위해서 청취 기술, 인터뷰와 질문 기술, 분석 기술, 중재 기술, 관찰 기술, 작성 기술, 조직 기술, 모델작성 기술도 사용한다
| 분석 기술 | 설명 |
|---|---|
| 청취 기술 | 이해관계자로부터 의견을 듣는 기술 |
| 인터뷰와 질문 기술 | 이해관계자를 만나 정보를 수집하고 이야기를 나누는 기술 |
| 분석 기술 | 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 기술 |
| 중재 기술 | 이해관계자들의 상반된 요구에 대한 중재기술 |
| 관찰 기술 | 사용자가 작업하는 것을 관찰하면서 사용자가 언급하지 않은 미묘한 의미를 탐지할 수 있는 기술 |
| 작성 기술 | 문서 작성기술 |
| 조직 기술 | 수집된 방대한 정보를 일관성 있는 정보로 구조화하는 능력 |
| 모델 작성 기술 | 수집한 자료를 바탕으로 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해하기 쉽도록 모델로 작성하는 기술 |
③ 요구사항 명세 단계
요구사항 명세 단계는 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계이다
▼요구사항 명세 단계 주요 기법
- 비정형 명세 기법
- 비정형 명세 기법은 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법
- 사용자와 개발자의 이해가 용이
- 명확성 및 검증에 문제
- 정형 명세 기법
- 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법
- 정형 명세 언어인 Z-스키마, Petri Nets, 상태차트 활용
- 표현이 간결, 명확성 및 검증이 용이
- 기법의 이해가 어려움
요구사항 명세 단계의 산출물로 요구사항 명세서가 있다
▼요구사항 명세 원리 및 검증 항목
- 명확성: 각각의 요구사항 명세 내용은 하나의 의미만 부여해야 함
- 완전성: 기능, 성능, 속성, 인터페이스, 설계 제약 등에 관한 모든 시스템 요구사항이 포함되어야 함
- 검증 가능성: 요구사항 내용의 충족 여부와 달성 정도에 대한 확인이 가능해야 함
- 일관성: 요구사항의 내용 간 상호 모순이 없어야 함
- 수정 용이성: 요구사항 변경 시 쉽게 수정 가능해야 함
- 추적 가능성: 각 요구사항 근거에 대한 추적과 상호참조가 가능해야 함
- 개발 후 이용성: 시스템 개발 후 운영 및 유지보수에 효과적인 이용이 가능해야 함
④요구사항 확인 및 검증 단계
- 요구사항 확인 및 검증은 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대한 검토, 베이스라인을 설정하는 활동이다
- 프로젝트 참여자들이 요구사항을 이해했는지 확인(Validation)하고 요구사항 문서가 회사의 표준에 적합한지, 일관성을 만족하는지, 완전한지를 검증(Verification)해야 한다
- 요구사항 명세서의 오류가 개발 단계나 운영 중인 상태에서 발견된다면 오류 수정 및 재작업 비용이 많이 소요되므로 요구사항 확인 및 검증은 반드시 필요하다
▼요구사항 확인 및 검증 절차
- 요구사항 목록 확인
- 요구사항 목록에서 업무 기능에 대한 요구사항 반영 여부 확인
- 요구사항 정의서 작성 여부 확인
- 요구사항 목록 중 수용인 경우, 요구사항 정의서(유스케이스 명세서)가 작성되었는지 확인
- 요구사항 정의서(유스케이스 명세서)에서 시스템의 동작 방식을 명확하고 구체적으로 기술하고 있는지 검토
- 비기능적 요구사항의 확인
- 시스템 특성, 품질, 제약사항 등 비기능적 요구사항이 명확하게 도출되었는지 검토
- 성능, 가용성, 사용 용이성, 유지보수 용이성, 안전성, 보안성 등에 대한 요구사항의 문서화 여부 확인
- 타 시스템 연계 및 인터페이스 요구사항 확인
- 타 시스템 또는 하위 시스템 등과의 모든 인터페이스 요구사항이 정의되어 있는지 확인
- 인터페이스 구분(내부/외부), 주기, 방법, 제공자, 요청자 등이 명확하게 정의되어 있는지 확인
▼요구사항 확인 및 검증 단계의 주요 기법
요구사항 검토
- 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토
- 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자 1명 이상 포함 필요
- 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서를 완성한 시점에서 검토
정형 기술 검토 활용
- 동료 검토(Peer Review)
- 2~3명이 진행하는 리뷰의 형태
- 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행
- 워크 스루(Walk Through)
- 오류를 조기에 검출하는 데 목적
- 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화
- 인스펙션(Inspection)
- 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
프로토타이핑 활용
- 개발할 시스템에 대한 주요 기능이나 일부분을 개발하여 최종 사용자나 고객을 대상으로 시연하면서 시스템이 작동하는 모습을 경험할 수 있게 하여 요구사항을 확인
- 요구사항이 잘못된 경우 유용한 피드백 제공
- 사용자 인터페이스의 동적인 행위에 대한 이해가 문서나 그래픽 모델보다 용이
모델 검증
- 분석단계에서 개발된 모델의 품질 검증 필요
- 객체 모델의 경우 객체들 사이의 의사소통 경로를 검증하기 위한 정적 분석 수행에 유용
테스트 케이스 및 테스트를 통한 확인
- 요구사항의 중요한 속성은 최종 제품이 요구사항을 만족시키는지 확인 가능해야 함
- 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 수립하고 테스트 케이스 작성
- 테스트 케이스를 생성한 후에는 단계별 테스트 및 인수 테스트에서 활용
- 인수 테스트에는 알파 테스트와 베타 테스트가 있음
CASE 도구 활용 검증
- 구조화된 요구사항 명세서에 대해서는 자동화된 일관성 분석을 제공하는 CASE 도구 활용 가능
- 대규모 개발 프로젝트에서는 다양한 이해관계자들이 요구사항 명세서 검토가 필요하기 때문에, 요구사항 명세서에 대한 형상 관리 수행이 가능한 CASE 도구 이용
베이스라인(Baseline)을 통한 검증
- 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검증 수행
요구사항 추적표(RTM; Requirement Traceability Matrix)를 통한 검증
- 요구사항 정의서를 기준으로 개발단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인이 가능한 문서
▼상세 정형 기술 검토 기법
관리 리뷰(Management Review)
- 프로젝트 진행 상황에 대한 전반적인 검토를 바탕으로 범위, 일정, 인력 등에 대한 통제 및 의사결정을 지원하는 리뷰
기술 리뷰(Technical Review)
- 정의된 계획 및 명세를 준수하고 있는지에 대한 검토를 수행하는 리뷰
- 변경 사항이 적절하게 구현되었는지를 평가하고, 여러 대안을 추천하거나 대안을 검토
- 대표 엔지니어가 주재하며 경우에 따라서 관리자도 참가 가능
인스펙션(Inspection)
- 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법
- 동료 검토(Peer Review)라고도 함
워크 스루(Walk Through)
- 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 문제 식별, 대안 조사, 개선 활동, 학습 기회를 제공하는 가장 비형식적인 검토 기법
감사(Audit)
- 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 기법
- 감사는 소프트웨어 제품의 제공자, 소비자, 제3기관이 수행
동료 검토를 인스펙션이라고 부르기도 한다
3. 요구사항 관리 단계(CMM Level 2 프로세스 영역)
- 요구사항 관리는 프로젝트 진행 과정에서 발생하는 요구사항의 변경에 대해 일치성과 무결성을 제공하기 위해 변경제어와 추적 등 일련의 관리를 수행하는 활동이다
- 주요 산출물로는 요구사항 변경요청서, 요구사항 변경승인서, 요구사항 추적표가 있다
▼요구사항 관리 단계 절차
| 순서 | 절차 | 내용 | 기법/산출물 |
|---|---|---|---|
| 1 | 요구사항 협상 | 가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 기법 | 우선순위 설정, 시뮬레이션 |
| 2 | 요구사항 기준선 설정 | 공식적으로 검토되고 합의된 요구사항 명세서를 통해 기준선을 설정하기 위한 방법 | 공식 회의, 형상 관리 |
| 3 | 요구사항 변경관리 | 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법 | 형상통제 위원회, 영향도 분석 |
| 4 | 요구사항 확인 및 검증 | 구축된 시스템이 이해관계자가 기대한 요구사항에 부합하는지 확인하기 위한 방법 | 확인 및 검증 |
나 혼자 공부 기록