2. 요구사항 확인 - 6. 요구사항 개발

728x90

반응형

SMALL

06. 요구사항 개발

1. 요구사항 분석

2. 요구분석 기법과 분류 기준

3. 요구사항 명세 기법

---

요구공학 (Requirements Engineering)

요구사항을 정의하고, 문서로 만들고, 관리하는 프로세스를 의미한다.

효과적인 의사소통을 통하여 공통 이해를 설정하며, 불필요한 비용 절감, 요구사항 변경 추적이 가능해진다.

 

분석 결과의 문서화를 통해 향후 유지보수에 유용하게 활용할 수 있다.

자료 흐름도, 자료 사전 등이 효과적으로 이용될 수 있으며, 더 구체적인 명세를 위해 소단위 명세서가 활용될 수 있다.

 

요구공학의 목적

1. 소프트웨어 개발 시 이해관계자 사이의 원활한 의사소통 수단을 제공한다.(문서화를 하기 때문에)

2. 요구사항 누락 방지, 상호 이해 오류 등의 제거로 경제성을 제공한다.

3. 요구사항 변경 이력 관리를 통하여 개발 비용 및 시간을 절약할 수 있다.

4. 비용과 일정에 대한 제약 설정과 타당성 조사, 요구사항 정의 문서화 등을 수행한다.    

---

요구사항 베이스라인 (BaseLine, 기준선)

이해 당사자 간의 명시적 합의 내용이며 프로젝트 목표 달성 여부를 확인하는 기준이다.

요구사항을 조기에 명확히 확정하고, 추후 발생 가능한 변경사항을 체계적으로 관리하기 위한 기준이 된다.

 

---

요구공학(개발) 프로세스 ☆

요구사항을 명확히 분석하여 검증하는 진행 순서를 의미한다.

- 경제성, 기술성, 적법성, 대안성 등 타당성 조사가 선행되어야 한다.

순서

1 단계. 요구사항 도출

개발 대상에 대한 요구사항을 체계적으로 도출한다.

예) 은행어플의 계좌 이체, 조회 등 어떤 기능을 넣을 것인지 문서화한다.

 

2 단계. 요구사항 분석

도출된 요구사항(문서화)을 분석한다.

 

3 단계. 요구사항 명세

분석 결과를 명세서에 정리한다.

 

4 단계. 요구사항 검증(확인)

정리된 명세서를 마지막으로 확인, 검증하는 일련의 단계를 말한다.

---

1단계. 요구사항 도출 (Requirement Elicitation)

현재의 상태를 파악하고 문제를 정의한 후 문제 해결과 목표를 명확히 도출하는 단계이다.

 

이해관계자 (Stakeholder)가 식별되며, 개발팀과 고객 사이의 관계가 만들어지는 단계이며, 다양한 이해관계자와 효율적인 의사소통이 중요하다.

요구사항의 위치와 수집 방법과 관련되어 있다.

 

요구사항 도출 기법 ☆

고객의 발표, 문서 조사, 설문, 업무 절차 및 양식 조사, 브레인스토밍, 워크숍, 인터뷰, 관찰 및 모델의 프로토타이핑, Use Case, 벤치마킹, BPR(업무 재설계), RFP(제안요청서)

---

1. (2단계) 요구사항 분석 (Requirement Analysis) ☆

소프트웨어가 환경과 어떻게 상호작용하는지 이해하고, 사용자의 요구사항을 걸러내기 위한 과정을 통하여 요구사항을 도출하고, 요구사항 정의를 문서화하는 과정이다. 

구조화와 열거가 어려워, 명확하지 못하거나 모호한 부분이 많기 때문에 각각 정리하여 문서화한다.

 

도출된 사항을 분석하여 소프트웨어 개발 범위를 파악하고 개발 비용, 일정에 대한 제약을 설정하고 타당성 조사를 수행한다.

- 요구사항 간 상충하는 것을 해결하고, 소프트웨어의 범위(비용과 일정)를 파악하고 타당성 조사를 시행한다.

- 요구사항 기술 시 요구사항 확인, 요구사항 구현의 검증, 비용 추정 등의 작업이 가능하도록 충분하고 정확하게 기술한다.

 

요구분석을 위한 기법

- 사용자 의견 청취, 사용자 인터뷰, 현재 사용 중인 각종 문서 분석과 중재, 관찰 및 모델 작성 기술, 설문 조사를 통한 의견을 수렴한다. 

---

요구사항 분석 수행 단계

1. 문제 인식 

인터뷰, 설문 조사 등 도구를 활용하여 요구 사항을 파악하는 과정이다.

 

2. 전개

파악한 문제를 자세히 조사하는 작업이다.

 

3. 평가와 종합

요구들을 다이어그램이나 자동화 도구를 이용하여 종합하는 과정이다.

 

4. 검토

요구분석 작업의 내용을 검토, 재정리하는 과정이다.

(서로 상충되는 부분이 있나? 이 기능을 하려면 저 기능은 사용할 수 없어 등..)

 

5. 문서화

요구사항 분석 내용을 문서로 만드는 단계이다.

---

요구사항 분류

기술 내용에 따른 분류

기능 요구사항, 비기능 요구사항

 

기술 관점 및 대상에 따른 분류

시스템 요구사항(윈도우에서 원하는 기능,. 등), 사용자 요구사항

 

요구사항 분류 기준 ☆

1. 기능 요구사항, 비기능 요구사항을 구분하고 우선순위 여부를 확인한다.

2. 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 확인한다.

3. 이해관계자나 다른 원천(Source)으로부터 직접 발생한 것인지 확인한다.

4. 요구사항이 제품에 관한 것인지 프로세스에 관한 것인지 확인하고 요구사항이 소프트웨어에 미치는 영향의 범위를 확인한다.

5. 요구사항이 소프트웨어 생명주기 동안에 변경이 발생하는지를 확인한다.

 

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

기능적 요구사항

- 시스템이 실제로 어떻게 동작하는지에 관점을 둔 요구사항

- 차량 대여 시스템에서 대여를 할 수 있어? 의 실질적인 기능적 요구 

 

비기능적 요구사항

- 시스템 구축에 대한 성능, 보안, 품질, 안정성 등으로 실제 수행에 보조적인 요구사항

- '차량 대여 시스템이 제공하는 모든 화면이 3초 이내에 사용자에게 보여야 한다'는 비기능적 요구

---

3단계. 요구사항 명세(Requirement Specification)

시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성한다.

- 체계적으로 검토, 평가, 승인될 수 있도록 문서로 만드는 것을 의미한다.

- 개발자가 효과적으로 설계할 수 있고 사용자가 쉽게 이해할 수 있도록 한다.

 

설계 과정의 오류사항을 추적할 수 있어야 한다.

- 기능 요구사항은 빠지는 부분 없이 명확하게 기술한다.

- 비기능 요구사항은 필요한 것만 명확하게 기술한다.

---

요구사항 명세 기법 ☆

구분	정형 명세	비정형 명세
기법	수학적 기반/ 모델링 기반	- 상태/기능/객체 중심 명세 기법 - 자연어 기반
종류	- Z. VDM - Petri-Net(모형 기반) - LOTOS(대수적 방법) - CSP. CCS	- FSM(Finite State Machine) - Decision Table, ER 모델링 - State Chart (SADT) - Use Case - 사용자 기반 모델링
장점	- 시스템 요구 특성을 정확하고 간결하게 명세할 수 있다. - 명세/구현의 일치성	- 명세 작성 이해 용이 - 의사전달 방법 다양성
단점	- 낮은 이해도 - 이해관계자의 부담 가중	- 불충분한 명세 가능 - 모호성

- 정형 명세는 공식이 있다.

- 비정형은 문법적인 게 아니라 사용자가 어떻게 움직이느냐에 대한 것을 본다. 이것을 비정형 명세라고 한다.

 

요구사항 명세(문서화) 6가지 속성

1. 정확성

요구사항은 정확해야 한다.

 

2. 명확성

단 한 가지로만 해설되어야 한다.

 

3. 완전성

모든 것이 표현(기능 + 비기능) 가능해야 한다.

 

4. 일관성

요구사항 간 충돌이 없어야 한다.

 

5. 수정 용이성

요구사항 변경이 가능해야 한다.

 

6. 추적성

RFP, 제안서를 통해 추적 가능해야 한다.

---

4단계. 요구사항 검증(확인) (Requirement Validation)

요구사항 분석 단계를 거쳐 문서로 만들어진 내용을 확인하고 검증하는 단계이다.

- 요구분석가가 요구사항을 이해했는지 확인 (Validation)이 필요하다

- 회사의 표준에 적합하고 이해할 수 있고, 일관성이 있고, 완전한지 검증한다.

 

리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 다음과 같은 검증을 수행한다.

표준에 적합한가?, 이해 가능한가?, 일관성 있는가?, 완전한가?

 

요구사항 관리 도구의 필요성 ☆

요구사항 변경으로 인한 비용 편익 분석, 요구사항 변경의 추적, 요구사항 변경에 따른 영향 평가 

---

형상 관리 (Configuration Management)

애플리케이션 개발 단계에서 도출되는 프로그램, 문서, 데이터 등의 모든 자료를 형상 단위라고 하며, 이러한 자료의 변경을 관리함으로써 애플리케이션 버전 관리 등을 하는 활동이다.

(V1, V1.1, V2, V2.1.1 등..)

 

요구사항 할당 (Requirement Allocation)

- 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 활동이다.

- 식별된 타 구성 요소와 상호작용 여부 분석을 통하여 추가 요구사항을 발견할 수 있다.

 예) 네이버 

카페 - 글쓰기 기능, 판매기능.. 등

이메일 - 보내기, 삭제, 받기.. 등

이런 식으로 기능을 할당해서 분할하는 것으로 말한다.

 

정형 분석 (Formal Analysis)

- 구문(Syntax)과 형식적으로 정의된 의미(Semantics)를 지닌 언어로 요구사항을 표현한다.

- 정확하고 명확하게 표현하여 오해를 최소화할 수 있다.

- 요구사항 분석의 마지막 단계에서 이루어진다.

---

요구사항 확인 기법의 종류

1. 프로토타이핑(Prototyping)

2. 모델 검증 (Model Verification)

3. 요구사항 검토 (Requirement Reviews)

4. 인수테스트 (Acceptance Tests)

---

 

요구사항 확인 기법 - 프로토타이핑 

도출된 요구사항을 토대로 프로토타입(시제품)을 제작하여 대상 시스템과 비교하면서 개발 중에 도출되는 추가 요구사항을 지속해서 재작성하는 과정이다.

 

새로운 요구사항을 도출하기 위한 수단이다. 

소프트웨어 엔지니어 관점에서 요구사항을 확인하기 위한 수단으로 많이 사용되고 실제 구현 전에 잘못된 요구 사항을 적용하는 자원 낭비를 방지할 수 있다.

 

절차

1. 요구사항 분석 단계

2. 프로토타입 설계 단계

3. 프로토타입 개발 단계

4. 고객의 평가 단계

5. 프로토타입 정제 단계

6. 완제품 생산 단계

 

장점

1. 분석가의 가정을 파악하고 잘못되었을 때 유용한 피드백을 제공할 수 있다.

2. 문서나 그래픽 모델보다 프로토타입으로 이해하기 쉬워 사용자와 개발자 사이의 의사소통에 도움이 된다.

3. 요구사항의 가변성이 프로토타이핑 이후에 급격히 감소한다.

4. 빠르게 제작할 수 있으며, 반복 제작을 통하여 발전된 결과를 가져올 수 있다.

 

단점

1. 사용자의 관심이 핵심 기능에서 멀어질 수 있으며 프로토타입의 디자인이나 품질 문제로 집중될 수 있다.

2. 프로토타입 수행 비용이 발생한다.

3. 전체 범위 중 일부 대상 범위만 프로토타입을 제작하면 사용성이 과대 평가될 수 있다.

---

요구사항 확인 기법 - 모델검증

분석 단계에서 개발된 모델의 품질을 검증한다.

모델은 각각의 기능들을 배치한 것을 말한다.

 

정적 분석 (Static Analysis)

- 객체 모델에서 객체들 사이에 존재하는 Communication Path(의사소통 경로)를 검증하기 위해 사용한다.

멈춰져 있을 때의 구조(의사소통 경로)를 보는 것 (A라고 하는 기능과 B라고 하는 기능이 어떤 식으로 연결되어 있는지 )

- 명세의 일관성과 정확성을 확인 분석하는 도구이다.

 

동적 분석 (Dynamic Analysis)

- 실행해보는 것이다.

- 직접 실행을 통하여 모델을 검증하는 방식이다.

 

---

요구사항 확인 기법 -  인수 테스트

최종 제품이 설계 시 제시한 요구사항을 만족하는지 확인하는 단계이다.

인수 시 각 요구사항의 확인 절차 계획해야 한다.

 

종류

1. 계약 인수 테스트

2. 규정 인수 테스트

3. 알파 검사

4. 베타 검사

5. 사용자 인수 테스트

6. 운영 인수 테스트

---

문제 풀이

 

1. 소프트웨어 개발 시 사용자의 요구를 정확히 반영한 시스템 개발을 위하여 추출, 분석, 명세, 검증, 관리하는 구조화된 활동 집합을 무엇이라고 하는가?

요구공학 

 

2. 다음은 SWEBOK에 따른 요구사항 개발 프로세스이다. 빈칸에 알맞은 절차명을 쓰시오

도출(Elicitation) -> 분석(Analysis) -> ( ) -> 확인(Validation)

명세 

 

3. 소프트웨어 개발 방법 중 요구사항 분석 (Requirements Analysis)과 거리가 먼 것은?

① 비용과 일정에 대한 제약 설정

② 타당성 조사

③ 요구사항 정의 문서화

④ 설계 명세서 작성

 

4번

설계는 요구사항이 다파악된뒤 한다.

 

4. 사용자의 요구사항 분석 작업이 어려운 이유로 가장 거리가 먼 것은?

① 개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호이해가 쉽지 않다. 

② 사용자의 요구는 예외가 거의 없어 열거와 구조화가 어렵지 않다.

③ 사용자의 요구사항이 모호하고 부정확하며, 불완전하다.

④ 개발하고자 하는 시스템 자체가 복잡하다. 

 

2번

사용자는 비전공자이기 때문에 열거하기 어렵고, 구조화하기에도 어렵다. 

기능별로 관계가 어떤지는 개발자가 다 해야 한다.

 

5. 요구사항 분석 시에 필요한 기술로 가장 거리가 먼 것은?

① 청취와 인터뷰 질문 기술

② 분석과 중재 기술

③ 설계 및 코딩 기술

④ 관찰 및 모델 작성 기술

 

3번

구현단계에 필요한 기술이다.

 

1. 애플리케이션 개발 단계에서 도출되는 프로그램, 문서, 데이터 등의 모든 자료의 변경을 관리함으로써 애플리케이션 버전 관리 등을 하는 활동을 무엇이라고 하는가?

형상 관리

 

 

2. 애플리케이션 개발 과정에서 가장 먼저 해야 할 일은?

① 프로그램 코딩

② 프로그램 구현

③ 요구사항의 분석

④ 유지보수

 

3번

 

3. 요구사항 명세 기법에 대한 설명으로 틀린 것은?

① 비정형 명세 기법은 사용자의 요구를 표현할 때 자연어를 기반으로 서술한다.

② 비정형 명세 기법은 사용자의 요구를 표현할 때 Z 비정형 명세 기법을 사용한다.

③ 정형 명세 기법은 사용자의 요구를 표현할 때 수학적인 원리와 표기법을 이용한다. 

④ 정형 명세 기법은 비정형 명세 기법에 비해 표현이 간결하다.

 

2번

Z. VDM은 정형 명세 기법의 종류이다.

 

4. 프로토타입 모형에 대한 설명으로 가장 옳지 않은 것은?

① 개발 단계 안에서 유지보수가 이루어지는 것으로 볼 수 있다.

② 최종 결과물이 만들어지는 소프트웨어 개발 완료 시점에 최초로 오류 발견이 가능하다.

③ 발주자나 개발자 모두에게 공동의 참조 모델을 제공한다.

④ 사용자의 요구사항을 충실히 반영할 수 있다.

 

2번

최종 결과물에서 최초로 오류발견이 가능한 게 아닌

시제품을 통해 오류발견이 가능하다.

---