요구사항 개요 설명

@UML
@웹 프로젝트 진행순서
1단계. 착수
-제안요청서(RFP)
2단계. 요구 사항 정의
3단계. 요구 사항 분석
4단계. 설계 - uml 이 필요함
5단계. 구현
6단계. 테스트
7단계. 이관
8단계. 운영지원

@제안요청서(RFP)
-Request For Proposal
- 발주가(갑)가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 
제안자(을)가 제안서를 작성하는데 도움을 주기 위한 문서

@요구사항
- 문제의 해결 또는 목적 달성을 위하여 고객에 의해 요구되거나, 
 표준이나 명세 등을 만족하기 위해서 시스템이 가져야할 서비스 또는 제약사항
- 고객이 요구한 사항과 요구하지 않았더라도 당연히 제공되어야 한다고 가정되는 사항들

@요구사항의 중요성
- 참여자들로 하여금 개발되는 소프트웨어 제품을 전체적으로 파악하도록 하여 
 의사소통 시간을 절약하게 해주는것
- 상세한 요구사항이 있어야만 산정이 가능하고, 이를 기반으로 계획을 세울 수 있기 때문이다.

@요구사항의 분류
1. 기능적 요구사항(Functional Requirements)
- 목표로 하는 어플리케이션의 구현을 위해 소프트웨어가 가져야 하는 기능적인 속성
- 목표로 하는 제품의 구현을 위해 소프트웨어가 가져야 하는 기능적 속성
ex) Word -> 작성한 글을 저장, 편집, 보기, 프린트......
2. 비기능적 요구사항
- 어플리 케이션의 품질 기준 등을 만족시키기 위해 소프트웨어가 가져야하는 성능, 사용의 용이성, 신뢰도,
 보안성, 운용상의 제약, 안정성, 유지보수성 등과 같은 행위적 특성으로 시스템의 기능에 관련되지 않은 요구사항
ex) 응답시간, 처리량, 보안 등

@요구사항 정의서
- 서비스를 구현하기 위해 거론되는 다양한 요구사항을 명확하게 정리하기 위하여 작성한 것
- 요구사항 명세서라고도 하며 요구사항을 분석하여 명확하고 완전하게 기록하는 것
- 소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약조건에 대해 개발자와 관련자가 합의한
 스펙에 대한 사항을 명세한 것

@요구사항 명세서 <-- 정의서와 명세서를 분류하는 곳도 있음.

-하나의 항목에 대해서 상세하게 설명하는 문서

@ 요구사항 정의서 작성이유
- 프로젝트 전체 규모를 파악
- 구현 가능 여부에 대한 논의
- 커뮤니케이션 비용 절약
- 프로젝트 일정 계획 수립

@UML(Unified Modeling Language)
- 통합 모델링 언어- 설계관련된 약속
- 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어로 소프트웨어 개념을 다이어그램으로
 그리기 위해 사용하는 시각적인 표기법.
- 프로그램 설계를 표현하기 위해 사용하는 그림으로 된 표기법을 위미함.
- 소프트웨어 시스템, 업무 모델링, 시스템의 산출물을 규정하고 시작화하며 문서화하는 언어이다..
<-- 따로 텍스트 형식이 아니라서 한번보면 기억남는 언어-->

@UML 필요 이유
- 시스템의 복잡성을 표준적인 표기법으로 모델링하여 단순하게 표현가능
- 팀 간의 의사 소통에 필요
- 대규모 프로젝트 구조의 로드맵을 만들때 유용 <-- 설계도와 같은 의미 -->
- 개발할 시스템 구축에 대한 기초마련
- 백엔드 문서용으로 사용하기 좋음 

@UML 종류
1. 유스케이스 다이어그램
- 시스템의 제공하는 기능과 이용자와의 관계 표현<--졸라맨 : 사용자가 프로그램을 사용하는 스토리로 구성-->
2. 클래스 다이어그램 <-- JAVA, DB처럼 클래스명/ 변수명/ 메소드명/ 기재하고 그대로 소스코드로 변경하는 것-->
3. 스퀀스 다이어그램 <-- 글래스 다이어그램 통해서 소스코드 작성하면 진행의 순서를 시간순으로 스토리를 만드는 것-->
==========================위에 3가지정도 알면됨
4. 액티비티 다이어그램
5. 콜라보레이션 다이어그램
6. 상태 다이어그램
7. 컴포넌트 다이어그램
8. 배포 다이어그램