소프트웨어공학 3장

소개글

소프트웨어공학 3장에 대한 보고서 자료입니다.

본문내용

능을 정확하고 완벽하며 일관성 있게 작성하여야 한다. 소프트웨어에 포함될 기능과 제약조건들을 나열한다. 기능에 대한 자세한 설명과 예외의 처리들을 어떻게 처리하는가도 기술한다. 시스템의 성능과 관련된 사항, 속도, 정확성, 사용 용이성들도 포함한다.
3.4.1 요구 분석 명세서 작성
요구 분석서는 사용자와 시스템 개발자를 연결시키는 중요한 문서이다.
모든 용어와 절차는 정확히 이해하기 쉽게 정의되어야 하며, 가정과 제약 조건들도 자세히 설명되어야 한다.
+ Gilbert가 제안한 요구 분석서 작성 시 주의해야 할 사항
① 요구 분석서는 사용자와 개발자 모두가 쉽게 이해할 수 있도록 써야 한다.
요구 분석서는 사용자와 개발자 사이의 계약서와 같은 것이므로 쌍방이 무엇에 동의하였는가를 이해하기 쉽게 명확히 작성하여야 한다. 또한 시스템 개발 전체 과정을 위하여 사용한다. 여러 목적으로 쓰이므로 읽기 쉽게 작성하여야 한다.
② 요구 분석서에 기술된 조건은 개발자와 사용자가 모두 동의한 것이어야 한다.
쌍방은 서로의 제약을 이해하여야 한다. 사용자는 개발 불가능한, 또는 지불되는 비용 이상으로 개발을 가용해서는 안된다. 개발자는 시스템이 어떤 기능을 갖는지, 언제 개발이 완료되는지, 어느 정도의 비용이 드는지를 정확히 사용자에게 알려주어야 한다. 쌍방은 계약에 서명한 후에는 변경할 수 없음을 인지하여야 한다.
③ 요구 분석서는 제안된 시스템에 의하여 수행될 모든 기능을 정확히 기술하여야 한다. 제안된 시스템에 의하여 수행될 시스템의 기능은 요구 분석서의 핵심이라고 할 수 있다. 이 단계에서는 어떤 기능이 포함되어야 하는가를 정확하고 완벽하게 기술하여야 한다.
④ 요구 분석서는 제안된 시스템에 영향을 주는 모든 제약 조건을 기술한다. 제약 조건들은 제안된 시스템의 설계에 영향을 미치는 요소가 되어 처음부터 이를 알고 있어야 한다.
⑤ 요구 분석서는 시스템의 인수를 위한 테스트 기준을 제공하여야 한다. 사용자는 시스템 개발을 의뢰할 때 시스템에 대하여 기대하는 수준이 있다. 원하는 기능, 특성, 품질 등에 대해서 정확히 정량적으로 기술한다.
⑥ 요구 분석서는 원하는 시스템의 품질과 상대적인 중요도 및 품질을 재는 방법이 기술되어야 한다. 의료 지원 시스템이나 인공 위성 제어 시스템은 정확성과 고품질이 생명이다. 수행 속도와 사용 용이성이 더 중요한 경우도 있기 때문에, 사용자는 소프트웨어의 품질 기준에 대한 우선 순위를 정해야 한다. 품질 기준은 시험 가능한 기준이 되어야 한다.
+ 요구 분석서의 목차
1. 개요
1.1 시스템의 개요
1.2 목표
2. 기능적 요구
2.1 자료 흐름도
2.2 자료 사전
2.3 소단위 명세서
2.4 기능 면에서의 시스템의 특성
3. 기타 요구 및 제약 사항
3.1 성능 요구(반응 시간, 처리 소요 시간, 처리율)
3.2 H/W 요구(기억 장치 규모, 통신 수용도)
3.3 예외 조건 및 이의 처리
3.4 사용자 인터페이스
3.5 자원, 인력에 대한 제약 조건
4. 인수 조건
4.1 기능 시험 및 성능 시험
5. 참고 자료 및 용어 해설
1장 개요에서는 제기된 문제와 제안된 문제 해결방법에 대한 개요와 시스템 개발의 목표를 기술한다. 다루는 문제에 대하여 익숙하지 않은 독자를 위하여 쉽게 개발적으로 써야 한다. 계획서의 문제 범위를 다루는 부분이 좀 더 구체화 된 것이라 할 수 있다
2장 기능적 요구에서는, 기능적 요구 사항을 자료 흐름도, 자료사전, 소단위 명세서로 표현한다. 기능적 요구는 현재의 시스템과 제안한 시스템에 대하여 나누어 표현하여도 좋으나 제안할 시스템은 모순 없이 정확하게 표현되어야 한다.
3장 기타 요구 및 제약 사항에서는 비기능적 요구 사항들에 대하여 기술한다. 시스템의 품질에 관한 요구뿐만 아니라 프로젝트를 진행하는 과정에 대한 제약9일정과 인력, 자원)사항도 포함된다.
4장 인수 조건에서는 일반적인 인수 조건을 기술한다. 구체적인 테스트 사례를 나열 하는 것이 아니라 인수 테스트의 방법 밑 인수를 만족할 조건을 기술한다.
5장 참고 자료 및 용어 해설은 요구 분석 단계에서 모은 문서나 정보를 첨부하여 설계에 도움이 되게 하여 사용자가 요구분석서를 읽을 때 도움이 되도록 용어 설명을 덧붙인다
3.4.2 요구 분석 명세서의 평가
+ 소프트웨어 개발 과정에서 무엇보다 중요한 것은 산출물에 대한 평가이다. 산출물이란 소프트웨어 뿐만 아니라 중간 단계에서 완성된 명세서 등의 결과도 포함된다.
평가를 하는 이유는 프로젝트의 진행을 측정하고 관리하기 위해서이다. 프로젝트가 계획된 일정대로 진행되고 있는지 확인하는 수단이 되는 것이다. 또한 수행하는 일을 결적으로 측정할 수 있다. 일의 결과가 질적으로 예상한 기준 이상의 것인지 확인 할 수 있고 만일 그이하의 것이라면 어떤 작업이 필요한지 대책을 강구할 수 있다.
+ 요구 분석 명세서를 평가 하는 기준
① 무결성과 완벽성
요구 분석서는 사용자의 요구를 오류없이 완벽하게 반영하고 있어야 한다. 요구 분석이 정확하지 않다면 개발된 소프트웨어는 사용자가 원하는 대로 작동하지 않게 된다. 또한 요구 분석이 사용자의 요구를 완벽하게 기술하지 못했다면 개발된 소프트웽J는 사용자가 원하는 시스템의 일부 기능만 갖는 것이 된다.
② 일관성 : 요구 분석서 안에 서로 모순되는 부분이 없어야 한다.
③ 명확성 : 요구 분석의 내용이 여러 의미로 해석되는 모호한 점이 없는지 살펴본다. 요구 분석은 모호한 점이 없도록 간결하고 명쾌하게 써야 한다
④ 기능적 : 기능적이란 요구 분석 명세서가 ‘어떻게’보다 \'무엇을‘에 관점을 두고 기술되어야 함을 의미한다.
⑤ 검증 가능성 : 두 가지로 검증 가능하여야 한다. 먼저 요구분석이 사용자의 요구를 만족시키고 있는지 검증할 수 있어야 한다. 또한 개발된 시스템이 요구 분석에 기술된 내용과 일치하는지를 검증할 수 있어야 한다.
⑥ 추적 가능성 및 변경 용이성 : 요구 분석 명세서의 내용은 장, 절, 문단으로 나뉘어 체계적으로 정리되어야 한다. 설계서, 사용자 지침서 등, 후에 작성될 문서에서 인용하거나 특정 내용을 변경하기 위하여 찾기 쉽도록 하기 위한 것이다.

키워드

소프트웨어공학,   다음은 컴퓨터 실습실의 비디오 감시 시스템에 대한 ,   소프트웨어