[소프트웨어공학] 요구사항 공학

date

Jul 14, 2023

slug

swen-requirements-engineering

author

status

Public

요구사항 공학 🧾

Requirements engineering(요구사항 공학)이란?

: 소프트웨어 개발 프로세스에서 사용자나 고객, 시스템에 대한 요구사항을 수집, 분석, 명세하고, 이를 관리하는 활동이다.

요구사항의 기능은 무엇일까?

1. 이해되기 쉬워야하고

2. 자세히 명세되어야 한다. → 간단 명세서 or 자세한 명세서로 나뉜다. → 추상적 명세 수준으로는 자연언어를 사용하고, 상세 명세 수준에서는 그림, 수학, 논리 등을 사용한다.

사용자 요구사항

: 고객을 위해 작성된다. ex) 병원에서 한 달동안 발행된 처방전을 검토하여 처방된 모든 약들의 총액을 월간보고서로 만들어 보고한다.

시스템 요구사항

: 시스템의 기능, 제약사항 등을 자세하게 기술한 구조적인 문서이다. (개발자가 시스템 요구사항을 주로 살펴보게 된다!!) ex) 1. 매달 말 일에 summary를 생성한다. 2. 매달 말일 17:30에 report를 생성한다…~ 등으로 아주 상세하게 작성한다.

1. 기능적 요구사항

시스템이 제공해야 하는 서비스들

시스템이 특정 입력에 어떻게 반응해야 하는지?

시스템이 하지 말아야 하는 것들 기술

2. 비기능적 요구사항

시스템이 제공하는 기능이나 서비스에 가해진 제약사항들

대개의 경우 개별 기능이나 서비스에 적용되기 보다는 시스템 전체에 적용되는 사항들

ex) 신뢰성, 응답시간, 기억 장소의 제약 등 프로그래밍 언어, 개발 방법론 등

비기능적 요구사항들이 기능적 요구사항보다 더 중요할 수 있다. 비기능적 요구사항을 만족하지 못하는 시스템은 사용 불가능하기 때문이다!!!

비기능적인 것들의 분류

1. 개발된 제품이 만족해야 하는 요구사항 ex) 이런 언어로, 이런 최대 속도를 가져야 한다.

2. 조직의 법규 및 절차에 가해지는 요구사항 ex) 전자상거래 법을 다 밝혀내야 한다.

3. 시스템의 외부에서 가해지는 요구사항

⇒ 비기능적 요구사항이 명확하게 작성되는게 주요하다.!!! 이게 명확하게 기술되지 않으면, 추후에 검증되기 어려우므로 … 먼저 비기능적 요구사항의 목표를 수립하고, 검증 가능한 형태로 명세해야 한다.

비기능적 요구사항의 객체들

speed 속도

size 크기

ease of use 사용의 편의성

reliability 신뢰성

robustness 견고성

portability 이식성 (사용자 입장에서 관여되는 요구사항들이 아님!!!)

소프트웨어 요구사항 명세서

: 사용자 요구사항 & 시스템 요구사항을 모두 포함해야 한다!

설계 문서가 아니다!!! 시스템이 어떻게 해야 하는지 보다는 무엇을 해야 하는지 설정해야 한다.

요구사항 명세서 문서를 고객은 이게 내가 원하는 사항인지 확인하는 용도로 이용할 수 있다. 매니저들은 요구사항에 따라 시스템 개발 계획을 작성한다. 시스템 엔지니어들은 개발할 시스템을 이해할 수 있다. 테스트 엔지니어 들은 시스템 검증을 위한 테스트를 생성할 수 있다.

사용자 요구사항의 경우에는, 기술적인 지식이 없는 일반 사용자가 이해할 수 있도록 작성되어야 한다. 시스템 요구사항의 경우에는 과학적인 정보를 포함해서 상세히 기술해야 한다.

요구사항 명세서는은 계약서로도 사용될 수 있다!!!!→ 그래서 완성도 있고, 모호하지 않아야 한다.

요구 공학 과정! 검증!

자, 그럼 이러한 요구사항 공학 과정은 어떻게 일어날까? case by case가 있다. 하지만, 보통은 (1) Requirements elicitation 추출 (2) analysis 분석 (3) validation 검증 (4) management 관리 의 과정으로 일어난다.

(1) 요구사항 추출 & (2) 요구사항 분석

: 요구사항 추출 및 분석과 관련된 이해관계자들을 알아낸다. 근데 이게, 범위가 짱 크다보니까 한번에 하기가 어렵다. 그래서 반복해서 추출&분석해낸다.

요구사항을 발견해내면→ 조직화하고 그룹화한다→ 우선순위를 매기고→ 요구사항 명세를 한다.

🤩

요구사항 지식 수집 방법으로는 세가지가 있다. 1. 인터뷰/ 2. 시나리오 작성/ 3. 유즈케이스(행위와 사람 간의 활동 기술)

인터뷰는 기본적인 기능적 요구사항을 알아낼 때 사용하는디, 시스템 및 stakeholder들이 어떻게 시스템과 상호작용 할 것인지에 대한 개괄적인 이해를 얻어내는 데에는 적합하다. 그러나! 도메인의 요구사항을 이해하는 목적으로는 적합하지 않다!!!(전문적인 지식에는 편차가 이따.)

시나리오 작성은 마리죠. 시스템이 어떻게 사용되는 가?에 대한 real-life examples 을 작성한다. 포함 내용은 다음과 같다. (starting situation, normal flow of events, alternative flow of events, other activities, ending situation 이렇게 이렇게 할 것이다~ 하는 거를 연극 시나리오처럼 예상해서 검증함.)

UML의 시나리오 기반 기술이다. 다이어그램을 통해 묘사하고, sequence diagram(메세지 전달형)을 덧붙여서 자세하게 나타낸다. 이걸로 요구사항을 분석하고 명확하게 정의할 수 있다!

자, 그러면 드디어. 검증은 어떻게 하느냐???

(3) 요구사항 검증

고객이 원하는 데로 요구사항들이 작성되어서, 시스템에 올바르게 정의되었는가를 확인하는 작업이다.

요구사항 오류가 나서 해결하려고 하면 돈이 무지막지하므로… 오류나기전 검증이 매우 중요하다. checking list를 만들어서 요구사항을 만족하는지 확인하기!

요구사항 검증 후 회의는 정의가 일어나는 동안 정기적으로 개최되어야 한다. 개발자 및 고객과 원활한 의사소통을 통해서 시스템 개발 초기 단계에 문제를 해결할 수 있다.

(4) 요구사항 관리

요구사항이 명확하게 공유되고 있고, 변경 사항이 관리되는지, 유지되도록 관리하는 프로세스이다. 요구사항 관리를 위한 의사결정 사항을 몇가지 가진다.

1. 요구사항들은 유일하게 식별되어야 한다.

2. 변경으로 인한 영향력을 추정하는 활동을 가진다.

3. 요구사항끼리의 관계를 정의하고 기록한다.

4. 사용될 도구를 관리한다.