요구 공학 (Requirement Engineering)

---

요구 공학은 소프트웨어 공학에서 요구사항 부분이 파생된 학문으로 Wiki 에서 확인할 수 있다.

위키 백과 바로가기

 

 

요구사항은 사용자 요구사항과 시스템 요구사항으로 구분할 수 있으며 비 개발 직군인 기획자의 경우 사용자 요구사항을 담당하고 개발직군은 시스템 요구사항을 담당해야 한다. 하지만 요구사항 분석가나 아키텍트나 그에 준하는 직무가 없는 경우 자신의 업무가 아니라는 식으로 작성하지 않는 경우가 태반이다.

 

 

비 개발직군은 아래 링크만 확인하고

요구 사항_수집?분석?정의?명세? 우선 펼쳐보자

개발직군은 위 링크와 아래 요구 공학 프로세스를 확인하는 것이 좋다.

 

 

소프트웨어 요구 사항의 전제 조건

- Clear : 명확해야 한다.

- Correct : 정확해야 한다.

- Consistent : 일관되어야 한다.

- Coherent : 간섭이 없어야 한다.

- Comprehensible : 이해할 수 있어야 한다.

- Modifiable : 수정 가능해야 한다.

- Verifiable : 증명할 수 있어야 한다.

- Prioritized : 우선순위를 설정할 수 있어야 한다.

- Unambiguous : 모호하지 않아야 한다.

- Traceable : 추적 가능해야 한다.

- Credible source : 출처가 신뢰할 수 있어야 한다.

 

* 유저 스토리에 대한 요구사항은 아래 글을 참고

요구사항_INVEST in Good User-story

 

소프트웨어 요구 사항 분류

소프트웨어 개발에서 요구사항은 기능과 비 기능 요구사항 2개의 범주로 구분한다.

(ISO 25010 품질의 주 특성과 부 특성 참고)

 

기능적 요구 사항

시스템 또는 시스템 요소가 수행하기 위해 자격을 갖추어야 하고 다른 형식으로 문서화되어야 하는 기능을 정의한다. 기능 요구 사항은 시스템의 기능과 관련이 있는 시스템의 동작을 설명한다.

 

비 기능적 요구 사항

시스템의 특정 동작 대신 작동을 결정하는 데 사용할 수 있는 기준을 지정하는 필수 사항이 된다.
비 기능적 요구 사항은 두 가지 주요 범주로 구분할 수 있다.
- Execution qualities(실행 품질) : 런타임에 관찰할 수 있는 보안 및 유용성.
- Evolution qualities(속성 품질) : 시스템의 정적 구조에 구현된 테스트 가능성, 유지 보수 가능성, 확장성.

 

---

 

 

요구 공학 프로세스

요구 공학 프로세스

 

1. 타당성 조사

타당성 조사의 목적은 사용자가 수용할 수 있고 변경에 유연하며 표준을 준수하는 소프트웨어를 개발하는 이유이다.

 

타당성 유형

- 기술 타당성 : 시간과 예산 내에서 고객 요구 사항을 달성하는 데 필요한 현재 기술을 평가한다.

- 운영 타당성 : 비즈니스 문제와 고객 요구 사항을 해결하기 위해 필요한 SW 제품의 수행하는 범위를 평가한다.

- 경제적 타당성 : 필요한 소프트웨어가 조직에 이익을 창출할 수 있는지 여부를 결정한다.

 

 

2. 요구사항 추출 및 분석

요구사항 수집 단계와 동일하다. 신규 개발의 요구사항은 고객이나 스폰서, 클라이언트, 시장조사를 통해 식별되고, 유지 보수나 리뉴얼의 경우 기존 시스템의 프로세스나 개선 요청사항으로부터 식별되는 것이 보통이다.

 

 

요구사항 추출 및 분석 프로세스

1. 요구 사항 분석은 요구 사항 추출로 시작한다.

2. 요구사항에 대한 불일치, 결함, 누락 등을 식별하기 위해 분석된다.

3. 관계 측면에서 요구 사항을 설명하고 갈등이 있는 경우 해결한다.

4. 요구사항의 검증하고 사양에 대해 정의한다.

요구사항 추출 및 분석 프로세스

요구 사항 추출 및 분석 과정의 문제들

- 모든 인원이 아닌 관련된 적절한(right) 사람만 참여한다.

- 이해 관계자들은 종종 자신이 원하는 것이 무엇인지 모른다.

- 이해 관계자는 그들의 입장에서 요구 사항을 표현한다.

- 이해 관계자는 상충되는 요구 사항을 가질 수 있다.

- 요구사항 분석 중 요구 사항 변경된다.

- 내/외부(조직, 정책 등) 요인이 요구사항에 영향을 준다

 

 

3. 요구사항 사양 정의

소프트웨어 요구 사항 사양 문서는 다양한 유입 경로를 통해 수집된 요구 사항(일반 언어로 작성된 고객에게서 받은 요구 사항)과 이를 바탕으로 소프트웨어 분석가(아키텍트나 선임 개발자, 그에 준하는 직무)가 생성하는 문서입니다. 요구 사항을 기술 언어로 작성하여 개발 팀이 이해할 수 있도록 하는 것이 요구 사항에 대한 사양 정의이다.

 

이 단계에서 사용되는 방법은 엔티티 관계 다이어그램(ERD), 데이터 플로우 다이어그램 (DFD), 기능 분해 다이어그램 (FDD), 데이터 사전 등이 포함될 수 있다.

• 데이터 흐름 다이어그램(DFD) : 요구 사항을 모델링하는 데 널리 사용된다고 한다. DFD는 시스템을 통한 데이터 흐름을 보여줍니다. 시스템은 회사, 조직, 일련의 절차, 컴퓨터 하드웨어 시스템, 소프트웨어 시스템 또는 이들의 조합이다. DFD는 데이터 플로우 그래프 또는 버블차트라고 한다. 
• 데이터 사전 : DFD에서 정의된 모든 데이터 항목에 대한 정보를 저장하는 저장소, 사전이다. 요구 사항 단계에서 데이터 사전은 최소한 고객 데이터 항목을 정의하여 고객과 개발자가 동일한 정의와 용어를 사용할 수 있도록 해야 한다. (용어 사전)
• 엔티티-관계 다이어그램(ERD) : 조직에 대한 데이터의 상세한 논리적 표현이며 데이터 엔터티, 관계 및 관련 속성과 같은 세 가지 주요 구성을 사용한다.

쉽게, ERD 와 시퀀스 다이어그램이 요구사항 사양 정의서가 된다.

 

4. 요구사항 검증(Validation)

요구사항 사양(Spec)에 대한 검증 조건

- 실제 구현 가능한가?

- 기능이 명확한가?

- 모호한 부분이 있는가?

- 설명 가능한가?

 

요구 사항 검증 기법

- 요구 사항 검토 / 검사 : 요구 사항에 대한 체계적인 수작업 분석.

- 프로토 타이핑 : 시스템의 실행 가능 모델을 사용하여 요구 사항을 확인.

- 테스트 케이스 생성 : 테스트 가능성을 확인하기 위한 요구 사항 테스트.

- 일관성 분석 : 구조화된 요구 사항 설명의 일관성을 확인.

 

5. 요구사항 관리

요구 사항 관리는 요구 사항 엔지니어링 프로세스 및 시스템 개발 중에 변화하는 요구 사항을 관리하는 프로세스이다. 비즈니스에 변화가 필요하고 시스템에 대한 이해가 깊어짐에 따라 프로세스 중에 새로운 요구 사항이 나타나게 된다. 

 

요구사항의 잦은 변경은 프로젝트에 나쁜 영향을 미칠 수 있지만 적절한 변경은 시장의 변화와 고객의 니즈를 더 많이 충족할 수 있는 좋은 제품이 될 수 있기 때문에 긍정적인 자세를 취해야 한다.

 

- 요구 사항의 우선순위는 개발 프로세스 중에 변경될 수 있다.

- 시스템의 비즈니스 및 기술 환경은 개발 중에 변경될 수 있다.

 

 

 

 

 

요구사항_Given When Then 이 어쨌다고??

요구사항_Given When Then 이 어쨌다고??

---