요구사항 ⭐⭐⭐
요구사항 개념
1. 요구공학의 개념 : 사용자의 요구가 반영된 시스템 개발을 위해 요구사항에 대한 도출, 분석, 명세 확인 및 검증하는 구조화된 활동
2. 요구공학의 목적
- 이해관계자 사이에 효과적 의사소통 수단 제공, 시스템 개발의 요구사항에 대한 공통된 이해 설정
- 요구사항 누락 방지 및 이해 오류로 인한 불필요 비용 절감, 요구사항 변경 추적 용이
- 초기 요구사항 관리로 개발 비용과 시간 절약, 효과적인 의사소통 수단 제공
3. 요구사항의 분류
| 구분 | 기능적 요구사항 | 비기능적 요구사항 |
| 개념 | · 시스템이 제공하는 기능, 서비스 | · 시스템 구축에 대한 제약사항 |
| 도출 방법 |
· 특정 입력에 대한 반응 · 특정 상황에 대한 동작 |
· 품질 속성에 관련하여 시스템이 갖춰야 할 사항 · 시스템이 준수해야할 제한 조건 |
| 특성 | · 기능성, 완전성, 일관성 | · 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보완성 및 품질관련 요구사항, 제약사항 |
| 사례 | · 상품의 결제수단은 신용카드, 무통장입금, 포인트 결제가 가능해야함 | · 특정 함수의 호출시간은 3초를 넘지 않아야 함 |
요구공학 프로세스 : 요구사항 개발 단계와 요구사항 관리 단계로 구성
1. 요구사항 개발 단계 (CMM Level 3 프로세스 영역)
| 도출 | 분석 | 명세 | 확인 |
| · 요구사항 소스 · 도출 기법 |
· 요구사항 분류 · 개념 모델링 · 기술 구조 설계 및 요구사항 할당 · 요구사항 협상 |
· 시스템 정의서 · 시스템 요구사항 명세서 · 소프트웨어 요구사항 명세서 |
· 검토 · 프로토타이핑 · 모델 검증 · 인수 테스트 |
2. 요구사항 개발 단계 상세
- 요구사항 도출 단계 : 소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계
| 주요기법 | 설명 |
| 인터뷰 | 이해관계자와 직접 대화해 공식적/비공식적 정보 수집 |
| 브레인스토밍 | 대화하기 편한 분위기를 조성해 아이디어를 비판없이 수용하는 회의 |
| 델파이기법 | 전문가의 경험지식을 통한 문제해결, 미래예측 |
| 롤플레잉 | 현실 장면을 설정하고 각자 맡은 역할을 연기해 요구사항 분석 및 수집 |
| 워크숍 | 단기간 집중을 통해 전문적 정보 획득, 공유. 프로젝트 핵심인물참여 필요. 사전 준비 요구 |
| 설문조사 | 설문지, 여론 조사로 간접적 정보 수집. 다수의 의견수렴 용이. |
- 요구사항 분석 단계 : 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계
└ 절차
| 순서 | 절차 | 설명 |
| 1 | 요구사항 분류 | · 요구사항이 기능/비기능 확인 · 요구사항이 SW에 미치는 영향 범위 파악 · 요구사항이 SW 생명주기 동안 변경이 발생하는지 확인 · 하나 이상의 상위 요구사항에서 유도된 것인지 or 이해관계자나 다른 원청으로부터 직접 발생한 것인지 분류 |
| 2 | 개념 모델링 생성 및 분석 | · 모델링 : 요구사항을 쉽게 이해할 수 있도록 단순화, 개념적으로 표현한 것 → 모델링을 만드는 활동 · 개념모델 : 문제 도메인의 엔티티들과 개별 관계 및 종속성을 반영 · 다양한 개념모델 작성 가능 → 유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터랙션, 객체 모델, 데이터 모델 · 모델링 표기는 주로 UML 사용 |
| 3 | 요구사항 할당 | · 요구사항에 만족하기 위한 아키텍처 구성요소를 식별하는 활동 · 다른 구성요소와 어떻게 상호 작용하는지 분석을 통해 추가적인 요구사항 발견 가능 |
| 4 | 요구사항 협상 | · 두 명의 이해관계자의 의견이 상충되는 경우 적절한 지점에서 합의하기 위한 활동 |
| 5 | 정형 분석 | · 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현하는 활동 · 구문과 의미를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현 · 요구사항 분석의 마지막 단계 |
└ 기법
- 자료흐름지향 분석 : 데이터 흐름도, 자료 사전으로부터 SW 구조 유도 방법
- 객체지향 분석 : 시스템 기능과 데이터 분석, UML로 표준화
└ 기술 : 청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성
- 요구사항 명세 단계 : 체계적으로 검토, 평가, 승인될 수 있는 문서(요구사항 명세서)를 작성하는 단계
└ 기법
| 비정형 명세기법 | 요구표현을 자연어로 서술. 명확성 및 검증에 문제. 사용자와 개발자의 이해가 용이. |
| 정형 명세기법 | 요구표현을 수학적 원리와 표기법으로 서술. 정형 명세인 Z-스키마, Petri Nets, 상태차트 활용. 표현 간결, 명확성 및 검증 용이. 기법 이해 어려움. |
└ 요구사항 명세 원리 및 검증 항목 : 명확성, 완전성, 검증 가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성
- 요구사항 확인 및 검증 단계 : 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대한 검토, 베이스라인을 설정하는 활동
└ 순서 : 요구사항 목록 확인 → 요구사항 정의서 작성 여부 확인 → 비기능적 요구사항 확인 → 타 시스템 연계, 인페 요구사항 확인
└ 주요 기법
| 주요 기법 | 설명 | |
| 요구사항 검토 | · 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 검토 · 담당자들이 수작업으로 분석 |
|
| 정형 기술 검토 | 동료검토 | · 2~3명 리뷰 진행. · 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 들으면서 결함을 발견하는 형태로 진행. |
| 워크스루 | · 검토 자료를 회의 전에 미리 배포하여 짧은 시간동안 회의를 진행하는 형태로 리뷰를 통해 오류 검출. · 사전검토 |
|
| 인스펙션 | · 소프트웨어 요구, 설계 원시 코드 등의 작성자 외의 다른 전문가 or 팀이 검사하여 오류를 찾아내는 공식적 검토 방법 | |
| 프로토타이핑 | · 실제 개발될 소프트웨어의 견본품을 만들어 최종 결과물 예측 | |
| 모델 검증 | · 분석단계에서 개발된 모델의 품질 검증 필요 · 정적 분석 수행에 유용 |
|
| 테스트 케이스 및 테스트를 통한 확인 | · 테스트 케이스를 생성하고 이후 요구사항이 현실적으로 테스트 가능한지를 검토 · 인수테스트에는 알파 테스트와 베타 테스트가 있음 |
|
| CASE 도구 활용 | · 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리, 표준 준수 여부 확인. · 자동화된 요구 사항 관리 도구 이용 |
|
| 베이스 라인 검증 | · 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검층 수행 | |
| 요구사항 추적표 | · 요구사항 정의서를 기준으로 개발단계별 최종 산출문의 반영과 변경을 확인가능한 문서 | |
└ 상세 정형 기술 검토 기법 : 관리리뷰, 기술리뷰, 인스펙션(== 동료검토), 워크스루, 감사
3. 요구사항 관리 단계 (CMM Level 2 프로세스 영역)
- 프로젝트 진행 과정에서 발생하는 요구사항의 변경에 대해 일치성과 무결성을 제공하기 위해 변경제어와 추적 등 일련의 관리를 수행하는 활동
TEST → 정답은 드래그!
| 정답 | 문제 |
| 요구공학 | 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동이다. |
| 비기능적 요구사항 | 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항으로, 품질 속성에 관련하여 시스템이 갖춰야 할 사항에 관하여 기술한다. |
| 기능적 요구사항 | 시스템이 제공하는 기능, 서비스에 대한 요구사항으로, 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대해 기술한다. |
| 브레인스토밍 | 말을 꺼내기 쉬운 분위기로 만들어 회의 참석자들이 내놓는 아이디어들을 비판없이 수용할 수 있도록 하는 회의이다. |
| 롤 플레잉 | 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법이다. |
| 워크숍 | 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법으로 프로젝트에 참여하는 모든 핵심 인물의 참여가 필요하고, 참석자들은 해당 전문 영역별로 팀 협력이 필요하며 사전 준비가 요구된다. |
| UML | 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할 시 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어이다. |
| 비정형 명세 기법 | 명세 기법 중에서 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법으로 사용자와 개발자의 이해가 용이하지만, 명확성 및 검증에 문제가 있다. |
| 정형 명세 기법 | 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법으로, Z-스키마, Petri Nets, 상태 차트를 활용하여 표현한다. |
| 인스펙션 | 정형 기술 검토 기법 중 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법이다. |
| 워크스루 | 정형 기술 검토 기법 중 컴토 자료를 회의 전에 배포해서 사전 검도한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 문제 식별, 대안 조사, 개선 활동, 학습 기회를 제공하는 가장 비형식적인 검토 기법이다. |
| 감사 | 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 기법으로 소프트웨어 제품의 제공자, 소비자, 제3기관이 수행한다. |
※ 해당 글은 수제비 2022 도서 참고하였습니다.
수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페
수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)
cafe.naver.com
'정보처리기사' 카테고리의 다른 글
| Ⅱ 화면설계 - UI 요구사항 확인 (0) | 2023.01.30 |
|---|---|
| [2023] 정보처리기사 시험 일정 (0) | 2023.01.05 |
| Ⅰ 요구사항 확인 - 분석 모델 확인하기 (0) | 2022.12.02 |
| Ⅰ 요구사항 확인 - 현행 시스템 분석 (0) | 2022.11.17 |
| Ⅰ 요구사항 확인 - 소프트웨어 개발 방법론 (1) | 2022.11.17 |