기능적 요구사항과 비기능적 요구사항

소프트웨어 시스템 요구사항은 크게 기능적(functional), 비기능적(non-functional) 또는 도메인(domain) 요구사항으로 분류될 수 있다.

 

1. 기능적 요구사항(Functional requirements)

- 시스템에 주어지는 특정 입력에 대한 시스템이 산출하는 출력 통해 정의된다. 

예) 식별자 REQ-1: 입력으로 사용자가 휴대폰의 통화버튼을 누른다. 출력으로 시스템은 최근 통화 목록을 표시한다. 첫 항목을 선택시킨다.

- 시스템이 제공하는 기능(functionality) 또는 서비스(services)에 대한 기술
- 기능적 사용자 요구사항(Functional user requirements)는 시스템의 동작사항에 대한 추상적 기술이지만, 기능적 시스템 요구사항(Functional system requirements)는 시스템 서비스에 대한 상세한 기술이어야 한다.
: 특정 입력(input)에 대해 시스템이 어떻게(how) 반응해야 하는지에 대한 기술
: 특정 상황에 대해 시스템에 어떻게 동작(behavior)해야 하는지에 대한 기술
※ 시스템이 하지 말아야할 것(what the system should not do)에 대해 기술하는 경우도 있다.
- 소프트웨어 종류(type of software), 예상되는 사용자(expected users), 소프트웨어가 사용
되는 시스템의 종류(type of system)에 좌우

□ 기능적 요구사항의 예
- 사용자는 초기 데이터베이스의 모든 정보를 검색하거나, 일부를 선택할 수 있어야 한다.
- 시스템은 문서 저장소에 있는 문서를 사용자가 읽기 쉽도록 적당한 뷰어(viewers)를 제공해야한다.
- 모든 주문(order)은 고유번호인 ORDER_ID를 가져야 하며, 이것을 사용자가 영구 저장소에 복사할 수 있어야 한다.

※ 기능적 요구사항의 완전성과 일관성

□ 부정확한 요구사항
- 요구사항이 정확하게 기술되지 않은 경우는 문제가 발생한다
- 모호한(ambiguous) 요구사항은 개발자(developers)와 사용자(users)가 각기 다르게 해석할 수 있다.
(예) “적당한 뷰어"의 경우
: 사용자 의도 - 각 문서의 종류마다 다른 전용의 뷰어
: 개발자 해석 - 문서의 내용을 보여주는 텍스트(text) 뷰어

■ 요구사항의 완전성(Completenes)와 일관성(Consistency)
- 요구사항은 완전(Complete)하고 일관적(Consistent)이어야 한다.
: 완전성(Completeness): 시스템이 필요로하는 모든 기능들에 대해 기술되어야 한다.
: 일관성(Consistency): 시스템의 기능들에 대한 내용에서 충돌(conflicts)이 발생하거나 모순(contradictions)이 생겨서는 안된다.
- 실제로 복잡한 대규모 시스템에서 완전하고 일관성 있는 요구사항 문서를 만들기는 불가능하다. 이유는 본질적으로 복잡한 시스템과 견해가 다른데서 나오는 비일관적 요구 때문이다.

 

 

 

2. 비기능적 요구사항(Non-functional requirements)

- 시스템의 속성들과 제약사항들을 정의하는 요구사항이다. 예를들면 안정성, 응답 시간, 요구 저장공간 같은 속성들

- 기능적 요구사항보다 더 결정적인 부분이 될 수 있다. 왜냐하면 이 부분이 충족되지 않으면 시스템은 이용가치가 없으므로

- 비기능적 요구사항은 기능적 요구사항과 확실히 구분을 시켜야 한다.

=> 하지만 기능적/비기능적 요구사항들은 시스템의 특성에 따라 사람마다 다르게 볼 수 있다.

 

- 비기능적 요구사항에서 품질 요구사항은 성능, 신뢰성, 보안성, 안전성, 가용성이 있다.

=> 성능: 시스템의 자원을 얼마나 효율적으로 사용하는가 

예) 사용자가 통화버튼을 누르면 2초 이내에 통화 연결이 성립되어야 한다.

=> 신뢰성: 시스템이 주어진 요구사항을 준수하여 동작하는 정도를 뜻한다.

예) 지대공미사일은 100개를 발사하면 90개는 목표에 명중해야한다.

=> 보안성: 허가되지 않은 사용자가 시스템에 접근하거나, 사용자가 접근권한이 없는 시스템의 정보를 접근하거 해서는 안된다.

예) 등록된 사용자만이 시스템이 접근할 수 있어야 한다.

=> 안전성: 시스템이 주변 환경, 인명, 재산에 피해를 주지 않아야 한다는 요구사항

예) 엘리베이터 문이 열린 상태에서는 엘리베이터는 이동해서는 안된다.

=> 가용성: 사용자가 원하는 순간에 시스템은 서비스를 제공해야 한다는 요구사항

예) 인터넷 뱅킹 시스템은 1년 365, 하루 24시간 동안 서비스를 제공해야 한다.

 

- 비기능적 요구사항에서 개발에 대한 제약사항(개발 방법과 개발 플랫폼)을 정한다.

예) 모델링 언어는 UML 2.x를 사용해하며, 개발 언어는 java언어, 운영체제는 Linux에서 동작해야 한다.

 

- 각자의 위치에 따라 요구사항 명세서의 역할이 다름

=> 개발자: 분석/설계/구현에 대한 기준

=> 테스터: 테스트에 대한 기준

=> 고객 및 사용자: 시스템의 개발 완료 승인에 대한 기준

 

- 요구사항 명세서가 위와 같은 역할로 사용되기 위해서는 다음과 같은 특징을 갖추어야 한다.

=> 명확성: 기술된 요구사항은 항상 동일한 의미로 해석되아야 한다. (모호하지 않아야 한다.)

=> 완전성: 사용자가 기대하는 모든 기능/비기능적 요구사항이 기술되어야한다.(누락되어서는 안된다.)

=> 일관성: 서로 상충되는 요구사항이 있어서는 안된다. (중복되는 부분이 있으면 안된다.)

=> 검증가능성: 객관적으로 검증할 수 있도록 구체적이어야 한다. (기준이 명확해야함.)

=> 구현가능성: 가용한 기술과 한정된 일정/비용으로 구현이 가능해야 한다.

출처: https://gomoveyongs.tistory.com/17

소프트웨어공학(요구공학) - 소프트웨어 요구사항 | 해맥(海脈)의 IT/정보기술 (i-bada.blogspot.com)