개요
1) 요구 공학(Requirements Engineering)이란?
고객이 시스템으로부터 요구하는 “서비스(Services)”와 시스템이 동작하거나 개발되는 과정에 발생하는 "제약사항(Constraints)"을 구하는 과정이다.
2) 요구사항(Requirements)이란?
요구 공학을 통해 생성된 “서비스”와 “제약사항”에 대한 기술 그 자체를 의미하며, 추상화 수준의 서비스에 대한 설명부터 상세한 수학적 기능 명세에 이르기까지 범위가 다양하다.
3) 요구사항의 종류
① 사용자 요구사항(User Requirements)
시스템이 제공하는 서비스나 조작에 대한 제약사항을 자연어(natural language)나 다이어그램(diagram)으로 기술한 것으로 주로 고객을 위해 작성된다.
② 시스템 요구사항(System Requirements)
자세한 서비스, 제약사항이며 기능 명세(Functional specification)이라고도 불리는 시스템, 요구사항 문서(system requirements document)는 내용이 정확해야 한다.
③ 소프트웨어 명세(Software Specification)
소프트웨어 설계나 구현 단계를 위한 기초 정보가 상세히 기술되어 있는 것으로 주로 개발자를 위해 작성된다.
□ 다양한 계층의 담당자들을 위해 다양한 수준의 시스템 명세가 필요하다.
1. 1 장 기능적/비기능적 요구사항
1) 소프트웨어 시스템 요구사항
① 기능적 요구사항(Functional requirements)
- 시스템이 제공해야 하는 서비스(services)에 대한 기술
- 특정 입력(input)에 대해 시스템이 어떻게(how) 반응해야 하는지에 대한 기술
- 특정 상황에 대해 시스템에 어떻게 동작(behavior)해야 하는지에 대한 기술
※ 시스템이 하지 말아야 할 것(what the system should not do)에 대해 기술하는 경우도 있다.
② 비기능적 요구사항(Non-functional requirements)
- 시스템에 의해 제공되는 서비스나 기능에 대한 제약사항(constraints)
- 시간, 개발 프로세스, 표준 등에 대한 제약
③ 도메인 요구사항(Domain requirements)
- 응용 도메인(application domain)으로 부터 생기는 요구사항으로 특정 도메인의 특성이 반영된다. 이 요구사항 역시 기능적이거나 비기능적이다.
2) 기능적 요구사항(Functional requirements)
① 제공하는 기능(functionality)과 시스템 서비스(system services)
② 소프트웨어 종류(type of software), 예상되는 사용자(expected users), 소프트웨어가 사용되는 시스템의 종류(type of system)에 좌우
③ 기능적 사용자 요구사항(Functional user requirements)는 시스템의 동작사항에 대한 추상적 기술이지만, 기능적 시스템 요구사항(Functional system requirements)는 시스템 서비스에 대한 상세한 기술이어야 한다.
3) 기능적 요구사항의 예
① 사용자는 초기 데이터베이스의 모든 정보를 검색하거나, 일부를 선택할 수 있어야 한다.
② 시스템은 문서 저장소에 있는 문서를 사용자가 읽기 쉽도록 적당한 뷰어(viewers)를 제공해야 한다.
③ 모든 주문(order)은 고유 번호인 ORDER_ID 를 가져야 하며, 이것을 사용자가 영구 저장소에 복사할 수 있어야 한다.
4) 부정확한 요구사항
① 요구사항이 정확하게 기술되지 않은 경우는 문제가 발생한다.
② 모호한(ambiguous) 요구사항은 개발자(developers)와 사용자(users)가 각기 다르게 해석할 수 있다.
- 앞에서의 “ 적당한 뷰어"의 경우
□ 사용자 의도 - 각 문서의 종류마다 다른 전용의 뷰어
□ 개발자 해석 - 문서의 내용을 보여주는 텍스트(text) 뷰어
5) 요구사항의 완전성(Completeness)와 일관성(Consistency)
① 요구사항은 완전(Complete)하고 일관적(Consistent)이어야 한다.
② 완전(Complete): 시스템이 필요로 하는 모든 기능들에 대해 기술되어야 한다.
③ 일관적(Consistent): 시스템의 기능들에 대한 내용에서 충돌(conflicts)이 발생하거나 모순(contradictions)이 생겨서는 안 된다.
④ 실제로 복잡한 대규모 시스템에서 완전하고 일관성 있는 요구사항 문서를 만들기는 불가능하다. 이유는 본질적으로 복잡한 시스템과 견해가 다른 데서 나오는 비일관적 요구 때문이다.
6) 비기능적 요구사항(Non-functional requirements)
① 시스템 속성(properties)이나 제약사항(constraints)에 대해 정의한다.
□ 신뢰도(reliability), 반응 시간(response time), 저장소(storage) 요구사항 등
□ 창발적 속성과 관련 있다. 대부분 개별적 기능이 아닌 전체적 모습에 관한 요구
② 프로세스 요구사항이 있을 수도 있다.
□ 특정 CASE 시스템, 프로그래밍 언어나 개발 방법론을 사용해야 하는 경우
③ 비기능적 요구사항이 기능적 요구사항보다 훨씬 중요하다.
□ 비기능적 요구사항이 만족되지 않는 경우 시스템 자체가 쓸모없게 될 수도 있다.
7) 비기능적 요구사항의 분류
① 제품 요구사항(Product requirements)
□ 제품이 특정 조건에 맞도록 동작해야 한다.
수행 속도(execution speed), 신뢰도(reliability)
□ 예: APSE 와 사용자간의 모든 통신은 표준 Ada 문자 집합으로 표현되어야 한다.
② 조직 요구사항(Organizational requirements)
□ 고객이나 개발 조직의 정책(policies)에 맞아야 한다. 프로세스 표준, 구현 요구사항 등
□ 예: 시스템 개발 프로세스와 도출 문서는 KNOU-SP-STAN-2004 에 정의된 프로세스와 문서형식을 따라야 한다.
③ 외부 요구사항(External requirements)
□ 시스템과 개발 프로세스 외부에서 발생하는 요구사항 상호 운용성 요구사항, 법적 요구사항 등
□ 예: 사용자의 이름 외에 다른 개인 정보는 시스템 운영자에게 노출되어서는 안 된다.
8) 도메인 요구사항(Domain requirements)
① 응용 도메인으로 부터 주어지며, 시스템의 특성에 영향을 준다.
② 새로운 기능적 요구사항 또는 기존의 요구사항에 대한 제약사항이 되거나 특별한 계산식을 정의하는 것 등이 될 수 있다.
③ 도메인 요구사항이 만족되지 않으면 시스템이 쓸모없게 된다.
④ 예:
□ 기차의 감속도는 다음과 같이 계산한다. Dtrain = Dcontrol + Dgradient
□ Dgradient = 9.8ms2 * compensated gradient/alpha
9) 도메인 요구사항의 문제점
① 이해도(Understandability)
□ 해당 응용 도메인의 언어로 표현된다.
□ 그러므로, 시스템을 개발하는 소프트웨어 공학자가 이해하기 어렵다.
② 함축성(Implicitness)
□ 도메인 전문가가 잘 이해하는 부분이기 때문에 도메인 요구사항에 대해 상세히 기술할 필요가 없다고 생각한다.
2. 2 장 사용자 요구사항
1) 사용자 요구사항(User requirements)
① 세부 기술에 대한 지식이 없는 시스템 사용자가 이해할 수 있도록 기능적/비기능적 요구사항이 기술되어야 한다.
② 자연어(natural language)나 테이블(tables), 다이어그램(diagrams) 등을 사용해서 정의된다.
2) 자연어의 문제점
① 명확성이 떨어진다.
② 기능적 요구사항과 비기능적 요구사항이 뒤섞여서 표현되는 등, 요구사항에 혼동이 있을 수 있다.
③ 다양한 요구 사항들이 한꺼번에 함축적으로 표현되는 경우가 많다.
3) 요구사항 정리를 위한 가이드라인
① 표준 문서를 만들어 두고, 모든 요구사항에 대해 적용시킨다.
② 언어를 일관성 있게 사용한다. 예를 들어, 필수항목과 희망항목을 구분할 수 있는 표현을 정하여 사용한다.
③ 요구사항의 주요부분을 표시하기 위해 형광색등으로 표시를 한다.
④ 컴퓨터 전문용어를 피한다.
3. 3 장 시스템 요구사항
1) 시스템 요구사항(System requirements)
① 사용자 요구사항보다 상세한 명세를 제공한다.
② 시스템을 설계하는데 기초 자료로 사용된다.
③ 시스템 계약 시 사용된다.
④ 시스템 모델(교재 8 장)을 사용하여 표현되기도 한다.
2) 요구사항과 설계
① 요구사항(requirements)은 시스템이 무엇(what)을 해야 하는지에 대한 기술이며, 설계(design)는 시스템이 어떻게(how) 동작하는가에 대한 기술이다.
② 실제로는 독립적으로 분리된 것이 아니다.
예: 요구사항을 더욱더 구조화 시키기 위해 시스템 아키텍쳐를 설계하는 경우
3) 자연어 명세의 대안(Alternatives)
- 자연어 명세는 모호(Ambiguity)하며, 너무 유연하며(Over-flexibility) 모듈화가 어렵기 때문에(Lack of modularization) 다음과 같은 방법으로 문제점을 해결한다.
□ 구조화된 언어 명세(Structured language specifications)
□ 설계 기술 언어(Design description language)
□ 시각적 표기(Graphical notations)
□ 수학적 명세(Mathematical specifications)
4) 구조화된 언어 명세(Structured language specifications)
① 요구사항을 표현하는데 사용하기 위해 자연어를 제한하여 사용한다.
② 이렇게 함으로 해서, 모호성(ambiguity)나 유연성(flexibility)를 줄이고, 명세에 대해 일관성을 부여할 수 있다.
③ 특정 형식(forms)을 기반으로 하는 경우도 있다.
5) PDL 을 사용한 요구사항 명세
① 프로그래밍 언어의 표현을 추상화하여 사용함
② 다음과 같은 상황에 사용하면 적당함
□ 특정 오퍼레이션(operation)이 일련의 간단한 활동들(actions)로 나타나고 실행 순서가 중요한 경우
□ 하드웨어와 소프트웨어의 인터페이스가 명세 되어야 하는 경우
③ PDL 사용의 단점
- 도메인 관련 개념을 표현하기 어렵다.
- 프로그래밍 언어에 익숙한 사람들만 이해할 수 있다.
- 시스템을 이해하기 위한 모델(model)이기 보다는 설계 명세에 가깝다.
6) 인터페이스 명세(Interface specification)
① 대부분의 시스템이 다른 시스템과 함께 동작하기 때문에 요구사항의 일부로 인터페이스가 명세 되어야 한다.
② 정형적인 표기법(Formal notations)이 효과적이다.
[ 정리하기 ]
□ 요구사항은 시스템이 무엇(what)을 해야 하는지와 동작이나 구현에 있어서의 제약사항(constraints)를 정의하는 것이다.
□ 기능적 요구사항은 시스템이 제공해야 하는 서비스(services)에 대해 기술한 것이다.
□ 비기능적 요구사항은 시스템 개발이나 방법론에 대한 제약사항(constraints)을 기술한 것이다.
□ 사용자 요구사항은 시스템이 무엇을 해야 하는지에 대한 상위 레벨(High-level)의 명세이기 때문에 자연어, 테이블, 다이어그램을 사용하여 표현된다.
□ 시스템 요구사항은 사용자 요구사항의 내용을 보다 상세화하고 구체화시킨 것으로 구조화된 자연어, PDL 이나 정형적 언어를 사용하여 표현된다.
[ 참고하기 ]
Requirements Engineering
by Elizabeth Hull, Ken Jackson, Jeremy Dick
http://www.amazon.com/exec/obidos/tg/detail/-/1852335777/qid=1078490922/sr=1- 3/ref=sr_1_3/103-7583756-7029449?v=glance&s=books
200 쪽 정도의 분량으로 최신의 요구 공학 기술을 간단 명료하게 설명한 책이다. 요구사항 추출, 검증 및 확인, 변경 관리 등에 관한 일반적 방법과 구체적 방법을 예를 들어 설명하고 있다.
'정보과학 > 소프트웨어공학특론' 카테고리의 다른 글
| 시스템 모델 (1) | 2023.11.25 |
|---|---|
| 요구 공학 프로세스 (2) | 2023.11.25 |
| 소프트웨어 프로세스(2) (1) | 2023.11.23 |
| 소프트웨어 프로세스(1) (1) | 2023.11.23 |
| 시스템 공학 (0) | 2023.11.23 |
