요구분석 단계

요구공학

요구 유추 기술

요구사항 명세서

StarUML의 사용

2

요구공학

3

의미

• 데이터 처리 문제를 해결하는 단계

• 사용자 요구사항이 주의 깊게 인식되고 문서화

• 요구사항은 제공될 기능들 뿐 아니라 성능, 신뢰성, 사용자 문서, 교육, 비용 등의 요구사항 들도 포함

요구공학의 결과는 요구 명세서(requirements specification)

요구공학은 그 요구들을 어떻게 표현하느냐에 따라 관련된 기술뿐만 아니라 사회적인 인식의 관점(cognitive aspects)에서 주요한 역할을 수행하는 것도 포함

요구공학의 3가지 처리 과정

• 요구사항 추출 : 문제를 이해하는 것에서 요구사항이 나온다.

• 요구사항 명세 : 문제를 이해하면 문장으로 기술하면서 설명

• 요구사항 검증 : 문제를 기술하면 서로 다른 부분들이 일치

4

요구추출

사용자

요구명세서

요구검증

문제 도메인

사용자 요구사항

도메인 지식

지식

더 많은 지식 요구 검증 결과

사용자에 의해 검증된 모델

사용자 피드백

도메인 지식

요구사항 모델

요구 명세서

요구 공학을 위한 네 가지 범례

기능주의(objective-order) • 기능주의자 패러다임에서, 개발자는 적당한 원인-결과 관계를 위해 검

색하는 시스템 전문가

상대론주의(social-relativism) • 분석가는 용이하게 해주는 사람으로서 작용

• 분석가는 변화된 대리인

• 모든 사람으로부터 습득을 쉽게 하기 위해 탐색

• 기본적 구조주의(radical-structuralism)

기본적 구조주의(radical-structuralism) • 기본적인 패러다임에서 주요한 가설은 힘, 명성, 자원에 대한 두 가지

또는 그 이상의 사회적 종류 사이의 충돌에서 일어나는 시스템 개발

신인간주의(neohumanism)

• 시스템은 기본적 담화를 위한 또 다른 장벽과 왜곡된 작용을 제거하기 위해 개발

민주주의(democratic)

• 관리되어지는 그룹 사이의 차이점을 추정

• 공동의 애플리케이션 개발은 접근과 같은 예

네트워크(network)

• 여기에서 조직은 협력하는 개별적 계획과 목적을 가지는 사람의 네트워크로 볼 수 있다.

• 특별한 요구에 맞게 상품화하기 위한 능력과 관련하여 사람들은 망구조 시스템과 조화될 수 있다.

요구 유추 기술

전제

• 임의의 어떤 것에서부터(out there) 시작되고, 그것으로부터 요구사항이 유도된다는 것

유추 기법 목록에서 밑으로 내려갈수록 그 방법이 정교한 기술

질문(asking) • 사용자에게 시스템으로부터 무엇을 기대하는지 간단히 질문할 수 있다.

질문조사는 행위, 자세, 의견 등에 대한 데이터를 수집하는데 유용한 도구

작업 분석 • 사서의 작업은 책을 빌리기 위해 요청되는 핸들링, 새로운 책의 목록,

책의 주문 등과 같은 일

• 보다 높은 단계의 작업은 서브 작업으로 나눌 수 있다.

시나리오 기반 분석 • 인터뷰 혹은 작업 분석에서는 기초적인 계획을 찾지만, 분석가는 작업

의 사례들을 연구

• 시나리오는 특정 작업 사례가 작성되는지에 대해 언급.

• 시나리오는 실제 또는 인위적일 수 있다

인종학

• 예를 들어 인터뷰를 통하여 요구사항을 추출하는데 가장 큰 단점은 분석가가 사용자에게 자신의 관점을 주입시키는 것

형태 분석

• 도메인에 대한 많은 정보들은 사용되는 다양한 양식의 형태로 발견되고 또 모델링 될 수 있다.

자연 언어 명세

• 여러 형식들처럼 자연언어 명세는 설계 영역에 대한 많은 유용한 정보를 제공

기존 시스템으로부터의 파생

• 기존 시스템으로부터의 시작은 새로운 시스템의 요구를 만들고,

현재 상황의 상세 내용을 얻으며, 신중을 기해야 한다.

비즈니스 프로세스 재설계 (BPR) • 현 상황을 자동화하자는 것

• 비즈니스 프로세스 재설계에서는 다른 전략들이 제공

• BPR의 단계 • 변화를 위한 프로세스의 파악

• 변화의 수단 파악

• 프로세스 비전의 개발

• 현재 프로세스에 대한 이해

• 새로운 프로세스를 설계하고 프로토타입 구축

Prototyping • 어렵지만 불가능하지 않은 일이 주어졌을 때, 시작부터 정확한

시스템을 만들기 위해 사용

• 질문(asking)방식은 명확성이 가장 적은 방법인 반면에 프로토타이핑은 불명확성이 가장 적은 방법

요구사항 명세서

요구사항 명세서

• 요구공학 단계의 최종 산출물

• 분석결과에 대한 그 다음의 재구성

• 다음단계(설계단계)를 위한 출발점

• 요구사항 명세는 사용자마다 다르지만, 일관성 있는 형태로 제공

목적

• 목적은 이러한 결과를 다른 것에게 전달하기 위한 것

요구사항 명세서를 위한 다양한 요구

• 요구사항 명세는 정확하여야 한다.

• 요구사항 명세는 그것을 사용하는 사람과 만드는 사람 양쪽 모두에게 명백(unambiguous)해야 한다.

• 요구사항 명세는 완전해야 한다(complete).

• 기능성, 성능, 제약사항과 같이 모든 중요한 것은 문서화되어야 한다.

• 요구사항 명세는 일관되어야 한다(consistent).

• 요구사항 명세의 다른 부분들 이 서로 충돌되어서는 안 된다.

• 요구사항 명세는 증명 가능하여야 한다(verifiable).

• 요구사항이 충돌 하는지 아닌지를 결정하기 위한 제한된 프로세스가 있다는 것을 의미

• 요구사항 명세는 수정 가능해야 한다(modifiable)

• 소프트웨어 모델은 사실 의 일부분이다. 그러므로 이것은 변화 가능하다.

• 요구사항 명세는 추적 가능하여야 한다(traceable)

• 각 요구사항 또는 모든 요 구사항의 근원과 원리는 추적 가능해야 한다.

요구사항 명세 목록을 위한 가이드라인으로 IEEE 830 표준을 따른다.

요구공학 프로세스는 많은 결정과 조정사항을 수반

큰 시스템 코드의 95% 이상이 사용자 요구사항에 의해서 다시 작성

15

StarUML 설치

http://sourceforge.net/projects/staruml/files/staruml/5.0/

16

17

18

요구공학의 개념을 설명하시오.

요구 유추 기술에는 어떠한 것이 있는가?

요구사항 명세방법에 대하여 설명하시오.

UML 도구를 설치해서 사용해보자.

연습문제