요구분석 단계 1

요구공학 요구 유추 기술 요구사항 명세서 StarUML의 사용

요구공학의 결과는 요구 명세서(requirements specification) 의미 데이터 처리 문제를 해결하는 단계 사용자 요구사항이 주의 깊게 인식되고 문서화 요구사항은 제공될 기능들 뿐 아니라 성능, 신뢰성, 사용자 문서, 교육, 비용 등의 요구사항 들도 포함 요구공학의 결과는 요구 명세서(requirements specification) 요구공학은 그 요구들을 어떻게 표현하느냐에 따라 관련된 기술뿐만 아니라 사회적인 인식의 관점(cognitive aspects)에서 주요한 역할을 수행하는 것도 포함

요구공학의 3가지 처리 과정 요구사항 추출 : 문제를 이해하는 것에서 요구사항이 나온다. 요구사항 명세 : 문제를 이해하면 문장으로 기술하면서 설명 요구사항 검증 : 문제를 기술하면 서로 다른 부분들이 일치

기능주의(objective-order) 요구 공학을 위한 네 가지 범례 기능주의(objective-order) 기능주의자 패러다임에서, 개발자는 적당한 원인-결과 관계를 위해 검색하는 시스템 전문가 상대론주의(social-relativism) 분석가는 용이하게 해주는 사람으로서 작용 분석가는 변화된 대리인 모든 사람으로부터 습득을 쉽게 하기 위해 탐색 기본적 구조주의(radical-structuralism) 기본적인 패러다임에서 주요한 가설은 힘, 명성, 자원에 대한 두 가지 또는 그 이상의 사회적 종류 사이의 충돌에서 일어나는 시스템 개발

신인간주의(neohumanism) 민주주의(democratic) 네트워크(network) 시스템은 기본적 담화를 위한 또 다른 장벽과 왜곡된 작용을 제거하기 위해 개발 민주주의(democratic) 관리되어지는 그룹 사이의 차이점을 추정 공동의 애플리케이션 개발은 접근과 같은 예 네트워크(network) 여기에서 조직은 협력하는 개별적 계획과 목적을 가지는 사람의 네트워크로 볼 수 있다. 특별한 요구에 맞게 상품화하기 위한 능력과 관련하여 사람들은 망구조 시스템과 조화될 수 있다.

유추 기법 목록에서 밑으로 내려갈수록 그 방법이 정교한 기술 요구 유추 기술 전제 임의의 어떤 것에서부터(out there) 시작되고, 그것으로부터 요구사항이 유도된다는 것 유추 기법 목록에서 밑으로 내려갈수록 그 방법이 정교한 기술

질문(asking) 작업 분석 시나리오 기반 분석 사용자에게 시스템으로부터 무엇을 기대하는지 간단히 질문할 수 있다. 질문조사는 행위, 자세, 의견 등에 대한 데이터를 수집하는데 유용한 도구 작업 분석 사서의 작업은 책을 빌리기 위해 요청되는 핸들링, 새로운 책의 목록, 책의 주문 등과 같은 일 보다 높은 단계의 작업은 서브 작업으로 나눌 수 있다. 시나리오 기반 분석 인터뷰 혹은 작업 분석에서는 기초적인 계획을 찾지만, 분석가는 작업의 사례들을 연구 시나리오는 특정 작업 사례가 작성되는지에 대해 언급. 시나리오는 실제 또는 인위적일 수 있다

인종학 예를 들어 인터뷰를 통하여 요구사항을 추출하는데 가장 큰 단점은 분석가가 사용자에게 자신의 관점을 주입시키는 것 형태 분석 도메인에 대한 많은 정보들은 사용되는 다양한 양식의 형태로 발견되고 또 모델링 될 수 있다.

자연 언어 명세 기존 시스템으로부터의 파생 여러 형식들처럼 자연언어 명세는 설계 영역에 대한 많은 유용한 정보를 제공 기존 시스템으로부터의 시작은 새로운 시스템의 요구를 만들고, 현재 상황의 상세 내용을 얻으며, 신중을 기해야 한다.

비즈니스 프로세스 재설계 (BPR) Prototyping 현 상황을 자동화하자는 것 비즈니스 프로세스 재설계에서는 다른 전략들이 제공 BPR의 단계 변화를 위한 프로세스의 파악 변화의 수단 파악 프로세스 비전의 개발 현재 프로세스에 대한 이해 새로운 프로세스를 설계하고 프로토타입 구축 Prototyping 어렵지만 불가능하지 않은 일이 주어졌을 때, 시작부터 정확한 시스템을 만들기 위해 사용 질문(asking)방식은 명확성이 가장 적은 방법인 반면에 프로토타이핑은 불명확성이 가장 적은 방법

요구사항 명세서 요구사항 명세서 목적 요구공학 단계의 최종 산출물 분석결과에 대한 그 다음의 재구성 다음단계(설계단계)를 위한 출발점 요구사항 명세는 사용자마다 다르지만, 일관성 있는 형태로 제공 목적 목적은 이러한 결과를 다른 것에게 전달하기 위한 것

요구사항 명세서를 위한 다양한 요구 요구사항 명세는 정확하여야 한다. 요구사항 명세서를 위한 다양한 요구 요구사항 명세는 정확하여야 한다. 요구사항 명세는 그것을 사용하는 사람과 만드는 사람 양쪽 모두에게 명백(unambiguous)해야 한다. 요구사항 명세는 완전해야 한다(complete). 기능성, 성능, 제약사항과 같이 모든 중요한 것은 문서화되어야 한다. 요구사항 명세는 일관되어야 한다(consistent). 요구사항 명세의 다른 부분들 이 서로 충돌되어서는 안 된다. 요구사항 명세는 증명 가능하여야 한다(verifiable). 요구사항이 충돌 하는지 아닌지를 결정하기 위한 제한된 프로세스가 있다는 것을 의미

요구사항 명세 목록을 위한 가이드라인으로 IEEE 830 표준을 따른다. 요구사항 명세는 수정 가능해야 한다(modifiable) 소프트웨어 모델은 사실 의 일부분이다. 그러므로 이것은 변화 가능하다. 요구사항 명세는 추적 가능하여야 한다(traceable) 각 요구사항 또는 모든 요 구사항의 근원과 원리는 추적 가능해야 한다. 요구사항 명세 목록을 위한 가이드라인으로 IEEE 830 표준을 따른다. 요구공학 프로세스는 많은 결정과 조정사항을 수반 큰 시스템 코드의 95% 이상이 사용자 요구사항에 의해서 다시 작성

StarUML 설치 http://sourceforge.net/projects/staruml/files/staruml/5.0/

연습문제 요구공학의 개념을 설명하시오. 요구 유추 기술에는 어떠한 것이 있는가? 요구사항 명세방법에 대하여 설명하시오. UML 도구를 설치해서 사용해보자.