요구공학 프로세스

[ 요구공학 프로세스 ]

요구 사항 도출 및 분석	사용자와 중개인이 원하는 것이 무엇이고 기대하는 것이 무엇인지 파악한다. 기존 시스템을 조사하고, 사용자와 중개인과 의논하고 업무 분석을 수행함으로써 시스템 요구사항들을 생성하는 과정이다..
요구 사항 명세화	요구사항을 표준화 하여 상세하게 정의한다. 수집한 정보를 요구 사항의 집합을 정의한 보편적인 양식 문서로 변환하는 과정이다.
요구 확인	고객이 원하는 것이 맞는지 요구사항을 확인한다. 시스템 요구 사항을 상세하고 정확하게 설명하는 것이 고객과 개발자 사이의 계약의 기초가 된다.
요구 사항 관리	요구사항의 변경을 관리한다.

  

[ 요구 공학 추출 및 분석 ]

▪ 시스템의 기능적 & 비기능적 요구사항의 모으는 것이다.

▪ 다양한 부류의 사람이 참여한다.(최종 사용자, 개발자, 관리자, 도메인 전문가 등)

▪  요구사항 추출의 어려움

  - 참여자는 대부분의 일반적인 용어를 제외하고는 컴퓨터 시스템으로부터 그들이 요구하는 것이 무엇인지 모른다. 그들은 시스템이 해주기를 원하는 것이 무엇인 지를 정확하게 말하는 것이 힘들거나, 그들의 요청에 대한 비용이 얼마나 드는 지를 모르기 때문에 비현실적인 요구를 할 수 있다.

  - 참여자는 자기들의 용어로 그들 자신의 일에 관한 암묵적인 지식을 사용하여 요구사항을 표현한다. 고객의 분야에서 경험이 없는 요구사항 엔지니어는 이러한 요구사항을 이해해야 한다.

  - 상이한 참여자마다 나름대로 표현된 다른 요구사항을 가지고 있다. 요구사항 엔지니어는 요구사항, 공통점, 상충점을 발견하기 위해서 가능한 모든 출처를 고려해야 한다.

  - 정치적 요소가 시스템의 요구사항에 영양을 미칠 수 있다. 예를 들어, 관리자가 조직의 영향을 증가시키는 특정 시스템 요구사항을 요청할 수 있다.

  - 분석이 이루어지는 동안에 경제적인 비즈니스 환경은 동적이다. 그것은 필연적으로 분석 프로세스 동안에 변경된다. 그러므로 특정 요구사항의 중요성이 변한다. 새로운 요구사항이 애초에 관여하지 않았던 새로운 참여자로부터 나올 수 있다.

▪ 요구사항 추출 기술

Interviewing (면담)	만남을 통해 요구 공학 팀은 그들이 사용할 시스템과 개발될 시스템에 관하여 참여자에게 질문을 한다. 요구사항은 질문에 대한 답으로부터 유도된다.
Scenarios (시나리오)	상호작용에 예에 대한 것을 기술한 것으로 추상적인 기술보다는 실제의 예를 들어서 요구사항을 추출할 때 사용한다. 개괄적인 요구사항에 좀 더 상세한 사항을 추가할 때 더 유용하다.
Use cases (유스케이스)	객체지향 시스템 모델을 서술하기 위한 UML 표기법의 기본적인 기능이 되었다. 유스케이스는 상호작용의 종류와 참여하고 있는 액터를 식별한다. 하나의 유스케이스는 시나리오(상호작용)를 모두 포함한다.

 

댓글이나 공감 남겨주는 사람 착한사람