5. 요구 공학

1. 요구 공학의 개요

가. 요구 공학의 정의

요구의 정의 (IEEE Std 용어사전)	(1) 사용자의 문제를 해결하거나 목적을 달성하기 위해 필요한 조건이나 능력 (2) 계약, 표준, 명세서나 공식적인 문서 내용을 만족하기 위해 시스템이나 시스템 컴포넌트가 소유하거나 만족해야만 하는 조건이나 능력
요구 공학의 정의	사용자 요구를 체계적으로 다루기 위한 프로세스와 방법, 도구, 기법 등을 정의한 학문

-조건은 비기능 요구사항, 능력은 기능 요구사항을 의미함

 

나. 요구의 분류

기능 요구사항		-시스템에 의해 제공되어야 하는 기능/서비스/능력을 의미
비기능 요구사항	가용성	-특정 시점에서 시스템이 얼마나 정상 운영되는지에 대한 요구 (오전 6시부터 오후 12시까지 최소 99.5% 정상 운영)
	효율성	-시스템이 자원을 얼마나 효율적으로 이용하는가에 대한 요구 (프로세스 용량 25%, 메모리 용량 25% 이상 이용 금지)
	유연성	-시스템에 새로운 기능을 용이하게 확장할 수 있는지에 대한 요구 (1일 이내에 새로운 검색 기능 추가 가능)
	무결성	-소프트웨어나 데이터 접근 통제, 불법적인 접근 통제를 위한 시스템 기능에 대한 사용 제한 요구 (특정 권한 보유자만 검색 가능)
	상호운영성	-시스템의 데이터와 서비스를 얼마나 용이하게 다른 시스템과 교환 가능한지에 대한 요구 (다른 서브 시스템으로부터 발생하는 문서를 종류에 관계없이 수용 가능)
	신뢰성	-주어진 시간 동안 올바르게 수행 가능한지에 대한 요구 (시스템 오동작에 대한 시험 중 0.5% 미만의 오류 발생율)
	강건성	-불법적인 입력이나 예기치 못한 문제에 직면했을 때 얼마나 적절히 운영가능한지에 대한 요구 (시스템 다운 시 다운 전 상태로 시스템 복구)
	사용성	-시스템 이용의 용이함 또는 사용자가 사용상의 제한 조건에 대한 요구 (평균 5분 이내에 신규 회원 가입 절차 완료)
	유지보수성	-새로운 요구나 환경 변화에 따른 수정 또는 오류 수정에 대한 용이성 제공 요구 (24시간 이내에 오류 해결 및 적용)
	이식성	-시스템을 다른 운영 환경으로 이전하는 것에 대한 요구 (온 프라미스의 Linux 운영 환경에서 클라우드 환경으로 이전)
	재사용성	-기존 컴포넌트를 재사용하기 위해 얼마나 수정이 필요한지에 대한 요구 (비밀번호 관리 기능을 타 시스템에서도 재사용 가능)
	시험용이성	-시스템 컴포넌트나 통합 서브 시스템에서 얼마나 오류를 발견하기 쉬운지에 대한 요구 (한 모듈에 대한 순환적 복잡성은 20을 초과 금지)
	성능	-응답시간이나 처리량과 같은 시스템 부하에 대한 요구 (사용자의 요청에 대해 0.5초 이내에 응답)
	환경	-제약조건에 대한 요구 -시스템 개발과 운영, 유지보수 환경 및 외부 시스템과의 인터페이스에 대한 요구 (PC는 Windows 운영체제를 사용하면 자마와 SOAP을 이용하여 외부 시스템 이용 필요)
	표준	-제약조건에 대한 요구 -준수해야 할 표준, 정책, 산업, 행정 등에 대한 요구

-비기능 요구사항은 시스템에 대한 제약조건이나 품질과 관련된 요구를 의미

 

2. 요구 공학의 개념도 및 구성요소

가. 요구 공학의 개념도

나. 요구 공학의 구성요소

구분	특징	설명
요구 추출	정보 소스 파악 정보 수집 시스템 정의서 프로토타입 비즈니스 모델 유스케이스	-다양한 소스로부터 요구를 추출, 발견하는 활동 (문제 도메인을 이해하는 단계) -요구분석 활동 포함 -인터뷰, 관찰, 문서 검토, 유사 시스템 분석, 설문지, 프로토타입, 유스케이스 작성 등 -사용자와 원활한 의사소통을 위해 사용자 언어(자연어)를 사용
요구 분석	요구 명세서 모델링	-사용자 요구를 깊이 이해하고 개발될 시스템에서 어떤 서비스를 제공해야 하는지 구체적으로 정의하는 활동 -개발자와 사용자 사이의 원활한 의사 소통 -복잡한 시스템에 대한 이해, 문제 영역과 사용자 요구에 대한 이해를 향상시키기 위해 여러 관점에서 분석하고 다양한 모델 생성 -정확한 이해와 명세를 위해 자연어보다 정형화 모델링 언어 이용
요구 명세	SRS (IEEE Std 830)	-요구 분석 결과와 분석 모델을 문서화한 요구 명세서(SRS)를 작성하는 활동 -좋은 SRS의 특징 정확성, 일관성, 완전성, 확인성, 수정성, 추적성
요구 검증	검토 프로토타입 모델 검증 인수 검사	-명세서가 사용자가 원하는 것을 정확히 반영했는지 검사하는 활동

-요구 추출 단계에서의 요구는 비구조화, 이해와 유지보수 어려움, 일관성이 없고, 중복 가능성이 존재

-요구 분석단계에서의 요구는 구조화, 이해와 유지보수 용이, 일관성 및 중복성 확인이 용이