[소프트웨어공학] 요구분석서

소개글

[소프트웨어공학] 요구분석서에 대한 보고서 자료입니다.

목차

1. 개요(Overview)
1.1 시스템의 개요(System Overview)
1.1.1 수강신청 전 시나리오(Before Scenario)
1.1.2 수강신청 후 시나리오(After Scenario)
1.2 목표(Goals)

2. 기능적 요구(Functional Requirements)
2.1 자료 흐름도(Data Flow Diagram)
2.2 자료 사전(Data Dictionary)
2.3 소단위 명세서(Mini Specification)
2.4 기능면에서의 시스템 특성(Functional System Property)
2.4.1 수강 신청 기능(Course Registration)
2.4.2 내역 조회 기능(Breakdown Inquiry)
2.4.3 이수 학점 처리(Completion Points)
2.4.4 검색 서비스(Search Services)

3. 기타 요구 및 제약 사항(Restriction Condition)
3.1 성능 요구(Performance Requirements)
3.2 H/W 요구(Hardware Requirements)
3.3 예외 조건 및 이의 처리(Exception Control)
3.4 사용자 인터페이스(User Interface)
3.5 제약 사항(Restriction Condition)

4. 인수 조건(Undertaking Condition)
4.1 기능 시험 및 성능 시험(Function & Performance Test)
4.1.1 모듈별 테스트(Module Test)
4.1.2 인터페이스 테스트(Interface Test)
4.1.3 통합 알파 테스트(Integration Alpha Test)
4.1.4 통합 베타 테스트(Integration Beta Test)
4.1.5 인수 테스트(Acceptance Test)

5. 참고자료 및 용어 해설(References & Terms Description)
5.1 참고 자료(References)
5.2 용어 해설(Terms Description)

본문내용

2) 시스템 설치 시 및 운영상에 발생되는 기본적인 사항은 사용자 매뉴얼을 통해 배포하도록 한다.
3) 사용자 매뉴얼로 처리할 수 없는 사항은 유지 보수 계약에 따라 유지보수 팀에서 수행하도록 한다.
3.4 사용자 인터페이스(User Interface)
1) 시스템의 주 사용자층은 관리자를 제외하고 수강신청을 이용하는 학생, 교수이다. 시스템을 사용하는데 전문적인 지식을 최소화 하여 설계한다.
2) 기존 시스템에 대한 멘탈 모델을 기초로 설계하여 변경된 인터페이스에 대한 거부감을 없애도록 한다.
3.5 제약 사항(Restriction Condition)
1) 현 수강신청 시스템은 실제 서비스를 위해서는 시간, 비용 등이 너무 많이 드므로 본 프로젝트에서는 "컴퓨터 정보통신 공학전공"내의 수강신청을 대상으로 한다.
2) 기본적인 학사 사항은 미리 데이터베이스 내에 저장되어 있다고 가정한다.
3) 수강신청 시스템의 사용자는 학생, 조교, 교수 등 다양할 수 있으나 본 시스템에서는 학생으로 한정한다.
4) 관리자는 현재 수강신청 시스템의 수강 정보를 등록, 삭제, 변경을 맞고 있는 교육지원과의 관리자를 의미한다.
5) 별도의 웹서버, 데이터베이스의 관리는 별도의 전문가가 관리 함을 원칙으로 한다.
4. 인수 조건(Undertaking Condition)
4.1 기능 시험 및 성능 시험(Function & Performance Test)
기능시험은 각 단계별로 모듈별 테스트, 인터페이스 테스트를 거친다. 또한 전체적인 성능 시험을 위해 자료 구조 중심 테스트, 통합테스트를 실시하고 완성된 제품에 대한 인수 테스트를 거쳐 인수조건을 만족하도록 한다.
4.1.1 모듈 별 테스트(Module Test)
사용자, 관리자 모듈 별로 기능 테스트를 수행한다.
서버-클라이언트 모델을 기반으로 수행한다.
서버 -> 클라이언트 접속 여부, 데이터베이스와의 연동을 확인한다.
클라이언트 -> 서버 접속 여부, 적절한 트랜잭션 처리를 확인한다.
4.1.2 인터페이스 테스트(Interface Test)
사용자, 관리자 인터페이스의 기능테스트를 수행한다.
요구가 충분히 반영되었는지 확인한다.
요구가 불충분하거나 추가 사항 반영 시 일정을 고려하여 반영한다.
4.1.3 통합 알파 테스트(Integration Alpha Test)
각 모듈을 통합한 후 알파테스트를 수행한다.
각 모듈별 정상적인 동작에 대하여 테스트를 수행한다.
각 기능별 반응시간 및 처리량에 대한 테스트를 수행한다.
4.1.4 통합 베타 테스트(Integration Beta Test)
알파 테스트를 완료한 시스템을 대상으로 베타테스트를 수행한다.
가상의 호스트를 추가하여 트래픽에 대한 안정성을 테스트한다.
각 기능별 반응시간 및 처리량에 대한 테스트를 수행한다.
4.1.5 인수 테스트(Acceptance Test)
베타 테스트를 통과한 시스템에 대하여 인수테스트를 실시한다.
실제 사용 환경에서 테스트를 한다.
5. 참고 자료 및 용어 해설
(References & Terms Description)
5.1 참고 자료(References)
[1] 소프트웨어 공학론, 정익사(최은만 저, 1995)
[2] Code Complete, 정보문화사(Steve McConnell, 서우석 역, 2005)
[3] 우리가 미처 알지 못했던 소프트웨어 공학의 사실과 오해(로버트 L. 글래스 저, 윤성준 외 1명 역, 인사이트)
[4] http://terms.co.kr
[5] http://terms.naver.com/
5.2 용어 해설(Terms Description)
- 자료흐름도(DFD;Data Flow Diagram)
시스템에서의 데이터 흐름을 나타내기 위해 시스템의 분석 과정이나 설계 과정에서 사용되는 그래픽을 이용한 도표이다. 이는 구조적 분석(SA) 및 구조화 설계(SD) 기법에서 가장 기본적인 시스템 분석 도구로, 시스템의 각 부분에서 데이터가 어떻게 처리되어 흘러가는지를 명확히 나타낸다.
- 자료 사전(DD;Data Dictionary)
자료사전은 프로그래머, 또는 이것을 참조할 필요가 있는 사람들의 편의를 위하여, 데이터 모델 내의 데이터 객체들이나 항목들의 설명을 모아놓은 것이다. 사용자와의 상호작용이 있는 객체 시스템을 분석하는 첫 번째 단계는, 각 객체와 다른 객체들 간의 관계를 식별하는 것이다. 이러한 과정을 흔히 데이터 모델링이라고 부르며, 그 결과는 종종 객체의 관계를 나타내는 그림으로 표현된다. 각 데이터 객체나 항목에 이름이 부여되고 나면, 그것들 사이의 관계와 데이터 형태 (텍스트, 이미지, 또는 바이너리 값 등)에 대한 설명, 그리고 미리 정의할 수 있는 값들이 나열되며, 간략한 설명문이 제공된다. 이러한 것들의 모음은 참고를 위해 데이터 사전이라고 불리는 책으로 구성될 수 있다.
- 소단위 명세서(Mini Specification)
소단위 명세서는 자료 흐름도의 최하위 프로세스(primitive process)가 어떤 기능을 하는 가에 대해 논리적 처리 절차를 요약하여 기술한 것이다. 소단위 명세서(mini-spec)는 프로세스 명세서(process specification), 또는 소 작업 명세서(activity specification)로 불리 운다.
소단위 명세서를 작성하는 방식은 다음의 3가지가 대표적이다.
구조적 언어(Structured Language) : 처리 내용을 설명하기 위해 순서형 구조, 결정형구조, 반복형구조 등의 구조적으로 제한된 제어 구조와 제한된 단어, 제한된 문장을 가지고 말하듯이 자연어 형식으로 구성하는 방법으로 가장 보편적인 방법이다.
의사 결정표(Decision table) : 처리 내용을 설명하기 위한 표 구조로, 조건 항목, 조건 기입란, 행동항목, 행동 기입란, 규칙 란으로 구성되어 있다. 주로 복잡한 조건이 있는 경우에 사용한다.
의사 결정도(Decision tree) : 조건 항목 부분과 처리 부분으로 나누어 목(tree) 구조로 표시하여 설명한다. 의사 결정표와 마찬가지로 주로 복잡한 조건이 있는 경우에 사용한다.

키워드

소프트웨어공학,   요구분석서,   소공,   분석서