제안요청서: Difference between revisions
From IT위키
(새 문서: 분류:소프트웨어 공학분류:프로젝트 관리 ;RFP; Request for proposal == 요구사항의 구분 == {| class="wikitable" ! 구분 ! 내용 |- | 비즈니스 요...) |
No edit summary |
||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
[[분류:소프트웨어 공학]][[분류:프로젝트 관리]] | [[분류:소프트웨어 공학]][[분류:프로젝트 관리]] | ||
;RFP; Request for proposal | ;RFP; Request for proposal | ||
;발주자가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 제안자가 제안서를 작성하는데 도움을 주기 위한 문서 | |||
* 어법상 '제안 요청서'로 띄어씀이 맞으나 NIPA, 조달청 등 국가·공공기관에서 붙여쓰므로 이를 준용 | |||
== 요구사항의 구분 == | == 요구사항의 구분 및 속성 == | ||
=== 요구사항 구분 === | |||
{| class="wikitable" | {| class="wikitable" | ||
! 구분 | ! 구분 | ||
Line 9: | Line 12: | ||
| 비즈니스 | | 비즈니스 | ||
요구사항 | 요구사항 | ||
| * 왜(Why)에 해당하는 정보 | | | ||
* 왜(Why)에 해당하는 정보 | |||
* 발주기관에서 프로젝트를 추진하는 배경 | * 발주기관에서 프로젝트를 추진하는 배경 | ||
* 시스템을 개발함으로써 얻어지는 효과 | * 시스템을 개발함으로써 얻어지는 효과 | ||
Line 15: | Line 19: | ||
| 사용자 | | 사용자 | ||
요구사항 | 요구사항 | ||
| * 무엇(What)에 해당하는 정보 | | | ||
* 무엇(What)에 해당하는 정보 | |||
* 시스템을 통하여 달성되는 "무엇"을 설명 | * 시스템을 통하여 달성되는 "무엇"을 설명 | ||
* 발주기관 현업에서 수행하려는 시스템 | * 발주기관 현업에서 수행하려는 시스템 | ||
Line 21: | Line 26: | ||
| 기능 | | 기능 | ||
요구사항 | 요구사항 | ||
| * 개발해야 하는 기술 행위 요구사항(Behavior Requirements) | | | ||
* 시스템이 | * 개발해야 하는 기술 행위 요구사항(Behavior Requirements) | ||
* 시스템이 수행해야 하거나 시스템을 이용해 발주기관에서 할 수 있어야 하는 것들 | |||
|} | |} | ||
=== 요구사항 속성 === | |||
{| class="wikitable" | |||
! 구분 | |||
! 내용 | |||
|- | |||
| 정확성 | |||
| 명세화된 요구사항이 실제 시스템 구현 시 필요한 것인지 알 수 있도록 정확해야 함 | |||
|- | |||
| 명확성 | |||
| 요구사항을 혼동하지 않도록 한가지 방향으로 해석되어야 함 | |||
|- | |||
| 완전성 | |||
| 시스템이 구현될 때 필요한 요구사항이 빠짐없이 모두 반영되어야 함 | |||
|- | |||
| 일관성 | |||
| 요구사항들 간의 충돌이 없어야 함 | |||
|- | |||
| 수정 용이성 | |||
| 구조와 스타일의 일관성이 유지되면서 요구사항 수정이 용이해야 함 | |||
|- | |||
| 추적성 | |||
| 각각의 요구사항들이 관련 있는 요구사항들과 유기적으로 연결되어야 함 | |||
|} | |||
== 상세 요구사항 분류 == | |||
{| class="wikitable" | |||
! 구분 | |||
! 내용 | |||
|- | |||
| 기능-SFR | |||
(System Function Requirement) | |||
| | |||
* 목표시스템이 반드시 수행하여야 하거나 목표시스템을 이용하여 사용자가 반드시 수행할 수 있어야하는 기능 (동작)에 대하여 기술 | |||
* 단, 개별 기능요구사항은 전체시스템의 계층적 구조 분석을 통해 단위 업무별 기능구조를 도출한 후, 이에 대한 세부기능별 상세 요구사항을 작성하는 것을 원칙으로 하며, 기능 수행을 위한 데이터 요구사항과 연계를 고려하여 기술 | |||
|- | |||
| 성능-PER | |||
(Performance Requirement) | |||
| | |||
* 목표 시스템의 처리속도 및 시간, 처리량, 동적․정적 용량, 가용성 등 성능에 대한 요구사항을 기술 | |||
|- | |||
| 시스템장비구성-ECR | |||
(Equipment Composition Requirement) | |||
| | |||
* 목표사업수행을 위해 필요한 하드웨어, 소프트웨어, 네트워크 등의 도입 장비 내역 등 시스템 장비 구성에 대한 요구사항을 기술 | |||
|- | |||
| 인터페이스-SIR | |||
(System Interface Requirement) | |||
| | |||
* 목표시스템과 외부를 연결하는시스템 인터페이스와 사용자인터페이스에 대한 요구사항을 기술한 것으로 타 소프트웨어, 하드웨어 및 통신 인터페이스, 타 시스템들과의 정보교환에 이용되는 프로토콜과의 연계도 포함하여 기술 | |||
* 단, 인터페이스 요구사항의 경우 사용자 편의성, 사용자 경험 등의 사용자 중심의 요구사항을 기술 | |||
|- | |||
| 데이터-DAR | |||
(Data Requirement) | |||
| | |||
* 목표 시스템의 서비스에 필요한 초기자료 구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등 데이터를 구축하기 위해 필요한 요구사항을 기술 | |||
|- | |||
| 테스트-TER | |||
(Test Requirement) | |||
| | |||
* 구축된 시스템이 목표대비 제대로 운영되는 가를 테스트하고 점검하 기 위한 요구사항을 찾아내어 기술 | |||
* 목표 시스템의 테스트 유형(단위테스트, 통합테스트, 시스템테스트, 성능테스트 등), 테스트 환경, 방법, 절차 등에 대한 요구사항을 기술 | |||
|- | |||
| 보안-SER | |||
(Security Requirement | |||
| | |||
* 정보 자산의 기밀성과 무결성을 확보하기 위해 목표 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항을 기술 | |||
|- | |||
| 품질-QUR | |||
(Quality Requirement) | |||
| | |||
* 목표 사업의 원활한 수행 및 운영을 위해 관리가 필요한 품질 항목, 품질 평가 대상 및 목표에 대한 요구사항을 기술 | |||
* 신뢰성, 사용성, 유지보수성, 이식성, 보안성으로 구분하여 기술 | |||
|- | |||
| 제약사항-COR | |||
(Constraints Requirement) | |||
| | |||
* 목표시스템 설계, 구축, 운영과 관련하여 사전에 파악된 기술·표준· 업무·법제도 등 제약조건 등을 파악하여 기술 | |||
|- | |||
| 프로젝트 관리-PMR | |||
(Project Management Requirement) | |||
| | |||
* 프로젝트의 원활한 수행을 위한 관리 방법 및 추진 단계별 수행방안에 대한 요구사항을 기술 | |||
|- | |||
| 프로젝트 지원-PSR | |||
(Project Support Requirement) | |||
| | |||
* 프로젝트의 원활한 수행을 위해 필요한 지원사항 및 방안에 대한 요구 사항을 기술 | |||
* 시스템/서비스 안정화 및 운영, 교육훈련 및 기술지원, 하자보수 또는 유지관리 요구사항 등을 기술 | |||
|- | |||
| 유지관리수행-MPR | |||
(Maintenance Project Requirement) | |||
| | |||
* 유지관리 대상별 유지관리 방법을 기술한 대상별 유지관리 필요 내역을 도출하는 것으로 장애관리, 변경관리, 성능관리, 백업/복구, 운영 상황 모니터링 등에 대한 요구사항을 기술 | |||
|- | |||
| 유지관리인력-MHR | |||
(Maintenance Human Requirement) | |||
| | |||
* 유지관리 수행 요구사항을 충족하기 위한 운영인력 체계, 담당자 별 역할 및 책임을 포함한 효율적인 유지관리 운영인력 체계와 관리방안에 대한 요구사항 및 유지관리 범위와 서비스를 고려하여 적정한 인원과 투입인력 자격 조건에 대한 요구사항을 기술 | |||
|- | |||
| 컨설팅-CNR | |||
(Consulting Requirement) | |||
| | |||
* 정보화사업의 업무 효율성과 생산성을 높이는 정보시스템을 갖추고 운영할 수 있도록 제반사항을 지원하는 요구사항을 기술함 | |||
|- | |||
| 공사-ENR | |||
(Engineering Requirement) | |||
| | |||
* 정보화 사업 중 전산실 공사, 상황실 공사, 내부 인테리어 등을 요구 하는 경우에 기술함 | |||
|} | |||
== 참고 문헌 == | |||
* 공공 SW사업 제안요청서 작성을 위한 요구사항 상세화 실무 가이드라인(NIPA) | |||
* 소프트웨어사업 요구사항 분석·적용 가이드(NIPA) |
Latest revision as of 01:32, 2 November 2019
- RFP; Request for proposal
- 발주자가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 제안자가 제안서를 작성하는데 도움을 주기 위한 문서
- 어법상 '제안 요청서'로 띄어씀이 맞으나 NIPA, 조달청 등 국가·공공기관에서 붙여쓰므로 이를 준용
요구사항의 구분 및 속성[edit | edit source]
요구사항 구분[edit | edit source]
구분 | 내용 |
---|---|
비즈니스
요구사항 |
|
사용자
요구사항 |
|
기능
요구사항 |
|
요구사항 속성[edit | edit source]
구분 | 내용 |
---|---|
정확성 | 명세화된 요구사항이 실제 시스템 구현 시 필요한 것인지 알 수 있도록 정확해야 함 |
명확성 | 요구사항을 혼동하지 않도록 한가지 방향으로 해석되어야 함 |
완전성 | 시스템이 구현될 때 필요한 요구사항이 빠짐없이 모두 반영되어야 함 |
일관성 | 요구사항들 간의 충돌이 없어야 함 |
수정 용이성 | 구조와 스타일의 일관성이 유지되면서 요구사항 수정이 용이해야 함 |
추적성 | 각각의 요구사항들이 관련 있는 요구사항들과 유기적으로 연결되어야 함 |
상세 요구사항 분류[edit | edit source]
구분 | 내용 |
---|---|
기능-SFR
(System Function Requirement) |
|
성능-PER
(Performance Requirement) |
|
시스템장비구성-ECR
(Equipment Composition Requirement) |
|
인터페이스-SIR
(System Interface Requirement) |
|
데이터-DAR
(Data Requirement) |
|
테스트-TER
(Test Requirement) |
|
보안-SER
(Security Requirement |
|
품질-QUR
(Quality Requirement) |
|
제약사항-COR
(Constraints Requirement) |
|
프로젝트 관리-PMR
(Project Management Requirement) |
|
프로젝트 지원-PSR
(Project Support Requirement) |
|
유지관리수행-MPR
(Maintenance Project Requirement) |
|
유지관리인력-MHR
(Maintenance Human Requirement) |
|
컨설팅-CNR
(Consulting Requirement) |
|
공사-ENR
(Engineering Requirement) |
|
참고 문헌[edit | edit source]
- 공공 SW사업 제안요청서 작성을 위한 요구사항 상세화 실무 가이드라인(NIPA)
- 소프트웨어사업 요구사항 분석·적용 가이드(NIPA)