요구공학의 개념 정리

내, 외부 인터페이스 요구사항은 조직 내, 외부에 있는 시스템들이 상호 간 접속하여 특정한 기능을 실현하기 위한 접속 방식이나 규칙에 대한 필수적인 요구사항이다. 이러한 내, 외부 인터페이스 요구 사항을 위하여 구성요소들을 대상 시스템 및 기관과 연동 방안에 대한 사전 협의가 필요하다. 내, 외부 인터페이스 요구사항은 인터페이스 연계 범위 및 내용, 인터페이스 이름, 연계 방식, 연계 대상 시스템, 송신 데이터, 인터페이스 주기 그리고 기타 여러 고려사항으로 구성되어 있다. 내, 외부 인터페이스 요구사항은 기능적 요구사항과 비기능적 요구사항으로 분류된다. 기능적 요구사항이란 내, 외부 인터페이스 연계를 이용해 작업될 기능과 관련해 소프트웨어가 가지는 기능적 속성에 대한 요구사항이다. 비기능적 요구사항은 내, 외부 인터페이스 연계 시의 안전성, 성능, 신뢰도, 사용의 용이성, 보안성, 운용상의 제약 등 전반적인 시스템과 관련된 요구사항이다. 요구공학의 개념을 성명하자면 요구공학은 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증을 사용자의 요구가 나타나는 시스템을 개발하기 위해 구조화한 활동이다. 이러한 요구공학의 목적은 이해관계자 사이에서 좀 더 효과적인 의사소통 수단을 제공하고 시스템 개발의 요구사항에 관한 공통적인 이해를 설정한다. 요구사항이 누락되지 않도록 하고 이해 오류로 인하여 나타나는 불필요한 비용을 절감하며 요구사항 변경 추적을 할 수 있게 해 준다. 초기 요구사항 관리로 효과적인 의사소통 수단 제공과 개발 시간 및 비용을 절약하게 해 준다. 요구공학의 기본은 시스템의 요구사항을 파악할 수 있어야 한다. 기능적 요구사항이 시스템이 제공하는 기능과 서비스에 관한 요구사항이라면 비기능적 요구사항은 시스템이 수행하는 기능 외의 사항들, 구축에 대한 제약사항에 관한 요구사항이다. 기능적 요구사항은 특정 입력에 대해 어떻게 시스템이 반응해야 하는지에 대해 기술하고 특정한 상황에서 시스템이 어떻게 동작해야 하는지에 대해 기술하는 도출 방법을 쓴다. 기능성, 일관성, 완전성의 특성을 가지고 있다. 기능적 요구사항의 예를 들자면 온라인 홈페이지에서 주문하고자 하는 물건들을 쇼핑카트에 저장할 수 있는 장바구니 기능을 제공해야 하고, 결제를 위한 수단은 신용카드, 포인트 결제, 계좌이체가 가능하게 해야 한다는 것이다. 반면 비기능적 요구사항은 시스템이 지켜야 할 제한 조건들에 대해 기술하고 품질 속성에 관련해 시스템이 갖추어야 할 상항에 관해 기술하는 도출 방법을 사용한다. 유지보수성, 이식성, 신뢰성, 효율성, 사용성, 보안성의 특성을 갖는다. 비기능적 요구사항의 예로는 특정 함수의 호출시간이 5초를 넘지 않게 하거나 시스템 가동률은 99.5%를 만족하면서 하루 이십사 시간 가동되게 하는 것들이 있다. 요구공학 프로세스는 요구사항 개발 단계와 요구사항 관리 단계가 있다. 요구사항 개발 단계는 요구사항 도출, 요구사항 분석, 요구사항 명세, 요구사항 확인 및 검증 단계로 이뤄져 있다. 요구사항 도출이란 소프트웨어가 풀어야 할 문제가 무엇인지 이해하고 고객이 제시하는 추상적 요구에 대해 관련된 정보를 구별하고 어떻게 수집할 것인지 결정해 수집된 요구사항들을 세부적으로 표현하는 단계이다. 이러한 단계에서 이해관계자가 구별되고 고객과 개발자 사이에 관계가 형성되며 여러 가지 이해관계자와 효율적으로 의사소통을 하는 것이 중요하다. 주요 활동으로 조직 환경 분석, 고객 분석, 후보 요구사항 정제, 후보 요구사항 분류, 요구사항 소스 관리가 있다. 요구사항 분석이란 도출된 요구사항에 관하여 충돌, 누락, 중복 등을 파악하여 일관성이 있는지 완전성이 있는지 확보하는 단계이다. 상충되는 요구사항을 해결하고 소프트웨어가 어떻게 환경과 상호작용하고 범위가 어떠한지 파악하는 단계이다. 요구사항 명세란 체계적으로 검토, 평가, 승인이 될 문서를 쓰는 단계이다. 한 가지 이상의 형태로 동의한 요구사항을 저장하여 정형화된 요구사항을 만들어내는 활동을 한다.  요구사항 확인 및 검증 절차는 고객이 원하는 시스템을 요구사항이 제대로 정의하고 있는지 확인하는 과정이다. 개발이 완료된 후 문제점이 발견된다면 굉장한 재작업 비용이 들기 때문에 요구사항 검증 단계가 아주 중요하다. 실제 요구를 요구사항이 제대로 반영하는지, 서로 상충되는 점은 없는지 등을 점검한다. 요구사항 명세 원리 및 검증 항목에는 각각의 명세 내용은 한 가지의 의미만 부여해야 한다는 명확성과 설계 제약, 속성, 인터페이스, 성능, 기능 등에 대해 모든 시스템 요구사항이 들어있어야 한다는 완전성, 요구사항 내용의 충족 여부와 달성도에 대해 확인이 가능해야 한다는 검증 가능성, 내용 속 상호 모순이 없어야 한다는 일관성, 변경 시에 수정이 쉬워야 한다는 수정 용이성, 각 근거에 대한 추적과 요구사항에 상호참조가 가능해야 한다는 추적 가능성, 시스템 개불 후에 운영 및 유지보수에 효과적으로 이용이 가능해야 한다는 개발 후 이용성까지 총 다섯 가지 항목이 있다. 요구사항 도출 단계의 주요 기법에는 인터뷰 기법, 브레인스토밍 기법, 델파이 기법, 롤 플레잉 기법, 워크숍 기법, 설문조사 기법이 있다. 요구사항 분석 단계 기법에는 자료 흐름 지향 분석 기법과 객체 지향 분석 기법이 있다. 요구사항 명세 단계에는 비정형 명세기법과 정형 명세 기법이 있으며 요구사항 확인 및 검증 단계에는 동료 검토 기법, 워크 스루 기법, 인스펙션 기법이 있다.