요구 공학 프로세스

요구공학 프로세스

: 어플리케이션 도메인, 개발자, 조직에 따라 다르지만 공통적인 부분이 있음

: 요구사항 유도(elicitation), 분석(analysis), 확인(validation), 관리(management)

 

가능성 분석

: 제안된 시스템이 할 만한 가치가 있나?

: 조직의 목적에 기여 가능? 현재 시스템과 통합되나? 현재 기술과 예산으로 개발이 가능한가?

 

유도 및 분석

: 요구사항 유도 or 발견이라 불린

: 직원과 고객이 함께 만듬. 도메인, 서비스, 제한사항 등을 찾음.

: 최종 사용자, 개발자, 관리자, 공학자, 도메인 전문가, 마케팅 관계자 => Stakeholder

: Stakeholder는 자기 분야 외에는 잘 모름, 뭘 원하는지 모름, 의견 차이가 있을 수 있음.

: 조직 or 정책적 요인이 요구사항에 변경을 줄 수 있고 분석 과정동안 변할 수 있음

 

시스템 모델 - 요구사항 분석동안 생성

: Partitioning : 개체 사이의 구조적 관계 인식, 요구사항 분할

: Abstraction : 개체 사이의 일반성 인식

: Projection : 문제를 바라보는 여러 관점 인식

 

관점 중심 유도

: Stakeholder들은 각자 분야가 다르고, 여러 관점을 가짐.

: 외부의 사용자들의 관점. 비기능적 요구사항 구조화에 사용될 수 있음

 

방법 중심 분석

: 가장 많이 사용

: 시스템을 이해하기위해 사용

: 시스템 모델링 표기법, 보고서 양식 등 사용

 

System 범위(Contexts - 상황)

: 무엇이 구현되는지 결정하기 위해 시스템의 경계가 설정되어야함

: 환경 내에있는 다른 시스템에 대한 기술도 포함

 

시나리오

: 시스템이 사용되는 방식에 대한 설명

: 요구사항 유도에 도움을 줌

 

이벤트 시나리오

: 특정 이벤트 발생하면 시스템이 어떻게 반응하는지 설명

 

Use Cases

: 외부 행위자와 시스템과의 상호작용에 대해 표현

: 시간적 흐름에 따라 Sequence Diagram을 쓰기도 함.

 

요구사항 확인

: 요구사항이 고객이 정말로 원하는 시스템을 정의 했는가 확인

: 한 번 정하고 오류를 수정하는데 100배의 비용이 드니 매우 중요

 

지속성 요구사항 - 고객 조직의 핵심적 활동에서 나온 안정적 요구사항 ex) 병원-> 의사, 간호사

휘발성 요구사항 - 개발하는 동안 또는 시스템을 사용하는 동안 변경되는 요구사항 ex) 건강관리 정책 등

 

추적성(Traceability)

: 요구사항, 요구사항의 근원, 시스템 설계 사이의 관계 위주

: 근원 추적성 = Stakeholder와 요구사항의 관계

: 요구사항 추적성 = 종석적인 요구사항 사이의 관계

: 설계 추적성 = 요구사항과 설계의 관계

 

Case 도구 지원 - 요구사항, 변경, 추적성 등을 보관, 검색