6. 요구사항 정의

[ SECTION 6. 요구사항 정의 ]

 

Ⅰ. 요구사항의 개념 및 특징

• 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명, 제약조건
• 소프트웨어의 전반적인 내용 확인
• 이해관계자들의 의사소통을 원활하게 함

★ 이해관계자: 소프트웨어 개발 의뢰자, 개발자, 사용자

 

Ⅱ. 요구사항의 유형

➡ 내용에 따라(기능/ 비기능)

① 기능 요구사항: 시스템이 무엇을 하는지, 어떤 기능을 하는지, 입출력

ex) 사용자는 아이디와 비번으로 로그인을 할 수 있음

② 비기능 요구사항: 시스템 장비, 성능, 인터페이스, 보안, 품질, 테스트, 데이터

ex) 시스템은 1년 365일 하루 24시간 운용 가능해야함

 

➡ 기술 관점, 대상의 범위에 따라 (사용자/ 시스템)

③ 사용자 요구사항: 사용자 관점, 친숙한 표현

④ 시스템 요구사항: 개발자 관점, 전문적.기술적 용어, 소프트웨어 요구사항

 

Ⅲ. 요구사항 개발 프로세스

요구사항 추출/분석/명세/검증/관리

순서: 타당성 조사- 요구사항 추출 및 분석- 명세화- 검증

➡ 타당성 조사를 제일 먼저 해야함 (비즈니스 목적에 부합하는지, 예산은 적정한지)

➡ 개발 대상에 대한 요구사항을 도출, 분석한 후 분석 결과를 명세서에 정리, 확인.검증하는 구조화된 활동

 

① 요구사항 도출(수집)

➡ 관련된 사람들이 의견을 교환해 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별, 이해

• 이해관계자간의 효율적인 의사소통
• 개발자와 고객 사이의 관계가 만들어짐, 이해관계자가 식별됨
• 소프트웨어 개발 생명 주기 동안 계속됨
• 주요기법: 설문, 인터뷰, 브레인스토밍, 프로토타입, 유스케이스, 워크샵

② 요구사항 분석- section 7

➡ 명확하지 않고 모호해 이해가 어려운 요구사항을 발견해 걸러내는 과정

• 사용자 요구사항의 타당성 조사, 비용과 일정에 대한 제약 설정
• 요구사항의 소프트웨어 범위 파악, 소프트웨어와 환경이 상호작용하는 방법 이해

③ 요구사항 명세

➡ 요구사항을 체계적으로 분석한 후 문서화 하는 것

• 기능 요구사항은 빠짐없이, 비기능 요구사항은 필요한 것만 기술
• 사용자가 이해하기 쉽고 개발자가 효과적으로 설계할 수 있도록

④ 요구사항 확인(검토)- section 8

➡ 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정화, 완전하게 작성되었는지 검토

• 요구사항 명세서가 이해하기 쉬운지, 일관성은 있는지, 누락된 내용은 없는지 검증
• 이해관계자들이 검토, 요구사항 정의 문서들에 대해 형상관리를 해야함

★ 형상: 어떠한 작업의 결과물, 프로그램, 프로그램을 설명하는 문서나 데이터

★ 형상관리: 형상의 변경 사항을 관리하는 일