[소프트웨어 설계] 5. 요구사항 정의, 분석, 확인

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

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

② 타당성 조사

③ 요구사항 정의 문서화

④ 설계 명세서 작성

>> 정답 4번

** 설계 명세서 (현재 내가 공부한 것을 기초로) : 요구사항에서 사용할 것이 아니라 소프트웨어 설계(직접적으로 만들떄) 사용된다. 

 

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

① 청취와 인터뷰 질문 기술

② 분석과 중재기술

③ 설계 및 코딩 기술

④ 관찰 및 모델 작성 기술

 

>> 정답 3번

 

** 설계 및 코딩 기술은 요구사항을 분석한 후 이 요구사항에 맞게 설계할 때 필요한 기술이다.

나머지 항목은 요구사항(사용자의 요구)를 얻기 적합하다

 

 

 

16. 소프트웨어 개발 단계에서 요구 분석 과정에 대한 설명으로 거리가 먼 것은?

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

② 개발 비용이 가장 많이 소요되는 단계이다.

③ 자료흐름도, 자료 사전 등이 효과적으로 이용될 수 있다.

④ 보다 구체적인 명세를 위해 소단위 명세서 (Mini-Spec)가 활용될 수 있다.

 

>> 정답 2번

 

** 개발비용이 가장 많이 소요되는 단계는 유지보수 단계로 프로젝트 비용의 절반 이상을 차지한다. 

 

 

 

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

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

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

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

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

 

 

>> 정답 2번

 

** 정형 명세 기법은 수리, 논리에 기반하여 하드웨어 시스템 또는 소프트웨어 시스템을 명세, 개발, 검증하는 방법으로 관련자가 아니면 이해하기가 어렵다

비정형 명세 기법 비정형 명세는 상태, 기능, 객체 중심 명세 기법으로 의사전달 방법이 다양하다 이 때문에 모호성이 높다 

 

정형 명세 기법에는 Z, VDM, Petri-Net(모형기반), CSP, CCS, LOTOS(대수적방법)이 있으며
비정형 명세에는 FSM, Desicion table, ER 모델링, State chart, UseCase가 있다.

 

따라서 Z는 정형 명세 기법으로 사용하기 때문에 2번이 틀렸다

 

개인적으로 Z를 몰라도 풀 수 있는 문제였다. 정형과 비정형의 차이점을 기억하자!

 

 

3. 요구사항 검증(Requirements Validation)과 관련한 설명으로 틀린 것은?

① 요구사항이 고객이 정말 원하는 시스템을 제대로 정의하고 있는지 점검하는 과정이다.

② 개발 완료 이후에 문제점이 발견될 경우 막대한 재작업 비용이 들 수 있기 때문에 요구사항 검증은 매우 중요하다.

③ 요구사항이 실제 요구를 반영하는지, 문서상의 요구사항은 서로 상충되지 않는지 등을 점검한다.

④ 요구사항 검증 과정을 통해 모든 요구사항 문제를 발견할 수 있다.

 

>> 정답 4번

 

** 요구사항 검증은 요구사항이 제대로 적용되었는지 확인하는 작업이다. 검증 과정을 통해 부족한 요구사항을 확인할 수도 있으나 요구사항 단계를 다 지나서도 수정할 사항이 생기니.. 모든 요구사항 문제를 발견할 수는 없다. 

 

 

19. 요구 사항 정의 및 분석·설계의 결과물을 표현하기 위한 모델링 과정에서 사용되는 다이어그램(Diagram)이 아닌 것은?

① Data Flow Diagram

② UML Diagram

③ E-R Diagram

④ AVL Diagram (이진트리)

 

 

>> 정답 4번

 

요구사항 분석에 사용하는 기능 모델링 기법
1. 데이터 흐름도 DFD
2. 자료사전 DD
3. UML
4. 유스케이스 usecase
5. 시퀀스 다이어그램 sequence diagram

 

 

** 차라리 아닌 것을 기억하자 AVL 은 이진트리다 자료구조할 때 등장한다.

 

 

 

20. 요구 분석(Requirement Analysis)에 대한 설명으로 틀린 것은?

① 요구 분석은 소프트웨어 개발의 실제적인 첫 단계로 사용자의 요구에 대해 이해하는 단계라 할 수 있다.

② 요구 추출(Requirement Elicitation)은 프로젝트 계획 단계에 정의한 문제의 범위 안에 있는 사용자의 요구를 찾는 단계이다.

③ 도메인 분석(Domain Analysis)은 요구에 대한 정보를 수집하고 배경을 분석하여 이를 토대로 모델링을 하게 된다.

④ 기능적(Functional) 요구에서 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 성능, 보안, 품질, 안정 등에 대한 요구사항을 도출한다.

 

 

>> 정답 4번

 

요구사항 분석에서 기능은 소프트웨어 자체의 기능을 의미한다. 4번의 경우 기능적 요구가 아닌 비기능적 요구에 해당한다.

비기능적 요구는 기능들에 대한 조건, 제약사항, 시스템 속성 등에 관한 요구사항이다.

 

 

 

14. 다음 중 요구사항 모델링에 활용되지 않는 것은?

① 애자일(Agile) 방법

② 유스케이스 다이어그램(Use Case Diagram)

③ 시퀀스 다이어그램(Sequence Diagram)

④ 단계 다이어그램(Phase Diagram)

 

 

>> 정답 4번 

 

** 아닌 것을 기억하자 단계다이어그램

 

 

** 개념 모델 종류

유스케이스 다이어그램 use case diagram

데이터 흐름 모델 data flow model

상태 모델 state model

목표 기반 모델 goal based model

사용자 인터렉션 user interations

객체 모델 object model

데이터 모델 data model

 

 

 

7. 요구사항 분석이 어려운 이유가 아닌 것은?

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

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

③ 사용자의 요구사항이 모호하고 불명확하다.

④ 소프트웨어 개발 과정 중에 요구사항이 계속 변할 수 있다.

 

 

>> 정답 2번

 

** 사용자의 요구는 모호하고 부정확하며 기능을 표현하기 어려운 경우도 있다. 따라서 예외도 있어서 열거와 구조화가 어렵다

 

---

https://www.youtube.com/watch?v=qr21JYt8ZI8 

---

개발시 필요한 시스템과 환경
개발할 때는 사용자의 요구사항

요구사항 > 원하는 서비스에 대한 설명 및 제약사항

기능 : 원하는 기능 자체에 대한 서술
비기능 : 기능에 대한 품질, 제약사항 서술
사용자 : 사용자 입장의 쉬운 표현
시스템 : 개발자 입장의 전문용서 사용

도출 - 분석 - 명세 - 확인

도출 : 요구사항 수집
이해관계자 간의 의사소통 중요
> 인터뷰, 브레인 스토밍, 프로토타이핑, 유스케이스


분석 : 요구사항 분석 단계
도출된 요구 사항의 타당성 조사
요구사항을 특정 기준으로 분류
분류된 기준들을 단순화 시켜 개념적으로 표현하기 >> 개념 모델링
각각의 요구 사항을 만족시키기 위 해 요구 사항을 할당하고

* 개념 모델링 : 분석 단계 중 한 부분
요구사항을 단순화하여 개념적으로 표현하는 일
객체(개체) 간의 관계와 종속성 분석
다양한 관점으로 표현할 수 있음
주로 UML 사용

 

** 개념 모델 종류

유스케이스 다이어그램 use case diagram

데이터 흐름 모델 data flow model

상태 모델 state model

목표 기반 모델 goal based model

사용자 인터렉션 user interations

객체 모델 object model

데이터 모델 data model

 

요구 사항이 충돌이 일어나는 경우 요구 사항을 협상한다.
따라서 우선순위가 있다면 문제 해결할 수 있다.

마지막 분석 단계로  정형 분석을 해서 
구문과 의미를 갖는 언어를 이용하여 수학적 기호로 표현한다.


명세 : 문서화
개발 승인을 위해 문세화하는 것이기 때문에 
명확하고 이해하기 쉽게 기록하자


확인 : 요구사항 검증 단계
명세서 검증
형상관리 수행

형상관리는 작업 결과물을 정리 및 관리하기

검증 방법

요구사항 검토 > 고객 대표가 꼭 포함되어 훑어보기
프로토 타입 > 지속적으로 프로토 타입을 작성하여 빠른 제작 및 사전 피드백을 받을 수 있다. 다만 비용이 많이 들고 프로토 타입에 몰두할 수 있다.
모델검증 > 요구사항 충족 여부를 검증한다. 실행 검증이 아니라 논리적인 검증(정적검증)만 한다.
인수테스트 > 사용자 입장에서 요구 사항 해결되었는데 확인하는 방법 (계획표필요)