[정처기] 요구사항 정의를 알아보자!

요구사항의 개념 및 특징

 

소프트웨어의 문제 해결을 위한 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건을 나타낸다.

 

소프트웨어의 개발과 유지보수 과정에서 필요한 기준과 근거를 제공한다

 

전반적인 소프웨어의 내용을 확인할 수 있게하므로 개발에 참여하는 관계자들 간의 의사소통을 원할하게 하는데 도움을 제공한다.

 

제대로 정의 되어야만 과정의 목표와 계획을 수립할 수 있다.

 

요구사항의 유형( 종류 )

요구사항은 기술하는 내용에 따라 기능 요구사항, 비기능 요구사항으로 구분하며 기술 관점과 대상의 범위에 따라 시스템 요구사항, 사용자 요구사항 으로 나눈다.

 

기능 요구사항 ( Functional Requirements )

• 시스템의 역활, 기능에 대한 사항
• 입력과 출력의 목적과 포함, 저장할 데이터와 연산할 기능이 있는지 여부 파악
• 시스템이 반드시 수행해야하는 기능
• 사용자가 시스템을 통해 제공 받기를 원하는 기능

비기능 요구사항 ( Non-Functional Requirements )

• 시스템 장비 구성 요구사항 ( Hardware )
• 성능 요구사항 ( 처리 시간, 처리량 )
• 인터페이스 요구사항
• 데이터 요구사항
• 테스트 요구사항
• 보안 요구사항 ( 운영 접근 통제 )
• 품질 요구사항 ( 가용성, 정합성, 상호 호환성, 대응성, 신뢰성, 사용성, 유지-관리성, 이식성, 확장성, 보안성 등으로 구분하여 기술한다. )
• 제약 사항 ( 설계, 구축, 운영 )
• 프로젝트 관리 요구사항 ( 관리 방법 )
• 프로젝트 지원 요구사항 ( 지원 )

 

요구사항 개발 프로세스

 

소프트웨어 개발 대상에 대항 요구사항을 체계적으로 도출하고 분석한 후에 결과를 명세서에 정리하고 확인 및 검증하는 일련의 구조화된 활동이다.

 

요구사항 개발 프로세스가 진행되기전에 프로세스가 비즈니스 목적에 부합한지, 예산은 적정한지등의 정보수집후에 평가한 보고서를 토대로 타당성 조사( Feasibility Study )가 선행되어야 한다.

 

요구사항 개발은 요구공학( Requirement Engineering )의 한 요소이다.

 

요구사항 개발 프로세스의 절차

 

요구사항 도출 ->요구사항  분석 ->요구사항  명세 ->요구사항  확인

 

요구사항 도출 ( Requirement Elicitation : 요구사항 수집 )

 

시스템, 사용자, 시스템 개발에 관련된 의견을 교환하여 어떻게 수집할 것인지 식별하고 이해하는 과정이다.

 

• 요구사항 도출은 소프트웨어가 해결해야할 문제를 이해하는 첫 단계다.
• 개발자와 고객 사이의 관계가 만들어지고 이해관계자( Stackholder )가 식별된다.
• 이해관계자와의 효율적인 의사소통이 중요하다.
• 개발 생명 주기( SDLC )동안 지속적으로 반복된다. ( Software Development Life Cycle )
• 기법에는 청취, 인터뷰, 설문, 브레인 스토밍, 워크샾, 프로토타이핑, 유스케이스가 있다.

 

요구사항 분석( Requirement Analysis )

개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정이다.

 

• 사용자의 요구사항에 대한 타당성을 조사하고 일정에 대한 제약조건을 설정한다.
• 중복되거나 통합되어야하거나 서로 상충되는 요구사항이 있으면 이를 중재하는 과정이다.
• 도출된 요구사항을 기반으로 소프트웨어의 범위를 파악한다.
• 도출된 요구사항을 기반으로 소프트웨어와 주변 환경이 상호작용하는 방법을 이용한다.
• 분석에는 자료흐름도( DFD ), 자료사전( DD )등의 도구가 사용된다.

 

요구사항 명세( Requirement Specification )

 

분석한 요구사항들을 문서화하는 것을 의미한다. 

 

• 요구사항은 완전하고 명확하게 기술해야한다.
• 비-기능 요구사항은 필요한 것만 명확하게 기술해야한다.
• 사용자가 이해하기 쉬워야하며 개발자가 효과적으로 설계할 수 있게 작성되어야한다.
• 설계 과정에 잘못된 부분이 확인되면 요구사항 정의서에서 추적할 수 있어야한다.
• 소단위 명세서( Mini-Spec )이 사용될 수 있다.

 

요구사항 명세서 / 명세 기법

 

업계 표준 용어로 소프트웨어가 반드시 제공해야하는 기능이다.

 

소프트웨어의 특징, 제약조건등을 명시한다.

 

• 성능, 보안, 사용성과 같은 품질도 기술한다.
• 프로젝트 유형에 맞는 양식을 만들어서 사용한다.
• 소프트웨어 요구사항 명세서에 포함되는 시스템의 기능, 데이터 저장, 외부 인터페이스, 품질요구사항을 명시한다.

 

요구사항 명세 기법

구분	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반, 모델 기반	상태, 기능, 객체 중심
작성방법	수학적 기호, 정형화된 표기법	일반 명사, 동사등의 자연어를 기반으로 서술 또는 다이어그램으로 작성
특징	요구사항을 정확하고 간결하게 표현할 수 있으며 완전성을 검증 가능하다. 표기법이 어려워 사용자가 이해하기 어렵다.	자연어로 인해 작성자에 따라 일관성이 떨어지며 해석이 달라진다. 내용의 이해가 쉬어 의사소통이 용이하다.
종류	VDM, Z, Petri-net, CSP등	FSM, Decision Table, ER모델링, State chart( SADT )등

 

 

요구사항 확인 ( Requirement Validation : 요구사항 검증 )

요구사항 명세서가 정확한지 완전한지 검증하는 단계이다.

 

• 요구사항을 이해한 후 작성했는지 확인( Validation )필요
• 실제 요구사항인지 서로 상충되는 내용인지 검증
• 재작업 비용이 발생하므로 검증이 필수적이다.
• 요구사항이 이해하기 쉬운지, 일관성이 있는지, 회사의 기준에 적합한지, 누락한 것이 없는지 검증이 중요하다.
• 요구사항 정의 문서들의 형상관리가 필요하다.