[데이터모델링]요구사항 분석

・요구사항 분석의 플로우

-요구사항 수집의 기대되는 최종적 아웃풋은 다음단계의 개념적 설계의 인풋으로 사용되는 엔티티,어트리뷰트, 관계를 파악하는 것 어떤 조사를 하던 요구 조사단계의 최종 아웃풋을 잊어서는 안돼.

-> 어떤 조사 방법들을 사용하면, 무지한 클라이언트들로부터 그들이 요구사항을 구체적으로 뽑아내고, 개념적 설계로 나아갈 수 있는 인풋 자료들을 확보할 수 있을지..

-먼저 클라이언트 들은 데이터 베이스에 대한 개념도 없을 것이므로, UI베이스로 클라이언트가 어떤 것을 만들고 싶은지(예를 들어, 수강신청, 학생조회 시스템등), 구축하고 싶은 시스템이나 어플이 무엇인지와 그 시스템이 어떤 기능을 가지고 있는지를 파악.

-클라이언트가 희망하는 시스템에 따라, '아 당신들이 원하는 시스템이나 어플을 만들기 위해서는 이런이런 데이터들이 피요하겠군요' 하고 데이터들을 설명하고, 클라이언트의 요구사항을 구체화

-프로젝트를 더 효율적으로 진행시키기 위해서, 기존에 어떤 시스템을 가지고 있고 어떤 인프라를 가지고 있는지에 대한 조사도 필요

-클라이언트가 희망하는 시스템에 필요한 데이터들을 뽑아낸 이후에는 그 데이터들을 어떻게 엔티티와 애트리뷰트 그리고 관계로 만들어 낼 수 있을지 고민하기

・조사할 때 고려사항

-조사목적(요구사항 조사의 목적이 무엇인가)

-조사범위(어떤 부서, 어떤 사람들에게 질의를 할 것인가)

-개발 비용과 일정

-조사 결과

・K대학교의 데이터베이스 요구사항

-나 : 저희 왜부르셧어요, 뭐하고 싶으세요?

-관계자 : 다음과 같은 데이터들이 필요합니다(이런 똑똑한 클라이언트는 존재하지 않음 사실)

<학생관리>

 학번,이름주소,생년월일 등 개인정보를 관리, 그리고 학생은 하나의 전공학과에 속해야하며 , 한분의 지도교수 밑에서 전공지도를 받는다. 매 학기마다 강의를 신청하여 수업을 듣는다.

<과목관리>

교내에 개설된 과먹에 대한 정보를 관리한다(과목번호, 과목명, 과목개요) 그리고 각 과목은 여러개의 섹션으로 나누어서 관리한다. 단 섹션이 존재하지 않는 과목이 존재할 수도 있다.

<교수관리>

교수의 이름, 전공분야, 보유기술 등의 정보를 관리. 특히 보유기술은 여러가지가 있을 수 있음.그리고 교수는 관련 과목을 강의하고 지도학생을 보유한다.

<학과관리>

학과의 학과명, 사무실 위치, 전화번호 등의 정보를 관리한다. 그리고 각 학과의 교수들 중 학과장을 임명한다. 학과장은 임명날자가 있다.

<수강신청>

학생들은 과목을 수강하기 위해 등록을 한다.