NOTE3 - 5장 요구사항 분석이란? 5-1 5.1...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 5장 요구사항 분석이란? 5-1 5.1 요구사항 분석 정의 ■ 문제에 대한 정의 를 내리는 것 ■ 개발에 들어가기 전 문제에 대한 명확한 설명과 이해를 하기 위하여 필요 ■ 소프트웨어 개발 노력의 성패도 개발하는 시스템의 목표를 프로젝트 초기에 확립할 수 있느냐에 달려있다. ■ 시스템의 목표를 확립하는 과정 이 요구사항 분석과정 5-2 요구사항 분석과 라이프 사이클 요구사항 분석 요구사항 분석 설계 설계 구현 시험 시험 유지보수 유지보수 5-3 요구사항 분석 임무 ■ 요구사항의 발견, 정제, 모델링, 그리고 명세화하는 과정 ■ 문제기술을 보다 세부적으로 다루어 시스템의 요구사항을 세분화 하고 그 결과를 통합하여 원하는 시스템을 기술 ■ 시스템이 만족시켜야할 기능, 성능, 그리고 다른 시스템과의 인터페이스 등 규명 ■ 소프트웨어 개발에서 가장 어려운 부분은 사용자 또는 개발비용을 부담하는 후원인인 고객의 문제점을 이해하는 것 ■ 즉, 고객에게 무엇 (what)을 제공할 것인가를 정확히 기술하는 것이 다. ■ 요구사항 분석의 최종 산출물은 요구사항 명세서 5-4 분석(Analysis)의 특징 ■ 요구사항 분석은 설계, 코딩 및 시험과는 다른 많은 특징을 가지고 있다. ■ 고객들과 협상하여 공동의 목표를 끌어내야 하는데, 특히 요구가 다양하고 목표가 상반되어 그들 모두를 만족시켜야하는 일이 결코 쉬운 일이 아니다. ■ 요구사항을 분석하는 분석가와 사용자와의 인간 관계는 쉽지 않다. ■ 분석가의 위치가 수비적이 되기 쉽다는 문제점이 있다. ■ 분석과정에 있어서는 확정적이지 못한 것이 많다. ■ 분석과정을 통하여 많은 협상과 타협이 이루어진다. 5-5 5.2 소프트웨어 개발 환경의 변화 ■ 초기에 자동화되는 것들은 간단하고 초보적인 것들이었으며, 그 후 전산지식이 있는 사람들에 의해 다양한 응용분야가 전산화되기 시작했다. ■ 단순한 응용 분야는 전산화가 이루어진 지 오래이며, 현재는 복잡한 응용분야의 전산화가 이루어지고 있다. ■ 이제는 반대로 각 응용분야를 전공한 사람들이 전산 지식을 습득 하여 전산 업무에 뛰어들고 있는 실정이다. 5-6 5.2.2 시스템 분석가의 자질과 임무 ■ 응용 분야에 대한 지식 이 필수적 ■ 하드웨어, 소프트웨어를 포함한 컴퓨터에 대한 기술 을 이해 ■ 의사소통(communication) 능력 듣고, 말하고, 쓰고, 발표하는 능력 매우 중요 ■ 사용자의 요구사항과 전문가의 전문지식을 뽑아내는 것이 분석가의 임무이다. 5-7 요구사항 명세서 ■ 요구사항 분석의 최종 목표는 요구사항 명세서 ■ 요구사항 명세서는 산출물중 가장 중요한 문서 ■ 요구사항 명세서는 소프트웨어 시스템의 생명이 다할 때까지 따라 다닌다. ■ 요구사항 명세서는 시스템의 목표를 기록하며 그 목표를 어떻게 달성할 것인가의 해결방법은 기록하지 않는다 ■ 시험 계획은 요구사항 명세서로부터 나온다. ■ 세계 표준화 기구인 ISO에서 제시하는 문서화된 품질 시스템에 요구되는 대표적인 문서가 요구사항 명세서 5-8 요구사항 명세서의 조건 ■ 명시되어 있는 조건들은 고객과 개발자가 동의한 것이어야 한다. ■ 제안된 시스템이 수행할 모든 기능을 명확하게 기술해 놓아야 한다. 시스템이 수행할 기능은 요구사항 명세서의 핵심 ■ 제안된 시스템에 영향을 미치는 모든 제약 조건을 요구사항 명세서 에 명시 ■ 시스템을 사용하기 위해 필요한 조항들을 검증할 수 있도록 요구 사항 명세서에 검증 기준을 제시 ■ 원하는 시스템의 품, 상대적인 중요성, 품질의 측정 및 검증 방법 등을 요구사항 명세서에 명시 ■ 시스템의 포용성과 오류 조건 명시 5-9 요구사항 명세서 문서 양식 1. 제목과 목차 (Title page and table of contents) 2. 서론 (Introduction) /*기술적인 목표와 사업 목표를 포함한 시스템의 목표를 기술한다.*/ 2.1 독자 (Audience) /*이 문서를 읽을 독자들을 기술하고 독자의 유형을 분류하여 문서 전체를 읽어야 하는 경우와 문서의 일부를 생략하고 읽어도 되는 경우를 기술한다. */ 2.2 전체 기술 (Overall Description) 2.3 프로젝트 제약조건 (Project Constraints) 3. 기능 기술 (Functional Description) /*정보 흐름이 어디로 어떻게 이루어지는지 체계적이며 구체적으로 기술한다. 독자들이 이해하기 쉽도록 정보의 흐름과 내용, 구조 등이 쉽게 기술되어야 한다.*/ 3.1 자료 흐름도 (Data Flow Diagram) 3.2 프로세스 명세서 (Process Specification) /*DFD 의 최하위 프로세스(원시 프로세스)에 대한 기본 기능이 기술된다. 가능하면 한 장에 한 프로세스만을 기술하는 것이 좋다.*/ 3.3 자료 사전 (Data Dictionary) /*4.2의 자료사전과 합쳐질 수 있다*/ 4. 정보 기술 (Information Description) /*시스템의 객체, 객체의 속성, 객체 사이의 연관성을 규명한다*/ 4.1 ERD (Entity-Relationship Diagram) 4.2자료 사전 (Data Dictionary) /*3.3의 자료사전과 합쳐질 수 있다*/ 5 - 10 요구사항 명세서 문서 양식(계속) 5. 초보 사용자 매뉴얼 (Preliminary User Manual) /*매뉴얼의 사용자가 누구인가 규명하고 사람과 시스템 사이의 인터페 이스에 대한 정보를 기술한다. 데이터를 중심으로 예상되는 6. 입출력 메뉴 구조, 스크린, 보고서 형식 등이 포함될 수 있다.*/ 검증 기준 (Validation Criteria) /*최종 결과물이 실제로 요구사항 명세서에 기술되어 있는지 사용자와 평가자가 검증할 수 있도록 검증 기준을 기술한다. 약속한대로 시스템이 만들어졌는지 결정할 수 있도록 점검 리스트(check list)를 포함 한다.*/ 7. 무기능 요구사항(Nonfunctional Requirements) /*규제 조항과 제약 조건을 기술한다. 예를 들어 외부 규제, 법률 (예: 사생활 침해), 안전도 규제 사항, 표준과 관계되는 사항을 기술 한다. '모든 정보는 ASCII 문자 집합으로 기술되어야 한다' 또는 '시스템은 명령이 떨어진 후 2초 내에 반응해 야 한다' 등은 그 예이다.*/ 8. 요약 (Summary) 9. 감사의 글 (Acknowledgments) 10. 부록 (Appendices) /*이 프로젝트와 관련하여 앞으로 향상될 수 있는 부분에 대하여 기록한다*/ 5 - 11 5.2.5 분석의 문제점 ■ 의사 소통의 문제 ■ 요구사항의 계속적 변화 ■ 분석도구의 미비 ■ 문서화의 어려움 ■ 정치적인 문제 ■ 일 할당 문제 5 - 12 5.3 정보 수집 및 사용자와의 대화 방법 ■ 누구(WHO): 누가 분석을 하는 과정에 참여할 것인가? 각 참여자는 어떤 역할을 수행할 것인가? 누가 만들 시스템을 쓸 것인가? ■ 무엇(WHAT): 현재 무엇이 문제인가? 만들어질 시스템은 어떤 모습 이며 어떤 기능이 수행되어야 하는가? ■ 언제(WHEN): 언제 새 시스템이 설치되어야만 하는가? ■ 어디(WHERE): 기존 한경의 어디에 새 시스템이 이용될 것인가? ■ 왜 (WHY): 왜 새로운 시스템이 개발되어야 하느가? 왜 고객이 새로운 시스템의 개발을 필요로 하는가? ■ 어떻게(HOW): 새로운 시스템은 어떻게 기능을 수행할 것인가? 새로운 시스템은 어떤 제약 조건 하에서 기능을 수행할 것인가? 5 - 13 5.3.3 질문의 유형 1) 열린질문 (open questions) 2) 닫힌질문 (closed questions) 3) 추가질문 (probes questions) 5 - 14 5.3.4 인터뷰의 구조 ■ 인터뷰의 구조는 인터뷰를 하기 이전에 다한 유형의 질문들을 어떻게 준비하느냐에 따라 결정 - 피라미드 구조(pyramid structure), - 깔때기 구조 (funnel structure), - 다이아몬드 구조(diamond structure) 5 - 15 (1) 피라미드 구조 ■ 질문의 유형을 구체적인 예에서 일반적인 것으로 옮겨 가도록 준비 ■ 분석가는 구체적이며 닫힌질문을 시작하여, 열린질문을 하여 주제를 넓혀나가 일반화된 결과를 얻어 낸다. ■ 특히 인터뷰에 응하는 사람이 아이디어가 떠오를 수 있도록 하거나 주제에 대하여 논의하기를 꺼릴 때 바람직 5 - 16 (2) 깔때기 구조 ■ 분석가가 일반적이며 열린질문으로 시작하여 점차 닫힌질문으로 좁혀나갈 때 나타난다. ■ 일반적으로 인터뷰를 시작할 때 쉽게 접근할 수 있게 하여준다. ■ 이 경우 열린질문으로 시작하기 때문에, 인터뷰에 응하는 사람이 질문에 대하여 잘못된 답을 하지않을까 하는 중압감을 덜 느끼게 된다. ■ 인터뷰에 응하는 사람이 주제에 대하여 감정적이거나 자신의 감정을 표시하고자 할 때 도움을 줄 수 있다. 5 - 17 (3) 다이아몬드 구조 ■ 앞의 두 구조를 섞은 것 ■ 구체적인 질문으로 시작하여 일반적인 문제들이 다루어 진 후 마지막으로 구체적인 결론들이 유도될 수 있도록 인터뷰를 진행 ■ 다이아몬드 구조는 피라미드와 깔때기형 구조의 장점을 합친 것 ■ 주요 장점: 다양한 질문을 통하여 인터뷰 응하는 사람의 주의와 흥미를 끌 수 있게 할 수 있다. ■ 단점: 앞의 방법보다 시간이 많이 걸린다는 점 5 - 18 5.3.5 인터뷰의 주의점 ■ 인터뷰를 성공적으로 진행하여 필요로 하는 정보를 얻어내야 한다. ■ 이를 위해 분석가는 주도적으로 인터뷰 진행 ■ 이를 위해 분석가는 정직하고 직접적으로 자신의 의사를 표현 ■ 또한 인터뷰에 응하는 사람의 기분을 상하지 않는 방법으로 인터뷰가 진행되어야 한다. ■ 어떤 질문은 상대방을 속박하고 마음을 불편하게 할 수 있다. 예: '다른 관리자들이 동의하는 것처럼 재고 관리가 자동화되어야 한다고 생각합니까?' 다른 방법: '재고관리의 자동화에 대하여 어떻게 생각하십니까?' 5 - 19 5.3.6 설문지 ■ 질문사항을 만들어 우편이나 인터네트 등의 통신망으로 보내거나 설문지를 전달하여 간접적으로 정보를 모으는 방법 ■ 설문지를 통해 사람들의 자세, 믿음, 행위 등에 관한 정보를 모을 수 있다. ■ 설문지의 질문들도 열린 경우와 닫혀진 경우로 나눌 수 있다. ■ 열린질문에 대한 응답은 여러 가지로 분석되고 해석될 수 있다. ■ 설문지를 통해 많은 사용자 단체에 대한 응답을 구할 수 있고, 그 결과를 정량화 할 수 있다. ■ 인터뷰가 수행되기 이전, 문제점이나 논쟁의 대상이 되는 것을 미리 파악할 수 있다. ■ 우선 분석가는 설문지에 의해 수집되어야 하는 정보들을 결정하여야 한다. 5 - 20 설문지가 적당한 경우 ■ ■ 사람들이 지역적으로 널리 분산되어 있는 경우 시스템에 의해 많은 사람들이 영향을 받고 다양한 기능에 대한 그들의 의견이 요구되는 경우 ■ 시스템에 대한 전체 의사가 필요한 경우 ■ 현재 시스템의 문제점을 파악하고 싶은 경우 5 - 21 설문지의 주의점 ■ 설문지를 사용하는 경우 직접적인 교류가 가능하지 않다. ■ 설문지의 질문들은 명확히 이해할 수 있어야 하고, 질문의 흐름이 논리적으로 순서에 맞아야 하고, 응답자의 질문을 예상할 수 있어야 한다. ■ 열린질문이 있을 경우 어떠한 종류의 대답이 있을 것인지 예측하고 있어야 한다. 이를 통해 받은 응답들을 올바로 분석할 수 있다. 예: 만약 '시템에 대하여 어떻게 생각합니까?'라는 질문은 그 반응이 너무 광범위하여 해석하기가 어렵다. ■ 질문들은 구체적인 방법으로 대답할 수 있도록 좁혀지는 것이 바람직 하다. 예: '아래의 소프트웨어 패키지 중 당신이 가장 많이 사용하는 것을 골라주십시오' 등도 그 예이다. ■ 잘 설계된 설문지를 만들어야 응답자들의 호기심을 자극시키고 보다 나은 정보를 얻어낼 수 있다. 5 - 22 5.4 모델링 (Modeling) ■ 모델링이란 개발대상 시스템의 성능분석이나 동작과정 등을 알아보기 위하여 간단한 물리적 모형, 도해를 만들거나 또는 그 시스템의 특징을 수학적으로 표현하는 과정 ■ 우리는 실세계를 이해하기 위해 그의 표현을 필요로 하며, 모델링은 실세계의 표현을 가능하게 한다. ■ 모델링은 어떤 것을 만들기 전에 그것을 이해하기 위한 목적으로 추상화하는 작업 ■ 모델이란 우리의 관심 분야에 맞추어 실세계의 존재를 의도적으로 불완전하게 표현한 추상적인 것 ■ 모델링의 결과는 우리의 관심 분야가 아니거나 필수적이 아닌 세부적인 것은 생략하기 때문에 다루기가 쉽고 필수적인 것만을 표현 ■ 추상화 기능은 어렵고 큰 문제를 다루는 데 있어서 필수적 5 - 23 추상화 작업 ■ 현재의 목적과 무관한 부분을 제거시켜 우리의 관심 부분에 집중할 수 있도록 하는 것 ■ 추상화를 위해서는 그 목적이 뚜렷해야 하며, 이러한 목적은 무엇이 중요하고 중요하지 않은지를 결정 ■ 추상화의 결과는 항상 불완전하고 부정확하지만 그것이 추상화의 필요성과 유용성을 감소시키지는 않는다. ■ 좋은 모델은 어떤 문제의 중요한 핵심만을 포함하고 나머지 것들을 생략 5 - 24 모델의 활용 ■ 용도에 따라 실제의 모습을 여러 가지로 나타냄 ■ 어느 한 모델이 실세계 또는 시스템의 모든 관점을 다 표현할 수 없다. ■ 모델은 단순하고 이해하기 쉬워야 하며 모호성이 없어야 한다. ■ 너무 많은 기호가 사용되면 많은 내용을 포함할 수는 있으나 이 모델은 사람들이 이해하기 어렵게 되고 외면 당하여 결국에는 사용하지 않게 된다. ■ 모델링의 결과는 요구사항 명세서의 핵심 부분이 되며 프로젝트의 다음 단계로 옮겨가는데 필요한 정보 제공 ■ 모델링은 도표를 사용하여 시스템을 논리적으로 분할할 수 있게 하여 준다. ■ 모델링의 결과는 사용자와 개발자 사이의 대화의 도구로 사용 ■ 프로젝트의 초기 단계에서 필요한 요구사항을 뽑아내는 데 많은 도움을 준다. ■ 개발 단계에(설계, 구현, 시험 포함) 필요한 시스템의 윤곽과 골격 제공 5 - 25 모델의 예: 지도(1/2) (a) 실제의 모습 (c) 불완전한 표현 5 - 26 모델의 예: 지도(2/2) (c) 지형학적 표현 (d) 지질학적 표현 5 - 27 5.4.1 모델링의 기본 요소 (1) 표현(Representation): 사용자 공급자 공급 부속품 생산 판매 생산자 < 그림 5.4 정보 모델의 표기법 > 5 - 28 모델링의 기본 요소(계속) (2) 규약 (Convention) : 시각적인 표현에 대한 설명 생산자 판매 엔티티 타입 관계 타입 < 그림 5.5 정보 모델의 규약 > (3) 상술 (Specification) - 시각적인 표현을 텍스트로 확증하는 과정으로 모델링 과정에서 나타난 도표의 구체적인 정의 - 이 구체적인 설명은 모델의 일부분 - 상술된 자료는 미니 명세서, 자료사전 등에 저장하여 관리 5 - 29 5.5 소프트웨어 시스템의 3가지 관점 ■ 실제의 모습은 그 용도와 관점에 따라 다르게 표현되고 사용 ■ 한 모델은 한 관점을 정확히 표현하여 유용하게 사용되면 족하며 한 모델을 통해 여러 관점을 나타내기는 어렵다. ■ 시스템은 바라보는 관점 (view)에 따라 모습이 달라지고 용도도 달라진다. ■ 어느 한 관점도 실세계에 존재하는 그의 실제 모습을 완벽하게 나타내지는 못하며 불완전하고 부정확 ■ 그러나 각 관점은 그를 나타내는 중요한 핵심을 포함하고 있기 때문에 각 관점의 필요성과 유용성을 감소시키지는 않는다. ■ 소프트웨어는 3가지의 주요 관점에서 보아지고 기술 - 기능 관점 - 동적 관점 - 정보(객체) 관점 5 - 30 소프트웨어 시스템의 세관점 정 보 ( 객 체 ) 모 델링 (Information Modeling) 정보 ( 객체 ) 관 점 기능 관 점 동적 관 점 소프트웨어 시 스템 기능 모 델링 (Function Modeling) 동 적 모 델링 (Dynamic Modeling) < 그림 5.6 소프트웨어 시스템의 세 관점 > 5 - 31 a. 기능 관점 (Function Space) ■ 기능 모델은 시스템이 어떠한 기능을 수행하는가의 관점에서 시스템 기술 ■ 데이터에 대하여 수행되는 계산에 초점을 맞춘다. ■ 기능 모델은 주어진 입력에 대하여 어떤 결과가 나오는가를 보여 주는 관점이며 연산과 제약조건을 묘사 ■ 기능 모델은 시스템의 계산에 관한 논리와 현상을 보여주는 반면, 계산이 일어나는 순서는 물론 데이터가 생성되거나 도착하는 순서 등에 대하여 기술하지 않는다. ■ 기능모델의 일반적인 표현 방법은 바블 도표라고도 불려지는 자료 흐름도에 의하여 도식적으로 나타난다. ■ 자료흐름도는 데이터에 수행되는 계산에 근거하여 시스템을 쪼개 나간다. ■ 자료흐름도의 중요 구성요소는 기능을 수행하는 프로세스와 자료 흐름이다. 5 - 32 기능 관점 ■ 기능 모델링에 사용되는 대표적인 분석기법을 구조적 분석이라 하며 자료흐름도와 자료사전에 의해 그 결과를 나타낸다. ■ 구조적 분석기법은 정보의 흐름과 정보의 변환을 나타내는 방법으로 요구사항 분석 도구로 가장 많이 사용되고 있다. 사람 물 끓이기 물 차 준비 우유 추가 끓인 물 차 추가 차 설탕을 첨가한 홍차 설탕 추가 홍차 5 - 33 b. 동적 관점 (Dynamic Space) ■ 시간의 변화에 따른 시스템의 동작과 제어에 초점을 맞추어 시스템의 상태 (state)와 상태를 변하게 하는 원인들을 묘사 ■ 이는 시스템의 시간과 변화에 대한 것을 포함 ■ 시스템은 시간의 변화에 따라 한 상태에서 다른 상태로 변화하게 되므로 이러한 변화는 동적인 면을 가지게 되고, 그로 인해 이 모델을 동적 모델 이라 부른다. ■ 많이 사용되는 동적 모델링 도구로는 상태변화도 와 사건추적도 등 ■ 상태와 사건이 동적 모델링의 주요 구성 요소 5 - 34 동적 관점 ■ 외부와의 상호작용이 많은 실시간 시스템들은 동적 관점에서 시스템 이 기술되어야 한다. ■ 상태변화도(State Transition Diagram), State Chart, SDL(Specifi -cation and Description Language), 페트리네트(Petrinet) 등은 그 대표적인 도구이다. 물 추가 물 끓이기 차 추가 설탕 추가 차 만드는 시스템 우유 추가 차 준비 사람 5 - 35 c. 정보 관점 (Information Space) ■ 정보 모델은 시스템에 필요한 정보를 보여줌으로써 시스템의 정적인 정보구조를 포착하는 데 사용 ■ 시스템에 사용되는 정보 객체를 찾아내고, 이들 객체의 특성, 객체들 사이의 관계와 연관성을 규명 ■ 정보 모델은 다른 두 관점보다 실세계를 정확히 묘사할 수 있는 장점 ■ 이 모델에 나타나는 객체들은 다른 모델에서 나타나는 결과와는 달리, 변하지 않고 안정감이 있어 시스템 개발에 있어 튼튼한 기초를 제공 ■ 정보 모델은 시스템의 기능이나 동적인 면을 고려하지 않으며 오직 정적인 것에만 초점을 맞춘. ■ 정보 모델은 특히 시스템의 데이터베이스를 분석하는 데 많이 사용 ■ ER 모델 또는 EER 모델은 그 대표적인 도구 5 - 36 정보 관점 ■ 정보의 중요성이 부각됨에 따라 시스템의 기능보다는 정보와 데이터 에 초점을 맞추는 추세이며 정보 모델링의 중요성도 증가 ■ 객체지향 시스템 개발 방법론도 정보 모델링을 기초로 하여 시스템 을 분석하고 개발하는 접근 방법 ■ 객체지향 모델은 객체의 정적인 정보에 객체의 동적인 면과 기능 관점을 추가하여 완벽한 객체를 구현하는 게 그 목적 차 설탕 물 찻잎 우유 사람 5 - 37 5.5.1 세 관점의 통합 ■ 이들 세 가지 모델은 시스템의 각기 다른 면을 나타내며 어느 하나도 시스템 전체를 완벽히 설명하지는 못한다. ■ 이들 세 가지 관점이 모아지고 통합 (integration)되어야 시스템의 요구사항이 완벽히 표현될 수 있다. ■ 개발하는 응용 분야에 따라서는 한 관점이 시스템의 필요한 모든 모습을 거의 다 설명하여줄 수도 있을 것이며, 이런 경우 다른 관점은 간략하게 묘사되거나 생략될 수 있다. 예: 컴파일러 시스템: 기능 모델링 데이터베이스 시스템: 정보 모델링 통신 시스템: 동적 관점과 기능 관점에서의 모델링 5 - 38 5.6 요약 ■ 요구사항 분석은 시스템의 목표를 확립하는 과정이며 개발에 들어가 기전 문제에 대한 연구를 하는 것 ■ 목표가 정확해야 프로젝트가 성공적으로 이루어질 수 있으며 목표는 구체적이어야 한다. ■ 요구사항 분석의 결과물인 요구사항 명세서는 사용자와 개발자 모두 에게 공통의 목표를 제시하는 것 ■ 요구사항 명세서는 시스템 개발 전과정에 걸쳐 기준이 되는 중요한 문서 ■ 요구사항을 완벽하게 이해하는 것은 소프트웨어 개발이 성공적으로 되기 위한 필수조건 ■ 요구사항 명세서는 사용자와 개발자 모두에게 대화의 도구로서 사용 되며 설계 및 프로그래밍 단계에서 필요로 하는 중요한 정보를 포함하고 시스템의 윤곽과 골격을 제공 5 - 39 요약(계속) ■ 분석가에게는 전산학적인 배경이외에 다른 많은 자질이 요구 ■ 분석가에게는 의사소통 기술과 협상기술이 요구 ■ 좋은 품질의 제품은 각 공정과정마다 철저한 검증을 거쳐나갈 때만 가능하며 특히 요구사항 분석과정의 결과물인 요구사항 명세서의 검증은 완벽히 이루어져야 한다. ■ 공식 기술 검토회를 거쳐 많은 문제점이 여과된 후 개발에 들어가야 한다. ■ 모델링은 요구사항 분석을 체계적으로 할 수 있게 해주고 그 결과를 문서화할 수 있도록 도와주는 기법 ■ 소프트웨어 시스템은 크게 3가지의 주요 관점인 기능 관점, 동적 관점, 정보 관점에서 보아진다. ■ 체계적인 개발을 위해 3가지 관점이 통합되어야 하며 응용분야에 따라 특정 관점이 다른 관점보다 중요시 됨 5 - 40 ...
View Full Document

This note was uploaded on 11/15/2011 for the course ECON 101 taught by Professor David during the Spring '11 term at Kwansei Gakuin University.

Ask a homework question - tutors are online