요구사항 확인
요구사항
문제의 해결 또는 목적 달성을 위해여 고객에 의해 요구되거나, 표준이나 명세등을 만족하기 위하여 시스템이 가져야 하는
서비스 또는 제약사항
요구사항의 분류
- 요구사항 파악의 기본은 시스템의 요구사항에 대한 파악이다.
- 요구사항은 기능적 요구사항과 비기능적 요구사항으로 분류된다.
구분 | 기능적 요구사항 | 비기능적 요구사항 |
개념 | 시스템이 제공하는 기능, 서비스에 대한 요구사항 | 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항 |
도출방법 | 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대해 기술 특정 상황에 대해 시스템이 어떻게 동작하는지에 대한 기술 |
품질 속성에 관련하여 시스템이 갖춰야할 사항에 대해 기술 시스템이 준수해야 할 제약조건에 대해 기술 |
특성 | 기능성, 완전성, 일관성 | 신뢰성, 가용성, 효율성, 유지보수성, 이식성 |
사례 | 온라인 홈페이지에서는 쇼핑카트에 주문하고자 하는 품목을 저장할 수 있는 장바구니 기능을 제공해야 함 상품의 결제수단은 신용카드, 무통장 입금, 포인트 결제가 가능해야 함 최종 주문이 완료되면 배송추적 조회가 가능해야함 |
특정 함수의 호출시간은 3초를 넘기지 않아야함 시스템은 하루 24시간 가동되어야 하며 가동률 99.5%를 만족해야 함 시스템은 운영되고 있는 중에 패치 및 업그레이드가 가능해야함 |
* 기능적 요구사항 : 기완일, 비기능적 요구사항 : 신가효유이
요구 사항 개발 프로세스
요구사항 개발 프로세서는 요구사항 도출, 분석, 명세, 확인 순으로 수행한다.
* 도분명확
도출 | 분석 | 명세 | 확인 |
- 요구사항 소스 - 도출 기법 |
- 요구사항 분류 - 개념 모델링 - 기술 구조 설계 및 요구사항 할당 - 요구사항 협상 |
- 시스템 정의서 - 시스템 요구사항 명세서 - 소프트웨어 요구사항 명세서 |
- 검토 - 프로토타이핑 - 모델 검증 - 인수 테스트 |
요구사항 개발 프로세스 상세
순서 | 프로세스 | 설명 |
1 | 요구사항 도출(Elicitation) | - 요구사항이 어디에 있고, 어떻게 수집할 것인지 파악 - 이해관계자가 요구사항을 식별, 개발팀과 고객 사이의 관계가 형성 - 다양한 이해관계자와 효율적인 의사소통 중요 |
2 | 요구사항 분석(Analysis) | - 상충되는 요구사항을 해결하고, 소프트웨어의 범위 파악, 소프트웨어가 환경과 어떠헥 상호작용 하는지 이해하는 단계 - 시스템 요구사항을 정제하여 소프트웨어 요구사항 도출 |
3 | 요구사항 명세(Specification) | - 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계 - 요구사항 명세서에는 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항 작성 |
4 | 요구사항 확인(Validation) | - 요구사항 문서가 표준에 적합하고 이해 가능하며, 일관성이 있고 완전한지 검증 |
* 요구사항 개발 프로세스 중에서 요구사항 확인과 관련된 단계는 분석 및 검증 단계이다.
요구사항 개발 프로세스 주요 기법
순서 | 프로세스 | 기법 | 설명 |
1 | 도출 | 인터뷰 | 1:1의 관계에서 사용자 및 사용자 측 의사결정권자와 시스템에 대한 요구사항 추출 철저한 사전 준비 작업 필요 |
설문조사 | 설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집 개발될 시스템의 사용자가 다수일 경우 의견 수렴에 용이 |
||
브레인스토밍 | 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판 없이 수용할 수 있도록 하는 회의 | ||
워크숍 | 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법 프로젝트에 참여하는 모든 핵심 인물의 참여가 필요 참석자들은 해당 전문 영역별로 팀 협력이 필요하며 사전 준비가 요구 |
||
2 | 분석 | 자료 흐름 지향 분석 | 데이터 흐름(DFD: Data Flow Diagram)으로부터 소프트웨어 구조를 유도하는 방법 |
객체지향 분석 | 시스템의 기능과 데이터를 함께 분석 UML(Unified Modeling Langugae)로 표준화 |
||
3 | 명세 | 자연어에 의한 방법 | 사용자와 개발자의 이해가 용이 명확성 및 검증에 문제가 있다. |
정형화 기법 사용 방법 | 명확성 및 검증이 용이하다 기법의 이해가 어렵다 |
||
4 | 확인 | 동료 검토 | 2~3명이 진행하는 리뷰의 형태 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견 하는 형태 진행 |
워크 스루 | 오류를 조기에 검출하는데 목적 검토 자료를 회의전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검토하고 문서화 |
||
인스펙션 | 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 팀이 검사하여 오류를 찾아내는 공식적인 검토 방법 |
요구사항 관리 프로세스
요구사항 관리를 위해서 요구사항, 협상, 요구사항 기준선, 요구사항 변경 관리, 요구사항 확인 및 검증을 수행한다.
요구사항 관리 절차
프로세스 | 주요기법 | 설명 |
요구사항 협상 | 우선순위 설정, 시뮬레이션 | 가용한 자원과 수용 가능한 위험 수준에서 구현가능한 기능을 협상하기 위한 기법 |
요구사항 기준선 | 공식 회의, 형상 관리 | 공식적으로 검토되고 합의된 요구사항 명세서 |
요구사항 변경 관리 | CCB, 영향도 분석 | 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법 |
요구사항 확인 및 검증 | 확인 및 검증 | 구축된 시스템이 이해관계자가 기대한 요구사항에 부합하는지 확인하기 위한 방법 |
* CCB(Configuration Control Board, 형상통제위원회) : 형상 항목에 대한 형상 베이스라인이 승인된 후, 발생되는 형상 항목의 변경에 대하여 평가, 조정, 승인/보류/기각을 결정하는 심의 조직
요구사항 분석
- 요구사항 분석 기법으로 요구사항 븐류, 개념 모델, 요구사항 할당, 호구사항 협상, 정형 분석이 있다.
- 요구사항 분석 기법을 활용하여 업무 분석가가 정의한 응용 소프트웨어의 요구사항을 확인할 수 있다.
기법 | 설명 |
요구사항 분류 | - 요구사항이 기능적 요구사항인지 비기능적 요구사항인지 - 요구사항이 소프트웨어에 미치는 영향의 범위를 파악 - 요구사항이 소프트웨어 생명주기 동안 변경이 발생하는지 확인 |
개념 모델링 | - 개념 모델은 문제 도메인의 엔티티(Entity)들과 개별 관계 및 종속성을 반영 - 시나리오로 나타내기 위해 유스케이스 다이어그램을 주로 사용한다. - 대부분의 모델링 표기법은 UML을 사용한다. |
요구사항 할당 | - 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별하는 활동이다. - 다른 구성요소와 어떻게 상호작용하는지 분석을 통해 추가적인 요구사항의 발견 가능 |
요구사항 협상 | - 두 명의 이해관계자가 서로 상충되는 내용을 요구하는 경우, 어느 한쪽을 지지하기보다는 적절한 지점에서 합의하기 위한 기법 |
정형분석 | - 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현 - 정확하고 명확하게 표현 - 요구사항 분석의 마지막 단계에서 이루어진다. |
* 요구사항 분석 : 분개할협정
요구사항의 확인
- 업무 분석가가 요구사항을 이해했는지 확인하는 것이 필요하고, 요구사항 문서가 기업의 표준에 적합하고 이해 가능하고, 일관성이 있고,
완전한지 검증해야 한다.
요구사항 확인 기법
기법 | 설명 |
요구사항 검토 | - 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이를 검토 - 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자 1명 이상 포함 필요 - 시스템 정의서, 시스템 사양서, 소프트웨어 명세서를 완성한 시점에 검토 |
프로토타이핑 | - 새로운 요구사항을 도출하기 위한 수단 및 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 활용 - 요구사항이 잘못된 경우 유용한 피드백 제공, 사용자 인터페이스의 동적인 행위가 문서나 그래픽 모델보다 용이 |
모델검증 | - 분석단계에서 개발된 모델의 품질 검증 필요 - 객체 모델의 경우 객체들 사이의 존재하는 의사소통 경로를 검증하기 위한 정적 분석 수행에 유용 |
인수테스트 | - 요구사항의 중요한 속성은 최종 제품을 기준으로 요구사항을 만족시키는지 확인이 가능해야 한다. - 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획 수립 후, 요구사항을 확인하는 테스트 |
* 프토로타이핑 : 사용자가 요구한 주요 기능을 프로토 타입으로 구현하여, 사용자의 피드백을 통해 개선, 보완하여 완성 소프트웨어를
만들어가는 기법
요구사항 확인 프로세스
기법 | 설명 |
요구사항 목록확인 | 요구사항 목록에서 업무 기능에 대한 요구사항 반영 여부 확인 |
요구사항 정의서 작성 여부 확인 | - 요구사항 목록 중 수용인 경우, 요구사항 정의서(유스케이스 명세서)가 작성 되었는지 확인 - 요구사항 정의서(유스케이스 명세서)에서 시스템의 동작 방식을 명확하고 구체적으로 기술하고 있는지 검토 |
비기능적 요구사항의 확인 | - 시스템 특성, 품질, 제약사항 등 비기능적 요구사항이 명확하게 도출되었는지 검토 - 성능, 가용성, 사용 용이성, 유지보수 용이성, 안전성, 보안성 등에 대한 요구사항의 문서화 여부 확인 |
타 시스템 연계 및 인터페이스 요구사항 확인 | - 타 시스템 또는 하위 시스템 등과의 모든 인터페이스 요구사항이 정의되어 있는지 확인 - 인터페이스 구분(내부/외부), 주기, 방법, 제공자, 요청자 등이 명확하게 정의 되어 있는지 확인 |