소프트웨어공학
[소프트웨어공학] 5. Requirements Engineering (1)
leziwn.cs
2023. 9. 27. 09:20
Requirements engineering (요구 공학)
: 고객이 시스템에서 요구하는 서비스와 시스템의 운영, 개발에 대한 제약사항을 설정하는 과정
- 시스템 요구사항: 요구 공학 프로세스에서 생성되는 시스템의 서비스 및 제약사항에 대한 설명
What is a requirement? (요구)
: 시스템이 수행해야 하는 작업 (시스템이 무엇을 해야 하는가?)
- 서비스, 제약사항에 대한 상위 수준의 추상적인 설명 ~ 세부적인 기능 사양에 이르기까지 다양하다.
Types of requirement
▶ 사용자 요구사항
: 시스템이 사용자에게 제공해야 할 서비스와 동작상의 제약사항에 대해 자연어, 다이어그램으로 기록한 문장
- 고객을 위해 작성한다.
▶ 시스템 요구사항
: 시스템의 기능, 서비스, 운영 제약에 대해 보다 상세하게 설명한 구조화된 문서
- 구현해야 할 사항을 정의하므로, 클라이언트와 계약자 간 계약의 일부가 될 수 있다.
예제
Readers of different types of requirements specification
▶ 사용자 요구사항
: 고객 관리자, 계약 관리자, 시스템 최종 사용자, 고객 엔지니어, 시스템 아키텍트
▶ 시스템 요구사항
: 시스템 최종 사용자, 소프트웨어 개발자, 고객 엔지니어, 시스템 아키텍트
Functional and non-functional requirements
▶ 기능 요구사항
: 시스템이 제공해야 하는 서비스, 특정 입력에 대해 시스템이 반응하는 방식, 특정 상황에 시스템이 동작해야 하는 방식을 기술한 것
--> 시스템이 해서는 안 되는 일을 명시할 수 있다.
▶ 비기능 요구사항
: 시간적 제약, 개발 프로세스에 대한 제약, 표준 등과 같이 시스템이 제공하는 서비스, 기능에 대한 제약사항
- 개별 기능, 서비스보다 전체 시스템에 적용되는 경우가 많다.
▶ 도메인 요구사항
: 운영 영역에서 시스템에 대한 제약사항
1) Functional requirements (기능 요구사항)
- 사용자 기능 요구사항: 시스템이 수행해야 하는 작업에 대한 상위 수준의 설명 (자연어)
- 시스템 기능 요구사항: 시스템 서비스를 자세히 설명
Requirements imprecision(부정확)
- 요구사항이 정확하게 명시되지 않으면 문제가 발생한다.
- 모호한 요구사항은 개발자와 사용자가 다르게 해석할 수 있다.
Requirements completeness(완전성) and consistency(일관성)
: 원칙적으로, 요구사항은 완전하고 일관성 있어야 한다.
- 완전성: 사용자가 필요로 하는 모든 서비스와 정보가 포함되어야 한다.
- 일관성: 요구사항에 대한 설명에 충돌이나 모순이 없어야 한다.
예제
2) Non-functional requirements (비기능 요구사항)
- 시스템의 속성, 제약조건을 정의한다. (예: 안전성, 응답시간, 메모리 공간)
- 프로세스 요구사항 -- 프로그래밍 언어, 개발 방법
- 비기능 요구사항이 기능 요구사항보다 더 중요할 수 있다. 만약 비기능 요구사항이 충족되지 않으면, 시스템이 쓸모 없을 수 있다.
Types of nonfunctional requirement
--> 속성을 통일하였다.
- 기능 요구사항: 기능성
- 비기능 요구사항: 신뢰성, 효율성, 사용성, 유지보수, 이식성
Software Quality Characteristics (소프트웨어 품질 속성)
Goals and requirements
- 비기능 요구사항: 정확하게 기술하기 매우 어려울 수 있고, 부정확한 요구사항은 검증하기 어려울 수 있다.
- 검증 가능한 비기능 요구사항: 객관적으로 테스트할 수 있는 몇 가지 척도를 이용해서 요구사항을 작성한다.
